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.
New features you can't use unless you are in Python 3
191–200 of 264 posts
Re: New features you can't use unless you are in Python 3
#192One 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…
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
#193I 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".
Re: New features you can't use unless you are in Python 3
#194Earlier 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.
Re: New features you can't use unless you are in Python 3
#195Re: New features you can't use unless you are in Python 3
#196Just 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…
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
#197My 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://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
#198How 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.
Re: New features you can't use unless you are in Python 3
#199Earlier 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.
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
#200Feature 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...)