Good. The glacial migration from Python 2 to 3 is one of the worst things about an otherwise fantastic ecosystem. The tide is turning though, with Django having already dropped support for 2, and now with Numpy too hopefully Python 2 can be properly consigned to the history books.
For people wondering why it's been like this for almost a decade(!) since Python 3.0 was released: Python 3.0 was actually terrible. It lacked many critical things, and was riddled with bugs and security flaws until 3.3, which was released 4 years after 3.0. This cemented in many people's minds the idea that Python 3 was a bad thing. Python 2 was and is a fantastic programming language, so it was a very high bar to move up from. Python 3 has come a long way since then, Python 3.6 is now a decent step up from 2.7.
Frankly, I still haven't seen a single reason to switch to Python3 beyond the fact that the original authors have gotten bored of providing security and bugfix updates and will stop in 2020. That's it.
The only thing in the last decade or so of Python3's existence that even got me slightly interested in using it was asyncio, and after looking into it a bit, it frankly seems like more trouble than its worth.
I know Python 2.7 extremely well. It works perfectly fine for just about everything I use it for. It's STABLE. For the tasks I use it for, it runs faster than Python3... (Not that performance is my greatest concern when using Python.) So, please tell me -- why on earth is it a good thing that people are trying to kill off Python2? What exactly makes Python 3.6 a "decent step up" from 2.7? I'm still at the point of thinking, as you said, that Python3 is a bad thing.
why on earth is it a good thing that people are trying to kill off Python2?
Because the community is fragmented and that weakens language adoption, productivity, and enjoyment.
The 2-3 schism in Python has been a pain to deal with for years. I use Python casually here and there, but I'm so sick of trying to do something quickly in Python and finding out that I'm on a machine that only has 2 but the module I need is only for 3 or having the bulk of my app written in 3 but the only version of a module I need is for 2.
Same goes for examples you find on the Internet to do a particular thing. Ooops, it's 2.x syntax/modules so you have to fix it up for 3. Ooops, it's 3 syntax/modules so you have to fix it up for 2.
For the good of any computer language, old versions need to eventually die off.
>For the good of any computer language, old versions need to eventually die off.
I would say instead: for any good computer language, new versions need to retain compatibility with old versions. Every single system I run has python 2.7 (including my brand new Macbook running latest OS X). Luckily I don't need numpy, and I can probably do without python at all if I have to.
Compare to perl: I can run old perl scripts on basically any system without having to worry about it breaking. I do all of my server scripting in perl for this reason.
Perl6 is incompatible with Perl5, so they're also going through a similarly painful transition.
Everyone waxes lyrical about how Python 2.x was "good enough and why would you change it", but there were several things in Python 2.x that were objectively awful (unicode was broken, iterator variables can leak to the outer scope, division of integers producing integers, xrange, raw_input, mixed indentation "working", etc). And while no single issue alone would justify Python 3.x, the combination of all of these issues as well as some other semantic problems justified the need for Python 3.
Of course, that being said, Python 3 also had some issues that it took several versions to iron out.
The classic division operator makes it hard to write numerical expressions that are supposed to give correct results from arbitrary numerical inputs. For all other operators, one can write down a formula such as xy*2 + z, and the calculated result will be close to the mathematical result (within the limits of numerical accuracy, of course) for any numerical input type (int, long, float, or complex). But division poses a problem: if the expressions for both arguments happen to have an integral type, it implements floor division rather than true division.
-----------------------
To guarantee the correct mathematical behavior in python2, one would probably have to write:
def true_math_div(a,b) :
if type(a) is int or type(a) is long :
a = float(a)
if type(b) is int or type(b) is long :
b = float(b)
return a/b
as a and b could be int, float, complex, or some object defining the method __div__.
I wouldn't call it awful, but it is slightly annoying. In a dynamically typed language it's hard to know apriori if a variable is an int or a float with a whole number value and you end up having to write x/float(y) all over the place just to make sure your code does what you want it to do.
The new case of / always being float division and // always being integer division just makes everything more explicit.
This particular language quirk I don't think has anything to do with dynamic typing: it's equally annoying in C-style languages where 3/2 and 3/2.0 mean different things.
They have it already.
Perl6 is about 10 years old, had at least 4 virtual machines. When it was announced people thought perl 5 was obsolete. And in the same time came RoR.
A few years(like 7 maybe?) ago a some new developers took over perl5 and added some really interesting new features. That made some perl6 developers unhappy, wanting to focus community around perl6. Perl5 developers believe a completely new language should have a different name. Some suggested renaming perl5 perl7. Then there was a website perl11.org redirecting visitors to scala-lang.org. That was about 3 years ago. Since then - I don't care:)
Perl6 will have to find itself a niche. The one once occupied by perl5 - a ducktape of the web is now taken by js.
So, a long transition is better than a remote perspective of unknown transition.
Good point, I didn't realise Perl6 was in a similar situation. However it seems that adoption of Perl6 is very low, so I suspect Perl5 isn't going to get killed off any time soon.
Very little new stuff is being developed in Perl, period. I don't know anyone working in Perl who is not maintaining existing codebases. I haven't heard Perl proposed for anything new in over a decade. That further reduces the motivation to move to Perl 6.
It depends what you're using it for. Certainly it wouldn't make sense to use it for web stuff. However I use perl exclusively for server-side "shell" scripting, and it excels at that. More powerful than bash, less compatibility worries than python (I've had issues even between 2.* versions). If I have perl5.* on a server my scripts work everywhere. I regularly start new server-side scripting projects using perl, including a recent webpage-to-video conversion batch script. To be honest there is no other platform that I would even consider using for this kind of thing. Is there even anything that comes close to perl's cross-platform, rapid development, stability and general compatibility?
That's because of binary API changes, and only affects Perl modules with C parts in them. Source compatibility has been preserved at least across the entire 5.x line.
The plan for Perl6 is to eventually run Perl5 code with the `use v5` statement. You just don't throw 30 years worth of CPAN into the garbage bin. Meanwhile, Perl5 is being actively developed, new minor versions are released at least once a year, people are actively improving the language via extensions and even the core is evolving slowly but steadily. I don't thing it will be abandoned any time soon. Perl6 is being developed separately, mosty by other people.
It's really sad. In retrospect they certainly should have named it something different. The Perl 5 community could have progressed, maybe even made a Perl 6, while the NGPerl skunkworks project continued independently for 15 years.
I never quite understood why the division of integers resulting in integers was a problem.
I get that for people with no knowledge of programming whatsoever it can be confusing, but it's standard behavior in nearly every typed language.
In C/C++, you divide an Int and you get an Int. If you want floating point division, you divide by a float. Problem Solved.
Almost EVERYTHING else could have been done with slow migration, or simply documenting the odd or quirky behavior.
Iterator variable leaking is just a result of poor programming.
Raw_input vs input could have been solved by slowly deprecating input. Or just left as is.
xrange is the same story.
It all seems like someone just decided to throw their hands up in a fit, throw their toys on the ground, and make a new Python. I enthusiastically jumped at Python 3 in the begining, then ran into problems, and crawled back to my 2.7 and decided I could let others fight the stupid cult war that was coming over 2 vs 3. I'd rather use a tool that works than change all my code over someone's idea that newer is better.
> I never quite understood why the division of integers resulting in integers was a problem [...] but it's standard behavior in nearly every typed language.
And hence why it's a problem in Python. If you have a function like
def foo(a, b):
return a / b
What are the types of a and b? You don't know. Sure, you could check with isinstance, but now you've broken the illusion of duck typing. The argument is that Python should just do "the right thing". Just because 3/4==0 in most languages doesn't justify repeating that mistake. Not to mention that float(a)/float(b) -- aside from being incorrect in the general case -- is ugly as hell.
> Iterator variable leaking is just a result of poor programming.
I think it's a language bug. Why? Imagine if you could do this in C:
for (int a = 1; i <= 3; a++)
foo(a);
printf("%d\n", a);
People would think this is clearly a language bug because it breaks the scoping semantics (not to mention common sense). Now, you could argue that Python supports this sort of nonsense so it's "fine":
# a is not defined
if something:
a = 1
else:
a = 2
print(a)
But the reason that works is because otherwise Python would need to have JS-like "var" syntax to declare a variable. Personally I think that'd be better, but the for-loop situation is different.
> raw_input vs input could have been solved by slowly deprecating input. Or just left as is. xrange is the same story.
And this is how PHP ended up having three different string escaping functions for SQL statements. The first one (escape_string) was broken, so they added real_escape_string, and then they needed to handle connection-specific quirks so they added mysqli_real_escape_string.
Some people still use escape_string even though it's broken -- and the language devs cannot fix it because "that would break users".
The issue is that "xrange" does the right thing, but the seemingly-more-correct (unless you happen to know about "xrange") "range" does the wrong thing (create a list rather than a generator, which is inefficient). Same thing with "raw_input" doing the right thing, but "input" being completely wrong (and an attack vector because it's just a glorified "exec").
And instead of behind-the-scenes lazily creating the range, so you have a generator that reifies when its modified and has a nice __str__ etc they go make incompatible changes; got it! ;)
I know rather too much about how CPython and other VMs work under the hood and am in no mood to try and save the day any more. I still use python, but the latest stuff around MyPy and async io just make me despair frankly. I think rust+go will probably pick up a lot of people who used to care deeply about python. So it is.
Perl is a weird language language for you to cite when we're talking about languages that do major transitions well. Perl 6 was created because Perl 5 was an evolutionary dead end, took 15 years, has no adoption, and Perl 5 usage shrunk tremendously in the meantime. Not saying this glibly as I love Perl and I hope Perl 6 sees some adoption, but come on now. Also remember that Perl 5 itself was nearly a complete rewrite from 4.
Exactly my thought regarding the need to evolve as a language. Perl is mostly dead because it didn't keep up with the times and I say that as a person who spent a tremendous amount of time learning and using Perl. The Schwartzarian transform was a beautiful thing to behold.
Perl is born to solve portability and limitation problems of shells (csh, sh, ksh*), awk and sed. People who do not live on the command line can not appreciate the power of perl.
Huh. I guess it's one of those cases where once you have a thing, you wonder how you could have gone 20 years without it. :) Although, to be fair, I only started working with Perl (beyond one-liners on the shell) in 2012.
Unlike Python 3's relation to Python 2, Perl 6 is genuinely a new language. It would make little sense for the community to discontinue Perl 5 and push for Perl 6.
In retrospect it probably would have been better for the community if they'd given Perl 6 a new name.
Yeah, I really don't get this Python mindset at all. I have out in the wild both Scheme code that's approaching 30 years old, and Perl code approaching 20 years old, running on commercial systems. There's no real need for constant version churn.
Perl example is a bad one given Perl 6 having near zero adoption, and being incompatible with 5. And this is hardly "constant" version churn. This was a major event for Python to fix some long-running issues that needed fixing, but could only be done with an incompatible version.
Over the course of 2014, the "pip" project alone went from 1.4.1 to 6.0.6(!) through 2 minor releases, 1 major release, and 9 point releases, 6 of which were on the same day as another point release (it's called a "release candidate", people). They included regressions such as "segfaults on Windows at every invocation", "freezes if the specific server pypi.org is not reachable", and dropping support for a python version that was less than 2 years old at that point. They also introduced a third package archive format into the ecosystem.
The library ecosystem is the problem, and it's what's driving the language churn.
It’s a balancing act. Breaking compatibility creates work, unfixed bugs and design flaws create work, which is more work varies. Retaining compatibility can be, in sum, a harmful decision.
That's a really poor reason to kill an old version. To be clear, I FEEL YOUR PAIN. However, new isn't legit just because it's new.
As a non-Python pro, I cannot say why one version over another. However, arguing that the old one is bad just because it is inconvenient isn't valid.
As someone who struggles with versions of Python on my Mac and on production servers (and with code that runs on 2.7 and 3.6+), as far as I'm concerned (as a pragmatic solutions-first person goes), I cannot discern the difference between ancient Python and new Python.
There are really few languages with such impact as Python. So we cannot blame the Python community for this situation as they probably really labored over their decisions regarding compatibility and versions. But in retrospect, I would have preferred they killed off the old version long ago. It would definitely have made life better for the users in the long run.
I think the argument here is that Py3 is better for many people (Unicode-by-default was generally the reason, but these days it's also the numerous language improvements, e.g. async/await). For those who find themselves on the fence with no particular personal reason to go either way, though, going where the others are is a legitimate way to choose.
What we often forget are the large numbers of people who just use Python (or any other tech tool) as a means to an end.
In this case I'm included. Python is not my first, second, or third love. But it is the most available and the simplest tool available to glue things together. CSVs, json, web apis (private and commercial), etc., are all so easy to do with Python.
So my guess is that there are a lot of users who may not even realize the benefits that Python3.x gives vs 2. "We" don't know or care about features we don't need. But we do feel the pain of modules that only work for one version.
In hindsight, I would have voted for a hard break from 2->3 perhaps 2 years ago. I suspect the ultimate human time effort would have been less than we waste now straddling or stumbling with two versions.
*I can feel the pain of devs that have to deal with Python 2 and 3. To me the beginning of the ugly Python 3.0 announcement was too off putting, it stopped my interest in Python and I went back to PHP, Java and later also NodeJS, Go.
In comparison PHP and Java always successfully transitioned to new versions, keeping it backward-compatible and do baby steps instead of a big incompatible cut. PHP canceled the ill fated PHP6 fork, and went from PHP 5.2 then up to 5.6 and then jumped to PHP7 (as several PHP6 books got published about an alpha version).
Language with a rocky transition (mostly due to incompatible syntax) were C#/dotNet 1->2, Perl 5 -> 6, Lua 5.1 -> 5.3, Ruby 1 -> 2, Swift 1 -> 2 -> 3, Rust 0.x -> 1, and more
And? So did PHP 5.x. So do all languages. That's what I mentioned with "baby steps".
You can run PHP3, PHP4 and PHP5 projects with little or no change at all, code dating back to 1990s with PHP7. If you cared a bit and adjusted your code over the years, most changes are announced many versions ago and got deprecated. E.g the original MySQL API had been deprecated for a decade or so years, and only got removed with v7, yet it's easy to update the code to the newer APIs, as it was possible since early 2000s, when the newer API got introduced and stayed unchanged since then. And you could use a shim too.
PHP and Java (and several other languages) have really kept an eye on backwards compatibility, you cannot deny that or paint it in another light.
I was responding to "keeping it backward-compatible", which it did not do. In any case, Python 3 is not exactly a brand new language, many codebases can be adjusted to run on both engines without much effort. I don't think the difference is as stark as you've painted it.
Sure, but the community could continue to reject Python3 instead as it had been doing for years. It seems like it is catching on a bit now, but I hadn't really seen any good reason for it other than the upcoming EOL.
The NumPy project has supported both Python 2 and Python 3 in parallel since 2010, and has found that supporting Python 2 is an increasing burden on our limited resources;
That's a real team saying that they just can't support 2 major versions of the language any longer.
That is like the biggest fake argument ever. There is plenty of resources and Python 2 support is neither a burden nor this burden in any way increasing. The are plenty of people ready to step up to continue Py2 support (Even I would be glad to help).
This is a pure political decision based on ideology.
As the codebase grows, you need to maintain 2 growing codebases, how is that not increasing the burden?
Official support will be dropped by 2020, by then you will be relying on the community (who ?) to provide bug and security fixes. I'm not aware of anybody stepping up and declaring they will take over maintenance.
At this point, insisting on python 2 is the ideological "side". There's no practical nor realisitic reasoning behind it. Major parts of the community are moving to python 3 and dropping python 2.
You can stay with python 2 and maintain the language / libraries, but don't begrudge those that move on.
The resources aren't "code" but people and time. You have a limited set of folks who consistently contribute and become reviewers/committers. This is all based on volunteer time - no one is paying these folks to do it. So, asking these folks to divide their limited volunteered time between multiple versions of python is unfair. I think this is the right decision to take.
If you feel you have "plenty of resources" you can fork the python2 version of numpy and maintain it.
> There is plenty of resources and Python 2 support is neither a burden nor this burden in any way increasing.
Aside from what others have said, NumFOCUS is woefully underfunded. If you're interested in seeing continued development of NumPy and other amazing scientific Python packages, you should think about contributing!
Python would have lost popularity and would have eventually died without Python 3. Being a scripting language with a relatively low barrier to entry has always been among its selling points. Text processing is a very common use-case for such languages. In a Unicode world, you can't really have a language that is supposed to be easy to use yet requires contortions and has major pitfalls in simply handling text.
Yep, I'm always surprised by the number of people of people here who dismiss the usefulness of unicode. Not "dismissing" the hard way, but simply saying it's not a problem. I understand that we may have a lot of western/english people here but, unicode for me is a life saver. For example, I work on stuff for french speaking people, and I need the euro sign. In that very simple case, unicode already solve many issues : I don't have to convert between ISO-8859-1, ISO-8859-15, CP-1252 anymore, whatever my database uses, I just enforce unicode. Moreover, I can have french comment in source code (that's very important because sometimes we're talking about laws and some of our technical terms in those laws are not translated in english).
(I understand that in this particular case, I could have enforced ISO-8859-15 as well, but the crux of the matter is that with unicode built in python3, I don't have to think about it anymore)
And now my customer is copy/pasting additional information from documents coming from other countries as well...
You do realize unicode has been "built into Python" pretty much since the beginning (Python 2.0, 17 years ago), right?
The main difference is that unicode has a more efficient internal storage since Python 3.3+ (a neat technical detail), and that mixing bytestrings and unicode will fail with an explicit error since 3.0+ (a good idea IMO).
But that Python 2.7 didn't support unicode is simply FUD.
I have moved away from Python 2.7 because unicode support was not good enough.
Not good enough means I had to prefix every single string with "u" to make sure it's unicode. It was especially painful with code like this :
logger.debug("Name of the person I'm debugging {}".format(name))
forgetting the "u" simply lead to various crashes if the name had characters that could not be encoded in whatever the debug was piped to. Always thinking about the "u" was nothing I had the time to.
Well now you have to prefix b"" instead for bytestrings. The argument works both ways -- there's no magical improvement that happened in Python 3 (except that nice storage optimization in 3.3 that I mentioned above).
It's actually good practice to be explicit about the type, and write b"" and u"" always (easier on the person reading the code). The u'' literal prefix was re-introduced in 3.3 for this reason.
It doesn't because strings and text are a lot more common than bytes. Yours is a really weird line of argument - that the 3.x changes and what's in 2.7 are fundamentally equivalent and thus the changes are outright unnecessary and that the people who made them just got it wrong and did it for no apparent reason or benefit. I get that someone might not like what they did or how they did it but your take should give you pause just by its general improbability.
I don't think I am. In this thread you're repeatedly making the point that 2.7 supported Unicode and the difference is mostly technical details of things like internal representation and/or a matter of prefixes or whatnot.
This just isn't true. The fundamental change is - in Python 2, strings are bags of bytes and in Python 3 strings are collections of Unicode codepoints and you need to go through an encoding to convert to and from bytes. This is a big (and necessary) deal. No amount of debating the finer points of implementation, feature retention or reintroduction, etc is going to make that difference not matter.
The person you replied to didn't claim Python 2 doesn't support unicode. 'Bytestrings' has what is wrong with Python 2 neatly summarized in a single word (and this, incidentally, is a term the Python documentation avoids these days because it's bad). 3 is true but not really related to the topic at hand. 4 is, I think, outright wrong. As to 5, I'm not sure why you would even want to defend that. It's not what the poster said and even if they had said it, they'd be just wrong - it's not 'FUD'. That is just you being grumpy and rude.
I don't think anyone claimed it didn't support Unicode. Only that it allowed mixing bytes / strings and the default type most people used from the beginning was str. That's a trap that they'll regret the moment they actually need to handle something outside of Latin-1.
Lots of python 2 code out there fails because the default option was simple but bad. I know, because my name broke the CI pipelines in a few different projects.
Let's be honest, A lot of peoples experience with Python is restricted to the North America.
For these folks encountering anything other than ASCII is pretty uncommon.
Personally, I've worked on a Python 2.x project deployed in heavy industry across the globe including Japan and the number of times we had Python 2 unicode nightmare issues was too many to mention.
> Frankly, I still haven't seen a single reason to switch to Python3 beyond the fact that the original authors have gotten bored of providing security and bugfix updates and will stop in 2020. That's it.
It seems pretty clear now that 3rd party library developers are going to stop releasing packages that support 2.x and target only 3.x. Isn't that a bigger problem for Python 2.7 hold outs?
Originally, I was not super excited about Python 3. I liked "print" as a keyword. I liked the space efficiency and speed of latin-1 strings by default. I did a lot of network protocol stuff and bytes() was a pain to use. I knew how to use the 'u' prefix to get unicode when I needed. However, after using Python 3 for a few years now, I find Python 2 clumsy. Print as a function is better. Unicode works better. The implementation is just as fast or faster than Python 2 and getting faster every release. If you tried Python 3 a few releases ago, you should give it another go. It has matured a lot.
> Isn't that a bigger problem for Python 2.7 hold outs?
Yes, but it seemed like libraries (such as NumPy here) were mainly switching because of the EOL of Python2 rather than for any actual benefit provided by Python3. I've considered that as more of "Python 3 is a bad thing" by splitting the ecosystem further, and creating additional churn and rework of existing projects. Thus my question of why people seem to think this is a good thing now -- i.e. what has changed in Python 3.6 that they're happy to do this now when they were pissed off about it a couple years ago?
I've gotten a couple interesting responses here, and I hope for more. I wasn't really aware of f-strings -- that does seems like a nice-to-have feature -- and I wasn't aware of improved JSON serialization performance either.
> If you tried Python 3 a few releases ago, you should give it another go. It has matured a lot.
* Not only is print better as a function (I can now call print in a lambda!) doing anything beyond just printing variables (e.g. printing to a stream/file or suppressing the final newline) is both more straightforward and more readable. Also print(xxx, end="", flush=True) is my bae.
* API-wise keyword-only parameters are absolutely fantastic, even (especially!) for non-default params.
* Extended unpacking, and the ability to unpack in collection literals, make the language much more "expressive" (in the sense there are more cases where you can make do with just expressions) which is very convenient.
Thanks for the keyword-only parameters mention. I'm a Py3 fan so have been looking down this thread for inspiration of features I've missed. I've often wanted to use keyword arguments for readability but without supplying a default - this is just the ticket.
There are some great things about Python 3, and then there are some things that are more subjective. But we have to ask at what cost? Breaking compatibility has required developers to spend huge amounts of time porting and worrying about compatibility that they could have spent on other things. Many of the best features of Python 3 could be introduced in a backwards compatible way. Further, the language itself could have advanced much faster if it stuck with compatible changes. We could have had microthreads or a JIT by now.
Even if you like "print" as a function, is it really so important to wipe out the huge inventory of working Python 2 code and stall Python development for a decade? Python 3 is a tragedy.
> That is asinine bullshit and you should be ashamed. ... The development of Python never stalled, it barely even slowed.
Thanks for the language, but the only thing I'm ashamed of is Python's lost opportunities. How many thousands or perhaps millions of hours of developer time was spent on compatibility or maintaining two versions? What if that energy was directed on the improving the language instead. There's no question that it would be further along than it is now.
Of course I have, they were what I was referring to. If we didn't have to deal with this python 2/3 schism, there's a solid chance they'd be part of mainline python by now.
I haven't jumped into Python3 yet (for work/legacy reasons), but I'm really looking forward to nested exceptions and pathlib. Also, even when just working in English, unicode (or special classes for strings) were really annoying when interfacing with other libraries like Qt or databases.
I think you're right, only this wouldn't require breaking compatibility. It doesn't even require a python upgrade, you could just make a base class that remaps nicer named functions to the standard ones, like baseclass.is_lower_than = baseclass.__lt__
You're probably right. Sadly, the vast majority of the python upgrades probably did not require breaking compatibility. Or if they did, they weren't worth it. I understand that iterators are arguably better than lists and print should arguably be a real function, but those advantages are far too small to justify breaking compatibility.
Why is the super().__init__() comment dead below me? In Python 2 you had to do something like super(ClassName, self).__init__(), which is more ridiculous.
This could be because someone flagged the comment. If you believe there’s been a mistake you can vouch for a comment from comment’s page. I did vouch for x14 already—being able to shorten parent’s method calls into super().methodname() minor syntax sugar though it may be is one of the things I’m really looking forward to when I switch to Python 3 at my agency.
> Yes, but it seemed like libraries (such as NumPy here) were mainly switching because of the EOL of Python2 rather than for any actual benefit provided by Python3.
Actually if you ever wrote code that you wanted to make backwards compatible with Python 2.7 is a nightmare. The fact that they did not even wait until 2020 before depreciating it is a testament to that.
> I've considered that as more of "Python 3 is a bad thing" by splitting the ecosystem further, and creating additional churn and rework of existing projects. Thus my question of why people seem to think this is a good thing now -- i.e. what has changed in Python 3.6 that they're happy to do this now when they were pissed off about it a couple years ago?
I don't know about others, I always been supporting Python 3 since 3.4. I feel like many people were complaining about Python 3, but never used it, then eventually started using and realized that it is not so bad.
> I may do that.
You should, is much more enjoyable experience. Perhaps because you're so used to Python 2, you don't notice, but Python 2 has a lot of warts that accumulated over the years.
There should have been more innovation, making Python 3 compelling enough for Numpy use to deprecate Python 2 in 2010 for obvious, noncontroversial technical reasons. Instead there has been a thoroughly unpleasant and glacially slow transition between "we have to support Python 3 for bleeding edge users" to "we have to support Python 2 for retro users".
This is an ancient argument because no one can convince you that you need 3 for your use case. All I can do is say why I like it, and list reasons that probably don't apply to you or you would have switched already.
For example, print and division made more sense to me in 3, judging from friends who taught 2 and said those were always sticky for some students in every class. Intuitive lowers the barrier to entry. (But 2 is probably more intuitive to you because it's second nature to you by now.)
Unicode--when I would test some tiny scripts with Chinese characters or weird ciphers--was pretty easy out of the box in 3.
On systems that only support 2 I find myself slipping in basically a 'from future import all the things.'
These are admittedly mostly cosmetics. But cosmetics matter for noobs like I was, or maybe still am.
I guess 3 also fixed ambiguity in corner cases for error handling? Never came up for me so I don't know much about that one.
You probably just don't have those use cases?
Two people could use distinct subsets of python and neither is using it wrong. Meaning... there could be reasons many of us want 3 that simply don't apply to you. Which sucks, because you get hit with switching costs to help the rest of us.
I think that's the recipe for an endless debate with two reasonable sides.
I will say py2 was already fragmented without 3. PaiMei only ran on... 2.4 maybe? You'd find weird projects that you liked that would then get abandoned. Suddenly you're shimming them all or running four versions. I think 3 woke people up to this as a problem--by making it much harder to patch and way more universal. That made the project more conscious about future and backwards compatibility. Those dividends will only be seen over time. I hope they vest but can't prove how or if they have.
I hope this is helpful... Just know that I'm not saying you're wrong to want to use something that works for you. Switching costs are a real thing, I know it sucks to feel dragged along. But py3 is a lot better for me and others, possibly because we're using the language for different things.
It's pretty hard to make a case for transitioning from something that works pretty well to a new thing in general. The nicer the old thing is, and the wider it's been adopted, the harder the sell. That's just the way it is.
Too look at it a different way... If I see the benefit of & would like to make a change, actually making the change competes with all of my priorities. I'm under the impression that Python is used by many people who use reliable things with APIs that don't change often (I mainly of thinking of Bash & some Posix OS). I can see why they wouldn't be fans of making changes.
Personally I like using newer things, all other things being equal. That's mostly because it's easier to chat about recent stuff with people learning the same lessons I'm learning. Almost every time I ask a C/Bash/*NIX question on a Stack Exchange site, the question gets marked as a duplicate, links to a question with answers I had already, but failed to understand. That happens much less when inquiring on newer topics.
EDIT: More seriously py2's print handles parens in unpredictable ways if you have open questions about types, which has been a nightmare for me on multiple occasions.
I trust you that you never encountered them, but I did.
The whole point of my original post was begging for people to realize their personal experiences aren't universal. The py3 changes solve something for us, help us read code and avoid bugs, it's not just a novelty fetish, I promise. Unfortunately you only have our word for it...
The change to string handling justifies it for me. Writing `u’foo’` everywhere is a pain, and the rest of the 2.7 model is extraordinarily prone to runtime errors. With 3.6, I don’t have those problems.
Yeah, I was pretty much sold on Python 3 when I stopped having to use the `codecs` module to read my files and when it would strictly enforce the separation between `bytes` and `str`, rather than having to manually track what sort of sequence I was dealing with.
Yes, yes. My Python life is mostly about impelemnting odd protocols with Twisted. Will probably get serious about asyncio soon, but I have a lot of historical Twisted to deal with ATM.
I've noticed that the "Who cares about Python 3" types are not the people working on the kinds of problems I am. So my conclussion is that for many kinds of problems the benefits of Python 2 are kind of meh, so people stay in their comfort zone. For some kinds of problems, Python 3 is a huge, huge win over Python 2. Whether or not someone is a Python 3 advocate says more about the kinds of problems they work on than anything else.
How is the Twisted Py3 support coming along in practice? It looks like they are steadily ticking items off the todo list, but is it ready for production use yet?
Most people didn't learn to work around unicode issues during the 2.7 time frame.
Many third party modules tended to explode spectacularly with encode/decode errors, when they were fed non-ascii strings, when used by people who write using all these funny characters.
Just the correct handling of strings in Python 3 alone is a hell of a reason to switch to it.
Let's not forget the joy of third party libraries that wouldn't fail, but rather silently convert, your data because they had hidden ascii asumptions...
I have a contrary anecdote: for the sorts of work I do, having to distinguish between strings and bytes makes using Python3 more difficult, and more prone to errors.
I mostly deal with network protocols, lots of numeric content, and scarcely any non-English text.
But I appreciate other people have different needs.
> For the sorts of work I do, having to distinguish between lists and dictionaries makes using Python 3 more difficult and more prone to errors. I mostly deal with lists, and scaresely any dictionaries.
Yes, and while performance on some tasks has gotten worse, on others it has got much better - JSON serialisation in particular, which was huge for us. Python 3.7 will be faster again in many areas.
Sure, you can continue using Python 2, and it's going to work for you. I guess you can also keep using Windows XP (no reason not to use it beyond the fact that Microsoft has gotten bored of providing security and bugfixes), and code using your PS/2 keyboard...
USB for keyboards is slower (noticable for some types of gaming) and does not support over 6-key rollover. So PS/2 is superior (for keyboard, not mouse) and not dead. Ever noticed around 2010 motherboards stopped shipping with PS/2, but today most for desktops come with a single PS/2 port again?
Generally speaking, Python 3 is actually faster now. I am a bit surprised that no one else has commented on this. There was a talk about performance recently (https://www.youtube.com/watch?v=d65dCD3VH9Q). To sum it up, some parts are slower and other parts are faster, and the reasons depend on two questions:
1: Is it using a lot of small ints? Python 3 changed int from being small int to long int, and for work which deals with massive amount of ints this will result in a slow down. If for some reason you want to use a pure Python implementation of AES rather than using hardware acceleration (generally builtin to the CPU) or a C implementation, or the one built in the linux kernel, then you will hit the performance test that get the biggest negative difference between python 2.7 and master. Then there is numpy which uses C modules that can happy do things as small ints.
2: Bytes -> Unicode. Libraries that are Unicode unaware will run faster than libraries that are Unicode aware. The feature to understand that "ö" is a Swedish letter and not several characters does cost some CPU time. For parsing where per character manipulation is relevant (like say HTML), such parsing will be a bit slower in python 3.
Practically everything else is faster now in python 3.
> What exactly makes Python 3.6 a "decent step up" from 2.7?
The language and the standard lib improved a lot. There are so many improvements, it would be impossible to list them all after so many years of progress...
Just to name a few of the bigger improvements, that I have discovered recently:
* The typing module lets you add type annotations to your code and write code like this:
class User(NamedTuple):
id: int
name: str
age: int
def remove_user(u: User) -> None:
# ...
fred = User(123, 'fred', 42)
# ...
remove_user(fred)
Frankly, I still haven't seen a single reason to switch to Python3
This typically means one of two things:
1. You've never really looked at the features added in the Python 3.x release series, or
2. You develop abandonware which plans never to upgrade any part of its platform ever, for any reason, and so no conceivable new feature would be sufficient to convince you to do an upgrade.
At this point (1) is untenable because of how many people have written about the useful things available in 3.x, and (2) is disingenuous (but there are still plenty of people who use "don't see a reason to upgrade" as an excuse for "I always planned to abandon this").
Just in case you're one of the people in (1), here you go:
For anything non-trivial, 95% of the value is in the library ecosystem. So long as most prominent libraries kept releasing new features for Python 2 and 3, there's inevitably not a big pull factor to upgrade. That's changing as a number of major libraries start to make releases that require Python 3.
From a library maintainer POV, I do want to use Python 3. There's no one killer feature, but rather a bunch of small ones, like more specific exception classes (FileNotFoundError etc.).
But if you want to keep using Python 2.7, no-one will take it away from you.
Nobody is forcing you to stop using Python 2.7, but the rest of the world is getting over it and moving on.
I'm sorry if that seems mean, but in the grand scheme of things the differences between 2 and 3 are pretty trivial, and most people still complaining about this are just being stubborn. I refuse to believe somebody can know Python 2.7 "extremely well" but then also need more than ten years to learn the few areas where Python 3 is different.
The killer feature of Python3 is string representation. IO work in python2 (e.g. network programming) was made more complicated by the evolutionary mess of python2's string design.
If you want to get strong at network programming without spinning up on all the complex topics in async io (coroutines, futures, etc), you may like my networking system: github.com/solent/solent-eng
It is designed to allow the programmer to reason about exactly what the process is doing, rather than to hide things away.
The docs are not in great shape at the moment. Good starting points: the telnet client (in tools) and the snake game (demo package).
This was originally in python2. I moved because of subtle improvements in python3 packages over python2. But once I appreciated the string changes, I wished I had moved much earlier.
It's a presentation by core developer Brett Cannon which explains what's better about Python 3. The list is quite long for an HN comment, so I'm not going to repeat it here.
Now it's pretty dated as there had been more things added like async, so Python 3 is even better now.
There's all the pain of python 2's string/byte handling... is it a byte str? Or unicode code points? Python 2 likes to keep you guessing, and that's not a good thing. If you haven't felt the pain here, there's a good chance your stuff is subtly broken in ways you may not be aware of.
Moreover there were some packages even last year that were simply broken with Python 3.x. What am I supposed to do if I have to deliver something to a client and the Python 3 version of my stack is broken? I do not necessarily have the time to debug the issue and fix it and it is much easier to switch to 2.7 and just continue working on the business problem. Software guys (especially guys working on programming languages and environments, tools) have to understand that providing a broken alternative is not an real option at all.
Anyways, I haven't been running into issues with Python 3 recently and I use it as much as I can.
Python 2.7 has just about the worst unicode handling of ANY language I've ever used.
Plenty of otherwise crappy languages (Java, JavaScript, etc) managed to make one right choice when they decided that strings are always unicode and bytes are a different data type entirely.
Also, the asyncio implementation in Python 3, while a bit complicated, is on the whole very nice, providing a lot of flexibility.
Long story short, if you still think Python 3.6 is "bad" in this day and age then you need to move on to another language.
It's a bunch of smaller things, but I think the major one is the new compact dict implementation. Using less memory is a good thing and you basically get it for free using Python3.
Python2's unicode support is kind of an error-prone mess and that was what prompted the decision to make 3 a breaking change in the first place. It is much harder to shoot yourself in the foot with text handling in 3 IMO, though it's certainly still not perfect. Of course lots of people think their programs with broken unicode handling work fine until someone passes them data in any language other than English.
If you ever need to deal with encoding, you will very soon know why my friend. I've hated Python3 just as much but reality left me with no choice. It's time to say goodbye sooner rather than later.
Wild speculation (I'm relatively new to Python), it might also have to do with the Python community having several personalities.
Python 3 solves a lot of problems for me, as someone who does a lot of NLP work, and generally has to deal with strings from the outside world and multiple languages and all that on a more-or-less constant basis. I imagine it solves some problems for Web developers, too, though possibly to a lesser extent. But I don't see a whole lot of devops people being eager to jump off of Python 2, and I'm not sure I see it solving more annoyances in that domain than the process of migrating to Python 3 would create, either.
Agreed. My background is also in NLP and I made the switch to Python 3 early and enthusiastically because it resolved a lot of issues around working with multilingual text.
I think there were also more compatibility issues prior to 3.3 (when they started allowing u"") for libraries that did want to support both. It seems like the core team predicted that the most popular migration path for libraries would be `2to3` or something like that, when in fact the single-codebase-supporting-both strategy has been much more popular? Probably the transition would've been easier if everyone had seen that coming.
That's correct. If something like "six" would have been provided as part of 3.0, things would have went more smoothly. There could have been some language changes in 3.0 to make single-codebase easier. It was only later that the core developers realised that would be the normal way for libraries to support Python 3 (e.g allowing u prefix on strings in 3.x). Quite a bit of time was wasted while this got sorted out. Things are a lot better now. Soon, I think most people will stop worrying about 2.x backwards compatibility.
Yeah, for the longest time everyone kept using library support as an excuse for sticking with 2. But at this point I think it's the exception that a decent Python library doesn't support 3, rather than the rule.
The only one that comes to mind for me is fabric, to be honest.
Infrastructure changes to PyPI made it hard to work out what the top packages are. http://py3readiness.org/ is another effort, which currently lists 345/360 packages as Python 3 compatible.
That list is of the top packages. If internal Mozilla tools are downloaded enough to become top 200, then either Mozilla is larger than I thought or Python is smaller than I thought.
Download counts -- which usually power "most popular" charts -- are extremely misleading, because usually every run of an automated CI system triggers a download.
Arguably that works better as an indicator, as you can see which packages are being actively developed with. But that's beside the point.
Are you suggesting that Mozilla's CI system runs so often as to artificially inflate the download numbers of their internal only packages to the top 200 Python packages? Because if so, then my point still stands. Either Mozilla is a lot bigger than I thought or the Python community is a lot smaller than I thought.
I also am of the belief that if any team would think to cache their dependencies, it would be the team behind a modern browser.
Keeping in mind it's been a few years (my last day at Mozilla was in mid-2015), and I was in the web dev org, not the browser...
The sheer number of platforms, variants, etc. of the browser and the number of test runs that need to happen are mind-blowing. So it's entirely within the realm of believability for me that the mozbase packages (which provide a lot of the foundation for all of that automated infrastructure) could hit the most-downloaded list. It's not that Mozilla is necessarily that much bigger than other big-name tech companies, it's just that Mozilla open-sources everything by default and puts most stuff on PyPI.
As an aside, though, I think people do tend to underestimate the scaling stuff Mozilla deals with. Once I got to give a conference lightning talk pointing out we could probably claim the highest-traffic Django deployment in the world, for example (the version check done by Firefox on startup, if you're curious, is or at least was a Django-backed service). Though I'm pretty sure Instagram has taken that title now; back in 2013 when we talked about that we "only" served on the order of a billion requests/day :)
Even things like MDN -- which is what I worked on in my time there -- presented interesting challenges. Building a wiki with the kinds of features technical writers need, that's still responsive and fast to build and render the pages post-edit and capable of handling the traffic of a top-300-ish (Alexa currently puts MDN at #107 worldwide) site, isn't entirely simple to do.
I have always been interested in that cycle. We use 2 because NumPy supports it still. NumPy supports it because we use it. If a major library had dropped support earlier on, I am curious what would have happened.
> The only one that comes to mind for me is fabric
Speaking of Fabric, does anyone know of any Python 3 projects similar to it? I've been using Fabric3 since the switch but it's not a 1:1 port. I'd consider dropping it in favor of something better if it exists.
It's not just libraries that I use when developing.
Searching for code snippets and copy/pasting stackoverflow answers can easily take more time out of my days than library documentation. But it's so much slower when I have to rewrite something I found for python 3.
Yes, but during the long migration, it was no mere excuse.
Almost every time I tried to use a library, it was 2.7 only.
That situation has only changed recently, and with it people have moved on to 3. (Which sort of underscores that the library support was the main issue).
Not having a story for interoperability between 3 and 2 was incredibly shortsighted. The migration path from Objective-C to Swift is an example of how to do this sort of transition right; Python got it wrong.
Widespread adoption of Python 3 would've happened years earlier if you could start a new project in Python 3 and not have to worry about libraries you want to use not supporting it yet.
The Swift 1->2->3 breakage has permanently poisoned the ever-important well of StackOverflow answers.
For some tasks, there are literally 5 mutually incompatible syntaxes to understand (Obj C, Swift 1234). Even though the UI can sometimes autoconvert for you, it doesn't help at at when you're looking at someone else's code.
Django has not dropped Python2 yet. Django 2.0 will drop Python2 but that has not yet been released, and Django 1.11 (with Python2) support will be supported in LTS for several years.
In stark contrast to the brutal python 2-3 dichotomy, I feel compelled to express my gratitude for the degree to which — contra all the hating and churn and “fatigue” — es6+ (transpiled to es5 via babel) has become such a pragmatic and obvious center of gravity.
Yeah, why isn’t that part of the python ecosystem? Is the reason that unlike the browser, it is possible to upgrade the major version, so there wasn’t that driving force to support an ecosystem for transpiring?
There are gargantuan Python2 projects out in the wild which are expected to continue, and can't realistically be migrated to Python3. In 15 or 20 years we'll be looking at those jobs the same way we look at Perl jobs today.
If this is the case then wouldn't re-naming it Python 4 shake the negative view of it? Guess it's too late now for Python but I've seen it done in other open source projects and it worked pretty well.
Or just be like the cool kids and skip a version. Python 5, or name it after the year. Python 2020 sounds exciting enough to make everyone want to upgrade.
I wonder whether Python itself will improve faster when the development team no longer needs to maintain 2 versions or whether the burden on them will just reduce somewhat.
We use Appengine, which only supports python 2.7. As well as being a reason for us to stick with 2.7, I imagine Google prefers what is effectively a LTS release. If (hopefully "when") they provide 3.x, they will need significantly more support resources to keep up with continual releases.
Thanks for correcting me - after excitedly checking the docs, the "flexible" service indeed supports 3.0. The managed service is still 2.7, however.
The flexible service is basically running your own instance of appengine on a VPS, which means you have to provision and support the infrastructure. To my mind, that negates most of the advantage of Appengine - if I was happy to do my own system admin, I'd build my own stack on VPS.
The following example is pretty much the chief reason why I will not be porting much software to Python 3:
$ python3
Python 3.6.3 (default, Oct 3 2017, 21:45:48)
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 4/3
1.3333333333333333
Python3 is basically a different language than Python 2. If I wanted to port software to a different language, I would use any number of available languages that make other kinds of improvements over Python as well. The only remaining use case for Python for me will be as a quick scripting language, and data analysis and graphing tool.
It is a change, but you can use the // operator for floor division:
$ python3
Python 3.6.3 (default, Oct 3 2017, 21:16:13)
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 4//3
1
When I use python as a scripting language for small tasks I want something concise and convenient that just works. Python 3 is a downgrade in all those areas. I want to just some input into a string, do some operations on it, and print the result. Now I have to make extra special sure to convert the string between binary or utf8 as appropriate, catch encoding exceptions, not try to print anything that might have binary in it, and even the simple print statement was caught in this impractical mess that feels like it was designed by an out of touch academic committee comprised of people who'd never written real code in their lives deciding that string should actually mean only printable characters within a defined encoding and that statements are considered harmful. I can't wait for return to be a function too in python 4.
I suggest reading the eev.ee article others are linking in these comments. Or Joel Spolsky's "Back to Basics" article. Both do a pretty good job of highlighting some of the complexity in this area, and why things sometimes seem like they're being made harder.
Put most concisely, it's something like "making the most common use case as easy as possible can make slightly less common use cases wrong, dangerous and hard".
It's not an out of touch academic committee making these changes out of ignorance or spite. It's people who have to support more use cases than yours. Even if yours is the most common, that doesn't mean that the rest (internationalization, binary data transfer) are distant, rare outliers, or that the frequency of non-traditionally-"simple" ascii text handling applications isn't changing.
You don't need to do any of that. If you use `input()`, you get a string - all conversions are done for you. If you're reading from a file (or from stdin, treating it as a file object), again, in text mode you just get strings. Same thing for printing - if you print strings, they will get converted to the encoding appropriate for the target terminal.
Why not? There's no restriction on what kinds of characters can appear inside a Python Unicode string.
Or do you mean that the text in the log is UTF-8, but the log itself as a whole is not, because those control characters are mixed into it in (effectively) a different encoding? Then the log isn't a single string, and shouldn't be treated as such.
> When I use python as a scripting language for small tasks I want something concise and convenient that just works. Python 3 is a downgrade in all those areas.
Funny, I found the exact opposite, and despite $dayjob being LCD(2, 3) and the default Python on my system being 2, I've been writing all my small scripts in 3.6.
Python 3 has plenty of objectively good stuff, and some that is definitely more subjective. I have my opinions about the changes, but I don't get outraged over them.
The real crime of Python 3, is not the changes, but the compatibility break. Hundreds of thousands of engineer-hours wasted on porting, worrying about compatibility, and supporting unsupported libraries or two environments at once. In the meantime, the language does not meaningfully advance, and thousands of projects are slowed down. It's such a huge effort for a gain that is not worth it.
As a library writer, I cannot wait until we get rid of this self-inflicted handicap of writing in a subset of two incompatible languages. I'm glad the heavyweights are joining the cause.
This is great news. I've been working with Python 3 for a few years now, and it really is a nicer language than 2. Granted 2.7 is a hard act to follow.
Even though the transition from 2 to 3 has been slow, I take it as a positive sign about the Python ecosystem. The general Python community has traditionally erred toward stability, and conservative feature introduction. The gradual introduction of large changes to the core language reflects that characteristic.
Hopefully this will cajole Python 2.7 users to migrate. Assuming you have decent test coverage, the migration generally isn't that difficult.
If you do a lot of NLP or string processing, the sane unicode support is worth it alone.
It's not strange. Python developers might declare Python 2.X EOLed, but that won't stop people from using it. Like it or not, Python 2.X is not going away.
There are big companies with huge legacy 2.x codebases who will stall as long as possible. But popular libraries are dropping 2, and many new libraries aren’t supporting it to begin with. Python 2 is accelerating toward irrelevance.
You make it sound like they're holding out of some weird sense of spite. It's more reasonable to assume most large or small companies still using 2.x have not prioritized upgrading over, I don't know, staying in business?
As large libraries drop 2.x support over time they'll have to prioritize upgrading.
> have not prioritized upgrading over, I don't know, staying in business?
Banks use the very same excuse for a long time, which is why they can't even find Cobol devs to do the work. Bottom line: if having some new grad developer convert Python2 to 3 for some legacy shit would put you out of business, you're already well on your way out.
How do you plan on getting on when packages from PyPi stop supporting Python 2 at all? When Django, flask, numpy, requests, pandas, and more just don't even install? Will you just use ancient versions?
I don't understand: are you saying package authors are going to retroactively remove Python 2 support from existing versions? Why on earth would they do that?
Scheme that I wrote in the 1980s still runs (and is running today in commercial systems). I have so little patience at this point for this "higher version = better" nonsense.
And what happens when security issues are inevitably discovered in the libraries that are not updated anymore? Sure it's probably OK if you write things that never interface with a network.
Yes, no doubt there's going to be a crippling security vulnerability in this linear algebra library I use. Come on, you don't really believe that, do you?
I hope you don't use cryptography then, or networking, or image/file manipulation, or do anything with untrusted user input.
If you're only doing algebra on an air gapped computer then why do you even worry? Programming languages and tools will evolve but nobody is forcing you to. Keep a local copy of what you need and be happy. Just don't assume any new libraries you might need will support your stack forever.
I don't have do that for my 20 year old Perl code or 30 year old Scheme code. Is the bare-bones Python interpreter really that much more full of vulnerabilities?
Also, Python is the only ecosystem I know of where people actually get angry that you use an old and stable version of the software, as those downvotes indicate.
Python might be an especially loud case, but I've seen a fair amount of that in some other areas, for example:
- People getting angry at browser JS authors for coding in explicit support, or huge back-compat shims, for obsolete browsers and/or deprecated JS features.
- People getting angry at Perl authors for writing code that depends on a stable hash iteration order (changed in Perl 5.26 or something? I forget). There was an extremely vocal (tiny) minority of users raising a big stink about the change in that behavior and claiming that it would break the universe.
- C developers being criticized for coding to older (and often more verbose or tricky to use, but omnipresent) pure-POSIX macros and behavior rather than $latest_GNU_or_GCC_feature, which also had the pernicious effect of making things less portable, and damaging the culture of portability.
At the SciPy 2017 conference, for the first time I saw speakers who were presenting new libraries say that they were not going to be developing Python2 versions. Quite a change from a year or two ago.
All my libraries have been py3-only since around last year. I'm also not caring much about supporting 2 on the old ones I maintain. 2 is pretty old, it's time to move on.
Why? Just because "it's pretty old?" The 2-to-3 change seems mostly cosmetic. When Python users ignored 3, Python devs started flogging their dead horse. When the horse still refused to move, disappointed riders started shouting "shame!" at users who suggested that the horse looked dead. Eventually, the riders tied ropes to the horse and pulled it along the ground. The onlookers either switched to bicycles and cars, or figured that they might as well ride the man-hauled carcass awhile longer.
That's a very melodramatic comment for someone who clearly hasn't been keeping track of the 3.x changelogs – which pretty much all contain at least one compelling update to the language. Modern Python is v3. Legacy support drop-off is the same with any project.
I was going for "humor" more than "melodrama," but maybe I failed at both... The actual breaking changes between 2.x and early 3.x struck me as cosmetic and pointless.
To compare: Perl went one way by breaking everything to essentially make a new language, and failed to get people to switch; C++ bent over backwards to maintain compatibility, and failed to fundamentally evolve the language. Python basically failed in both ways, changing the language just enough to break most people's code, while changing it too little to effect significant change. It combines most of the disadvantages of both backward compatibility and novelty, with few of the advantages of either.
I'll happily debate the merits of breaking compatibility in general, but it's boring and completely academic for Python 3 which is getting on for a decade old and has very wide community support.
Same thing every Python thread. It doesn't matter if you liked the way 3.0 was handled (and there certainly was complaint at the time too), it's what Python is now, and that's that.
To also compare: Ruby made big breaking changes similar to Python 3 and called it "Ruby 1.9".
It wasn't really a big deal. There was some pain and it became essential to have multiple versions of Ruby installed. But I haven't heard of anyone insisting on new code written for Ruby 1.8.
So languages can break backwards compatibility once in a while, and it doesn't always have to be the shitstorm it was for Python.
Early 3.x was bad, and that probably gave critical mass to the backlash. But there's no reason to care anymore about what early 3.x was like. Modern 3.x is a way better language.
I was an outsider to the Ruby changes between 1.8 and 2.0, so thanks for the perspective. My sense was that, like modern JS programmers, they were used to constant churn and breakage, so having the language break as well was only a minor additional nuisance. Most of the stuff they used with 1.8 would be "obsolete" in a year or two even without 1.9.
Your view of Ruby programmers might be confused with Rails programmers. Those are more used to the "constant churn and breakage" which I also see as coming somewhat from the web side of programming. Although it's less of an issue in Rails as you can have properly stickied versions in a project.
AFAIK there was no breaking change in Ruby after 1.9, so anything that runs on 1.9 should run on any Ruby version up to the most current.
The biggest change in 1.9 was the support of different encoding and making UTF-8 the default encoding. Ruby did it differently than Python, so a string in 1.8 was a byte string, whereas a 1.9 string was a UTF-8 string. This off course broke many scripts.
Python 3 demonstrates exactly how much change a language project can get away with. Python is just barely managing the transition; any more change and it would have ended up like Perl 6. Perhaps future developers can use this data to plan large and painful migrations.
It's a nightmare to maintain compatibility with 2. Also you can't use any new features only because some lazy ass developers don't want to move.
You have a legacy app that you don't want to convert? Fine, use legacy modules, they won't suddenly disappear. You can even user python2.7 after 2020. Want to use something new? Why also not use more recent version of the language.
Similarly, I'd always watch at least a handful of Pycon talks every year. Last year I couldn't really find anything relevant to Python2. The closest thing was and update on removing the GIL...but that was more informational than practical for me.
The text changes are type safety, but there are many more miscellaneous type safety improvements (like the default comparison between types (alphabetically by type name, except NoneType!) being removed, so now you can use set comparison operators with confidence) – plus support for type annotations.
It's a bit verbose. A lambda with a single one letter param takes ten characters to write: `lambda x: `. In JS, it's 5: `x => `. Ruby blocks take sevenish: `{|x| }`. Six in haskell.
Multi-line lambdas will never happen. Lambdas are expressions. "Multi-line" means statements. There is no sane way you could embed statements into an expression with whitespace-based block syntax.
Fine, not technically lambdas, but still: function bodies declared inline in function calls. This provides great flexibility in higher-order functions.
> There is no sane way you could embed statements into an expression with whitespace-based block syntax.
Ruby does it. Of course, Ruby has a limitation that a function call may only have one "block", but still - Ruby blocks are statements embedded into an expression in a whitespace-based syntax.
Ruby has explicit syntax to end groups of statements. Python is equally powerful when it comes to higher-order functions; it just enforces a flatter, more explicit style.
I cheered Python's slow and steady 2.7 -> 3 move when it began but I'll admit I started to have some doubts a couple of years ago when it still had not completed. In hindsight I think it has been exceptionally well managed and is likely to keep Python in good stead for many years to come.
Their plan is more nuanced than "at the end of 2019". From a numpy feature standpoint, it's EOY 2018, bugs through EOY 2019:
> Until December 31, 2018, all NumPy releases will fully support both Python2 and Python3.
Starting on January 1, 2019, any new feature releases will support only Python3.
The last Python2 supporting release will be designated as a long term support (LTS) release, meaning that we will continue to merge bug fixes and make bug fix releases for a longer period than usual. Specifically, it will be supported by the community until December 31, 2019.
I am a python outsider, but like many others dealt with a lot of pain due to the simultaneous 2 and 3 versions.
Looking at the history, I see python1 ended at 1.6, and python2 ended at 2.7. Based on this the current python 3.6 seems to be nearing end of life.
https://en.wikipedia.org/wiki/History_of_Python
The Python developers plan to never break syntax or stdlib compatibility again. Core developer Nick Coghlan wants to see 4.0 within the decade but he wants it to be "uneventful". [1] In that way, it would be a lot like Python 2.0, which only broke compatibility in obscure ways, but added new ways to do things.
Here are some of my wild guesses at what features Python would want to commemorate with a 4.0 release:
- An easy, Pythonic way to opt out of the Global Interpreter Lock. (The GIL clearly isn't going away because so much extension code needs it, but that doesn't mean all code has to suffer from the GIL for eternity.)
- UTF-8 as the guaranteed default encoding, instead of trying to infer anything from stupid locale shit. (This wouldn't break any code that wasn't broken already.)
> UTF-8 as the guaranteed default encoding, instead of trying to infer anything from stupid locale shit.
This is already the case for source code, right? And I don't see where else it could apply. If you mean stdin/out, then those have to use locale to be compatible with other text-processing software (so that you can pipe things etc).
Locales are not a real way of specifying an encoding for standard in and out. They were not designed for a world with Unicode and UTF-8 in it; they were designed for a world with limited character sets where your text data would probably not be sent outside of your country.
Here are some reasons not to try to get your locale to tell you about UTF-8:
- There is no standard for this.
- Locale suffixes ".utf8" and ".UTF-8" are hacks by specific Linux distributions, and people want their Python code to work even if their system has not implemented this hack.
- The locale "C" does not really mean you want your program to explode when it sees a non-ASCII byte. What Python does here does not promote compatibility in any way.
- BSD has no UTF-8 locales and has never pretended that locales work with Unicode.
- Windows' equivalent of locales is extremely deprecated and never actually supported UTF-8. The modern Windows APIs that deal with standard in and out correspond to Python's Unicode string type, not its bytes type; encoding the Unicode I/O into bytes is not Python's responsibility.
- Really every operating system but Linux has this figured out, and in practice, Linux users want UTF-8 regardless of what their locale says.
To be compatible with other text-processing software in 2017, you don't use locales, you use Unicode APIs and UTF-8.
> Locale suffixes ".utf8" and ".UTF-8" are hacks by specific Linux distributions, and people want their Python code to work even if their system has not implemented this hack.
I do want my Python code to work, yes. But I assure you that if my locale says ru_RU.KOI8-R, when I say "work", I don't mean "dump garbled stuff on my screen, because you output UTF-8 when I specifically asked you to use KOI8-R".
I also don't see why the UTF-8 encoding specifier in locale is a "hack". UTF-8 is just that, an encoding. Locales are a generic mechanism for dealing with encodings. What makes UTF-8 special in that regard, and why is an UTF-8 locale a hack?
> The locale "C" does not really mean you want your program to explode when it sees a non-ASCII byte. What Python does here does not promote compatibility in any way.
That's true for any locale, if a character comes up in the output that cannot be encoded in it - it should just use some reasonable substitution. And if you're actually dealing with binary data, then you should be reading and writing bytes objects, not printing strings, and then the whole question of encoding is moot.
> BSD has no UTF-8 locales and has never pretended that locales work with Unicode.
That would be a surprise to my FreeBSD installation, which is running with en_US.UTF-8. Do you mean that the locales don't come generated by default? I'm not sure why it's a big deal ... I mean, Arch doesn't come with any locales generated by default, but I don't think anyone would claim that it doesn't support UTF-8.
One other thing BSD does, is that it doesn't guarantee that wchar_t is Unicode in all locales (Linux/glibc does). But that's a different and orthogonal issue.
> Windows' equivalent of locales is extremely deprecated and never actually supported UTF-8. The modern Windows APIs that deal with standard in and out correspond to Python's Unicode string type, not its bytes type; encoding the Unicode I/O into bytes is not Python's responsibility.
Win32 doesn't have any string-based I/O functions, except for console. So if you're printing directly to the screen (and ignoring / not supporting redirection!), then yes, you can just invoke WriteConsole, give it a UTF-16 string, and be done with it. But if you're printing to a file, or to stdin/out as a handle, then you only have ReadFile/WriteFile, which require a byte array; you're expected to do your own encoding.
By the way, and speaking of proper Unicode handling APIs - because of this disparity, and the desire to avoid a conversion unnecessarily (due to the lack of UTF-8 locale making it lossy) so as to allow printing out Unicode, Python actually has to resort to hacks to do this on Win32. Specifically, it has a special class - _io._Win32ConsoleIO - that is implemented using ReadConsole/WriteConsole. If output is a Win32 console, then that class is used, and Unicode is fully supported in the output. If output is redirected, then the standard implementation (that does encoding + Read/WriteFile) is used instead.
> Really every operating system but Linux has this figured out, and in practice, Linux users want UTF-8 regardless of what their locale says.
I strongly disagree. The users who want it but don't know how to configure it, are already using a distro that says that it should be UTF-8. The users who are using something that doesn't, either do it for a reason, or are knowledgeable enough to know what's going on and why, and deal with it accordingly. Either way, no harm is done by just using the locale setting. On Ubuntu etc, it will just be UTF-8, and everyone will be happy.
> Locales are a generic mechanism for dealing with encodings. What makes UTF-8 special in that regard, and why is an UTF-8 locale a hack?
Locales are a generic mechanism for dealing with code that should run differently in different countries. There have been other HN discussions recently about why this is terrible in the present day. Encodings are just one aspect of that.
The whole thing where you name a locale, then put a dot and tell it what encoding you really wanted, is what I'm referring to as a hack. There is no standard for locales with dots in them. But the locale system was created at a time when, say, the US was using ISO-8859-1 and Poland was using ISO-8859-2, and this was just a fact about how you had to deal with text.
But that's exactly what Unicode got rid of! You don't make Unicode decisions by country (with terribly awkward exceptions such as Japan, where Unicode itself is unpopular, and Python is too). It's not like the US uses UTF-8 and Canada uses UTF-16. You make Unicode decisions based on the OS and APIs that you're interacting with. And that's why we have this Linux dot convention for overriding what the locale would otherwise say so we can use Unicode.
So your recommendation to use locales is actually a recommendation to mostly ignore locales, and just use the part after the dot as the name of the encoding you should be using. And to make wild-ass wrong guesses if there's no dot. Taking the locale "C" and interpreting it as the encoding "ASCII" is an example of a wild-ass wrong guess.
But there are already environment variables that configure Python to use a particular encoding, without hacking it on top of archaic shit like locales.
And harm is done by trying to infer the encoding from the locale, because of the complete wrongness of assuming the "C" locale means to use Python's "ASCII" encoding. The resulting behavior is not correct, and the reasoning for it is not correct. It's a bug. It will probably be fixed in one of the next two versions of Python.
People run Python from cron jobs, from IDEs, from all sorts of places that don't set the locale the way the Ubuntu shell does, and get bafflingly inconsistent results. You can say "fix your locales then" all you want, but this is not an answer that makes Python more usable, and the developers have acknowledged this.
Here's a particular example of where I think you're coming at this from the wrong direction, where I think you're taking the current behavior of Python as if it were actually some sort of intentionally-designed standard:
> That's true for any locale, if a character comes up in the output that cannot be encoded in it - it should just use some reasonable substitution. And if you're actually dealing with binary data, then you should be reading and writing bytes objects, not printing strings, and then the whole question of encoding is moot.
You don't encode things in a locale! You encode things in encodings! I'm definitely not talking about binary data, I'm talking about printing out perfectly normal characters like "ü".
The locale "C" does not tell you anything about what encoding to use. Which is very different from Python's current assumption (which may go away in 3.7) that it's telling you to use ASCII and explode.
This really has nothing to do with Python per se. Python should do the exact same thing that C does, which is to say, what mbstowcs and wcstombs do. And those do "infer" encoding from locale.
I agree that the conflation of encodings and locales in Unix is rather unfortunate, but, again - nothing to do with Python. On Unix, Python should do what well-behaved Unix apps do, for the sake of consistency and interoperability.
Reading and writing files. This catches people out, because on most Linux and Mac systems it defaults to UTF-8, so people assume UTF-8 is the default. But it's based on the locale, so one day someone runs your code on Windows, or on Linux with the basic ANSI C locale, and suddenly writing text to a file blows up.
This is the number one thing I'd change if I were in charge of Python. ;-)
I would actually rather change it to make the encoding required when opening a text file. Sometimes you do want UTF-8, but other times you do actually want locale encoding (because other text processing tools expect locale). And then "Explicit is better than implicit".
That said, .NET has been defaulting to UTF-8 for text files since 1.0, and it seems to be working well in practice, so maybe it is a reasonable default after all.
One of the early principles of python was there is one idiomatic python way of doing it. Usefully, this enforced a world-wide code style guide, making it easy to read python code.
2.7 and 3.x essentially forked the language, enabling different idiomatic ways to do the same thing which reduced this particular advantage of python. I'm looking forward to seeing the community merge up again.
I'm a researcher and have used exclusively Python 2.7 and NumPy for many years. Originally I ported my codebase from Matlab to NumPy because I wanted to go open source. But it's a very nice thing in science if your code runs perfectly for many years. You don't want to do rewrites. So I feel like I should have stayed with Matlab.
Now that I'm soon forced to do another rewrite, I think I'll just switch to a different language with better future prospects on backwards compatibility. I don't feel that I can trust Python anymore in such things. Any ideas?
Matlab has changed far more over the years than Python (e.g. case sensitivity).
Switching from Python 2 to 3 is not a rewrite in the slightest - very little needs to change. Python 3 has many additional features which don't affect existing code (e.g. a matrix multiplication operator, type annotations, underscores as separators in numeric literals, etc.).
No language can improve without changing, and programs can't take advantage of improvements without changing. You are free to use old versions of Python and Numpy forever: languages with perfect backwards compatibility only have it because they're no longer improving.
Not a great analogy: Programs designed for Windows XP, or even as far back as Windows 95, still run on current versions of Windows. Support for 16-bit programs (from the era of Windows 3.0, released in 1990) started to be dropped in Windows 7 64-bit, and even that included "Windows XP Mode" so they could still be run.
MATLAB actually had a lot of changes over they years that broke working code (e.g. changing the order of function arguments and outputs). It is by no means more stable than Python (2 or 3).
When ruby broke all applications when changed from 1.8 to 1.9 (note that it also was a minor version change) no one complained, they just fixed their language and moved on.
I think Python spoiled developers.
There would be less issues if it would never released 2.7 (that version almost exclusively was backporting 3.x features - until 2015 people were asking what features 3 would give that 2.7 didn't have) and just deprecate 2.6 after a year or so like everyone else does.
I think it's a bit hyperbolic to compare rewriting your code from Python 2 to Python 3 to rewriting your code from Language A to Language B, when the former will likely only require changing a few print statements and other minor things. Have you tried running your current code in Python 3 and got a feel for the extent of what would need to be changed?
Let's hope this move helps with the transitioning to Python 3. I'm not a Python programmer myself, but I'm tired of things getting hairy on Linux dependencies written in Python. It almost seems like I always got to have a Python 2 and a Python 3 version of some packages so my system doesn't break.
Yes, but it's great to be able to use Python for simple scripting tasks too. In that context it's way too much to expect a user to download virtualenv, so instead people just write things for 2.x
You can still install just python3 and call that as-is if you are not using any extra libraries.
If you are using any extra libraries, you should not be installing that system-wide, and should use an environment anyway.
You literally can still use python3 for simple scripting tasks on your Mac, hell I do everyday. One just has to install python3, a trivial task on a Mac.
homebrew will install pip3 along with python3; on my install, python3 packages go in /usr/local/lib/python3.6/site-packages while python (2.7) packages go in /usr/local/lib/python2.7/site-packages . I can't understand the complaint except for having to type 3 I guess?
I was surprised to recently notice a yellow banner on the website of the very popular Requests library, which urges users to switch to Python 3. That's when I first thought switching may become inevitable. I guess this is being orchestrated behind the scenes now.
Still, I have no plans to switch. The only useful feature in Python 3 to me is more liberal use of unpacking. Unfortunately it comes at the cost of removed tuple parameter unpacking, which I use often, but most users apparently never do. I don't know what's difficult about Unicode in Python 2 either, once you understand the difference between Unicode and UTF-8.
It's unfortunate it ever had to come to this. Makes you wonder what Python would be like today without Py3K. (It's an open question.)
> The only useful feature in Python 3 to me is more liberal use of unpacking.
Unfortunately, this ignores composing software. Your user may use things you don’t. The result: your software won’t get used as a library. That may be fine! More power to you. Just don’t drag anyone else down to 2 with you. :)
Personally, python 2’s print keyword/statement is infuriatingly inconsistent with the rest of the language; the network modules are a mess, organizationally; there’s no async support; the unicode support makes me want to stab my eyes out. I don’t mean to convince you (I’m not very convincing...) just to give an opportunity to hedge your statement with empathy for everyone who did decide to move on. Surely you must have any commentary that doesn’t reduce to “I don’t like change”, right?
Python without py3k is just old software that is end of lifing soon, after all :)
> I don't know what's difficult about Unicode in Python 2 either, once you understand the difference between Unicode and UTF-8.
"once you understand the difference between Unicode and UTF-8" is what's difficult about Unicode in Python 2. I understand it, you might understand it, but I have to interop w/ and work w/ code written by people who do not. I'm not fool-proof either, so I greatly appreciate that the language makes a hard distinction now; doing the right thing by default is the point.
I still use Python 2.7 and all I need with strings is UTF-8 byte string nowadays in Japan.
If you read Japanese, read the following blog to know the current circumstances:
And note that Golang is getting popular in Japan, which uses UTF-8 byte strings solely.
Python 2.7 with byte strings as default has a good chance to evolve into a more elegant language :-)
It has been "orchestrated" ever since PSF announced an official end-of-life date for Python 2.7.
This is just the way things work: support eventually runs out, and if people didn't switch before then for other reasons, that's usually motivation enough to finally do so.
And the mess in naming functions and classes in the standard library is still the same. I remember name of a function, and I have no idea how to write it. As PEP8 says, we have mess in the stdlib, and we are not going to clear it.
Unfortunately they missed the great opportunity which was the release 3.0.
What is the preferred way to write an end-user program in Python? At least one platform (Arch Linux) has 3.x set for `/usr/bin/python`, while most others have 2.x as the default (macOS, other Linux distros).
The consequence is that Python scripts which need to "just work" must be written in the intersection of Python 2 and 3, a language for which no interpreters exist (do they?), and which inherits the pitfalls of both. This is a terrible state of affairs.
Nonsense. Use six, use tox for testing in both, easy peasy. They're not that different. Plenty of libraries do it. No reason scripts can't too. Plenty do. Specify a "/usr/bin/env python3" shebang if you want to use any cool features like f-strings
Thank you, I appreciate the reply, but taking a bunch of dependencies is not reasaonable. It is as if you said "Does your shell script use associative arrays? Just install bash 4 on your users machines..."
tox apparently depends on virtualenv; this is reasonable if your software is primarily Python, but absurd if your package merely uses Python for one-off scripts. macOS doesn't even install pip by default.
I guess what I'm saying is that Python 2 had an opportunity to fill the Perl/sh ubiquity niche (installed by default on Linux/macOS/FreeBSD!), but squandered it with the 2->3 incompatibilities.
> Thank you, I appreciate the reply, but taking a bunch of dependencies is not reasaonable. It is as if you said "Does your shell script use associative arrays? Just install bash 4 on your users machines..."
You can writes compatible Python code without using any extensions, I did that myself, but those tools just make it easier.
> I guess what I'm saying is that Python 2 had an opportunity to fill the Perl/sh ubiquity niche (installed by default on Linux/macOS/FreeBSD!), but squandered it with the 2->3 incompatibilities.
Since you mentioned FreeBSD I need to add that while ago they had an effort to remove any scripting language from the base system. So FreeBSD doesn't come with Perl, Python, Ruby etc preinstalled.
Actually, I think that was a really good decision. No need to worry that system depends on some old Python module which if you upgrade, you can break it.
Instead, you need python3.6? You install that version, you realize that something else needs python2.7? You install python2.7 side by side. In fact you can install all available versions without conflicts or worrying that something will break.
Using virtualenv for development doesn't mean your users have to install it. The Python website has some pages on supporting both major versions.[1][2]
There’s really not anything major in 3 that’s not easily available via back ports in 2.7. Or else why do you think people aren’t bothering to pay the price to switch?
This is also the reason maintainers are bringing out sticks. They realize the carrots just aren’t that tasty.
Library maintainers? Why do they care what Python you use? They're dropping 2.x support because it's a burden to them.
I'm still using Python2, but the things I know I'd use that aren't back ported are; well, having to download something to backport functionality (batteries included is a selling point for Python), native namespace packages, nested exceptions, function annotation, and not having to treat unicode differently when dealing with external libraries like Qt or databases. I often backport lru cache, pathlib, and terminal size came up for me last week. The other new things look interesting, but since I'm not using Python3 I can't really evaluate them.
The price to switch is too high. A codebase that took years to write will take years to migrate. To make the matter worse, it's impossible to support both python 2 and python 3 at the same time.
For any non-trivial project, most of the value of Python is the library ecosystem. So most of the 'carrots' are going to be libraries that are only available on Python 3. Like some future version of numpy, or pandas, or Django.
It's not a stick. You can keep using the old version if you prefer. There will just be some nice new features for people on Python 3.
async/await is available as a backport, so it can be introduced into legacy code bases.
Writing new projects in python 3 is great. Backporting old legacy codebases is a pain. It really depends so much on the library, and whose manager wants to dedicate the time to it?
Back posting anything to 2.7 was a mistake. It shouldn’t have happened because it offered a crutch to stand on instead of spurring ports to 3. 3.x has been around for years now. There was no excuse to have started porting an application that would have taken 3 or four years to do, 3 or four years ago. What did everyone think that 3.x python was a fad and not going anywhere?
I think it was an all or nothing thing. If they could have packported everything (the whole point of 2.7 was to be a bridge) then everyone would have moved up like they do for every point release. Only backporting the fun stuff left only the not-fun stuff when migrating your code.
Getting rid of the GIL is a big change. In py2.7 CPU-heavy threads are useless -- they lock up the process and starve other threads. py2.7 threads are only good for I/O heavy work.
You can use multiprocessing in py2.7 but with a lot of caveats if you want to share state and file descriptors.
IMO the GIL removal is the one thing "that's not easily available via back ports in 2.7".
Python 2 came out in 2000 and goes EOL 2020 I think. Perl 5 was released in 1994 and has no planned EOL date, so it is currently winning by a fair margin.
I agree that they were not very different languages.
I did port code from Python 1.5.2 to Python 2. It required two minor changes, because "from X import *" was no longer allowed inside of a function.
As a similar example, the transition from 2.5 to 2.6 meant that an assignment like "as = 0" (which might initialize a counter for the number of 'a's found) was no longer legal either.
Which makes me wonder how much of the incompatible changes that triggered the python 3000 change could have been introduced gradually. I mean 10 years could have been a long time to introduce small breaking changes one from future import at a time...
The future import technique works well for syntax changes which only affect a single module.
It doesn't help with objects passed between modules. For example, if s is a byte string, then "for c in s" returns a 1-byte string in Python 2 and integers in Python 3.
But if the string was created in a Py2 module and passed to a Py3 module, then what API should it present?
In principle there could be a wrapper to present the correct API. However, that's complicated, and not interesting compared to, say, a new methods for doing asynchronous programming.
This sort of backwards compatibility can be done. I've heard about IBM doing it for ... REXX, perhaps? .. where a program and perhaps even a module could declare which version to use. But it's expensive. And despite its popularity, there aren't scores of companies paying millions of dollars to ensure this level of compatibility,
For the bytes vs char, maybe you can make it more gradual : make unicode possible and non default (py2), make it possible, non default but deprecate raw strings literals, make unicode literals default one year after. Not TEN.
Or maybe JUST make it the ONLY check to go from python 2.7 to 2.8 and focus on supporting the change during one whole year.
Or provide both APIs - maybe as a compile time switch- but all the new APIs using text would be unicode only.
Wait for all libs to change focusing on just that. Make developers go 10 times that amount of verifications and changes.
Python had incompatible changes before so it wasn't a "take any 1.2 python code and it runs on py 1.5.2" level backwards compatibility (by example : string exceptions, new keywords ..). There hasn't been any drama for this, not ten-year level one at least. My point was that maybe py3 transition could have been smoother had it be done this way - it's very difficult to handle, and shall be glad to have the python 3.6+ we have now anyway)
Picking a version longevity winner probably depends on whether you mean specification, or implementation.
ANSI Common Lisp was standardized in 1994, and there have been no updates to the language since then. There are several supported implementations (though the implementations have probably all incremented their major version at least once since then).
It seems that JavaScript gave up numbering at 1.8.5 [1], so you might consider it to still be on "JavaScript 1.x", which dates back to 1996.
Most C++ code wont compile for multiple reasons. For example using namespace std will result in errors if your code calls a function which is now part of std.
I actually think that migrating from Qt4 to Qt5 has a lot of similarity with python 2 to python 3. Not sure why there aren't more people doing the comparison.
"most" is a great exaggeration. Yes, I few more names have been added. Also, it was always known adding namespace STD could cause problems. The same issues arise with import * in python.
That was part of Sun's "people pay more attention to the first number" reversioning. Solaris 2.6 was followed by Solaris 7.
This was partly because of the competitors (e.g. IRIX) were raving the first digit with each major version. When Solaris was version 2.6, IRIX was version 6.
As I recall it, Management had less confidence with things called "1.X" or "2.X" than things called "5.Y". So, Sun went through and started dropping the small leading digit from the versions of their products.
I think the OP is looking for something a bit different, not oldest supported programming language but longest time between major updates to the language.
This is a bit hard to address because Python does incremental language changes, as well as major changes, while the languages you listed have formal specifications.
Python 2 from creation in 2000 to end of new development will be 19 years.
Fortran 66 was around for 11 years, replaced by Fortran 77 and then Fortran 90, 95, 2003, and 2008. I think those dates are what the OP is looking for.
C89 to C99 was 10 years. Then C11 12 years later.
COBOL 61 was followed by 65, 68, 74, 85, and then the poorly supported 2002 followed by 2014.
I think a better contender is MUMPS, made an ANSI standard in 1995 and ISO standard in 1999. It's still in use in healthcare and financial applications. https://en.wikipedia.org/wiki/MUMPS
Another contender is Rexx, ANSI X3.274 / 1996.
Both Rexx and MUMPS are ranked in the range 50-100 on TIOBE.
Then there's FORTH, with FORTH-79, FORTH-83 (both de facto) and then ANS Forth in 1994. But that might be cheating as I think (based on hearsay) most Forth users specialize their implementations rather follow ANS Forth.
Those are still in reasonably wide-spread use. I think something like ALGOL, last revised in 1973, is outside of what the OP was thinking about.
Still, ANSI C89 is still being "developed" in the sense modern optimizing compilers still improve the state of the art and their STD (glibc/musl) still supports them as primary targets for development (rather than the newer C99/C11).
The same is true for Fortran and COBOL. Both are actively being developed as programming languages. Python2 is both a framework (extended std) and language, so the line is blurry. I would even say that Python2, as a language/runtime, has not been under development since quite a while meanwhile C89 development is still going full speed.
By that logic any language can be supported by never upgrading the system. Support implies some kind of active support from the creators / maintainers of the language, not active use by people.
I don't think anyone is going to pry it from you. If you want to keep using 2.7, go ahead. It's open source so you can even hire someone to keep maintaining it for you.
However, be aware that the vast majority of the people maintaining Python have moved on to 3.x. 2.7.x continues to be maintained because the team believes in giving people a stable platform and a long maintenance window. Long does not mean forever though and most of the people back-porting fixes to 2.7.x will stop by 2020.
So, you should have a plan for that. May give 3.x a spin and see how it works for you. I feel like 3.x adoption is speeding up because people have tried porting their code and decided that "yes, 3.x is better".
I'm open to the argument that Python 3's handling of string encoding is not ideal. But after using Python 3, I'm not willing to go back to a language that allows the programmer to freely mix encoded and decoded strings and uses the same type to represent both. That way lies insanity, and I'm glad to be rid of it.
In Python 2, I could never seem to figure out how to do string encoding properly. After trying to reason about the code and put the calls to str.encode() and str.decode() in what I thought was the right place and inevitably failing, my only recourse was to sprinkle random calls to str.encode() and str.decode() throughout my code like magic pixie dust until errors stopped happening. In Python 3, if I do it wrong, I get an easy-to-debug TypeError. For bonus points, if I use Mypy, I can get that error without even having to run the code.
I too felt 7 bit ascii was a good thing, and I believe I know members of the original ANSI committee who worked on it.
But, I now live and work in the Asia-Pacific region, and I regularly interact with data and content which is not represented in 7 bit ascii. This has altered my perspective.
My comrades from 7 bit land also migrated into a world of homophones. It is entirely true you can get into some awful places regarding what things look like and what semantically they mean, but the one thing that has never come up, is what errors of handling it introduced into the code: the code, is doing what it does. It is how you interpret it, that has to change.
uStrings just work. Unclench your Undead fists, and accept the news from your brothers and sisters outside of paper tape.
You know the phrase, "you don't have to go home, but you can't stay here"?
You don't have to move to Python 3, but Python 2 is gonna be EOLed. If you don't agree with Python 3's stances on things, it might be time to find another language entirely.
I think the amount of Python 2 source code existing in the world is too large for Python 2.7.x to stop working. A lot of that code is just never going to get ported to Python 3. Companies don't have the budget to do it. So, somehow there will still be a Python 2 interpreter to run the code, even after 2020.
That said, when nearly all of the Python 3rd-party library developers are targeting Python 3, do you really want to be stuck on 2.x? I think that's going to be the ultimate death of new Python 2.x development. The NumPy example seems typical. I.e. the cost of supporting 2.x is very soon not going to be worth it.
It seems clear to me now that there is not going to be a large faction of 3rd party library developers who refuse to move from 2.x. That is unlike Perl 5. As a Python developer, this is very happy result. The 2 to 3 transition was extremely painful but it appears to be mostly behind us now. Having two separate "flavours" of Python (2.x and 3.x) would have been bad.
> I think the amount of Python 2 source code existing in the world is too large for Python 2.7.x to stop working. A lot of that code is just never going to get ported to Python 3. Companies don't have the budget to do it. So, somehow there will still be a Python 2 interpreter to run the code, even after 2020.
Sure, but—as other people mention down-thread—there are still COBOL programs, and even COBOL (maintenance) developers. There's just no community for active, new COBOL development. That's what it means for a language to be EOLed.
> I think the amount of Python 2 source code existing in the world is too large for Python 2.7.x to stop working.
Exactly. And that is the major fuup that Python 3 brought. There was no fundamental reason to make most of the Python 2 code incompatible with the "better" and "newer" version. The really good Python 3 would have accepted most of the Python 2 code and execute it, while allowing the new 3 "goodies."
Only a year ago, I've installed "just" Python 3 on my main computer -- "Python 3 is mature enough" I've thought. Then I wanted to solve some problem X. Found the code that does 90% on the web. Try to run -- doesn't work on Python 3. Adjusting it. It runs after my changes, but I've lost time for something unnecessary. Then I've tried to solve some problem Y. The story repeats. The third time, I've just decided that it's not worth. I've installed 2 again and I can't be happier.
And all that was for my non-Numpy related work. There were some years where the libraries using Numpy were only Python 2, even after Numpy got its own 3 version.
So Python 3 was so very wrong for too long. The worst upgrade path I've lived through. And completely unnecessary. It was absolutely technically possible to make it much much easier to move.
Only Python 3? Are we there? I thought we are not there yet? I thought there is a big push going on for fedora to go Python 3 only and it will likely not end before end of next year? I imagine Debian and Red Hat and Canonical will continue python 2 default for a while?
In my experience, for my purposes and use cases, obviously not, exactly as I wrote above. And it didn't have to be that way for most of the code, I claim that, knowing how little additional code were needed to have a different result: compare with the Linux Kernel, much more complex piece of code, where "kernel never breaks user code" because Linus set that goal. Python is much, much less complex than Linux Kernel, and the same goal was possible: not breaking at least most of code written for 2, while still allowing different new code. The overhead would be insignificant. Note that even without that overhead, Python 3 was (maybe still is) significantly slower than 2. So there is really no valid excuse.
I'll add one more assertion to the list. People are born and people die. It is not fair for us to impose our mistakes and sins to the next generation. With that being said, my thought was simply all the scripts that are in python (even the simple build for Firefox was python 2 only last time I checked).
The way forward for anyone new to python is for us to tell them: Python 2 doesn't matter. Don't look at it. Learn python by which I mean 3.0+
I still don't get why Google of all places can't support python 3 in its standard app engine. To me it sounds like standard is deprecated for the flexible (which doesn't have a free tier).
It replaces one set of quirky hacks for a different set, just in different parts of your code. So in a way it's no worse.
I have to say I was sceptical of Ruby 1.9's new approach to Unicode thinking Python 3.0's approach looked much cleaner. It does on paper. In practice though, I have to admit I get where Ruby was going with it all now.
In Python 3, all strings are Unicode, period. When you need a sequence of bytes that's something else, there's a separate types for that (called, unsurprisingly, "bytes"). If you need to treat it as a string, you use the decode() method and pass the encoding should be used to interpret it. If you need to get byes out of a string, it's the reverse process - you call encode(), and, again, specify the encoding.
In Ruby, strings are byte sequences with encoding attached. Unicode is not special - it's just one of many available encodings. And different strings in the program can have different encodings. This makes it possible to represent data richer than what Unicode allows (e.g. the various East Asian encodings that avoid CJK unification issues). But it also means that it might be impossible to e.g. concatenate two random strings, or even compare them for equality in a meaningful way, because their encodings are incompatible.
I wonder if this has anything to do with Matz being Japanese. I do my best to avoid Unicode at all costs because as a native English speaker ASCII was working out great for me.
It was working fine for me, right up to the point I wrote an article that contained "naïve", at which point my naïve string handling (SQLite->HTML) broke horribly. Moving to Python3/Unicode was the easiest solution.
Of course string encoding is the most painful aspect of migrating from Python 2 to 3. The backwards-incompatible fix to how Python handles string encoding is literally the reason Python 3 exists.
For people wondering why it's been like this for almost a decade(!) since Python 3.0 was released: Python 3.0 was actually terrible. It lacked many critical things, and was riddled with bugs and security flaws until 3.3, which was released 4 years after 3.0. This cemented in many people's minds the idea that Python 3 was a bad thing. Python 2 was and is a fantastic programming language, so it was a very high bar to move up from. Python 3 has come a long way since then, Python 3.6 is now a decent step up from 2.7.