
Python 3 Features - Sami_Lehtinen
https://asmeurer.github.io/python3-presentation/slides.html
======
ak217
Very nice and fun presentation.

Another feature not in this talk is function annotations
([http://legacy.python.org/dev/peps/pep-3107/](http://legacy.python.org/dev/peps/pep-3107/))
and things they enable like optional runtime type checking
([https://github.com/kislyuk/ensure#enforcing-function-
annotat...](https://github.com/kislyuk/ensure#enforcing-function-
annotations)).

Also, as a library developer, I wanted to highlight some facts from experience
with Python 2/3 development:

\- Travis CI is an invaluable resource for running your test suite on a number
of Python versions at once. It has deep integration with GitHub, and together
they make the development flow a lot less cumbersome.

\- Writing to a subset of Python that is compatible with both 2.7 and 3.3+ is
not terribly hard. Lots of resources exist out there, including Armin's
porting guide, six, python-future, and eight
([https://github.com/kislyuk/eight­](https://github.com/kislyuk/eight­)).

\- Contrary to some opinions out there, Python 3 actually makes working with
Unicode a lot less perilous than Python 2, mostly by having a sane encoding
default (UTF-8 instead of Python 2's ascii) and not doing automatic
bytes/unicode coercion.

\- PyPy is awesome and just released their first non-beta Python 3 version.
Please donate!

------
shadowmint
I guess I'm in the minority here of being a full time python developer and
thinking 1) these are all totally unexciting for day to day python use, and 2)
the only actually interesting one (async io) is covered with:

    
    
        Not going to lie to you. I still don't get this.
    

...which is not really a call to arms for py3 as far as I'm concerned.

(pypy support and potentially having one binary running 2.7 _and_ 3.x at the
same time is _much_ more exciting)

~~~
jlarocco
I agree. I use Python3, but for none of the reasons given. Some of the advice
was just flat out bad, IMO.

Like replacing

    
    
        def wat(a, b, *args)
    

with

    
    
        def wat(*args)
            a, b, args = *args

~~~
mewwts
I'm sure (I hope) that was just a proof of concept. It's a horrible idea!

~~~
eliben
No one in the Python community is advocating the "replacement". I think it's
just an example of new syntax.

------
pixelmonkey
I think asyncio + "yield from" is the killer feature for Python 3.x right now.
(It's covered briefly in these slides.)

Beazley gives it a very detailed treatment in this amazing YouTube video,
which covers not only asyncio's internal implementation, but also explains
what coroutines are and when you'd actually benefit from using them in async
programming:

[https://www.youtube.com/watch?v=5-qadlG7tWo](https://www.youtube.com/watch?v=5-qadlG7tWo)

~~~
ibotty
how does asyncio deal with resource management, a very hard problem whenever
you invent lazy io?

------
stephendicato
Chained exceptions* is fantastic. I've found myself handling a specific set of
exceptions, logging/printing various pieces of the traceback, and continuing
on more times that I'd care to think about. This provides the level of context
to the exception I'd have wanted.

Combined with fine grained `oserrors`, that's awesome. I have so much magic
`errno` checking code over the years.

* [https://asmeurer.github.io/python3-presentation/slides.html#...](https://asmeurer.github.io/python3-presentation/slides.html#37)

------
hk__2
> Feature 0: Matrix Multiplication

It’s not really a feature, it’s an operator that can be overloaded. That is,
instead of using `mymodule.dot(a, b)`, you can use the much less readable `a @
b`.

> Feature 1: Advanced unpacking

> Refactor your functions

The given example is a _bad_ refactoring, because it moves away the function’s
self-documentation.

~~~
fddr
> It’s not really a feature, it’s an operator that can be overloaded. That is,
> instead of using `mymodule.dot(a, b)`, you can use the much less readable `a
> @ b`.

I disagree with you, and think it's definitely a feature. If you are doing
scientific computing it can be much more readable to use infix overloaded
operators. What is better, `np.dot(x.T(), np.dot(M, x))` or `x.T() @ M @ x`? I
find the second much more readable.

I get it that operator overloading can be abused and lead to unreadable code,
but in some use cases it is a godsend.

~~~
hk__2
That’s true, but you already can overload other operators like __mul__ to have
`x.T() * M * x`.

~~~
dagw
__mul__ has been used for elementwise multiplication in numerical python for
the past 18 years or so. You can argue if it was a good choice or not, but
it's a bit too entrenched to change now.

------
Choronzon
Too little too late and not good enough,very little offered for splitting the
user base. Python in the long run is badly positioned as

1\. Moores law partytime is over. Performance matters again and the language
has significant upper limits on speed.PyPy is not fast enough and further
splits the user base.

2.As performance matters again concurrency matters more,concurrency in python
in horribly implemented.

3.AsyncIo, What the hell am I even looking at? Gevent is vastly simpler than
this.

It is a pity as it is one of the cleanest languages around and a joy to code
in. But programmer productivity is more important than speed you say? We in
many cases that is true but languages like go and Julia can offer both so why
program in a slow language which you may have to replace later when its almost
as easy to take another option and have everything?

~~~
chrismonsanto
> PyPy is not fast enough and further splits the user base.

There is no split?

> Gevent is vastly simpler than this.

I prefer asyncio's explicitness to gevent's monkey-patch-and-pray-it-
doesn't-block semantics. Also, the asyncio approach makes it very clear when
you have released the "lock" on your state--it happens every time you yield
from your coroutine. The gevent approach is to hide these synchronization
points, which I think is a bad policy. For what it's worth this latter
objection is one of the main reasons asyncio is the way it is--GvR had been
bitten before by implicit yields.

~~~
ekimekim
If you're needing to think carefully on what code you call might cause a
switch and what won't, you're already doing it wrong. Instead of treating
gevent like coroutines with less predictable ordering, treat it like threads
with more predictable ordering. You know that basic operations (eg. checking
if something is a certain value, or assigning a variable) won't cause a
switch. So you can do two of those in a row, without thinking about race
conditions. Anything beyond that...use a lock (or a queue, or any of the other
provided concurrency primitives).

~~~
thristian
Well, thanks to operator overloading, comparisons or assigning a variable (to
a property of an object) _can_ cause a switch. If you really need to get a
mental model of what your code is doing, or could do under sufficiently
unusual circumstances, gevent doesn't really provide any guarantees beyond raw
threading.

Glyph (of Twisted fame) wrote a good blog-post about it:
[https://glyph.twistedmatrix.com/2014/02/unyielding.html](https://glyph.twistedmatrix.com/2014/02/unyielding.html)

------
latiera
I find no reason whatsoever to move to Python 3. These "features" offer
nothing of substance to me and my typical workload with Python. Finally,
Unicode handling in Python 3 is a huge mess.

No thanks.

~~~
ekimekim
I must admit, some of these features would be very nice. I'm sick of manually
dealing with __kwargs just because I wanted a keyword arg AND a *args.

...but you're right, it's not worth the unicode handling.

------
doreo
Later: "10 awesome libraries you can't use because they haven't been ported to
Python 3"

~~~
scrollaway
Can you cite me 10 awesome and useful libraries that haven't been ported to
Python 3 and don't have reasonably equal alternatives?

I know there are some critical libraries to some niches who don't particularly
care about recent versions. I know there's a fair amount of libraries that
don't work on Python 3 purely because the author used print instead of
print(). I know there are _apps_ that can't port to Python 3 because they were
designed with some core Python 2 functionality a decade ago (usually
unicode/bytes related).

None of these matter to real world devs. User-facing apps don't matter, easy-
to-port libs don't matter (fork & fix), niche libs don't matter (if your niche
doesn't care about Python 3, you're either here to troll or you're not
actually here).

I know it's very "in" to say that Python 3 is dead-on-arrival and all that but
it's simply untrue. Anyone who uses a Python 3-based Linux distribution will
understand that. Most new devs use Python 2 because they are too lazy to
install Python 3 and assume their code won't work; and as soon as they hit a
SyntaxError in print they complain that "Python 3 is hard".

Here are the facts:
[https://python3wos.appspot.com/](https://python3wos.appspot.com/)

You see all these libraries in red? Most of them depend on each other (Twisted
is a big one as well as another I forget about) and have excellent
alternatives available. Good luck finding 10 that match my criteria; I can't
even find one.

~~~
AhtiK
Often one does not need 10 reasons, 1 is enough if it's critical enough.

For my case the missing libs in py3 world are

* boto (AWS interface) * pika (RabbitMQ interface)

Yes, supervisor too, but it can run in a separate Python 2 env.

It's also about fear that next package that we need to progress faster might
not support py3.

But confidence builds over time and the list of Python 3 packages will only
improve over time. It will converge to one single Python 3, there is
absolutely no doubt.

~~~
gnur
Pika has a working python 3 tree, I have been using it for a few weeks now.

------
EdwardDiego
The unpacking is cool, reminds a little of pattern matching destructuring
binds in Erlang etc.

------
cabalamat
If Python 3 is so wonderful, why are the Python 3 developers still using
Python 2 in their toolchain? It's because it would reportedly take 1 man year
to port Mercurial to Python 3.

If an organisation has lots of legacy Python code, it'll cost them a lot of
effort to re-write it for Python 3, and for what? Programmers might be maybe
1% more productive in the new language than the old one. For most
organisations, this would not make business sense.

~~~
jsmeaton
> It's because it would reportedly take 1 man year to port Mercurial to Python
> 3.

Source?

> If an organisation has lots of legacy Python code, it'll cost them a lot of
> effort to re-write it for Python 3, and for what?

No need to port code that doesn't get a lot of attention. But if you want new
features of Python, then you just have to bite the bullet. Organisations
upgrade hardware all the time. They upgrade their OS somewhat regularly (on
the order of years, but still). You get to make a choice - stay current and
supported, or don't.

As for me, I will be (and have been) writing new applications with python 3.
But I still maintain and support a number of 2.7 apps which will probably
never be upgraded.

~~~
cabalamat
>> It's because it would reportedly take 1 man year to port Mercurial to
Python 3.

> Source?

Python 3.x has proven notoriously difficult to support, due to our pervasive
dependence on a byte-based encoding strategy and string manipulation. We have
invested a substantial amount of time into porting at this point and we
estimate at least a person-year of core developer time to make a full
3.x-compatible version.

\--
[http://mercurial.selenic.com/wiki/SupportedPythonVersions](http://mercurial.selenic.com/wiki/SupportedPythonVersions)

~~~
abuddy
\- They don't mention in the presentation that you should port your current
projects to 3.x Use it for your new projects.

\- It would take a lot of time for Mercurial team because they work with files
and have to support a lot of cases, encodings and stuff. Python 3 does a lot
for the developer now.

\- Mercurial is not the best example because you aren't supposed to use their
internal API anyway. It's their choice to port it to 3 or not.

------
js2
LRU cache for py2 -
[http://code.activestate.com/recipes/498245/](http://code.activestate.com/recipes/498245/)

Surprised no mention of concurrent futures, which also has a py2 backport -
[https://pypi.python.org/pypi/futures](https://pypi.python.org/pypi/futures)

------
manojlds
What are some of the best tools for creating such slides? I see that this one
uses remark.js. What else are people using?

~~~
bpicolo
Well, I can tell you the choice here wasn't good because I can't use my
mousewheel to scroll through it. Which is awful.

------
ulam2
Good move. Infact I'll suggest that the devs have some courage and make it a
new language entirely. Trying to keep python3 in an awkward backward
compatibility is harming it. And remove the GIL limitation at all costs.

------
badman_ting
Getting the first and last line of a file with unpacking is pretty slick.
Respect.

------
peaton
Could somebody explain what all the hype is about generators? Why is this
better practice? Optimization, readability, what's up?

~~~
abuddy
It's about RAM usage. I strongly encourage you to read this:
[https://wiki.python.org/moin/Generators](https://wiki.python.org/moin/Generators).

~~~
peaton
I see, great! That is exactly what I was looking for. Thanks!

------
BrandonLive
Can't get past the first slide on phone (IE 11, WP 8.1). That's pretty lame.

Edit: I guess that's why the PDF link is there.

------
cmdrfred
The trouble is for a good number of projects I need 2.7 because of libraries
being out of date.

------
cabalamat
Consider this Python 3 code extract:

    
    
        HCK = 3
    

Now, does that identifier consist of three ascii letters, or 3 Cyrillic
letters that happen to look the same, or some combination of the two? It's
impossible to tell.

In Python 3, identifiers don't identify!

~~~
jl6
There are countless examples of where allowing non-ASCII identifiers makes
code more readable in non-English languages. For example a Brazilian coder
might write

país = "Brasil"

Without the accent, pais means fathers rather than country.

Imagine how constraining it would be to code in a language that disallowed
vowels in identifiers (perhaps because it had been designed by Hebrew
speakers). That's how most of the world experiences Python 2.

~~~
gone35
Sure: your point _feels_ right logically and politically, but in fact it
doesn't quite work that way: for Latin script-based languages like Portuguese,
non-ASCII letters are _extensions_ (diacritics or liaisons) of the basic Latin
alphabet that are often left out in informal writing ( _eg_ by grade students,
when texting/chatting, or by "uneducated" speakers) when the context is clear
and a romanized phonetic approximation is available. As a result, native
speakers are well used to homonymy in daily use, even though it might appear
quite confusing to a non-native.

So, in practice, ambiguities like the one you point out are more likely than
not to be as constraining to Latin script-based programmers as common English
homographs like "bank" do.

