
What’s New in Python 3.5 - calpaterson
https://docs.python.org/3.5/whatsnew/3.5.html
======
ambivalence
Well, there's also type hints that so far we haven't added to "What's New" :)

[https://www.python.org/dev/peps/pep-0484/](https://www.python.org/dev/peps/pep-0484/)

~~~
Animats
Type hints are not Pythonic. The syntax is ugly. It adds "stub files", like
C's ".h" files, something newer languages such as Go and Rust don't need. Some
of the proposed syntax is even in comments, because it didn't fit the
language. But something had to be done to meet competition.

The problem Python faces is that Python's Little Tin God painted the language
into a corner. He insisted for years that everything in Python had to be fully
dynamic. This limited performance.

Then came competition in Python's space. Go came along, Javascript got
traction on the server, and Python faced a real threat. Both of those can beat
Python on performance, sometimes by huge margins, and they're useable by
Python-type programmers used to the freedoms of scripting languages.

The Python 3 debacle had already thrown the Python community into disarray -
most of the production work is still on Python 2, which was supposed to be
abandoned but refused to die because the cost of conversion was much higher
than expected. Meanwhile, Python 3 takeup was far less than expected; numbers
like 10-20% come from downloads, and production use is probably less. Another
incompatible change in the syntax would be rejected by the market. An
incompatible change to a "typed Python" wouldn't fly.

So we get PEP 484, which is ugly but might help Python survive. Might.

~~~
hyperpape
As far as I know type hints don't affect Python's performance, because they're
optional and not yet used by the runtime.

In any case, JavaScript is dynamically/unityped, so its performance is
unlikely to provide a reason for type annotations. The real problem here is
that PyPy is still maturing, and can't be used by many people because of
legacy C extensions.

~~~
gsnedders
An they're unlikely _ever_ to be used by the runtime, because what hints there
are are far too vague. Saying something is class X is useless when you don't
know what attributes that class has (because they can be dynamically added and
removed) nor what types those attributes are.

~~~
techdragon
The level if information modern Python tools like those in PyCharm and JEDI
can reason through to and discover about runtime behaviour is actually pretty
impressive. I don't think it's going to pose a huge challenge for these kinds
if tools to find. Dealing with ambiguous cases is a UI problem, too much info,
not enough space.

------
inglor
I'm extremely enthusiastic about `async/await` semantics, and in particular
async iterators and the `for async` loop.

It's astonishing to see how fast Python is moving in this direction. It is
truly a powerful language for async computations now - surpassing in this
ability both JavaScript and C# (at least for now). For example Python got
`async with` but JS isn't even close (userland solutions like Bluebird's using
exist) and C# is only starting to work on `IAsyncDisposable`

~~~
rayalez
This is awesome!

I want to ask:

\- Does it mean that it will be possible to create realtime apps with python?
Will it be possible to use it instead of node.js? Do you think Django will
implement that functionality?

\- Now that WebAssembly is coming - doesn't it mean that it could be possible
to create both backend and frontend for realtime apps in python?

That would be so cool....

~~~
inglor
> Does it mean that it will be possible to create realtime apps with python?

I'm not sure what you mean by realtime but usually real time means something
else and requires more deterministic behavior.

If you mean applications that use non-blocking IO to great extent then yes,
but this depends a lot on the ecosystem to provide libraries for async file
io, database io and so on. The Python language left good infrastructure to use
though.

> Now that WebAssembly is coming - doesn't it mean that it could be possible
> to create both backend and frontend for realtime apps in python?

Not anymore than we could before with asm.js unfortunately as seen in
[http://repl.it/languages/python3](http://repl.it/languages/python3) the
problem is wrapping and the library, I hope a company "picks up the glove" and
makes "Python for the frontend", sharing Python code between backend and
frontend could be amazing.

~~~
JustSomeNobody
People have started to hijack the word realtime. It's truly sad, because now
it just muddies up people's conversations. So now people have to ask, is it
the one that keeps planes in the air or the one that makes sure your email
badge counter updates.

~~~
Serow225
I wish there was a better alternative term for the web sense that I could
promote, just to help un-hijack the word before it gets out of control. But I
don't know of one that is likely to succeed. 'Responsive' makes sense to me
but it already has another meaning in the web world. What about something like
'reactive' or 'on-the-fly'? People will never go for 'near real-time' because
it sounds too weak in terms of its advertising value. Someone else below me
suggested 'push', which is pretty decent but again it's an overloaded term...
Thoughts or suggestions? :)

~~~
JustSomeNobody
I'm not much of a wordsmith, but I am leaning towards "forthcoming".

