20 ms·

New features you can't use unless you are in Python 3

331 points by bkudria 9y ago

cpburns2009 9y ago
This presentation could use some navigation buttons.
- edoceo 9y ago
  The buttons are on your keyboard. Swipe on touch interface
  - web007 9y ago
    I don't expect to have to use my keyboard to navigate a webpage. It's also not discoverable or prompted in any way.
    - coldtea 9y ago
      Using the arrows keys for the slides has been a standard since the dawn of web presentations, a decade or so ago. Doesn't have to be more discoverable imho. As soon one finds it out, they can use the knowledge for any other presentation they chance upon -- and presentations remain clutter free, without prompts and extra navigational buttons for the rest.
      - jonknee 9y ago
        > Using the arrows keys for the slides has been a standard since the dawn of web presentations, a decade or so ago. So have arrows icons you can click to switch slides... Such as on Slideshare (coincidentally a decade old!).
        jessaustin 9y ago
        If the icons disappear as soon as I use my keyboard or tap, that wouldn't be too terrible.
- howard941 9y ago
  For some reason only the arrows and page up/down work. Sometimes. edit 4 grammar
xutopia 9y ago
I'm impressed how much Python seems stuck on older versions. What went wrong?
- rjgonza 9y ago
  Python 3 came about with a split in the community.
  - vapemaster 9y ago
    what is the split that has to do with 2vs3? Really it just seems like some devs are still griping about fairly minor backwards compatibility issues. the whole print vs print() is obviously a straw man. but the major one, strings, unicode, and bytes, changes for the good in py3. the fact that people have to go back and "un-hack" their code is time, effort, and more commits but it's for the best. <rant> i think the real split is between CPython + C-Extensions and the JIT (PyPy,Numba) gang for heavy lifting in python. I for one wish Guido would embrace the effort of integrating the GILectomy into CPython and make python thread parrallism real for CPU bound work as opposed to the high overhead multiprocessing approach. Also, including mypy in the stdlib to make genuine optional static typing would make python a defacto standard for much of what it does now without the "we love python but...." production code pain points. </rant>
    - Jach 9y ago
      I don't think the whole print vs print() problem is a straw man (or similarly the division operator switch) apart from being relatively easy to fix or avoid by importing from __future__, but crucial in understanding the attitude the language owners have for its users. They could have kept print and introduced printf(), but they didn't. They didn't even get rid of the statement vs. expression distinction, which would have been a compelling reason to break print (and would give us real lambdas). The split you mention is real, but it's existed even longer than the 2vs3 split. All the various alternate Python implementations that have come and gone or are still around with the exception of Numba were started pre-3k. I wouldn't even argue that upstream was necessarily wrong not to prioritize performance and more specific use cases (like certain production uses, or scientific uses (a lot of begging to finally get the @ operator)), it just didn't matter as much for a long time. But things are different now. There are many other very expressive and much faster (either dynamically typed or static) languages in competition that lessen Python's effectiveness at reducing dev time in exchange for more hardware. Without a more serious focus on performance, Python will be driven only by momentum. That can last a long time, and is essentially the end point anyway when performance is "good enough" compared to the close alternatives, but it's not a great look when there's still much that could be done.
matthewmacleod 9y ago
Ruby's 1.8 to 1.9 transition seemed to go much smoother - I'm curious what the difference is. Just down to what is essentially better source comparability I guess.
- mattnewton 9y ago
  My guess is it could also have to do with the communities. Anecdotally, the limited sample of ruby-istas I have interacted with tend to have more tolerance of churn for improvement's sake whereas the people attracted to python are more interested in stability because they are focused on some other need that the code is mearly an ends to.
  - dom0 9y ago
    And/or because many Python projects have completely insufficient testing which means that any change that might break anything anywhere can go undetected.
- dragonwriter 9y ago
  Ruby 1.8 to 1.9 was a similar mess for a shorter period of time, and not because it was handled better, but because there was less diverse entrenched code and subcommunities to deal with: when Rails and popular Rails libraries worked, most of the community could move; Python had a whole lot more that had to be addressed, the curse of it's broader success. (Also, being already expression-oriented, Ruby didn't have to deal with running into problems where a core feature was a statement that couldn't be used in contexts limited to expressions; fixing that is inherently painful.)
  - TylerE 9y ago
    Didn't Ruby 1.9 also offer a meaningful performance boost as well? Whereas early Py3 was actually about 5-10% slower than Py2.
- dagw 9y ago
  Ruby managed to get their major libraries ported to 1.9 much much quicker. RoR basically worked from day 1. Python 3 was without both numpy as django for well over a year. Also the first few releases of python 3 weren't very good. It wasn't before 3.2 before you could really use python 3 in production and not before 3.5 before most of the interesting features where in place. Basically a lot of early momentum was lost due to this and and it never really regained it.
gshulegaard 9y ago
Quite a nice presentation! But I just wanted to point out that the title is a bit presumptuous. I don't refuse to upgrade to Python 3, it's that the default Python for most distributions is 2 (sometimes as far back as 2.6). If you want to write a user-space tool with Python you can either require additional dependency setup, bundle a full interpreter with your package, or just write Python 2.7/6 code that is forward compatible with Python 3...in which case I still can't use the new features of 3. At the end of the day, the continued slow adoption of Python 3 today is because ecosystems move slowly. Not to mention the original releases of Python 3 were really rough around the edges (such as being slower than Python 2.7 until ~3.4) which definitely contributed to the slow adoption in the early years.
- mixmastamyk 9y ago
  Python 3 has been available on most dists for 5-10 years.
  - euyyn 9y ago
    macOS Sierra today tells me its python is 2.7
    - mplewis 9y ago
      And Python 3 is available on macOS Sierra via Homebrew.
      - msie 9y ago
        Hilarious since Homebrew is written in Ruby...do you have to upgrade Ruby too?
    - seanp2k2 9y ago
      You should use homebrew to join the pythonistas club on Mac. Better yet, use https://github.com/asdf-vm/asdf/blob/master/README.md https://github.com/asdf-vm/asdf/blob/master/README.md to get all the pythons, rubies, nodes, and golangs you want. Ubuntu 18.04 LTS plans on Python 3-only, but Ubuntu has been shipping Python 3.x since 13.04 and 3.x is the default with 2.x available since 16.04 , so in terms of shipping Python 3 code, Ubuntu 12.04 LTS (the last LTS where you can't assume it has a python 3) EOL'd on April 28 2017. Assuming $WORK follows EOL depredations, you should be fine for Ubuntu.
iainmerrick 9y ago
The new keyword-only arguments look great, but it looks like it relies on adding a " * " parameter that allows any number of arguments. What if I want the safety of keyword-only arguments, but I don't want varargs? Is there a way to do that?
- arximboldi 9y ago
  This is covered in the link. Just put a * without a name, as in def foo(*, x=None, y="") (Edit) The specific slide: http://www.asmeurer.com/python3-presentation/slides.html#16 http://www.asmeurer.com/python3-presentation/slides.html#16
  - iainmerrick 9y ago
    Aha, thanks! I misunderstood -- I assumed the lone * would parse and discard any number of arguments. This is a very good feature, but a weird syntax!
  - dozzie 9y ago
    Oh my, it looks atrocious. Almost every time I see something introduced in Python 3 I have an impression that current Python envies Perl its baroque semantics, except that Perl usually tries to guess what the programmer meant, while with Python the relationship is reversed: the programmer needs to guess what the language wants. Python's main selling point was simplicity of syntax and semantics that preserved its high-level language status. This simplicity is no longer present in 3.x line.
    - dom0 9y ago
      Python 2 is a vastly more complex language compared to Python 3. Just try to name the basic classes of types that exist in Python 2. Hint: Cannot be counted on two hands.
      - dozzie 9y ago
        Well, try this for me, especially that you didn't use searchable terminology, so it's hard to confirm what you're saying. And then tell how much of that is important for typical code.
Fej 9y ago
Does anyone use 2.x by choice? I've only seen it required as to not break legacy code.
- jonknee 9y ago
  I'd wager most people don't even think about it and just use whatever comes on their OS (almost always 2.x).
- RodericDay 9y ago
  This shouldn't be downvoted, it's a legit question. I hear some people really really prefer `print as statement`, but I've never seem them in real life.
  - mixmastamyk 9y ago
    I do, but I understand the reasoning behind why it was changed. So I made a snippet in my editor and moved on with my life, haha. New print is now easier to to type than the old.
  - seanp2k2 9y ago
    Just from __past__ import print_statement I really hope someone makes this work. I literally laughed and thought that it was a troll the first time I saw the future print import and that being used as a compelling reason that I should switch to Py3.
    - mixmastamyk 9y ago
      Consistency and keyword args are useful.
      - pishpash 9y ago
        "11. There should be one-- and preferably only one --obvious way to do it." from the Zen of Python. Somebody intentionally misread it as, "There should be only one way to do it." They obviously made a grave mistake. Same with many 2->3 changes.
SeanDav 9y ago
Alternative view titles: Zero - The Number of Applications that Can only be Developed in Python 3 or 7456324 - The number of companies that only use Python 2.x Although these made up titles are slightly tongue-in-cheek, they do server to illustrate that for me at least, I do not have a compelling reason to switch to Python 3.
- teilo 9y ago
  That's also a meaningless argument. It's true of any turing-complete language.
  - SeanDav 9y ago
    > "That's also a meaningless argument. It's true of any turing-complete language." Title 1 of course. Title 2 is a far more compelling reason to stay with Python 2.x. If I program for fun, then Python 3 is definitely worth playing around in, but for professional development, everything I do in Python is done in Python 2.x. That is not a theoretical argument, that is fact.
    - minitech 9y ago
      > for professional development, everything I do in Python is done in Python 2.x. That is not a theoretical argument, that is fact. And everything I do professionally in Python is done in 3.x as of this January. Also fact! Industry standards sometimes move slowly, but they are moving.
    - teilo 9y ago
      That is only relevant if there is no significant professional Python 3.x development taking place. There is, in fact, significant 3.x development taking place, and that number is growing - exactly as one would expect. And by significant, I mean upwards of 40%. So, except for corporate inertia, or the rare can't-live-without libraries that have yet to be ported to 3.x (see: http://py3readiness.org http://py3readiness.org), there are no compelling reasons to stick with Python 2.x for new projects.
signet 9y ago
My personal favorite is native support for IP addresses, introduced in python 3.3[0]. Makes IP math and address validation so much easier. [0] https://docs.python.org/3/library/ipaddress.html https://docs.python.org/3/library/ipaddress.html
- bpicolo 9y ago
  To be fair, you can grab the original. https://pypi.python.org/pypi/ipaddress https://pypi.python.org/pypi/ipaddress
- jsmthrowaway 9y ago
  Anybody who likes that will like subnettree, too, which offers a C-based Patricia tree for IP addresses. In the past, I've gotten a lot of mileage out of this library: https://pypi.python.org/pypi/pysubnettree https://pypi.python.org/pypi/pysubnettree Last time I played with it, it didn't like Python 3 or ipaddress, though. I see a recent upload, so maybe they addressed that.
- est 9y ago
  > address validation just try: socket.inet_aton
  - pwdisswordfish 9y ago
    That doesn't seem to support IPv6 at all. And doesn't let you do much with a parsed address either.
NuSkooler 9y ago
How old is Python 3 now? I've always used Python for a "miscellaneous task" language, and still do... and even I find "...because you refuse to upgrade" a bit insulting. If I used it for something serious, even more so. The way 2.x -> 3.x was handled is/was/will is an absolute disaster. Upgrading simple scripts is a non-issue. Larger projects seem to always be a horrible pain.
- skykooler 9y ago
  9 years. Python 3 was first released in 2008.
