Serious question: Why would anyone still be doing anything with Python 2.7 except porting the last remnants of their code base to 3.X?
"Why should I switch to 3.x?" You haven't provided a reason to switch.
I don't know if it was your intent, but your question assumes that Python 3.x is the "default", and that there is some sort of obligation to use it instead of 2.x. That's a premise that a lot of people do not share.
As an example, they may not view 3.x as an "upgrade", but as a different language. So you might as well ask anyone doing work in one language "What reason is there for you to still use language X? Why not use language Y?"
As long as some team is willing to support Python 2.7 (and possibly backport non-breaking features), 2.7 will live on, and there is no reason it should go away. The only strong reason for many to switch to 3.x is "I have a library I need to use that is supported only in 3.x". Or "I need to hire developers, and I can't find people who know 2.x, but I can find those who know 3.x"
Languages are tools. As long as the tool is more than adequate for the task, the burden is on others to justify a change in tool.
Writing new code in Python 2 is completely nuts and just makes everyone's life harder (including your own).
And when it makes someone's life harder, they will change. If it's too late for them and affects them, they will have themselves to blame.
This, really, is the only reason for people to change to Python3. Yet people keep evangelizing all its great features, etc as if the existence of a much better language suddenly obligates everyone to switch to it.
It's fine to point out potential repercussions of not switching now. But moralizing it is counterproductive.
Just to put a stake in the ground, when did FreeCAD start? When did 3.0 come out, along with the announced end-of-life date for 2.7?
https://en.wikipedia.org/wiki/FreeCAD
...Python 3.0 was released in 2008:
https://www.python.org/download/releases/3.0/
...It looks like the port of FreeCAD to Python 3 stared in 2015:
Because Python 3.X is not backwards compatible and we have millions of lines of production code in Python 2.X.
I believe the common subset of Python 2 and 3 was created to ease that transition.
That's far from the only pitfall. For instance some of the P2 stdlib relies on implicit coercion to bytestrings whereas the Python 3 version has been properly converted to unicode (I discovered that when I tried to disable implicit coercion in one of the codebases I work with for cleanup/migration purposes).
So cross-platform string handling is not just a matter of properly splitting bytestrings and textstrings, but also finding out where "native strings" need to remain.
I hate it because Python2 is a flaming garbage heap, and 2.7 is what happens when you piss on a flaming garbage heap to put it out, whereas Python 3 is actually a nice language to work in, but until OS distributions get their act together on the Python front, some stuff is going to continue sucking.
I worked in Python 2 daily for about a year and a half (doing side stuff in 3), and switched over to Python 3 a few months ago. It's just not that big of a deal. Maybe it's because I'm pretty shielded from the madness of strings vs. bytes (or just import from future).
The lack of UnicodeDecodeErrors.
Just because there is a 90% overlap doesn't mean one can't be a pile of trash (i think that's a bit harsh though). The improvements under the hood are huge (unicode, no 'new-style' classes, speed improvements etc) as well as syntactic sugar means that as time goes on Python 2 looks worse and worse.
----------
try:
import queue as queue
import Queue as queueThey couldn't even consistently name portions of the standard library. Python 2 has a few random things where the first letter is capitalized while 99% of everything else isn't.
There's all sorts of things like this, where poor design decisions cause you to sit there with question marks appearing over your head. That 10% takes Python from being a joy to work with to being incredibly frustrating. I would be happy if I could just work exclusively in 3, but making sure things are backwards compatible to 2.7 is a frequent source of driving me up the wall.
>Maybe it's because I'm pretty shielded from the madness of strings vs. bytes (or just import from future).
If you lose this shielding it will help you understand my vitriolic response as well.
Not all of us have hobby-sized projects on the go.
I'd really like to understand this from a technology transition management standpoint.
If you'll allow a strained analogy, the 2.7 to 3.x transition appears in retrospect like an exercise in herding cats, because the transition was done using cat-herding style incentives. What should have been done differently to make the transition into greyhounds chasing a rabbit? What should the rabbit have been?
Any technology that lives long enough eventually has to transition its customer base. I'm trying to learn to identify rabbits.
K&R C no longer compiles. Not that the C to C++14 transition is what I would call an example of greatness, but it is somewhere along the success spectrum.
Seriously, you will someday need to transition your customer base. How do you plan to do it?
foo@virt-ubuntu:~/c$ gcc --version
gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
foo@virt-ubuntu:~/c$ cat 'k&r.c'
#include<stdio.h>
int main(argc, argv)
int argc;
char *argv[];
{
puts("hello, world!");
return 0;
}
foo@virt-ubuntu:~/c$ gcc 'k&r.c'
foo@virt-ubuntu:~/c$ ./a.out
hello, world!Now, you have 2.7 apps that are very mature, stable and reliant on lots of little things. Okay, big job.
Now let's throw another wrinkle into this. You can pay good money to develop your next feature, or to port your system to 3.x. One adds real value to your customers and improves your bottom line. One lets you say you are on 3.x and gets nods of approval from random programmers.
What do you think a business is going to do? Exactly.
When will we eventually port? Sometime shortly after 3.x becomes the overall standard. THIS is actually what we are seeing right now, which is great, but that hasn't been the case up until the last year or so.
>Any technology that lives long enough eventually has to transition its customer base.
While true, this costs money, time, and effort. So you better be damn well sure there is a good ROI that is something more than "This code that nobody but programmers see is more elegant and properly structured".
There's a reason banks are still using COBOL after all...
Slightly tangential but system ruby is stuck at 2.0.0p648 (which is well into unsupported) and perl v5.18.2 (which I don't know the status support of but is old enough to wonder).
They might as well rip them out and make them an optional package like CLI dev tools for possible backwards compatibility needs (easily installable either with something like xcode-select --install or the java/javac stubs).
I don't really see the benefit of a Python 3.6 to 2.7 transpiler/compiler though. More realistically I would require that all new code be both 2 and 3 compatible, for when the eventual migration will happen. This isn't necessarily and easy task either, but then you're only depended on the Python project, not some random transpiler that might not see further development.
- I like lambda a, b: a + b syntax better than lambda a_b: a_b[0] + a_b[1]
- I prefer map/reduce/filter to return lists rather than iterable
- I prefer dict.keys/values/items to return sets/lists rather than iterables, unless I call dict.iter[keys/values/items]
I wonder why isn't "lambda (a, b): a+b" allowed?
l = lambda (a, b): a + b
l((1, 2))
With regard to the second point, I also would have liked a more "gradual" step there, I find myself (especially in REPL environments) often doing `list(map(sth, sth))`. A `mapi`, `filteri` or something like this would probably not be zenny enough.
Both don't pose very strong points for python 2 > 3.
These seem like OK reasons, but I find myself continuously needing the destructuring idiom in lambdas, while these introspection and documentation concerns are just not there for me.
However tuple-parameters being an exception to rules (such as args and kwargs not being usable with them) is more compelling. And allowing destructuring only in lambdas would be weird, because they wouldn't be normal function objects any more.
Unless the destructuring was only syntactic sugar for the translation in the PEP? But that's again inconsistent.
Python 2.7 has imap and ifilter in itertools. Python 3 could have imported them into global namespace to simplify usage without breaking map/filter functions.
This. I wonder if you could have a switch to make ipython print out the list instead of the iterator object at the REPL.
uh, `lambda a,b: a + b` works in 3.6...
> I prefer ... to return lists rather than iterable:
Why? I'm just curious. Iterables are much more flexible than lists, unless you need random access... at which point list(...) works pretty well.
It already works this way.
Python 3.6.1 (v3.6.1:69c0db5, Mar 21 2017, 17:54:52) [MSC v.1900 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> add = lambda a, b: a + b
>>> add(1, 2)
3
You can produce a list from any iterable by passing it to `list()`. You cannot take a materialized list and make it lazy though.
> I prefer dict.keys/values/items to return sets/lists rather than iterables, unless I call dict.iter[keys/values/items]
Why? Sets are mutable. What happens when you mutate dict.values? It doesn't make sense.
>>> add = lambda a, b: a + b
>>> t = (1, 2)
>>> add(*t)
3
That works perfectly well in Python 3, you're thinking about `lambda (a, b)` aka `def foo((a, b))` aka tuple-parameter unpacking.
> - I prefer map/reduce/filter to return lists rather than iterable
1. why? 2. just wrap them in a list() call?
> - I prefer dict.keys/values/items to return sets/lists rather than iterables, unless I call dict.iter[keys/values/items]
You are aware that Python3's keyviews and itemsviews are sets but P2's are just lists right?
Python 2 is like FORTRAN. It might not be sexy anymore but it's not going anywhere.
Except Fortran is, and is going to be, further developed. (So, if a new useful programming concept appears, or a major design mistake is discovered, it always can be patched.)
Python 2 is going to be abandoned in 2020. Python 3 will supersede it.
But Python 2 is Free Software, so as long as people like it, they can keep improving it:
So I don't think there's much to be gained.
The 3 syntax and new features are not massively better than the sweet spot hit by 2, they're not even incrementally better. They're just massively more complicated.
So the cost/benefit ratio of Python 2 to 3 just isn't there. People are changing up because it's "the done thing" not because they really gain anything.
I was surprised as hell when I realized I wouldn't use Python 3, but it is a rational and considered opinion.
Elsewhere in the thread xrange has mentioned Tauthon. And there are more Python 2 interpreters than just the main C Python.
Pypy may stop supporting 2 syntax officially, but I doubt it. Since it never changes, there's next to no overhead to keeping it available.
And further, if your language isn't changing then maintenance and debugging become much easier. Conceivably the codebase(s) can asymptotically approach 100% correctness.
O_o