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
Support for certain unicode literals depends on sys.maxunicode #350
Comments
Just a note:
And then it works for me in a standard Python 2.7.14 on linux (openSUSE). I don't have such a machine available, so I'm not able to check if this would be possible. btw, https://pythonclock.org/ says python 2 will retire in 1 month 11 days... |
Yep, agree about the assert. It's crashing before it gets to that point, though. If you want to test on your own machine, you can get such a Python by compiling with I know that Python 2 will be retired soon, but I think many of my users still use Python 2, so I need to keep supporting it for some of my applications. |
I think #351 fixes it. |
We released 5.2: https://pypi.org/project/PyYAML/5.2/ edit: oops, wrong comment, as the fix was not in 5.2 |
The plan is to fix in 5.3 (or earlier, if there's a 5.2.1)? |
Yes. I hope it won't be too long until 5.3 |
released https://pypi.org/project/PyYAML/5.3/ |
It seems that support for unicode literals over code point
0xffff
, introduced in cf1c86c, depends onsys.maxunicode
. So for example, it'll work with standard Python 3 builds, but won't work with standard Python 2 builds, wheresys.maxunicode
is2**16-1
(built with UCS-2).Here's a simple test program that works on Python 3, but not on a standard Python 2 build:
It produces the following error on Python 2:
Is there any reasonable way to support this functionality on Python 2 as well?
The text was updated successfully, but these errors were encountered: