8 ms·

Python 3 Features

109 points by Sami_Lehtinen 12y ago

doreo 12y ago
Later: "10 awesome libraries you can't use because they haven't been ported to Python 3"
- bakareika 12y ago
  Yup, this certainly needs work. Myself, I was very skeptical, until one day I decided to start my new project in Python 3 and quickly realized that everything isn't that much ruined. Couple of pull requests here and there, could be worse (after reading some of the more... opinionated blog posts I expected something truly catastrophic). But the new goodness in 3.4 is totally worth it, in my opinion.
- pixelmonkey 12y ago
  This web application tracks the Python 3 compatibility status of Python's most popular libraries. https://python3wos.appspot.com/ https://python3wos.appspot.com/ It's mostly green. If there is a red one you really need, it's probably not hard to port it.
  - rch 12y ago
    Boto, pika, protobuf and thrift are still red, and probably nontrivial to port. It would be interesting to know if str/bytes problems are the main issue though.
    - drdaeman 12y ago
      What about https://github.com/GreatFruitOmsk/protobuf-py3 https://github.com/GreatFruitOmsk/protobuf-py3? I don't really see what could be non-trivial about Protocol Buffers. The encoding's simple to the extent one could probably hack a minimal working implementation over a weekend or another. That is, unless you need not the data format, but the very exact Google's library (which, to my tastes, is severely unpythonic and has an quite weird and bloated codebase - which is probably the issue with porting, but sadly is a dependency for some other libraries).
      - rch 12y ago
        Yes, sticking with Google's library is the limitation. Without the official library, there are probably better ways forward anyway.
- scrollaway 12y ago
  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.
  - dagw 12y ago
    if your niche doesn't care about Python 3, you're either here to troll or you're not actually here Please explain. As someone who will be writing Python 2 for the foreseeable future due to niche libraries, I really don't understand what you're trying to get at.
    - Derbasti 12y ago
      I was in your shoes a few times. I wanted to use Python3, but sime niche library I depended on was Python2 only. And you know what, I simply ported them. Took me a week or two, and I learned a lot. I have been using Python3 ever since.
  - AhtiK 12y ago
    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.
- est 12y ago
  Somebody please port MySQLdb and make it asyncio-compatible.
EdwardDiego 12y ago
The unpacking is cool, reminds a little of pattern matching destructuring binds in Erlang etc.
hk__2 12y ago
> 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 12y ago
  > 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 12y ago
    That’s true, but you already can overload other operators like __mul__ to have `x.T() * M * x`.
    - dagw 12y ago
      __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.
- mhd 12y ago
  Yeah, I didn't get the refactoring either. Unless it's a jab at Perl.
cabalamat 12y ago
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.
- melling 12y ago
  At this point, shouldn't organizations have a Python 3 plan? Legacy support ends in 5 years. Shouldn't new apps be written in 3 when possible?
  - cabalamat 12y ago
    > Legacy support ends in 5 years. Really? Support for Python 2.7 was going to end in 2015, but they recently extended it to 2020. What's the betting that in 2019 they won't extend it to 2025, followed shortly after by quietly dropping python 3 (or someone forking 2.7 to produce a compatible 2.8). > Shouldn't new apps be written in 3 when possible? There are no compelling reasons (for me at least) to change to what is in fact a different language which happens to use the same name. When the Python 3 people eat their own dogfood by using a Python 3 toolchain, I might reconsider.
    - melling 12y ago
      2014 + 5 years? Should your company fire you if you're wrong about an extension to 2025? You're going to cost them a lot of technical debt. I always wondered how we got to the Y2K problem. That was a pretty hard deadline and people knew it was coming for years. How do people get away with creating problems like this?
