search

avian2 / unidecode

ASCII transliterations of Unicode text - GitHub mirror
https://pypi.python.org/pypi/Unidecode
GNU General Public License v2.0
516 stars 62 forks source link

syntax error Unidecode 1.3.5 on python 3.5 #82

Closed remi-filament closed 1 year ago

remi-filament commented 1 year ago

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 commented 1 year ago

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

avian2 commented 1 year ago

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 commented 1 year ago

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 https://github.com/avian2/unidecode/pull/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 commented 1 year ago

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,