Numpy: Plan for dropping Python 2.7 support
github.com
github.com
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.
The only one that comes to mind for me is fabric, to be honest.
Right now 187 of the top 200 packages on Pypi support Python 3. https://python3wos.appspot.com/
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.
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.
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).
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.
But I'm not sure how far along it is yet.
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.
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.
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.
Just because we learned to work around unicode issues doesn't mean they're not completely bonkers in 2.7
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.
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.
Just use bytes where appropriate.
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.
Toy programs and rapid scripting and prototyping...
FWIW I love my trivial use of python.
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.
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.
I may do that.
Most of mine have to do with developer productovity and I didn’t find until Python 3.5.
– @, the matmul operator
– fstrings (f”{foo}”)
– parameter typing (foo: int = 0) which has exciting work with Cython
– other async features. I forget what library it was (tensorflow?) but for Python 3 it had better async support
* 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.
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.
> stall Python development for a decade?
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.
merged_dict = {
**source_dict1,
**source_dict2,
**{
'some_key': 'w00t!'
}
}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.
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...
That's not even a hipster thing, it's quite mainstream with gaming keyboards...
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.
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.
This is a pure political decision based on ideology.
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.
I've plan to migrate away from py2 by 2020 too, just not to py3.
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!
(Not a NumFOCUS person although I occasionally volunteer with them and definitely donate on a recurring basis.)
If you feel you have "plenty of resources" you can fork the python2 version of numpy and maintain it.
(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...
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.
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.
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))
Just an example.
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.
As I said, u'' literals were re-introduced by the Python developers themselves, in Python 3.3.
1. BOTH Python 2 and Python 3 come with built-in support for BOTH bytestring and unicode (contrary to OP's claims I responded to)
2. That mixing bytestrings and unicode will fail with an explicit error since 3.0+ (a good idea IMO)
3. Unicode has a more efficient internal storage since Python 3.3+ (a neat technical detail)
4. It's good practice to be explicit about the type of literals, and write b"" and u"" always
5. That Python 2.7 doesn't support unicode is simply FUD.
Can you articulate which point you're actually contesting? I'll be happy to clarify, but I'm honestly unsure what you're responding to.
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.
that was my point, by moving to python 3, I removed all my "u", the thing other developers not wanted (see PEP-414 again); I loved the "purity".
but removing u was tedious (at best).
In my use case, strings are "string" and binary are "bytes". Which I think is much safer.
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.
Hmmm... [THINKING FACE (U+1F914)]
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.
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.
I don’t recall it ever surprising me or behaving poorly.
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.
{Describing the old python-2 behavior:}
-------- Quote: -------
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
The new case of / always being float division and // always being integer division just makes everything more explicit.
z = 3/y
I'm not a particular fan of that - they should have changed the name entirely, IMO, eg. to Rby - but Perl 5 is not getting discontinued.
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 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.
And hence why it's a problem in Python. If you have a function like
def foo(a, b):
return a / b
> 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);
# a is not defined
if something:
a = 1
else:
a = 2
print(a)
> 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".
Meh, more like a clutch for systems where you couldn't install List::UtilsBy. (One of my favorite Perl modules of all time.)
In retrospect it probably would have been better for the community if they'd given Perl 6 a new name.
https://www.curiousefficiency.org/posts/2014/08/python-4000....
The library ecosystem is the problem, and it's what's driving the language churn.
Back when I cared about Perl, doing "man perldelta" was a nice way to entertain myself.
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.
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.
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
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.
It's an enormous amount of effort. It's been a decade and the end is nowhere in site. Python 3 is a tragedy.
docker-compose uses Python2 and has encoding issues on Windows that have no real workarounds other than upgrading to Python3: https://github.com/docker/compose/issues/2775
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.
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...
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.
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:
https://eev.ee/blog/2016/07/31/python-faq-why-should-i-use-p...
There are many minor improvements and new functionality that working with it is so much enjoyable and make code more readable and shorter.
I got to a point where it feels like a chore whenever I have to use Python 2.7.
Proper handling of Unicode, and more sensible distinction between bytes and characters.
Seriously, Python 3 has done that _so well_ that I wish other languages would take notice.
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)
file_path = f'{base_dir}/{user_name}/{latest_dir}'
* The refactoring of the subprocess module:
subprocess.run(my_cmd)
This is just off the top of my head...
But really, it's the overall improvement of the language and the standard lib that make the difference, not just the big features.
Anyways, I haven't been running into issues with Python 3 recently and I use it as much as I can.
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.
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.
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.
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 was always intended for the finished product to call itself Python 3.0, though.)
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.
Numpy is certainly not the only project with a plan to sunset Python 2 support: http://www.python3statement.org/#sections30-projects
$ 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
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
1One of my teammates just upgraded our django framework from 1.4 to 1.8 and it took him almost an entire week to do.
__future__.division was optional in 2.0.0, which was released in 2001
__future__.print_function was optional in 2.6.0a2, which was released in 2008
Simply adding the following line to new project over the past 8 years would have made the move to python 3 less difficult.
from __future__ import (division, print_function)
And Django 2.0 should come out December 1st, so it’s not far off.
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.
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.
Swift is a great example of what not to do.
So, what is it exactly that you're trying to do?
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.
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.
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.
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.
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.
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.
(Red Hat has been one of the primary maintainers of Python 2.7 in the last few years. https://news.ycombinator.com/item?id=7582300 )
The BSDs on the other hand (including MacOS) "run on" Python 2 and haven't made as much progress switching to Python 3.
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.
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.
Kudos to the numpy team for writing the most awesome python module under the sun, and for providing great support!
As large libraries drop 2.x support over time they'll have to prioritize upgrading.
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.
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.
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.
- 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.
There are more examples, but you get the idea.
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.
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.
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.
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.
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.
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.
(I'm still stuck using Python2--not by choice)
All that time for Unicode. Not concurrency or type safety or static guarantees or better lambda syntax or anything fun like that. Just Unicode.
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.
What do you mean by better lambda syntax? Is there something that you feel isn't adequate in the current syntax?
\x->> 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.
I guess it's due -- Python 3 finally has some improvements to the runtime that I think will start to pull more Python2 people over.
> 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.
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
So what will happen when python 4 comes out?
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.)
- More built-in syntax to support NumPy.
[1] https://www.curiousefficiency.org/posts/2014/08/python-4000....
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).
This is the number one thing I'd change if I were in charge of Python. ;-)
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.
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.
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 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.
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.
Larry is surely working on it.
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.
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?
Have you dropped using windows when XP is not supported anymore ?
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.
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.
workon #{projectname}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.
https://docs.python-requests.org
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.)
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 :)
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.
(I mistakenly manually changed the link to HTTPS.)
"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.
https://note.mu/ruiu/n/nc9d93a45c2ec
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 :-)
Unfortunately they missed the great opportunity which was the release 3.0.
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.
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.
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.
[1] https://wiki.python.org/moin/PortingToPy3k/BilingualQuickRef
Also arch is wrong: https://www.python.org/dev/peps/pep-0394/
From the linked PEP (emphasis mine)
> end users should be aware that python refers to python3 on at least Arch Linux (that change is what prompted the creation of this PEP)
This is also the reason maintainers are bringing out sticks. They realize the carrots just aren’t that tasty.
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.
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".
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.
async/await alone is a pretty big deal.
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?
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.
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)
The fundamental limitation is the economic cost of doing something along the lines of what you propose.
I can still run Java, C, C++ and Perl 5 (picking the first 4 languages that occur) that were written before then, with no problems.
https://en.wikipedia.org/wiki/Java_version_history#Versionin...
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.
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.
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.
Otherwise I could argue Commodore still "supports" the Commodore basic in a Commodore 64.
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.
[1]: https://en.wikipedia.org/wiki/JavaScript#Version_history
You can take my Python 2 when you pry it from my cold dead hands.
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 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 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.
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.
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.
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.
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.
I'd be happy if I'm wrong though...
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.
But to me ASCII seems like a hindrance.
``` fmt.Println("Hello, 世界") ```
This line of go lang looks beautiful. I bet they never have to worry about bytes vs Unicode.
Here is python...
https://www.youtube.com/watch?v=sgHbC6udIqc
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).
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.
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.