- jsmeaton 12y ago
  > 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 12y ago
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!
- scrollaway 12y ago
  Consider any bad code. What does it do? Supporting more than ascii in code is a wonderful, wonderful feature for some countries and opens up Python to people for whom the latin alphabet is as familiar as the [pick a non-latin alphabet you don't understand] is to you. Would I use it? No. Would I work on code that used it? Not in three lifetimes. Do I like that it's there? Hell yes. As the slides were showing, I can write shutil.rmtree("/"). Does that mean rmtree should prevent me from passing "/"?
  - cabalamat 12y ago
    > Supporting more than ascii in code is a wonderful, wonderful feature for some countries and opens up Python to people for whom the latin alphabet is as familiar as the [pick a non-latin alphabet you don't understand] is to you. No it doesn't, because reserved words and all the identifiers in the standard library are still in Latin. It is simply not possibly to write Python code without knowing the Latin alphabet.
    - scrollaway 12y ago
      There is a difference between learning the 33 keywords and learning and dealing with an entire foreign alphabet. And you would be surprised what "development translators" can come up with. You can write wrapper libraries for, heck, the entire stdlib. Yes, it's stupid; but if you are looking for devs in a country where English is less spoken than French on Saturn, it's actually useful.
      - cabalamat 12y ago
        > There is a difference between learning the 33 keywords and learning and dealing with an entire foreign alphabet. It's 52 letters, that're used everywhere in computing. Are there really large numbers of Python programmers who have difficulty with it? I doubt it. > but if you are looking for devs in a country where English is less spoken than French on Saturn, it's actually useful. Have a look at the most-downloaded Python packages at https://python3wos.appspot.com/ https://python3wos.appspot.com/ . How many of them have documentation in languages other than English?
pixelmonkey 12y ago
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 12y ago
  how does asyncio deal with resource management, a very hard problem whenever you invent lazy io?
manojlds 12y ago
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 12y ago
  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.
- abhinavk 12y ago
  Impress.js is far much pretty, better and a little heavier, too.
Choronzon 12y ago
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?
- ayrx 12y ago
  I really don't see how PyPy is "splitting the user base" when you have to make close to no changes to your code to gain an appreciable speedup in 90% of the cases. I see many people compare Python to Go and frankly? Go isn't nearly as nice to work with as Python (no exceptions? one among many small but noticeable annoyances). It's much nicer than C or C++ in cases where you require the raw performance but it isn't a replacement for Python. There are also many areas where performance is literally of zero consideration (small scripts to automate stuff) and those areas are where Python is hard to beat.
  - Zancarius 12y ago
    I think the problem with Go coming from Python is that the paradigm shift is a lot more substantial than it appears at first blush. My experience was quite the opposite: Go is pleasant to write in, exceptionally simple, and once you fully grok (and appreciate) slices and channels, the expressiveness of the language starts to take a life of its own. I never missed exceptions much (again, because you have to completely accept Go for what it is) and the fact the language specification is so short makes it easy to understand and relatively fast to pick up. Plus it's fast. My problem with Go has nothing to do with the language per se. Instead, my reservations fall mostly on the ecosystem. It's immature and compared to more established languages like Python, it isn't nearly as rich (after all, it isn't as old). I gather from reading the mailing list archives off and on that there's been some inertial resistance toward certain frameworks (I can't really fault anyone for this--Martini and Revel have too much "magic," for example), and in some cases, prospective users are advised to "roll your own" if it's not something in the standard library. But when it comes to certain odds and ends, it's just downright difficult at times to find something that works as well as its Python counterpart out of the box and is relatively API stable (blackfriday, the Markdown parser, comes to mind--but then I guess offloading that to the client using JS might be better these days?). Also, the abuse of the word "idiomatic" grates on me a little. There was someone on HN a number of months back who joked (paraphrasing) "Great, we're going to see 'idiomatic' abused as much as 'pythonic' and 'pivot.'" But, that's why I do agree with you: Sometimes performance doesn't matter quite as much as the ability to avoid "not invented here." And Python has libraries for almost everything--SQLAlchemy is probably one of Python's "killer apps." (I expect Go will progress there, one day, but for some use cases it's not quite at that point in my experience--so the answer is probably to contribute to those Go libraries/projects you find of use.)
ak217 12y ago
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-annotations https://github.com/kislyuk/ensure#enforcing-function-annotat...). 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!
stephendicato 12y ago
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#37 https://asmeurer.github.io/python3-presentation/slides.html#...
ulam2 12y ago
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 12y ago
Getting the first and last line of a file with unpacking is pretty slick. Respect.
shadowmint 12y ago
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 12y ago
  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 12y ago
    I'm sure (I hope) that was just a proof of concept. It's a horrible idea!
    - eliben 12y ago
      No one in the Python community is advocating the "replacement". I think it's just an example of new syntax.
  - sourpoi 12y ago
    Slight typo - the sample replacement should read: def wat(*args) a, b, *args = args ..But I don't see how moving required arguments from the signature to the body (or turning a TypeError into a ValueError) might be useful, or how it differs from the presentation's first advanced unpacking example.
- natrius 12y ago
  There's also a python 2.7 backport of asyncio that works perfectly fine for me. https://pypi.python.org/pypi/trollius https://pypi.python.org/pypi/trollius
- 12y ago
js2 12y ago
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
peaton 12y ago
Could somebody explain what all the hype is about generators? Why is this better practice? Optimization, readability, what's up?
- abuddy 12y ago
  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 12y ago
    I see, great! That is exactly what I was looking for. Thanks!
BrandonLive 12y ago
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.
latiera 12y ago
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 12y ago
  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.
cmdrfred 12y ago
The trouble is for a good number of projects I need 2.7 because of libraries being out of date.

Python 3 Features

109 points by Sami_Lehtinen 12y ago

doreo 12y ago

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

bakareika 12y ago
Yup, this certainly needs work. Myself, I was very skeptical, until one day I decided to start my new project in Python 3 and quickly realized that everything isn't that much ruined. Couple of pull requests here and there, could be worse (after reading some of the more... opinionated blog posts I expected something truly catastrophic). But the new goodness in 3.4 is totally worth it, in my opinion.
pixelmonkey 12y ago
This web application tracks the Python 3 compatibility status of Python's most popular libraries. https://python3wos.appspot.com/ https://python3wos.appspot.com/ It's mostly green. If there is a red one you really need, it's probably not hard to port it.
- rch 12y ago
  Boto, pika, protobuf and thrift are still red, and probably nontrivial to port. It would be interesting to know if str/bytes problems are the main issue though.
  - drdaeman 12y ago
    What about https://github.com/GreatFruitOmsk/protobuf-py3 https://github.com/GreatFruitOmsk/protobuf-py3? I don't really see what could be non-trivial about Protocol Buffers. The encoding's simple to the extent one could probably hack a minimal working implementation over a weekend or another. That is, unless you need not the data format, but the very exact Google's library (which, to my tastes, is severely unpythonic and has an quite weird and bloated codebase - which is probably the issue with porting, but sadly is a dependency for some other libraries).
    - rch 12y ago
      Yes, sticking with Google's library is the limitation. Without the official library, there are probably better ways forward anyway.
scrollaway 12y ago
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.
- dagw 12y ago
  if your niche doesn't care about Python 3, you're either here to troll or you're not actually here Please explain. As someone who will be writing Python 2 for the foreseeable future due to niche libraries, I really don't understand what you're trying to get at.
  - Derbasti 12y ago
    I was in your shoes a few times. I wanted to use Python3, but sime niche library I depended on was Python2 only. And you know what, I simply ported them. Took me a week or two, and I learned a lot. I have been using Python3 ever since.
- AhtiK 12y ago
  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.
est 12y ago
Somebody please port MySQLdb and make it asyncio-compatible.

EdwardDiego 12y ago

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

hk__2 12y ago

> 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 12y ago
> 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 12y ago
  That’s true, but you already can overload other operators like __mul__ to have `x.T() * M * x`.
  - dagw 12y ago
    __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.
mhd 12y ago
Yeah, I didn't get the refactoring either. Unless it's a jab at Perl.

cabalamat 12y ago

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.

melling 12y ago
At this point, shouldn't organizations have a Python 3 plan? Legacy support ends in 5 years. Shouldn't new apps be written in 3 when possible?
- cabalamat 12y ago
  > Legacy support ends in 5 years. Really? Support for Python 2.7 was going to end in 2015, but they recently extended it to 2020. What's the betting that in 2019 they won't extend it to 2025, followed shortly after by quietly dropping python 3 (or someone forking 2.7 to produce a compatible 2.8). > Shouldn't new apps be written in 3 when possible? There are no compelling reasons (for me at least) to change to what is in fact a different language which happens to use the same name. When the Python 3 people eat their own dogfood by using a Python 3 toolchain, I might reconsider.
  - melling 12y ago
    2014 + 5 years? Should your company fire you if you're wrong about an extension to 2025? You're going to cost them a lot of technical debt. I always wondered how we got to the Y2K problem. That was a pretty hard deadline and people knew it was coming for years. How do people get away with creating problems like this?
jsmeaton 12y ago
> 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 12y ago

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!

