Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

syntax error Unidecode 1.3.5 on python 3.5 #82

Closed
remi-filament opened this issue Sep 29, 2022 · 4 comments
Closed

syntax error Unidecode 1.3.5 on python 3.5 #82

remi-filament opened this issue Sep 29, 2022 · 4 comments

Comments

@remi-filament
Copy link

Hi, I updated my server today with latest and I now get the following error :

   File "/usr/local/lib/python3.5/dist-packages/unidecode/__init__.py", line 151
     __import__(f'unidecode.{file.stem}', globals(), locals(), ['data']).data,
                                       ^
 SyntaxError: invalid syntax

I am running python 3.5 on debian stretch.
Forcing previous version 1.3.4 solves the issue.
I am not sure if this means that Python 3.5 is not supported anymore on newest version or if there is an error in latest Unidecode version ?

@remi-filament
Copy link
Author

Issue seems related to f-strings which are only supported since Python 3.6

@avian2
Copy link
Owner

avian2 commented Sep 29, 2022

Thank you for reporting this!

As far as I can see the wheel release for 1.3.5 got built from a wrong git branch. It contains different code compared to the .tar.gz package.

I've yanked Unidecode 1.3.5 from PyPi and I'm investigating how this happened.

Downgrade back to 1.3.4 for now.

@avian2
Copy link
Owner

avian2 commented Sep 30, 2022

I've released Unidecode 1.3.6 now that should have the problem with the Wheel package fixed.

Can you verify that it works for you?

The Wheel package (but not .tar.gz) for 1.3.5 on PyPi contained code from #79 merged in. Apart from breaking Python 3.5 compatibility due to f-strings, this was benign, since the change only added some new functions and didn't affect any existing code.

I did not intend to merge this pull request in this release. I definitely was experimenting and testing this code in a separate branch so I had it on my computer, but I can't figure out how it ended up in a release Wheel. Especially puzzling is the fact that .tar.gz contained the correct code. The script that I'm using builds both a Wheel and .tar.gz at the same time with python3 setup.py sdist bdist_wheel. I can't reproduce the steps that led to this situation. My only explanation is that Wheel building step failed for some reason and an old build that was left in its place was then published.

Before publishing I was only running checks on the .tar.gz, which is why I didn't notice that the Wheel contained unexpected changes. I've amended my scripts now so that I'm also checking changes in the published Wheel.

@remi-filament
Copy link
Author

Thank you @avian2, I am afraid I cannot help understanding why this happened, but I tested again with 1.3.6 and I can report that the issue disappeared !
Thank you for your reactivity !
Best Regards,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants