Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

My way of remembering str -> decode; (s->d); sad. sad that I have to remember this and that it is still the "future of the language" despite significant and ongoing resistance.

EDIT: This last line of the article pretty much sums it up: "We structured the transition thinking the community would come along with us in leaving Python 2 behind, but that turned out not to be the case and instead we have taken some more time and are using a Python 2/3 compatible subset of the language to manage the transition."

I wonder if python 3.6 or 3.7 will acquiesce to this and give an option for something like "from __past__ import str" like we have for __future__ in 2.7 to make these backward incompatibilities easier to deal with.



> from __past__ import str

As the past did not contain the __past__ that is not going to work.


Excellent point. I guess the shims that collinmanderson references would be the ideal.


It would be nice if future python 3.x brought back shims for unicode(), iteritems, iterkeys, itervalues, xrange(), etc. That could help make the transition easier.


Why? What possible reason would there be to use the old behavior, except for laziness?


Because I'd like to be able to use the googleads Python client library within Python 3 without needing to fix 62,000 lines of code? I guess you could call that laziness if you want.


You just simply use it, if specific argument require python 2 sting you simply call bytes() on it.

For example

old_function(bytes(myarg))

if it needs to be a literal:

old_function(b"literal")

That's what I do, and works for me so far.


Nice. Thanks for attributing a negative personality trait as the only reason someone would prefer any other way.


I don't know if it's been edited since you posted this, but at the moment, the comment is a question asking why somebody would want this other than laziness.


True. I guess some would consider this a positive personality trait in a programmer. I think that's only for system design though (lazy for minimizing future effort required).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: