fails to install in python3 about fileseq HOT 12 CLOSED

fileseq hasn't yet been tested on python3

from fileseq.

I'm building an experimental python 3 environment to see where out pipline breaks. I will test fileseq and report back :-)

from fileseq.

At some point we will have to look at Python 3 support in this library. It hasn't been a driving force yet since our studio is still on Python 2

from fileseq.

we are on python 2 too but we started to run integration tests on python 3 to see what needs to be fixed.

from fileseq.

I started work on a python 3 branch:
https://github.com/donalm/fileseq/tree/63_python3

The tests are passing but apart from that I haven't run anything with it yet. I may get some more time for that in the coming days.

There are a couple of places where behaviour is changed even for Python 2, and you can see that I've modified a couple of tests to expect six.text_type instead of just 'str', whatever 'str' might be.

The utils.asString method now always returns a six.text_type (i.e. a unicode string), whereas in the past if you gave it bytes it would happily return bytes. The code I added assumes that the encoding for any bytes it encounters is utf-8.

I think this is a fair approach but reasonable people could disagree.

There are still many places in the code where values get cast to 'str'. Since str(x) has a completely different outcome on the two pythons, I suspect we might need more coverage to pick up errors (or at least ambiguities) that are being missed.

from fileseq.

Thanks for starting this work! I want to take a deeper look at what you have done so far, but I also want to start some conversations about the points you have made.

Ideally, if possible, I would love to see this remain API compatible so that we don't have to maintain two version streams for a while. I haven't used six before, but it looks like text_type is just directly unicode or str. And I don't see it as a huge deal if we started returning unicode in python2 instead of str.

One thing we should make sure is passing is the ability to preserve custom string classes:
https://github.com/sqlboy/fileseq/blob/master/test/test_unit.py#L437
That test was misnamed and I just fixed it :-)

from fileseq.

Hey - no worries man, thanks to you guys for sharing this project.

Yeah correct: the six.text_type basically means 'unicode' but unfortunately that keyword wasn't brought forward into PY3

I think returning unicode objects will be kinda unavoidable in PY3. Most folks will have code that creates string literals, and if we return bytes, they're going to get a shock when they substitute bytes into unicode strings:
"one %s three" % (b"two",)
"one b'two' three"

Oops.

So I don't see an easy way to avoid returning unicode by default. Like you say though - I think for most users that should be no problem. It's probably worth a major-version release but otherwise ¯_(ツ)_/¯

Fortunately on PY2, if you substitute unicode into a bytes object, it looks like the interpreter just assumes you want utf-8. It seems to do the intuitive thing.

One question - the code seems to lean towards being optimized for performance in places. Are there some users for whom this is an important criterion? For example; I replaced some bytearray-manipulation with unicode-string-manipulation, but I didn't look into the performance hit.

I'm pretty sure it was in some code that's only reached by {left|right} style clauses, so it's probably not going to be too much of a burden for most users, but I'm curious to know if that's important.

from fileseq.

from fileseq.

@donalm, do you want to create a WIP merge request so we can track comments? I started to look at this but there isn't a good place to make notes yet. Unless you want me to make comments in the individual commits in your fork?

from fileseq.

Sure - done. Careful not to merge the unicode filenames I added to the test data. It looks like Pip will be unable to install the package as long as they exist.

from fileseq.

Thanks! Will continue discussion in #67

from fileseq.

Closing as this has been fixed with the python3 support that was merged to master.

from fileseq.