Python 3 Is Close To Becoming The Default In Fedora 22

[TheBlackCat]

Python2 supports utf-8 just fine.

The core language does, as a separate type. The problem is that lots of modules, particularly third-party ones, explode when given unicode because python 2 can behave unpredictably or raise an exception when particular unicode is combined with strings in particular ways.

Print function is available in Python2 with a future import.

Yes, so much fun putting that in every single module you write and enter it every single time you start the python REPL (ipython can help with the latter if you manually configure it to import at startup, although that slows startup times).

[nanonyme]

The core language does, as a separate type. The problem is that lots of modules, particularly third-party ones, explode when given unicode because python 2 can behave unpredictably or raise an exception when particular unicode is combined with strings in particular ways.


Yes, so much fun putting that in every single module you write and enter it every single time you start the python REPL (ipython can help with the latter if you manually configure it to import at startup, although that slows startup times).

Well, the big change between Python2 and Python3 is no more implicit encoding and decoding between unicode objects and bytestrings. Just that Python2 strings are bytestrings while Python3 strings are unicode objects is honestly smaller. And Python3 does change many API's for which bytestrings make more sense to use unicode objects because consistency beat practicality in Guido's mind at the time. It is unfortunate these incorrect changes are so hard to revert without a Python4 which is not going to happen in foreseen future

[TheBlackCat]

And Python3 does change many API's for which bytestrings make more sense to use unicode objects because consistency beat practicality in Guido's mind at the time.

Such as? Lots of APIs use bytes where they make sense, and there will always be disagreements about whether bytes are better for a particular API or unicode is better, so judgement calls have to be made. I know there was some cases where there was the opposite issue, where frome a purely technical standpoint bytes may have been more correct, but it was felt that unicode was more convenient for users (practicality beats purity), but that is almost the opposite of what you are talking about.

Whatever your feeling about particular APIs, at the end of the day, the big advantage in this regard is that in Python 3 (but not Python 2), unicode is unicode and bytes are bytes. They are clearly, cleanly, and explicitly distinguished, and when you try to mix them you need to be explicit about it, without all the unexpected breakage in obscure encoding-specific corner cases.

[Togga]

Or you could just use list comprehensions.


Just things I have encountered:

1. Division is handled sanely without having to import from __future__
2. No more long vs. int
3. keyword-only arguments
4. a, b, *c = (1, 2, 3, 4, 5) (this may be even more flexible in 3.5)
5. Ranges are lazy (but still indexable), saving memory
6. Dict methods use views, saving memory
7. super() works
8. __pycache__ and supporting multiple python version .pyc files and .so files
9. yield from
10. 0100 != 64
11. statistics module
12. Pool, popen, and assertRaises context managers
13. pool.startmap
14. unittest.assertWarns and unittest.assertCountEqual
15. high-performance decimals

Stuff coming in 3.5:

1. math.nan and math.inf
2. type annotations

I see no justification for python3 here. A number of bugs (?) and annoyances that should (and is?) fixed or implemented in python2? There were really never any justifications for non-backwards-compatible changes to Python2.
For statistics, I recommend scipy instead (or R).