- jwilk 9y ago
  Python 3.0 was released on 2008-12-03. It actually become usable somewhere around 3.2/3.3, released in 2011/2012.
  - kstrauser 9y ago
    Wow! I hadn't thought about it, but Python 3 is older now (almost 9) than Python 2 (released on 2000-10-16) was when Python 3 came out.
  - collinmanderson 9y ago
    I think about it like: - 2008-2012: Becoming actually usable. - 2012-2016: Libraries porting over - 2016-2020: Applications porting over (more work needs to be done here. See http://portingdb.xyz http://portingdb.xyz )
- ubernostrum 9y ago
  Leaving out third-party open-source projects I contribute to, and projects I've been involved with as part of my work (both open and private), and just focusing on code from my own personal Python packages: By count of lines, 0.04% of Python code I've published exists only to deal with 2 vs. 3 issues. Of that code, 34% consists of importing and applying a decorator from Django that handles setting up either __str__() or __unicode__() on a Django model as appropriate. Tellingly, there are exactly two lines I could find that aren't that decorator and which deal with a str/unicode issue. And that's in code which doesn't just run on Python 3, it supports 2 and 3 in the same codebase.
i8472 9y ago
In an era where 32 hardware threads will soon be routine on the desktop, single-core Python 3 advantages are far too little too late. 2.7 will continue for reasons of massive legacy code and for new codebases, elixir or go make far more sense.
JupiterMoon 9y ago
Open page. Nothing works. Enable their scripts. First slide shows but nothing works - except the link to the pdf version. Why not give a link to the pdf version in a <noscript> element?
- giardini 9y ago
  Works for me! when I hit <enter> or right-arrow it goes to the next slide, <left-arrow> for previous slide.
  - JupiterMoon 9y ago
    Tried all of these - as well as space :(
- seanp2k2 9y ago
  Yeah, it's good info in an unfortunate format by default.
- nether 9y ago
  Works perfectly here. Press space to step through. Mac Chrome.
- gghhvgx 9y ago
  I'll never understand those who break the internet on purpose and then complain that nothing works, and that the people actually spending money and doing work should cater to their niche tastes. Please stop. Thanks.
  - pwdisswordfish 9y ago
    I'll never understand those who cannot serve a single page of static content without adding a bazillion of gratuitous hard dependencies on JavaScript libraries. Maybe if more people resisted the temptation to use the latest and shiniest frameworks where it isn't warranted, I wouldn't have to upgrade my otherwise perfectly functional hardware every five years because it just can't handle all of today's most fashionable abstraction layers over plain HTML. <http://motherfuckingwebsite.com/> http://motherfuckingwebsite.com/>
iandanforth 9y ago
Asyncio is the most important feature of 3.5+ imo. I'm not sure why this is buried at #8.
- metalliqaz 9y ago
  The new async features are kind of a mess. Many Python users just don't have the use case to make it worth digging in to it.
  - orf 9y ago
    But the ones that do absolutely love it. At least, I do.
- jessaustin 9y ago
  Perhaps this comment has something to do with that burial: "Not going to lie to you. I still don't get this." Personally, the most confusing thing about that code is that apparently return will wait on a yield from, which seems odd.
  - AgentME 9y ago
    Python 3.5+ supports the async/await syntax which is much easier to follow than yield from. I fully expected async/await to be item #1 of a list of Python 3 killer features over list comprehension doodads; it's surprising that it's entirely missing from this list!
jtchang 9y ago
Just wondering but what should you do if you decide to go with Python 3 and find a library you want to use that isn't compatible and you are short on time?
- metalliqaz 9y ago
  At this point in time, if you want to use a library and it isn't compatible with py3, then you probably shouldn't use that library. Essentially all actively maintained libraries are converted, and we are even starting to see libs that do not support py2.
  - ansgri 9y ago
    As a counterexample, there's ROS (Robot Operating System, which is not an OS actually but a middleware plus a lot of libraries), and it still doesn't support Py3 officially. There is some support in fact, but you probably don't want to have even more potential problems with ROS for not that big of a benefit.
- dr_zoidberg 9y ago
  That fear held me back 7 years ago when I started learning Python. In 2017, having worked in many projects, what I have to tell you is this: I never found such case where Python 3 wasn't supported, and I should've learned Py3 to begin with. YMMV, but the fear was unfounded back in 2010, and even more so today. There are very few projects without Py3 support, and most you'll find without Py3 support is because the project has been dead for quite some time.
  - xrange 9y ago
    >There are very few projects without Py3 support, and most you'll find without Py3 support is because the project has been dead for quite some time. One notable exception is FreeCAD for anyone who is looking to jump into a project to help with the transition from python 2 to 3.
- dom0 9y ago
  Nowadays it's more likely that a Python 2 user wants to use a library and finds it doesn't work on Python 2, because the developers never targeted nor tested on 2.
dlbucci 9y ago
I did not know you could append to a Path via "/", but that's really awesome! I also really love working with generators when I write Python. They are just such a simple idea that's very powerful and I miss them so much when I go back to javascript (I know javascript has them now, but I haven't written them, and they don't look as fluent as Python 3, where the large parts of the language design is based around them).
- rajathagasthya 9y ago
  > I did not know you could append to a Path via "/", but that's really awesome! I didn't know that too. It's pretty cool. Seems like they overload __truediv__ operator: https://github.com/python/cpython/blob/master/Lib/pathlib.py#L878 https://github.com/python/cpython/blob/master/Lib/pathlib.py...
  - lloeki 9y ago
    Homebrew does that in formulas (in Ruby), it's definitely neat.
- dekhn 9y ago
  can't say I'm thrilled about this sugar (override division operator in another context).
- Animats 9y ago
  Overloading operators for cute purposes is usually a misfeature. There was a fad for this in the early C++ days. I once wrote a marshalling library which overloaded "||", so that you could write p = stream || rec.a || rec.b || rec.c; and get an object which, if written, marshalled the record, and if read, unmarshalled it. The marshalling order was only specified once. Cute, but in retrospect, bad. Python's classic overload problem comes from using "+" for concatenate. For built-in vectors, "+" is concatenate, but for NumPy arrays, it's addition. You can use "+" between a NumPy array and a built-in vector. Does it add, or concatenate? ("|" is supposed to be the concatenate operator; it was added to ASCII to support PL/I. But decades of C have made it the bitwise OR operator to most programmers, so we're stuck. "_" is allowed within symbols, so that's taken. There's "⁀", character tie, but nobody can type it.) It seems to be best to restrict the math operators to math.
flavio81 9y ago
It seems i also can't scroll to the next page on this slide "because i refuse to upgrade to Python 3"...
morinted 9y ago
I really like the format strings in Python 3.6: https://docs.python.org/3/whatsnew/3.6.html#whatsnew36-pep498 https://docs.python.org/3/whatsnew/3.6.html#whatsnew36-pep49... Seems that this set of slides (which were very informative!) is for up to 3.5
- lottin 9y ago
  How many format strings does Python have already?
  - baq 9y ago
    https://pyformat.info/ https://pyformat.info/ should know, ask it
    - Sir_Cmpwn 9y ago
      This link does not mention f-strings, the feature in question. The answer is there are 3 ways to format a string: %, .format, and f-strings.
      - deathanatos 9y ago
        .format() and format string literals essentially share the same syntax, so I don't really think it's fair to bracket them out separately. You could sort of pull a retcon and say that .format() is the dynamic form of f'' literals. Having used the equivalent feature in JavaScript, this stuff is super handy. It also makes "printf" a lot nicer: print('I have {count} {color} {object}'.format(count=count, color=color, object=object)) print('I have {} {} {}'.format(count, color, object)) print(f'I have {count} {color} {object}') % had real issues, so I'm quite glad .format() came along.
flavio81 9y ago
TL;DR: The important stuff that makes a good case for Python 3: - Adittion of "yield from" allows easier programming with async I/O "a la " Node.js (using 'await') - Standarized annotations of function arguments and return values can help in the future for type checking, optimization, etc. Even more important stuff - Unicode can be used in symbols. You can now use Kanji characters in your function names, to annoy your coworkers and win the International Obfuscated Python Code Contest. Other stuff - Minor unimportant stuff that is definitely no reason alone for switching for Python 3.
- tutufan 9y ago
  Of those, only the async I/O stuff seems compelling. But compelling it is, at least as used in Curio. It feels like this is still shaking out, with the standard library and Trio (?) alternatives, but it looks really cool.
  - asdfgadsfgasfdg 9y ago
    If you work with international users full unicode support is very compelling.
    - loeg 9y ago
      Why do your users care about symbols internal to your code?
      - eyelidlessness 9y ago
        They don't, they care about `str` being unicode and developers not having to do additional work to support unicode strings.
        flavio81 9y ago
        Strings can be unicode in Python2, you start a unicode string with u". Python2 has full unicode support. While Python3 supports only unicode strings.
AndyMcConachie 9y ago
Read this and then realized a bug I was chasing in some Python 2.7 code was actually because I was comparing a Long with a String :) Thanks for helping me solve my bug dude!
ericfrederich 9y ago
From: http://www.asmeurer.com/python3-presentation/slides.html#55 http://www.asmeurer.com/python3-presentation/slides.html#55 ... why is this good: def dup(n): for i in range(n): yield i yield i ... but this one better? def dup(n): for i in range(n): yield from [i, i] ... it would seem you're needlessly creating (1): another level of generators, and (2) creating a real list
- jessaustin 9y ago
  Yeah at the very least this should be a tuple rather than a list: yield from (i, i) It does use fewer lines, but if that's the point then this would work: yield i; yield i
- maxerickson 9y ago
  I think for that example it doesn't matter, it is a poor illustration of yield from. In general `yield from` makes delegation inside a generator cleaner.
- kzrdude 9y ago
  Compare these instead: for i in range(n): yield i yield from range(n)
  - falcolas 9y ago
    Both seem quite readable, really. Seems similar to the usual "list comprehensions vs. for loop" arguments; to which I always think "use whichever is readable for the given code".
    - marcosdumay 9y ago
      The thing about "list comprehensions vs. loop" is that you can compose comprehensions, but you must edit loops to change them. I fail to see how anything similar would apply here.
    - kevin_thibedeau 9y ago
KerrickStaley 9y ago
One big thing that's missing from this list is the __traceback__ on exceptions, which pretty much does what you think it does. In Python 2, there's no way to access the traceback for an exception once you've left the `except:` block. This matters when you're using things like gevent; if one of your gevent greenlets throws an exception and you inspect the .exception attribute on it, you'll be able to get the exception message but won't know what line it came from. N.B. This is absent from Python 2 due to concerns with creating self-referential loops. The garbage collector got better in the meantime and the feature was never backported to Python 2.
- jsmthrowaway 9y ago
  Huh, I was almost sure you were wrong and that I'd done this before, but the frame does indeed "go away" once you leave the except block. Fascinating. In [8]: try: crasher() ...: except TypeError as e: ...: exc = e ...: In [9]: type(exc) Out[9]: TypeError In [10]: traceback.print_tb(exc) AttributeError: 'exceptions.TypeError' object has no attribute 'tb_frame' I can understand the concern, though it seems like there would be easier fixes than the garbage collector for that specific case.
- est 9y ago
  > there's no way to access the traceback for an exception once you've left the `except:` block Also in 2.4 if you assign a variable to a local inside a traceback it might leak memory.
KaiserPro 9y ago
thus, python did jump the shark. The biggest thing that python _needs_ is proper multithreading. The rest is nice noise.
alanfranzoni 9y ago
I still don't think that any of those new functions justifies the need of a total compatibility breakdown, like the one that was artificially induced from python2.7 to python3. Python3 is good, but should have happened as a smooth transition from python2.7. The way it was handled was just a mess, and still keeps polluting the Python world. Next time somebody asks what Java has over Python... here it is: nothing like the python 2 vs 3 mess.
- phire 9y ago
  Honestly, if they had just keep the print statement, the push back would have been almost non-existent. It was that one change that pushed python 3 from "some programs and libraries will need to be written" to "almost every single program and intro to python tutorial needs to change".
  - seanwilson 9y ago
    How hard would it have been to allow Python 2 and 3 code files to be mixed?
    - minitech 9y ago
      That’s a giant can of worms. One example problem: Python 2 has a type of class (old-style) that doesn’t exist in Python 3. What happens when you try to pass this type of class or one of its instances between the languages? There’s a bunch of stuff like that. You’d end up with a very weighed-down interpreter with a bunch of caveats if you ended up with one at all.
      - seanwilson 9y ago
        Would doing that then deprecating those features after 5 years or so not be better than what's happened with the Python 3 transition? I'm curious what options there are for how to make such a transition smoother.
        9y ago
mahyarm 9y ago
It's funny how the differences between python 2.7 & 3.x is less than swift 2 to 3, yet python stays in 2.7 land forever.
- saghm 9y ago
  Probably because there was a lot less Swift code than Python in the wild at the respective times each came out with the new version, so having everyone upgrade all the old, incompatible code was less daunting.
- deleted 9y ago
  [deleted]
jxramos 9y ago
Glad to see the Enum class made the list. We've put them to good use in our codebase, especially the Flags enum variant which gives as a powerful summary feature to annotated data samples with all the sorts of flagging information we want to tack around it.
maerF0x0 9y ago
@OP tag this 2014 https://github.com/asmeurer/python3-presentation/blob/gh-pages/slides.html#L1021-L1023 https://github.com/asmeurer/python3-presentation/blob/gh-pag... Feature 0: Matrix Multiplication Feature 1: Advanced unpacking Feature 2: Keyword only arguments Feature 3: Chained exceptions Feature 4: Fine grained OSError subclasses Feature 5: Everything is an iterator Feature 6: No more comparison of everything to everything Feature 7: yield from Feature 8: asyncio Feature 9: Standard library additions Feature 10: Fun (Unicode variable names etc...)
ptx 9y ago
The slides on chained exceptions (feature 3) are missing one thing, I think. The "raise from" example is not really a way to "do this manually", but rather a way make explicit the relation between the two chained exceptions (as can be seen in the traceback messages), which is quite helpful. The first example says that one error occurred, we tried to handle it, but then another error occurred in the handling. E.g. "Failed to find eggs in refrigerator. Tried to buy eggs, but tripped and broke leg." The syntax in second example should be used when the exception in turn causes a larger process to fail, e.g. "Failed to make pancakes due to a failure to find eggs in refrigerator."
assafmo 9y ago
I'm not touching python like it was fire since it threw YouHaveAMissingTabSomewhereException at me 6 years ago. And it always pisses me off to see a python source code all lower case. Someone would think upper case letters cost money and underscores are a must like a lemon in a corona. Am I the only one?
- tripzilch 9y ago
  Who can't touch fire? No ... ? But yeah syntactic whitespace was a thing to get used to for myself over 10 years ago as well. It's no big deal and it works great (imho).

331 points by bkudria 9y ago

cpburns2009 9y ago

This presentation could use some navigation buttons.

edoceo 9y ago
The buttons are on your keyboard. Swipe on touch interface
- web007 9y ago
  I don't expect to have to use my keyboard to navigate a webpage. It's also not discoverable or prompted in any way.
  - coldtea 9y ago
    Using the arrows keys for the slides has been a standard since the dawn of web presentations, a decade or so ago. Doesn't have to be more discoverable imho. As soon one finds it out, they can use the knowledge for any other presentation they chance upon -- and presentations remain clutter free, without prompts and extra navigational buttons for the rest.
    - jonknee 9y ago
      > Using the arrows keys for the slides has been a standard since the dawn of web presentations, a decade or so ago. So have arrows icons you can click to switch slides... Such as on Slideshare (coincidentally a decade old!).
      - jessaustin 9y ago
        If the icons disappear as soon as I use my keyboard or tap, that wouldn't be too terrible.
howard941 9y ago
For some reason only the arrows and page up/down work. Sometimes. edit 4 grammar

xutopia 9y ago

I'm impressed how much Python seems stuck on older versions. What went wrong?

rjgonza 9y ago
Python 3 came about with a split in the community.
- vapemaster 9y ago
  what is the split that has to do with 2vs3? Really it just seems like some devs are still griping about fairly minor backwards compatibility issues. the whole print vs print() is obviously a straw man. but the major one, strings, unicode, and bytes, changes for the good in py3. the fact that people have to go back and "un-hack" their code is time, effort, and more commits but it's for the best. <rant> i think the real split is between CPython + C-Extensions and the JIT (PyPy,Numba) gang for heavy lifting in python. I for one wish Guido would embrace the effort of integrating the GILectomy into CPython and make python thread parrallism real for CPU bound work as opposed to the high overhead multiprocessing approach. Also, including mypy in the stdlib to make genuine optional static typing would make python a defacto standard for much of what it does now without the "we love python but...." production code pain points. </rant>
  - Jach 9y ago
    I don't think the whole print vs print() problem is a straw man (or similarly the division operator switch) apart from being relatively easy to fix or avoid by importing from __future__, but crucial in understanding the attitude the language owners have for its users. They could have kept print and introduced printf(), but they didn't. They didn't even get rid of the statement vs. expression distinction, which would have been a compelling reason to break print (and would give us real lambdas). The split you mention is real, but it's existed even longer than the 2vs3 split. All the various alternate Python implementations that have come and gone or are still around with the exception of Numba were started pre-3k. I wouldn't even argue that upstream was necessarily wrong not to prioritize performance and more specific use cases (like certain production uses, or scientific uses (a lot of begging to finally get the @ operator)), it just didn't matter as much for a long time. But things are different now. There are many other very expressive and much faster (either dynamically typed or static) languages in competition that lessen Python's effectiveness at reducing dev time in exchange for more hardware. Without a more serious focus on performance, Python will be driven only by momentum. That can last a long time, and is essentially the end point anyway when performance is "good enough" compared to the close alternatives, but it's not a great look when there's still much that could be done.

matthewmacleod 9y ago

Ruby's 1.8 to 1.9 transition seemed to go much smoother - I'm curious what the difference is. Just down to what is essentially better source comparability I guess.

mattnewton 9y ago
My guess is it could also have to do with the communities. Anecdotally, the limited sample of ruby-istas I have interacted with tend to have more tolerance of churn for improvement's sake whereas the people attracted to python are more interested in stability because they are focused on some other need that the code is mearly an ends to.
- dom0 9y ago
  And/or because many Python projects have completely insufficient testing which means that any change that might break anything anywhere can go undetected.
dragonwriter 9y ago
Ruby 1.8 to 1.9 was a similar mess for a shorter period of time, and not because it was handled better, but because there was less diverse entrenched code and subcommunities to deal with: when Rails and popular Rails libraries worked, most of the community could move; Python had a whole lot more that had to be addressed, the curse of it's broader success. (Also, being already expression-oriented, Ruby didn't have to deal with running into problems where a core feature was a statement that couldn't be used in contexts limited to expressions; fixing that is inherently painful.)
- TylerE 9y ago
  Didn't Ruby 1.9 also offer a meaningful performance boost as well? Whereas early Py3 was actually about 5-10% slower than Py2.
dagw 9y ago
Ruby managed to get their major libraries ported to 1.9 much much quicker. RoR basically worked from day 1. Python 3 was without both numpy as django for well over a year. Also the first few releases of python 3 weren't very good. It wasn't before 3.2 before you could really use python 3 in production and not before 3.5 before most of the interesting features where in place. Basically a lot of early momentum was lost due to this and and it never really regained it.

gshulegaard 9y ago

Quite a nice presentation! But I just wanted to point out that the title is a bit presumptuous. I don't refuse to upgrade to Python 3, it's that the default Python for most distributions is 2 (sometimes as far back as 2.6). If you want to write a user-space tool with Python you can either require additional dependency setup, bundle a full interpreter with your package, or just write Python 2.7/6 code that is forward compatible with Python 3...in which case I still can't use the new features of 3. At the end of the day, the continued slow adoption of Python 3 today is because ecosystems move slowly. Not to mention the original releases of Python 3 were really rough around the edges (such as being slower than Python 2.7 until ~3.4) which definitely contributed to the slow adoption in the early years.

mixmastamyk 9y ago
Python 3 has been available on most dists for 5-10 years.
- euyyn 9y ago
  macOS Sierra today tells me its python is 2.7
  - mplewis 9y ago
    And Python 3 is available on macOS Sierra via Homebrew.
    - msie 9y ago
      Hilarious since Homebrew is written in Ruby...do you have to upgrade Ruby too?
  - seanp2k2 9y ago
    You should use homebrew to join the pythonistas club on Mac. Better yet, use https://github.com/asdf-vm/asdf/blob/master/README.md https://github.com/asdf-vm/asdf/blob/master/README.md to get all the pythons, rubies, nodes, and golangs you want. Ubuntu 18.04 LTS plans on Python 3-only, but Ubuntu has been shipping Python 3.x since 13.04 and 3.x is the default with 2.x available since 16.04 , so in terms of shipping Python 3 code, Ubuntu 12.04 LTS (the last LTS where you can't assume it has a python 3) EOL'd on April 28 2017. Assuming $WORK follows EOL depredations, you should be fine for Ubuntu.

iainmerrick 9y ago

The new keyword-only arguments look great, but it looks like it relies on adding a " * " parameter that allows any number of arguments. What if I want the safety of keyword-only arguments, but I don't want varargs? Is there a way to do that?

arximboldi 9y ago
This is covered in the link. Just put a * without a name, as in def foo(*, x=None, y="") (Edit) The specific slide: http://www.asmeurer.com/python3-presentation/slides.html#16 http://www.asmeurer.com/python3-presentation/slides.html#16
- iainmerrick 9y ago
  Aha, thanks! I misunderstood -- I assumed the lone * would parse and discard any number of arguments. This is a very good feature, but a weird syntax!
- dozzie 9y ago
  Oh my, it looks atrocious. Almost every time I see something introduced in Python 3 I have an impression that current Python envies Perl its baroque semantics, except that Perl usually tries to guess what the programmer meant, while with Python the relationship is reversed: the programmer needs to guess what the language wants. Python's main selling point was simplicity of syntax and semantics that preserved its high-level language status. This simplicity is no longer present in 3.x line.
  - dom0 9y ago
    Python 2 is a vastly more complex language compared to Python 3. Just try to name the basic classes of types that exist in Python 2. Hint: Cannot be counted on two hands.
    - dozzie 9y ago
      Well, try this for me, especially that you didn't use searchable terminology, so it's hard to confirm what you're saying. And then tell how much of that is important for typical code.

Fej 9y ago

Does anyone use 2.x by choice? I've only seen it required as to not break legacy code.

jonknee 9y ago
I'd wager most people don't even think about it and just use whatever comes on their OS (almost always 2.x).
RodericDay 9y ago
This shouldn't be downvoted, it's a legit question. I hear some people really really prefer `print as statement`, but I've never seem them in real life.
- mixmastamyk 9y ago
  I do, but I understand the reasoning behind why it was changed. So I made a snippet in my editor and moved on with my life, haha. New print is now easier to to type than the old.
- seanp2k2 9y ago
  Just from __past__ import print_statement I really hope someone makes this work. I literally laughed and thought that it was a troll the first time I saw the future print import and that being used as a compelling reason that I should switch to Py3.
  - mixmastamyk 9y ago
    Consistency and keyword args are useful.
    - pishpash 9y ago
      "11. There should be one-- and preferably only one --obvious way to do it." from the Zen of Python. Somebody intentionally misread it as, "There should be only one way to do it." They obviously made a grave mistake. Same with many 2->3 changes.

SeanDav 9y ago

Alternative view titles: Zero - The Number of Applications that Can only be Developed in Python 3 or 7456324 - The number of companies that only use Python 2.x Although these made up titles are slightly tongue-in-cheek, they do server to illustrate that for me at least, I do not have a compelling reason to switch to Python 3.

teilo 9y ago
That's also a meaningless argument. It's true of any turing-complete language.
- SeanDav 9y ago
  > "That's also a meaningless argument. It's true of any turing-complete language." Title 1 of course. Title 2 is a far more compelling reason to stay with Python 2.x. If I program for fun, then Python 3 is definitely worth playing around in, but for professional development, everything I do in Python is done in Python 2.x. That is not a theoretical argument, that is fact.
  - minitech 9y ago
    > for professional development, everything I do in Python is done in Python 2.x. That is not a theoretical argument, that is fact. And everything I do professionally in Python is done in 3.x as of this January. Also fact! Industry standards sometimes move slowly, but they are moving.
  - teilo 9y ago
    That is only relevant if there is no significant professional Python 3.x development taking place. There is, in fact, significant 3.x development taking place, and that number is growing - exactly as one would expect. And by significant, I mean upwards of 40%. So, except for corporate inertia, or the rare can't-live-without libraries that have yet to be ported to 3.x (see: http://py3readiness.org http://py3readiness.org), there are no compelling reasons to stick with Python 2.x for new projects.

signet 9y ago

My personal favorite is native support for IP addresses, introduced in python 3.3[0]. Makes IP math and address validation so much easier. [0] https://docs.python.org/3/library/ipaddress.html https://docs.python.org/3/library/ipaddress.html

bpicolo 9y ago
To be fair, you can grab the original. https://pypi.python.org/pypi/ipaddress https://pypi.python.org/pypi/ipaddress
jsmthrowaway 9y ago
Anybody who likes that will like subnettree, too, which offers a C-based Patricia tree for IP addresses. In the past, I've gotten a lot of mileage out of this library: https://pypi.python.org/pypi/pysubnettree https://pypi.python.org/pypi/pysubnettree Last time I played with it, it didn't like Python 3 or ipaddress, though. I see a recent upload, so maybe they addressed that.
est 9y ago
> address validation just try: socket.inet_aton
- pwdisswordfish 9y ago
  That doesn't seem to support IPv6 at all. And doesn't let you do much with a parsed address either.

NuSkooler 9y ago

How old is Python 3 now? I've always used Python for a "miscellaneous task" language, and still do... and even I find "...because you refuse to upgrade" a bit insulting. If I used it for something serious, even more so. The way 2.x -> 3.x was handled is/was/will is an absolute disaster. Upgrading simple scripts is a non-issue. Larger projects seem to always be a horrible pain.

skykooler 9y ago
9 years. Python 3 was first released in 2008.
jwilk 9y ago
Python 3.0 was released on 2008-12-03. It actually become usable somewhere around 3.2/3.3, released in 2011/2012.
- kstrauser 9y ago
  Wow! I hadn't thought about it, but Python 3 is older now (almost 9) than Python 2 (released on 2000-10-16) was when Python 3 came out.
- collinmanderson 9y ago
  I think about it like: - 2008-2012: Becoming actually usable. - 2012-2016: Libraries porting over - 2016-2020: Applications porting over (more work needs to be done here. See http://portingdb.xyz http://portingdb.xyz )
ubernostrum 9y ago
Leaving out third-party open-source projects I contribute to, and projects I've been involved with as part of my work (both open and private), and just focusing on code from my own personal Python packages: By count of lines, 0.04% of Python code I've published exists only to deal with 2 vs. 3 issues. Of that code, 34% consists of importing and applying a decorator from Django that handles setting up either __str__() or __unicode__() on a Django model as appropriate. Tellingly, there are exactly two lines I could find that aren't that decorator and which deal with a str/unicode issue. And that's in code which doesn't just run on Python 3, it supports 2 and 3 in the same codebase.

i8472 9y ago

In an era where 32 hardware threads will soon be routine on the desktop, single-core Python 3 advantages are far too little too late. 2.7 will continue for reasons of massive legacy code and for new codebases, elixir or go make far more sense.

JupiterMoon 9y ago

Open page. Nothing works. Enable their scripts. First slide shows but nothing works - except the link to the pdf version. Why not give a link to the pdf version in a <noscript> element?

giardini 9y ago
Works for me! when I hit <enter> or right-arrow it goes to the next slide, <left-arrow> for previous slide.
- JupiterMoon 9y ago
  Tried all of these - as well as space :(
seanp2k2 9y ago
Yeah, it's good info in an unfortunate format by default.
nether 9y ago
Works perfectly here. Press space to step through. Mac Chrome.
gghhvgx 9y ago
I'll never understand those who break the internet on purpose and then complain that nothing works, and that the people actually spending money and doing work should cater to their niche tastes. Please stop. Thanks.
- pwdisswordfish 9y ago
  I'll never understand those who cannot serve a single page of static content without adding a bazillion of gratuitous hard dependencies on JavaScript libraries. Maybe if more people resisted the temptation to use the latest and shiniest frameworks where it isn't warranted, I wouldn't have to upgrade my otherwise perfectly functional hardware every five years because it just can't handle all of today's most fashionable abstraction layers over plain HTML. <http://motherfuckingwebsite.com/> http://motherfuckingwebsite.com/>

iandanforth 9y ago

Asyncio is the most important feature of 3.5+ imo. I'm not sure why this is buried at #8.

metalliqaz 9y ago
The new async features are kind of a mess. Many Python users just don't have the use case to make it worth digging in to it.
- orf 9y ago
  But the ones that do absolutely love it. At least, I do.
jessaustin 9y ago
Perhaps this comment has something to do with that burial: "Not going to lie to you. I still don't get this." Personally, the most confusing thing about that code is that apparently return will wait on a yield from, which seems odd.
- AgentME 9y ago
  Python 3.5+ supports the async/await syntax which is much easier to follow than yield from. I fully expected async/await to be item #1 of a list of Python 3 killer features over list comprehension doodads; it's surprising that it's entirely missing from this list!

jtchang 9y ago

Just wondering but what should you do if you decide to go with Python 3 and find a library you want to use that isn't compatible and you are short on time?

metalliqaz 9y ago
At this point in time, if you want to use a library and it isn't compatible with py3, then you probably shouldn't use that library. Essentially all actively maintained libraries are converted, and we are even starting to see libs that do not support py2.
- ansgri 9y ago
  As a counterexample, there's ROS (Robot Operating System, which is not an OS actually but a middleware plus a lot of libraries), and it still doesn't support Py3 officially. There is some support in fact, but you probably don't want to have even more potential problems with ROS for not that big of a benefit.
dr_zoidberg 9y ago
That fear held me back 7 years ago when I started learning Python. In 2017, having worked in many projects, what I have to tell you is this: I never found such case where Python 3 wasn't supported, and I should've learned Py3 to begin with. YMMV, but the fear was unfounded back in 2010, and even more so today. There are very few projects without Py3 support, and most you'll find without Py3 support is because the project has been dead for quite some time.
- xrange 9y ago
  >There are very few projects without Py3 support, and most you'll find without Py3 support is because the project has been dead for quite some time. One notable exception is FreeCAD for anyone who is looking to jump into a project to help with the transition from python 2 to 3.
dom0 9y ago
Nowadays it's more likely that a Python 2 user wants to use a library and finds it doesn't work on Python 2, because the developers never targeted nor tested on 2.

dlbucci 9y ago

I did not know you could append to a Path via "/", but that's really awesome! I also really love working with generators when I write Python. They are just such a simple idea that's very powerful and I miss them so much when I go back to javascript (I know javascript has them now, but I haven't written them, and they don't look as fluent as Python 3, where the large parts of the language design is based around them).

rajathagasthya 9y ago
> I did not know you could append to a Path via "/", but that's really awesome! I didn't know that too. It's pretty cool. Seems like they overload __truediv__ operator: https://github.com/python/cpython/blob/master/Lib/pathlib.py#L878 https://github.com/python/cpython/blob/master/Lib/pathlib.py...
- lloeki 9y ago
  Homebrew does that in formulas (in Ruby), it's definitely neat.
dekhn 9y ago
can't say I'm thrilled about this sugar (override division operator in another context).
Animats 9y ago
Overloading operators for cute purposes is usually a misfeature. There was a fad for this in the early C++ days. I once wrote a marshalling library which overloaded "||", so that you could write p = stream || rec.a || rec.b || rec.c; and get an object which, if written, marshalled the record, and if read, unmarshalled it. The marshalling order was only specified once. Cute, but in retrospect, bad. Python's classic overload problem comes from using "+" for concatenate. For built-in vectors, "+" is concatenate, but for NumPy arrays, it's addition. You can use "+" between a NumPy array and a built-in vector. Does it add, or concatenate? ("|" is supposed to be the concatenate operator; it was added to ASCII to support PL/I. But decades of C have made it the bitwise OR operator to most programmers, so we're stuck. "_" is allowed within symbols, so that's taken. There's "⁀", character tie, but nobody can type it.) It seems to be best to restrict the math operators to math.

flavio81 9y ago

It seems i also can't scroll to the next page on this slide "because i refuse to upgrade to Python 3"...

morinted 9y ago

I really like the format strings in Python 3.6: https://docs.python.org/3/whatsnew/3.6.html#whatsnew36-pep498 https://docs.python.org/3/whatsnew/3.6.html#whatsnew36-pep49... Seems that this set of slides (which were very informative!) is for up to 3.5

lottin 9y ago
How many format strings does Python have already?
- baq 9y ago
  https://pyformat.info/ https://pyformat.info/ should know, ask it
  - Sir_Cmpwn 9y ago
    This link does not mention f-strings, the feature in question. The answer is there are 3 ways to format a string: %, .format, and f-strings.
    - deathanatos 9y ago
      .format() and format string literals essentially share the same syntax, so I don't really think it's fair to bracket them out separately. You could sort of pull a retcon and say that .format() is the dynamic form of f'' literals. Having used the equivalent feature in JavaScript, this stuff is super handy. It also makes "printf" a lot nicer: print('I have {count} {color} {object}'.format(count=count, color=color, object=object)) print('I have {} {} {}'.format(count, color, object)) print(f'I have {count} {color} {object}') % had real issues, so I'm quite glad .format() came along.

flavio81 9y ago

TL;DR: The important stuff that makes a good case for Python 3: - Adittion of "yield from" allows easier programming with async I/O "a la " Node.js (using 'await') - Standarized annotations of function arguments and return values can help in the future for type checking, optimization, etc. Even more important stuff - Unicode can be used in symbols. You can now use Kanji characters in your function names, to annoy your coworkers and win the International Obfuscated Python Code Contest. Other stuff - Minor unimportant stuff that is definitely no reason alone for switching for Python 3.

tutufan 9y ago
Of those, only the async I/O stuff seems compelling. But compelling it is, at least as used in Curio. It feels like this is still shaking out, with the standard library and Trio (?) alternatives, but it looks really cool.
- asdfgadsfgasfdg 9y ago
  If you work with international users full unicode support is very compelling.
  - loeg 9y ago
    Why do your users care about symbols internal to your code?
    - eyelidlessness 9y ago
      They don't, they care about `str` being unicode and developers not having to do additional work to support unicode strings.
      - flavio81 9y ago
        Strings can be unicode in Python2, you start a unicode string with u". Python2 has full unicode support. While Python3 supports only unicode strings.

AndyMcConachie 9y ago

Read this and then realized a bug I was chasing in some Python 2.7 code was actually because I was comparing a Long with a String :) Thanks for helping me solve my bug dude!

ericfrederich 9y ago

From: http://www.asmeurer.com/python3-presentation/slides.html#55 http://www.asmeurer.com/python3-presentation/slides.html#55 ... why is this good: def dup(n): for i in range(n): yield i yield i ... but this one better? def dup(n): for i in range(n): yield from [i, i] ... it would seem you're needlessly creating (1): another level of generators, and (2) creating a real list

jessaustin 9y ago
Yeah at the very least this should be a tuple rather than a list: yield from (i, i) It does use fewer lines, but if that's the point then this would work: yield i; yield i
maxerickson 9y ago
I think for that example it doesn't matter, it is a poor illustration of yield from. In general `yield from` makes delegation inside a generator cleaner.
kzrdude 9y ago
Compare these instead: for i in range(n): yield i yield from range(n)
- falcolas 9y ago
  Both seem quite readable, really. Seems similar to the usual "list comprehensions vs. for loop" arguments; to which I always think "use whichever is readable for the given code".
  - marcosdumay 9y ago
    The thing about "list comprehensions vs. loop" is that you can compose comprehensions, but you must edit loops to change them. I fail to see how anything similar would apply here.
  - kevin_thibedeau 9y ago

KerrickStaley 9y ago

One big thing that's missing from this list is the __traceback__ on exceptions, which pretty much does what you think it does. In Python 2, there's no way to access the traceback for an exception once you've left the `except:` block. This matters when you're using things like gevent; if one of your gevent greenlets throws an exception and you inspect the .exception attribute on it, you'll be able to get the exception message but won't know what line it came from. N.B. This is absent from Python 2 due to concerns with creating self-referential loops. The garbage collector got better in the meantime and the feature was never backported to Python 2.

jsmthrowaway 9y ago
Huh, I was almost sure you were wrong and that I'd done this before, but the frame does indeed "go away" once you leave the except block. Fascinating. In [8]: try: crasher() ...: except TypeError as e: ...: exc = e ...: In [9]: type(exc) Out[9]: TypeError In [10]: traceback.print_tb(exc) AttributeError: 'exceptions.TypeError' object has no attribute 'tb_frame' I can understand the concern, though it seems like there would be easier fixes than the garbage collector for that specific case.
est 9y ago
> there's no way to access the traceback for an exception once you've left the `except:` block Also in 2.4 if you assign a variable to a local inside a traceback it might leak memory.

KaiserPro 9y ago

thus, python did jump the shark. The biggest thing that python _needs_ is proper multithreading. The rest is nice noise.

alanfranzoni 9y ago

I still don't think that any of those new functions justifies the need of a total compatibility breakdown, like the one that was artificially induced from python2.7 to python3. Python3 is good, but should have happened as a smooth transition from python2.7. The way it was handled was just a mess, and still keeps polluting the Python world. Next time somebody asks what Java has over Python... here it is: nothing like the python 2 vs 3 mess.

phire 9y ago
Honestly, if they had just keep the print statement, the push back would have been almost non-existent. It was that one change that pushed python 3 from "some programs and libraries will need to be written" to "almost every single program and intro to python tutorial needs to change".
- seanwilson 9y ago
  How hard would it have been to allow Python 2 and 3 code files to be mixed?
  - minitech 9y ago
    That’s a giant can of worms. One example problem: Python 2 has a type of class (old-style) that doesn’t exist in Python 3. What happens when you try to pass this type of class or one of its instances between the languages? There’s a bunch of stuff like that. You’d end up with a very weighed-down interpreter with a bunch of caveats if you ended up with one at all.
    - seanwilson 9y ago
      Would doing that then deprecating those features after 5 years or so not be better than what's happened with the Python 3 transition? I'm curious what options there are for how to make such a transition smoother.
      - 9y ago

mahyarm 9y ago

It's funny how the differences between python 2.7 & 3.x is less than swift 2 to 3, yet python stays in 2.7 land forever.

saghm 9y ago
Probably because there was a lot less Swift code than Python in the wild at the respective times each came out with the new version, so having everyone upgrade all the old, incompatible code was less daunting.
deleted 9y ago
[deleted]

jxramos 9y ago

Glad to see the Enum class made the list. We've put them to good use in our codebase, especially the Flags enum variant which gives as a powerful summary feature to annotated data samples with all the sorts of flagging information we want to tack around it.

maerF0x0 9y ago

@OP tag this 2014 https://github.com/asmeurer/python3-presentation/blob/gh-pages/slides.html#L1021-L1023 https://github.com/asmeurer/python3-presentation/blob/gh-pag... Feature 0: Matrix Multiplication Feature 1: Advanced unpacking Feature 2: Keyword only arguments Feature 3: Chained exceptions Feature 4: Fine grained OSError subclasses Feature 5: Everything is an iterator Feature 6: No more comparison of everything to everything Feature 7: yield from Feature 8: asyncio Feature 9: Standard library additions Feature 10: Fun (Unicode variable names etc...)

ptx 9y ago

The slides on chained exceptions (feature 3) are missing one thing, I think. The "raise from" example is not really a way to "do this manually", but rather a way make explicit the relation between the two chained exceptions (as can be seen in the traceback messages), which is quite helpful. The first example says that one error occurred, we tried to handle it, but then another error occurred in the handling. E.g. "Failed to find eggs in refrigerator. Tried to buy eggs, but tripped and broke leg." The syntax in second example should be used when the exception in turn causes a larger process to fail, e.g. "Failed to make pancakes due to a failure to find eggs in refrigerator."

assafmo 9y ago

I'm not touching python like it was fire since it threw YouHaveAMissingTabSomewhereException at me 6 years ago. And it always pisses me off to see a python source code all lower case. Someone would think upper case letters cost money and underscores are a must like a lemon in a corona. Am I the only one?

tripzilch 9y ago
Who can't touch fire? No ... ? But yeah syntactic whitespace was a thing to get used to for myself over 10 years ago as well. It's no big deal and it works great (imho).