search

NSLS-II / metadatastore

DEPRECATED: Incorporated into https://github.com/NSLS-II/databroker
Other
2 stars 11 forks source link

from __future__ import unicode_literals: good or bad? #209

Closed ericdill closed 8 years ago

ericdill commented 8 years ago

In scikit-beam we removed all the from __future__ import unicode_literals. Should we do the same here?

danielballan commented 8 years ago

LMGTFY: http://python-future.org/unicode_literals.html

Before @CJ-Wright diligently puts PRs into more projects we should make a decision on this. To my reading, importing uicode_literals is better than the alternative (putting u in front of all the strings) for any codebase that has always supported Python 3. Seems like we should leave it in. Did whoever removed it from scikit-beam give a reason?

klauer commented 8 years ago

Correct me if I'm wrong, but I don't think any of the source files in this repository have non-ascii strings or even specify any encoding.

ericdill commented 8 years ago

We included unicode_literals in scikit-beam basically as a copy/paste from matplotlib but removed it during a refactor when @tacaswell mentioned that it was really more trouble than its worth. IIRC it doesn't really prevent any bugs in python 3 and it introduces bugs in python 2. @tacaswell can probably speak better to this.

ghost commented 8 years ago

@klauer pymongo specifies some encoding

klauer commented 8 years ago

@arkilic I mean in the form of https://www.python.org/dev/peps/pep-0263/

danielballan commented 8 years ago

@klauer I think you are correct. Which is why adding a blanket unicode_literals import is the right choice here: it doesn't break anything (there's nothing to break) and it guards against accidentally adding any strings that, without that import, would be interpreted differently by Python 2 and 3.

danielballan commented 8 years ago

Of course, if the files never end up with any non-ASCII strings this entire discussion is moot, but I'm not seeing the argument for going through and actively removing these imports.

tacaswell commented 8 years ago

Where the unicode literals breaks things is if you are doing fun things with programtically creating classes (as type in py2 does not cope with unicodes) and if you are doing a lot of string based file I/O (At the time we pulled it out of skbeam I was dealing with some other mpl / unicode related headache + that was around when I was working on the vistrails auto-wrapping code which involves a lot of programmatic class generation, hence my pessimism).

At this point if it is not causing harm it is not worth the effort to pull it out.