Live data from Hacker News

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

asmeurer.com

191–200 of 264 posts

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

#191

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

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.

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!

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

#192

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…

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.

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

#193
post #168

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…

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

2to3 should manage all that sort of low hanging fruit automatically. The real meat comes in the byte array string logic preservation or breakage.

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

#194

Earlier quoted context omitted.

How hard would it have been to allow Python 2 and 3 code files to be mixed?

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.

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.

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

#196
post #62

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?

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 pro…

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

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

#197
post #30

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

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

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.

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

#198

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.

I used to think like you, but when i started actually using Python 3 it all was a lot less worse than i've expected it to be from reading Hacker News comments. YMMV, but converting existing code for me usually didn't amount to more than adding parentheses around print statements. The proper support for unicode alone was enough of a reason to upgrade for me.

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

#199
post #148

Earlier quoted context omitted.

> This is just silly. It will take at least 100x more effort to rewrite the project in Java than it would to upgrade to Python 3. Yes, but in return it will bring a 10x performance improvement in lots of areas, and the option of a whole lot more sturdy statically checked code.

if performance is a problem, then start rewriting the critical pieces right now because python 2 also isn't for you. mypy is a much better type system than Java, btw, if that's what you're after.

>if performance is a problem, then start rewriting the critical pieces right now because python 2 also isn't for you.

You say it as if that would be a strange position to be it, but it's a common situation. A lot of time you start with the faster to prototype / more familiar language, and outgrow it.

That's what companies do after they grow so much that a language such as Python/Ruby/PHP is not doing it for them anymore or wont be doing it soon with their growth trajectory.

And you don't have to be Twitter scale either.

Even if you have moderate growth, you might find that with a different language, you can use 1/10 the servers, and thus drastically lower your operating expenses.

So, when some of those companies face the jump to Python 3, and the required rewriting, they often decide to bite the bullet, and do a fuller rewriting in another language (like Java, but Golang is also getting many Python converts, including e.g. Dropbox IIRC), that will give them much more bang for their buck.

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

#200
@OP tag this 2014 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...)

Post reply on HN