scrollaway 12y ago
Consider any bad code. What does it do? Supporting more than ascii in code is a wonderful, wonderful feature for some countries and opens up Python to people for whom the latin alphabet is as familiar as the [pick a non-latin alphabet you don't understand] is to you. Would I use it? No. Would I work on code that used it? Not in three lifetimes. Do I like that it's there? Hell yes. As the slides were showing, I can write shutil.rmtree("/"). Does that mean rmtree should prevent me from passing "/"?
- cabalamat 12y ago
  > Supporting more than ascii in code is a wonderful, wonderful feature for some countries and opens up Python to people for whom the latin alphabet is as familiar as the [pick a non-latin alphabet you don't understand] is to you. No it doesn't, because reserved words and all the identifiers in the standard library are still in Latin. It is simply not possibly to write Python code without knowing the Latin alphabet.
  - scrollaway 12y ago
    There is a difference between learning the 33 keywords and learning and dealing with an entire foreign alphabet. And you would be surprised what "development translators" can come up with. You can write wrapper libraries for, heck, the entire stdlib. Yes, it's stupid; but if you are looking for devs in a country where English is less spoken than French on Saturn, it's actually useful.
    - cabalamat 12y ago
      > There is a difference between learning the 33 keywords and learning and dealing with an entire foreign alphabet. It's 52 letters, that're used everywhere in computing. Are there really large numbers of Python programmers who have difficulty with it? I doubt it. > but if you are looking for devs in a country where English is less spoken than French on Saturn, it's actually useful. Have a look at the most-downloaded Python packages at https://python3wos.appspot.com/ https://python3wos.appspot.com/ . How many of them have documentation in languages other than English?

pixelmonkey 12y ago

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 12y ago
how does asyncio deal with resource management, a very hard problem whenever you invent lazy io?

manojlds 12y ago

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 12y ago
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.
abhinavk 12y ago
Impress.js is far much pretty, better and a little heavier, too.

Choronzon 12y ago

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?

ayrx 12y ago
I really don't see how PyPy is "splitting the user base" when you have to make close to no changes to your code to gain an appreciable speedup in 90% of the cases. I see many people compare Python to Go and frankly? Go isn't nearly as nice to work with as Python (no exceptions? one among many small but noticeable annoyances). It's much nicer than C or C++ in cases where you require the raw performance but it isn't a replacement for Python. There are also many areas where performance is literally of zero consideration (small scripts to automate stuff) and those areas are where Python is hard to beat.
- Zancarius 12y ago
  I think the problem with Go coming from Python is that the paradigm shift is a lot more substantial than it appears at first blush. My experience was quite the opposite: Go is pleasant to write in, exceptionally simple, and once you fully grok (and appreciate) slices and channels, the expressiveness of the language starts to take a life of its own. I never missed exceptions much (again, because you have to completely accept Go for what it is) and the fact the language specification is so short makes it easy to understand and relatively fast to pick up. Plus it's fast. My problem with Go has nothing to do with the language per se. Instead, my reservations fall mostly on the ecosystem. It's immature and compared to more established languages like Python, it isn't nearly as rich (after all, it isn't as old). I gather from reading the mailing list archives off and on that there's been some inertial resistance toward certain frameworks (I can't really fault anyone for this--Martini and Revel have too much "magic," for example), and in some cases, prospective users are advised to "roll your own" if it's not something in the standard library. But when it comes to certain odds and ends, it's just downright difficult at times to find something that works as well as its Python counterpart out of the box and is relatively API stable (blackfriday, the Markdown parser, comes to mind--but then I guess offloading that to the client using JS might be better these days?). Also, the abuse of the word "idiomatic" grates on me a little. There was someone on HN a number of months back who joked (paraphrasing) "Great, we're going to see 'idiomatic' abused as much as 'pythonic' and 'pivot.'" But, that's why I do agree with you: Sometimes performance doesn't matter quite as much as the ability to avoid "not invented here." And Python has libraries for almost everything--SQLAlchemy is probably one of Python's "killer apps." (I expect Go will progress there, one day, but for some use cases it's not quite at that point in my experience--so the answer is probably to contribute to those Go libraries/projects you find of use.)

ak217 12y ago

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-annotations https://github.com/kislyuk/ensure#enforcing-function-annotat...). 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!

stephendicato 12y ago

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#37 https://asmeurer.github.io/python3-presentation/slides.html#...

ulam2 12y ago

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

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

shadowmint 12y ago

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 12y ago
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 12y ago
  I'm sure (I hope) that was just a proof of concept. It's a horrible idea!
  - eliben 12y ago
    No one in the Python community is advocating the "replacement". I think it's just an example of new syntax.
- sourpoi 12y ago
  Slight typo - the sample replacement should read: def wat(*args) a, b, *args = args ..But I don't see how moving required arguments from the signature to the body (or turning a TypeError into a ValueError) might be useful, or how it differs from the presentation's first advanced unpacking example.
natrius 12y ago
There's also a python 2.7 backport of asyncio that works perfectly fine for me. https://pypi.python.org/pypi/trollius https://pypi.python.org/pypi/trollius
12y ago

js2 12y ago

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

peaton 12y ago

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

abuddy 12y ago
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 12y ago
  I see, great! That is exactly what I was looking for. Thanks!

BrandonLive 12y ago

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.

latiera 12y ago

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

cmdrfred 12y ago

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