4 ms·

You definitely want 2.7. The best learning material is in 2.7 (LPTHW), all libraries support 2.x but not 3.x, no PyPy that's not in beta, performance on 3.x is

You definitely want 2.7. The best learning material is in 2.7 (LPTHW), all libraries support 2.x but not 3.x, no PyPy that's not in beta, performance on 3.x is less than 2.7 and all online hosts are on 2.7 or earlier (Azure, Google App Engine, etc). Most of the resources available online for help are 2.x. Not to mention the unicode implementation is broken. I was just talking to a Russian user (someone you'd assume would want unicode by default), and Python3 not operating on bytes by default is a mess. He can't move to Python3 due to how unicode is implemented. print sys.getdefaultencoding() # ascii print locale.getpreferredencoding() # cp1251 print sys.stdout.encoding # cp866 print sys.getfilesystemencoding() # mbcs #~ print u"кодировочка!" #~ print u"кодировочка!".encode('cp866') #~ print unicode(u"кодировочка!", 'cp1251') #~ os.rename ('b', u'б') In most things in life, you'd always want the 'latest version', it would be a no-brainer. I wouldn't even bet on the transition to Python3 succeeding until it has- it's been 6 1/2 years already. Use 2.7 and then move to 3.x when and if it ever makes sense. It won't be hard at all to switch as a user, that's not the problem.

kbd 12y ago
> and Python3 not operating on bytes by default is a mess. I'm not arguing that it's not, but I don't how your examples support your point. Would you please explain how your examples show that "strings are unicode" is broken on Python 3? FWIW, here's what I get: Python 2: >>> import sys, locale >>> print(sys.getdefaultencoding()) ascii >>> print(locale.getpreferredencoding()) UTF-8 >>> print(sys.stdout.encoding) UTF-8 >>> print(sys.getfilesystemencoding()) utf-8 In Python 3, the only difference is: >>> print(sys.getdefaultencoding()) utf-8
viraptor 12y ago
> Not to mention the unicode implementation is broken. Can you provide more details? The one thing that python3 did well is actually fixing the unicode/str mixup. You posted some lines of code, but didn't tell exactly what's wrong with it. > Python3 not operating on bytes by default is a mess Why not just use the b'' prefix then and be explicit? > can't move to Python3 due to how unicode is implemented I'd like to see the bugs he raised against python 3 regarding this. There should be no difference in what you can and cannot do using python 2/3. I don't want to call BS on this, but... please provide some specific issues if you're claiming py3 is not usable.
ak217 12y ago
Actually, Unicode handling is broken on Python 2, and works just fine on Python 3. I'm also a Russian user :) Your code doesn't make any sense. Care to comment on what it means? Guido didn't do us any favors with his migration strategy, but Python 3.4 is a substantially better and more modern language, so I would suggest developing on it (it's supported out of the box on Ubuntu 14.04 LTS, for example). It's true that app platform providers have not caught up yet, though.
- dekhn 12y ago
  Yeah. I moved all code dealing with Unicode (in particular, parsing iTunes track names) to Python 3. That was the one part of the language that worked well for me- instead of utf8 codec hell, things just worked.
zokier 12y ago
I was going to argue that the vastly improved Unicode support in Py3k would be reason enough to use it. And this is coming from a person who is bilingual with both languages using different, non-7bit-ascii alphabets.
rspeer 12y ago
cp866 and cp1251? Something is seriously wrong there. This Russian user's OS is using two different obsolete 1-byte encodings, and claiming not to know anything about UTF-8. Is he running Python in, say, a Command Prompt window that's maintaining compatibility with a Russian-localized version of MS-DOS? I can see how he can't move to Python 3, because Unicode support in his environment is basically impossible. That's a deeper problem than just Python. If he's been writing Python 2 code that deals with Russian text, it's probably producing mojibake when run on any machine but his own!

kbd 12y ago

> and Python3 not operating on bytes by default is a mess. I'm not arguing that it's not, but I don't how your examples support your point. Would you please explain how your examples show that "strings are unicode" is broken on Python 3? FWIW, here's what I get: Python 2: >>> import sys, locale >>> print(sys.getdefaultencoding()) ascii >>> print(locale.getpreferredencoding()) UTF-8 >>> print(sys.stdout.encoding) UTF-8 >>> print(sys.getfilesystemencoding()) utf-8 In Python 3, the only difference is: >>> print(sys.getdefaultencoding()) utf-8

viraptor 12y ago

> Not to mention the unicode implementation is broken. Can you provide more details? The one thing that python3 did well is actually fixing the unicode/str mixup. You posted some lines of code, but didn't tell exactly what's wrong with it. > Python3 not operating on bytes by default is a mess Why not just use the b'' prefix then and be explicit? > can't move to Python3 due to how unicode is implemented I'd like to see the bugs he raised against python 3 regarding this. There should be no difference in what you can and cannot do using python 2/3. I don't want to call BS on this, but... please provide some specific issues if you're claiming py3 is not usable.

ak217 12y ago

Actually, Unicode handling is broken on Python 2, and works just fine on Python 3. I'm also a Russian user :) Your code doesn't make any sense. Care to comment on what it means? Guido didn't do us any favors with his migration strategy, but Python 3.4 is a substantially better and more modern language, so I would suggest developing on it (it's supported out of the box on Ubuntu 14.04 LTS, for example). It's true that app platform providers have not caught up yet, though.

dekhn 12y ago
Yeah. I moved all code dealing with Unicode (in particular, parsing iTunes track names) to Python 3. That was the one part of the language that worked well for me- instead of utf8 codec hell, things just worked.

zokier 12y ago

I was going to argue that the vastly improved Unicode support in Py3k would be reason enough to use it. And this is coming from a person who is bilingual with both languages using different, non-7bit-ascii alphabets.

rspeer 12y ago

cp866 and cp1251? Something is seriously wrong there. This Russian user's OS is using two different obsolete 1-byte encodings, and claiming not to know anything about UTF-8. Is he running Python in, say, a Command Prompt window that's maintaining compatibility with a Russian-localized version of MS-DOS? I can see how he can't move to Python 3, because Unicode support in his environment is basically impossible. That's a deeper problem than just Python. If he's been writing Python 2 code that deals with Russian text, it's probably producing mojibake when run on any machine but his own!