-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
python-dateutil encoding issues under python 3.3 #2373
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
Comments
For completeness, is there a link to your patch to python-dateutil in a tracker somewhere? (Or was is just a private e-mail... I can't seem to find any sort of tracker for python-dateutil)... |
It isn't exactly the easiest thing to find, but in the documentation there is a link to their development page: https://launchpad.net/dateutil look at the "Latest Bugs Reported" section. My 'patch' is just text in the report. |
Direct link to track progress: |
I have seen this bug in my mac-testing project. On MacOS 10.8, with python 3.3 binaries from python.org/system/macports/brew. All of them fail to install vanilla python-dateutil 2.1. |
Hmm... The best outcome is that this is patched in python-dateutil. If not, it's hard to imagine what we could do outside, but I'm open to ideas. |
vanilla dateutil 2.0 works just fine on 3.3. IIRC, dateutil 1.5 is python2 only. 2.0 is python3 only. 2.1 uses six to get both python2 and python3 support (well, nearly). as far as MPL goes, we should be able to detect the python version and then specify its a bit of a hack, but until dateutil gets its py33 house in order, I don't see alternatives. |
I just got a notification that this has been fixed in python-dateutil trunk. |
It sounds like this has been fixed upstream. @mdboom Please re-open if I misunderstood. |
@mdboom asked me to file this here, even though it isn't really a problem with matplotlib, but rather with one of it's dependencies.
The current version of python-dateutil, a dependency of matplotlib, doesn't install in python 3.3 if your default encoding is ascii. The problem is that setup.py reads a file containing a non-ascii character without specifying the encoding, and, for whatever reason, python 3.3 seems to be rather more sensitive to this sort of thing than 3.2. I have no idea if the same is true of python 3.4.
This is pretty easy to fix (by hacking setup.py to use the encoding option for python >3, or by changing your default encoding -- although some people seem to think the latter is a very, very bad idea), and I've submitted a patch -- but it seems to have been quite a while since the python-dateutil team responded to any bug reports.
Note this won't happen if your default encoding is something like utf-8, so this should only affect some users.
The text was updated successfully, but these errors were encountered: