24 ms·

What’s New in Python 3.5

288 points by calpaterson 11y ago

ergl 11y ago
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?
Lambdanaut 11y ago
Oh my god they finally removed the GIL!
- lambda 11y ago
  Hmm? Where does it say that?
- dalke 11y ago
  Umm, no? https://docs.python.org/3.5/glossary.html#term-global-interpreter-lock https://docs.python.org/3.5/glossary.html#term-global-interp... - "The mechanism used by the CPython interpreter to assure that only one thread executes Python bytecode at a time"
  - Lambdanaut 11y ago
    Wow, party pooper.
jdlyga 11y ago
I still use Python 2.7. I guess I should upgrade.
- theseatoms 11y ago
  I've found this website useful for checking which packages have made the jump. https://python3wos.appspot.com/ https://python3wos.appspot.com/
  - rspeer 11y ago
    That site uses a very outdated list of popular packages. Use http://py3readiness.org/ http://py3readiness.org/ instead.
    - theseatoms 11y ago
      Thanks!
      - rspeer 11y ago
        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.
inglor 11y ago
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 11y ago
  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 11y ago
    > 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 11y ago
      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.
chc 11y ago
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.
- nhumrich 11y ago
  If you read the PEP, it explains how they are adding it for easier python2 -> python3 migration
- lambda 11y ago
  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 11y ago
    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.
- deleted 11y ago
  [deleted]
- kbd 11y ago
  Thanks for bringing this up. I asked about this on reddit yesterday[1] and was linked the thread where they originally discussed this[2]. Basically, the goal is to make porting from 2 to 3 easier, and there's also a notion that printf-style formatting may be more natural than format-style formatting for bytes. I still wish they were consistent and provided a .format method for bytes, especially since, as you point out, .format was supposed to be the "new way" to do formatting and this feels like a step backwards. And what about backward compatibility for porting Python 2 code that used .format to do formatting on what are semantically byte strings? [1] https://www.reddit.com/r/Python/comments/3c7lne/python_350b3_is_out/cstcpg7 https://www.reddit.com/r/Python/comments/3c7lne/python_350b3... [2] http://thread.gmane.org/gmane.comp.python.devel/144712/focus=144856 http://thread.gmane.org/gmane.comp.python.devel/144712/focus...
jakob223 11y ago
How much of this is planning on being backported to python 2?
- ubernostrum 11y ago
  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 11y ago
    Except large chunks of the 3.5 standard library has been backported and are available via the cheeseshop.
lambda 11y ago
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).
- inglor 11y ago
  Let's not forget https://www.python.org/dev/peps/pep-0484/ https://www.python.org/dev/peps/pep-0484/ which looks really promising
  - deleted 11y ago
    [deleted]
- ngoldbaum 11y ago
  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 11y ago
    "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 11y ago
      It will stick around like Perl4 did and then fade away with time.
jason_s 11y ago
I hate the new @ operator for matrix multiplication, it just looks ugly. (And I use numpy matrix math all the time.) But whatever.
- inglor 11y ago
  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 11y ago
    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 11y ago
      Agreed; this needs an operator, but it doesn't need a single-character operator, and the operator should have had * in it.
      - ngoldbaum 11y ago
        The pros and cons of different operator possibilities are discussed extensively in the PEP that added the matrix multiplication operator.
        yoha 11y ago
        Direct link: http://legacy.python.org/dev/peps/pep-0465/#choice-of-operator http://legacy.python.org/dev/peps/pep-0465/#choice-of-operat...
        KeytarHero 11y ago
wldcordeiro 11y ago
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 11y ago
  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.
  - rudolf0 11y ago
    This is the unfortunate truth. My company still uses Python 2 solely, not a single line of Python 3. Unless there is some major breakthrough in porting tools (in combination with more and more libraries supporting 3), Python 2 will still probably be the only Python version in many enterprises for the next 10 years.
    - deleted 11y ago
      [deleted]
  - dragonwriter 11y ago
    > 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 11y ago
      > Everything dies Python itself might die when Python 2 dies, and arguably, Python 3 makes that more likely.
  - dr_zoidberg 11y ago
kozukumi 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      Many thanks for the replies. Much appreciated.
ambivalence 11y ago
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/
- benhoyt 11y ago
  Yes. I'm not entirely sure why this was posted now, as it's a couple of months from 3.5's release date yet, and What's New is not up to date. On python-dev, David Mertz just volunteered to write/update this "What's New" page, somewhat sponsored by the company he works for, Continuum: https://mail.python.org/pipermail/python-dev/2015-July/140654.html https://mail.python.org/pipermail/python-dev/2015-July/14065...
- Animats 11y ago
  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 11y ago
    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.
craigyk 11y ago
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.
deleted 11y ago
[deleted]
berkerpeksag 11y ago
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 11y ago
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).
- dalke 11y ago
  The answer is "all over the place". It really does depend on your benchmarks and use case. There is no aggregate real-world benchmark. Such a thing is very hard to do, and not all that portable. For example, in one performance intensive code that I use, while mostly written in Python, has a C extension, which itself uses inline assembly for the core routine. Similarly, most numeric calculations that use NumPy will end up doing BLAS / LAPACK / ATLAS calls, so the performance limitations aren't due to C. The switch from 2 to 3 isn't really going to affect these. If it was seriously and consistently worse, eg, for Django, then it's likely we would heard about it by now. Instead, there are reports like https://www.youtube.com/watch?v=f_6vDi7ywuA https://www.youtube.com/watch?v=f_6vDi7ywuA (slides at https://speakerdeck.com/pyconslides/python-3-dot-3-trust-me-its-better-than-python-2-dot-7-by-dr-brett-cannon https://speakerdeck.com/pyconslides/python-3-dot-3-trust-me-... ) from PyCon 2013. At minute 30:54 / slide 16 the speaker evaluates the two and finds that the median performance was effectively identical for microbenchmarks, and ~5% slower on macrobenchmarks, though even then it varies from 27% slower to 13% faster depending on the specifics, and as the speaker points out, the tested packages aren't doing exactly the same things on both versions. In any case, that was 2 years ago.
- 88e282102ae2e5b 11y ago
  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 11y ago
    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 :(
davesque 11y ago
How come `bytes` and `bytearray` got old-style formatting? Aren't we trying to do away with that in favor of a `format` method?
- theVirginian 11y ago
  I think the general opinion is "use where appropriate but be consistent" which I tend to agree with. There are times where the simplicity of old-style formatting just gets the job done but it certainly has it's limitations and new style can be extremely powerful.
- ngoldbaum 11y ago
  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 11y ago
    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 11y ago
      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.
kelvin0 11y ago
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-zipapp https://docs.python.org/3.5/whatsnew/3.5.html#whatsnew-zipap...
- uxcn 11y ago
  This is nice. I actually used to manually create zip archives and prepend a shebang.
- gambogi 11y ago
  Can that handle statically linking dependencies with FFI calls?
- talaketu 11y ago
  does PEX still have value? https://pex.readthedocs.org/en/latest/ https://pex.readthedocs.org/en/latest/
mackwerk 11y ago
It's going to be hard to get used to having the function body 'less' indented than `def`.
bcheung 11y ago
Does it really matter if nobody is going to upgrade past 2.7?
a3n 11y ago
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 11y ago
  Someone somewhere is.
mkempe 11y ago
We should appreciate the contributions of Serhiy Storchaka, who appears to be in the Ukraine (or Kazakhstan, or Tajikistan).

288 points by calpaterson 11y ago

ergl 11y ago

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?

Lambdanaut 11y ago

Oh my god they finally removed the GIL!

lambda 11y ago
Hmm? Where does it say that?
dalke 11y ago
Umm, no? https://docs.python.org/3.5/glossary.html#term-global-interpreter-lock https://docs.python.org/3.5/glossary.html#term-global-interp... - "The mechanism used by the CPython interpreter to assure that only one thread executes Python bytecode at a time"
- Lambdanaut 11y ago
  Wow, party pooper.

jdlyga 11y ago

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

theseatoms 11y ago
I've found this website useful for checking which packages have made the jump. https://python3wos.appspot.com/ https://python3wos.appspot.com/
- rspeer 11y ago
  That site uses a very outdated list of popular packages. Use http://py3readiness.org/ http://py3readiness.org/ instead.
  - theseatoms 11y ago
    Thanks!
    - rspeer 11y ago
      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.

inglor 11y ago

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 11y ago
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 11y ago
  > 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 11y ago
    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.

chc 11y ago

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.

nhumrich 11y ago
If you read the PEP, it explains how they are adding it for easier python2 -> python3 migration
lambda 11y ago
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 11y ago
  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.
deleted 11y ago
[deleted]
kbd 11y ago
Thanks for bringing this up. I asked about this on reddit yesterday[1] and was linked the thread where they originally discussed this[2]. Basically, the goal is to make porting from 2 to 3 easier, and there's also a notion that printf-style formatting may be more natural than format-style formatting for bytes. I still wish they were consistent and provided a .format method for bytes, especially since, as you point out, .format was supposed to be the "new way" to do formatting and this feels like a step backwards. And what about backward compatibility for porting Python 2 code that used .format to do formatting on what are semantically byte strings? [1] https://www.reddit.com/r/Python/comments/3c7lne/python_350b3_is_out/cstcpg7 https://www.reddit.com/r/Python/comments/3c7lne/python_350b3... [2] http://thread.gmane.org/gmane.comp.python.devel/144712/focus=144856 http://thread.gmane.org/gmane.comp.python.devel/144712/focus...

jakob223 11y ago

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

ubernostrum 11y ago
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 11y ago
  Except large chunks of the 3.5 standard library has been backported and are available via the cheeseshop.

lambda 11y ago

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).

inglor 11y ago
Let's not forget https://www.python.org/dev/peps/pep-0484/ https://www.python.org/dev/peps/pep-0484/ which looks really promising
- deleted 11y ago
  [deleted]
ngoldbaum 11y ago
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 11y ago
  "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 11y ago
    It will stick around like Perl4 did and then fade away with time.

jason_s 11y ago

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

inglor 11y ago
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 11y ago
  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 11y ago
    Agreed; this needs an operator, but it doesn't need a single-character operator, and the operator should have had * in it.
    - ngoldbaum 11y ago
      The pros and cons of different operator possibilities are discussed extensively in the PEP that added the matrix multiplication operator.
      - yoha 11y ago
        Direct link: http://legacy.python.org/dev/peps/pep-0465/#choice-of-operator http://legacy.python.org/dev/peps/pep-0465/#choice-of-operat...
        KeytarHero 11y ago

wldcordeiro 11y ago

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 11y ago
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.
- rudolf0 11y ago
  This is the unfortunate truth. My company still uses Python 2 solely, not a single line of Python 3. Unless there is some major breakthrough in porting tools (in combination with more and more libraries supporting 3), Python 2 will still probably be the only Python version in many enterprises for the next 10 years.
  - deleted 11y ago
    [deleted]
- dragonwriter 11y ago
  > 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 11y ago
    > Everything dies Python itself might die when Python 2 dies, and arguably, Python 3 makes that more likely.
- dr_zoidberg 11y ago

kozukumi 11y ago

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 11y ago
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 11y ago
  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 11y ago
    Many thanks for the replies. Much appreciated.

ambivalence 11y ago

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/

benhoyt 11y ago
Yes. I'm not entirely sure why this was posted now, as it's a couple of months from 3.5's release date yet, and What's New is not up to date. On python-dev, David Mertz just volunteered to write/update this "What's New" page, somewhat sponsored by the company he works for, Continuum: https://mail.python.org/pipermail/python-dev/2015-July/140654.html https://mail.python.org/pipermail/python-dev/2015-July/14065...
Animats 11y ago
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 11y ago
  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.

craigyk 11y ago

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.

deleted 11y ago

[deleted]

berkerpeksag 11y ago

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 11y ago

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).

dalke 11y ago
The answer is "all over the place". It really does depend on your benchmarks and use case. There is no aggregate real-world benchmark. Such a thing is very hard to do, and not all that portable. For example, in one performance intensive code that I use, while mostly written in Python, has a C extension, which itself uses inline assembly for the core routine. Similarly, most numeric calculations that use NumPy will end up doing BLAS / LAPACK / ATLAS calls, so the performance limitations aren't due to C. The switch from 2 to 3 isn't really going to affect these. If it was seriously and consistently worse, eg, for Django, then it's likely we would heard about it by now. Instead, there are reports like https://www.youtube.com/watch?v=f_6vDi7ywuA https://www.youtube.com/watch?v=f_6vDi7ywuA (slides at https://speakerdeck.com/pyconslides/python-3-dot-3-trust-me-its-better-than-python-2-dot-7-by-dr-brett-cannon https://speakerdeck.com/pyconslides/python-3-dot-3-trust-me-... ) from PyCon 2013. At minute 30:54 / slide 16 the speaker evaluates the two and finds that the median performance was effectively identical for microbenchmarks, and ~5% slower on macrobenchmarks, though even then it varies from 27% slower to 13% faster depending on the specifics, and as the speaker points out, the tested packages aren't doing exactly the same things on both versions. In any case, that was 2 years ago.
88e282102ae2e5b 11y ago
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 11y ago
  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 :(

davesque 11y ago

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

theVirginian 11y ago
I think the general opinion is "use where appropriate but be consistent" which I tend to agree with. There are times where the simplicity of old-style formatting just gets the job done but it certainly has it's limitations and new style can be extremely powerful.
ngoldbaum 11y ago
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 11y ago
  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 11y ago
    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.

kelvin0 11y ago

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-zipapp https://docs.python.org/3.5/whatsnew/3.5.html#whatsnew-zipap...

uxcn 11y ago
This is nice. I actually used to manually create zip archives and prepend a shebang.
gambogi 11y ago
Can that handle statically linking dependencies with FFI calls?
talaketu 11y ago
does PEX still have value? https://pex.readthedocs.org/en/latest/ https://pex.readthedocs.org/en/latest/

mackwerk 11y ago

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

bcheung 11y ago

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

a3n 11y ago

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 11y ago
Someone somewhere is.

mkempe 11y ago

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