------
kelvin0
Am I the only one surprised by Zipapp (since 2.6?). Wish I had known about
this before ... [https://docs.python.org/3.5/whatsnew/3.5.html#whatsnew-
zipap...](https://docs.python.org/3.5/whatsnew/3.5.html#whatsnew-zipapp)

~~~
talaketu
does PEX still have value?

[https://pex.readthedocs.org/en/latest/](https://pex.readthedocs.org/en/latest/)

------
chc
I thought % formatting was the "old way" and we're supposed to use format() in
Python 3. Strange that they're adding % support to bytes now.

~~~
lambda
As long as % formatting still works, it is in many ways more convenient that
format. '"Foo: %s" % bar' is a lot shorter to write than '"Foo:
{}".format(bar)'. And % formatting is still built into logger, so if you use
logger heavily you will probably be used to it.

While the format() mini-language is nicer in a lot of ways, the convenience of
% and its ubiquity mean that I generally use it more often. The main time when
I reach for format() is when I need more detailed control of column widths and
the like, which you can do with things like "{var:{width}}".format(var=var,
width=width)

~~~
kbd
Personally I dislike % formatting even if it's a few characters shorter to
type. .format is superior in every other way and has consistent-with-
everything-else method call syntax.

Edit: I think it's largely the special flower overloading of the % operator
that bugs me the most. If % was spelled .sprintf I'd like it more.

------
lambda
Lots of good stuff in here.

Python 3.5 may actually be what finally convinces me to move to Python 3
(that, and the end of Python 2.7 support coming up in a few years).

The new async stuff, finally fixing some of the problems with byte strings
that made them not really an adequate replacement for Python 2.x strings, and
os.scandir is a substantial performance improvement over os.listdir plus calls
to stat (though os.scandir, at least, is also available in Python 2.7 via
PyPI).

~~~
ngoldbaum
For what it's worth, even if the core Python developers discontinue support
for 2.7 (and they might not, it was originally supposed to EOL this year),
there is enough Python 2.7 code running in the wild, making people money, that
some entity will certainly take over maintenance responsibilities. Python 2.7
is here to stay for a very long time if only because of the huge amount of
legacy code written in it.

~~~
Animats
_" Python 2.7 is here to stay for a very long time if only because of the huge
amount of legacy code written in it."_

True. It might even outlive Python 3, just as Perl 5 looks like it will
outlive Perl 6.

~~~
kevin_thibedeau
It will stick around like Perl4 did and then fade away with time.

------
wldcordeiro
These kinds of advancements in the language are why I'm glad I've switched to
Python 3, Python 2 needs to die already.

~~~
Walkman
Python 2 will never die. Ask Kenneth Reitz for example. He says he will use
Python 2 forever. There are a lot of companies with huge codebases who never
will port to Python 3.

~~~
dragonwriter
> Python 2 will never die.

Everything dies.

> Ask Kenneth Reitz for example. He says he will use Python 2 forever.

So, assuming this currently-stated intent never changes _and_ Reitz is
immortal, Python 2 will always be in use.

The first of those premises is somewhat suspect, the second even moreso.

> There are a lot of companies with huge codebases who never will port to
> Python 3.

That's probably true. Its less likely true that those companies will never
port _off_ Python 2.

~~~
vegabook
> Everything dies

Python itself might die when Python 2 dies, and arguably, Python 3 makes that
more likely.

------
berkerpeksag
Note: The "What's New" document is not up-to-date yet. See
[https://hg.python.org/cpython/file/3.5/Misc/NEWS](https://hg.python.org/cpython/file/3.5/Misc/NEWS)
(warning - it takes time to load) for a more complete list.

------
bite_victim
I am a bit reluctant about asking this but where do we stand in terms of real
world performance? This is such a broad topic, I know, but surely there has to
be some in-house metric system about this (perhaps popular web and scientific
frameworks, game dev frameworks etc).

~~~
88e282102ae2e5b
An image-reading tool I maintain works 14 times faster in Python 3.4 compared
to Python 2.7. I have no way of accounting for the difference though.

~~~
dr_zoidberg
This is probably the first time I heard of such a speedup when going from 2.7
to 3.x, and the fact that you can't account for it makes it worse because we
can't evaluate what's happening and if such speedup could be achievable on
other projects :(

------
jakob223
How much of this is planning on being backported to python 2?

~~~
ubernostrum
Python 2 is feature frozen. 2.7 gets bugfixes and security improvements and
that's it; new language syntax/features only happen in 3.x.

~~~
ngoldbaum
Except large chunks of the 3.5 standard library has been backported and are
available via the cheeseshop.

------
kozukumi
While there are some Python experts around I have a question; in the world of
Python 3 does it matter between 32-bit and 64-bit anymore? I remember a while
back the only real option was 32-bit as most libraries were 32-bit only,
especially on Windows where Python wasn't fantastically supported compared to
Linux/OSX.

~~~
tdicola
If you're downloading pre-built binaries like on Windows then unfortunately
yes it does matter if you're using 32-bit or 64-bit libraries. Windows in
general has always been a bit of a second class citizen with Python library
support, although it will hopefully improve with easier access to compilers
(there's a free version of visual studio tools for python library compilation
apparently now). If you just want a lot of libraries that 'just work' you're
probably best served using a pre-built distribution like Anaconda. If you're
more adventurous this page has all kinds of pre-built libraries for Windows in
both 32 and 64 bit:
[http://www.lfd.uci.edu/~gohlke/pythonlibs/](http://www.lfd.uci.edu/~gohlke/pythonlibs/)

Alternatively it's insanely easy to spin up a Linux VM with vagrant and just
compile and run python scripts from there. Everything will pip install without
any issues.

~~~
wldcordeiro
Windows is a second class citizen for most language library support, that
being said though Python does a great job of having the most recent versions
available for Windows. The same can't be said of Ruby unfortunately. :(

~~~
kozukumi
Many thanks for the replies. Much appreciated.

------
mackwerk
It's going to be hard to get used to having the function body 'less' indented
than `def`.

------
ergl
Maybe this is obvious, but what would be the difference between the new async
/ await def and the current @asyncio_coroutine decorator?

Or between the new async / await and the current asyncio?

------
a3n
Does anyone retain their legacy Python2, write new in Python3, and communicate
between processes, read/write from a common database, and just in general keep
2 and write new in 3?

~~~
timetraveller
Someone somewhere is.

------
jdlyga
I still use Python 2.7. I guess I should upgrade.

~~~
theseatoms
I've found this website useful for checking which packages have made the jump.

[https://python3wos.appspot.com/](https://python3wos.appspot.com/)

~~~
rspeer
That site uses a very outdated list of popular packages. Use
[http://py3readiness.org/](http://py3readiness.org/) instead.

~~~
theseatoms
Thanks!

~~~
rspeer
Actually, did I speak too soon? I looked back at python3wos and they _have_
updated their package list.

It looks a lot like the one on py3readiness.org now, and it doesn't have all
the nonsense like "tiddlywebplugins" that it used to have.

------
davesque
How come `bytes` and `bytearray` got old-style formatting? Aren't we trying to
do away with that in favor of a `format` method?

~~~
ngoldbaum
It's much more convenient to decode bytestreams (e.g. for a wire protocol)
using % formatting. The lack of % formatting for bytes was a huge impediment
for porting mercurial to python3, just as an example.

~~~
davesque
Could you point me to a code example? It's hard to see how old-style
formatting would facilitate _decoding_. Typically, I think of decoding as
being a process which _deconstructs_ something; not like formatting, which is
really more about _constructing_.

~~~
takeda
I think he just meant encoding, which is true.

I remember Armin Ronacher (author of many nice things, especially Flask) even
wrote a blog post against Python 3 and this was one of things he hated about
it.

------
jason_s
I hate the new @ operator for matrix multiplication, it just looks ugly. (And
I use numpy matrix math all the time.) But whatever.

~~~
inglor
As a fellow numpy user - why? I would love having sugar for this, I use it all
the time. Introducing a _single_ operator to overload seems odd but it's
definitely a pragmatic solution to making code more readable. What would you
do instead?

~~~
Sanddancer
Personally, I'd have made it a diglyph of some sort, like :* or ^*, to make it
obvious to someone looking at python math code for the first time that this is
a multiplication operator. @ just leaves a weird taste here.

~~~
JoshTriplett
Agreed; this needs an operator, but it doesn't need a single-character
operator, and the operator should have had * in it.

~~~
ngoldbaum
The pros and cons of different operator possibilities are discussed
extensively in the PEP that added the matrix multiplication operator.

~~~
yoha
Direct link: [http://legacy.python.org/dev/peps/pep-0465/#choice-of-
operat...](http://legacy.python.org/dev/peps/pep-0465/#choice-of-operator)

~~~
mixmastamyk
What about the & char?

~~~
ngoldbaum
& is the bitwise and operator.

~~~
mixmastamyk
Yep, forgot thanks.

------
mkempe
We should appreciate the contributions of Serhiy Storchaka, who appears to be
in the Ukraine (or Kazakhstan, or Tajikistan).

------
Lambdanaut
Oh my god they finally removed the GIL!

~~~
dalke
Umm, no? [https://docs.python.org/3.5/glossary.html#term-global-
interp...](https://docs.python.org/3.5/glossary.html#term-global-interpreter-
lock) \- "The mechanism used by the CPython interpreter to assure that only
one thread executes Python bytecode at a time"

------
bcheung
Does it really matter if nobody is going to upgrade past 2.7?

------
craigyk
Looking good. Soon I'll just be waiting for the announcement that they have
sped things up 10X, and I might finally be able to let go of my Python ennui.

