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

python-dateutil encoding issues under python 3.3 #2373

Closed
aconley opened this issue Sep 3, 2013 · 8 comments
Closed

python-dateutil encoding issues under python 3.3 #2373

aconley opened this issue Sep 3, 2013 · 8 comments

Comments

@aconley
Copy link

aconley commented Sep 3, 2013

@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.

 import sys
 print(sys.getdefaultencoding())
@mdboom
Copy link
Member

mdboom commented Sep 3, 2013

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)...

@aconley
Copy link
Author

aconley commented Sep 3, 2013

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.

@mdboom
Copy link
Member

mdboom commented Sep 3, 2013

Direct link to track progress:

https://bugs.launchpad.net/dateutil/+bug/1208910

@mrterry
Copy link
Contributor

mrterry commented Sep 4, 2013

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.

@mdboom
Copy link
Member

mdboom commented Sep 4, 2013

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.

@mrterry
Copy link
Contributor

mrterry commented Sep 4, 2013

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 python-dateutil==2.0 as the correct dependency if dateutil isn't already installed.

its a bit of a hack, but until dateutil gets its py33 house in order, I don't see alternatives.

@aconley
Copy link
Author

aconley commented Nov 5, 2013

I just got a notification that this has been fixed in python-dateutil trunk.

@tacaswell
Copy link
Member

It sounds like this has been fixed upstream. @mdboom Please re-open if I misunderstood.

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

4 participants