61–70 of 264 posts
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.
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.
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.
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?
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?
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.
I'm impressed how much Python seems stuck on older versions. What went wrong?
It was source-level incompatible with older code so it couldn't be used as a smooth transition like... almost any other language upgrade I've ever seen. Breaking code like this was a big mistake in my opinion - it resulted in many people sticking on the old version for code and library compatibility. There are still libraries which don't work on Python 3, though now fairly few of them. In addition to that, the unicod…
Ruby released the source-incompatible Ruby 1.9 just months before Python 3. IIRC most versions of Swift have been source-incompatible with each other. Even a language as buttoned-down as C++ has made source-incompatible changes[1]. I have no idea where people got the notion that Python invented the idea of breaking changes, but it just isn't so.
[1]: https://stackoverflow.com/questions/6399615/what-breaking-ch...
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?
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
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.
Asyncio is the most important feature of 3.5+ imo. I'm not sure why this is buried at #8.
Earlier quoted context omitted.
It was source-level incompatible with older code so it couldn't be used as a smooth transition like... almost any other language upgrade I've ever seen. Breaking code like this was a big mistake in my opinion - it resulted in many people sticking on the old version for code and library compatibility. There are still libraries which don't work on Python 3, though now fairly few of them. In addition to that, the unicod…
Most Python 2 codebases probably have a lot of unknown bugs in them related to Unicode. The code will work fine for cases where the inputs are ASCII, but will subtly break if unicode inputs are provided. In term's of code reliability, Python 3's approach is much more sane.