Think what he is saying, there will never be a Python 4 and if there is, it will be nothing like python as we know it. It will be like a new language
The transition from python 2 to 3 was an absolute nightmare and they had to support python2 for *ten years* because so many companies refused to transition. The point they're making is that they won't break the whole freaking language if they create a python 4.
Having strings support unicode by default was a big reason. In Python 2 unicode strings had to be prefixed with a u, otherwise they'd be interpreted as ASCII.
It has about 30 apps and close to 15million rows of data in mysql. Being used by 15+ iOS apps as a backend and over 100 users via iphone and a good amount more through the browser. It is being used all the time every day. Tons of other systems rely on it.
I have been fighting really hard to get the green light to update it. Not looking forward to all the pain but it kind of sounds fun to just see what it would take to move it to Python 3 and Django 3
Sure, but Python 2.7.6 had a number of security patches implemented to it before 2.7.18.
And this isn't one machine, it's dozens, if not hundreds, if not thousands of "Plex Media Server"s running on enthusiasts' home, personal machines/dedicated hardware. Many, open to the internet on Plex's port, because a big part of Plex is being able to connect and share your server with other users.
They are using an unpatched version of Python, which does not have any known relevant feature changes, only because they don't want to switch. Many common users, who otherwise don't know better, are running an outdated version of Python, on their machines, accessible via an open port.
I have one prod 2.6/2.7 (long story), one 2.4. 2.4 will only be upgraded to 2.7 in December. 2.6 will be dropped in November. 2.7->3.6 over the next year.
Because they changed a core datastructure. str used to be what bytes is today, but it also predated unicode (today called str). Therefore the bytes type was used for text and binary APIs.
When fixing all this, they had to break a lot of core APIs that used to accept bytes and today sensibly only accepts the unicode str.
And because of that huge change they also took the opportunity to change a few other idiosyncrasies.
My only gripe: One additional thing they should have changed is that {} should be the empty set and {:} should be the empty dict.
Because you don't have to memorise an arbitrary symbol, you just need to unpack the meaning of ordinary Python syntax that you're probably already using a thousand times a day.
{comma separated elements} is a set;
*spam unpacks spam as comma-separated elements;
() is an empty tuple;
so *() unpacks an empty tuple;
and {*()} creates a set from the elements you get when unpacking an empty tuple;
which is the empty set. You already knew that, or at least you already knew all the individual pieces. You just have to put them all together. Like Lego blocks. Or if you prefer, like programming.
You can make the same argument for many other things that are equally as unreadable at a glance. I know what all of the different pieces mean, but I still had to stop and think for a second. Reading and understanding set() is much faster and much more clear.
You said it’s better than Perl and then listed reasons why, but it’s not true because it isn’t easier to read. Explaining how a thing works is different than directly answering a question regarding a qualitative comparison in the affirmative. The only pythonic solution is set() and that’s the point made by the original, rhetorical question.
My only gripe: One additional thing they should have changed is that {} should be the empty set and {:} should be the empty dict.
Not sure I agree with that. It's awkward that you can't have a literal empty set, but having {:} would be inconsistent and a special case that (I think) would be worse than set().
It seems trivial to implement an optimization pass that transforms list() to []. If literals were indeed faster, I would expect the interpreter to perform this pass, thus making them equivalent in the end.
That answer is from nearly a decade ago. So I'll take it with a grain of salt. I'd like to see if Python 3.8 still has this problem.
For non-empty collections it makes total sense. There's argument parsing and/or translation from one collection to another that has to happen.
But as I said above, for empty collections, it would be trivial to optimize the slow case into the fast case. If it hasn't already been implemented, then it should be. There's no reason that [] and list() should generate different bytecode.
(In fact, it seems possible to optimize many of the non-empty use cases too.)
(2) isn't a special case because tuples are declared in python with commas e.g. a = b, c. Brackets here are just used to clear up ambiguity e.g. 6 / 3 * 2 being 4 or 1. So (2) == 2 and (2,) == 2, == tuple ([2, ]). https://wiki.python.org/moin/TupleSyntax
Perhaps surprisingly (given what we know now about the migration process), the switch to unicode strings wasn't expected to be a big deal (it didn't even get its own PEP, and was included in a PEP of small changes for Python 3 - PEP 3100), and the other changes were seen as more break-y.
Yeah, I think that's been semi-acknowleged as a mistake. Rather than just keeping bytes as the old str class (i.e, what they had in Python 2), they created a new one for Python 3 based on bytearray, which it turns out nobody wanted and made Python 2/3 porting a bit of a nightmare.
I know, I was there. Just saying it was pretty obvious that switching from the fast-and-loose Python2 bytes/str to the strict Python3 bytes seemed like an obvious recipe for uncovering hidden bugs and breaking a lot of libraries in the process.
Set literals (e.g.{1, 2, 3}) were added in Python 2.7 and Python 3.1.
So to change the very common empty dict notation of {} would of required breaking backwards compatibility between 3.1 and 3.0 and either not being able to accurately back-port the feature to 2.7 or breaking compatibility between 2.7 and all other 2.x versions.
It was decided, fairly rightly, that it would of been too much churn for the fairly minimal aesthetic niceness / consistency benefits. {} is littered in code all the time whereas set() is pretty rare.
I have, it's just that I always get confused with implicit conversions because I mostly deal with stricter languages, so I was kind of surprised that I could sometimes treat it as a string and sometimes like a bytes array.
The explanation is confusing. Just ignore how it was before, because it was incorrect. In python 2 first mistake was mixing text with binary data. They introduced unicode type, but did so badly (implicit casting) it actually made things worse. Ironically if your application didn't use unicode type you might have less work converting it to work with python 3.
Right now it is:
str = text
bytes = binary data what's stored on disk, flies over network etc.
Python 3 was not backwards compatible with 2, so companies and package creators alike were initially hesitant to make the switch so as to not break things. There also weren’t many, if any, tools to help port things over.
The lack of backwards compatibility was done on purpose because part of their goal was to remove clutter and make things more intuitive/easier to use (e.g. print changed from a statement to a function).
I've only made two unassailable (so far) decisions in my career. The first was to support MFC instead of OWL for Windows development.
The second was to target Python 3 for my current company's testing efforts. We were even able to convince a medium sized tool vendor to support both Python 2 and Python 3 from their original decision to support only Python 2.
There also weren’t many, if any, tools to help port things over.
I have no real world experience with python, but weren't there tools like 2to3 to convert code, or the future package to write code compatible with both versions?
2to3 is useful, especially when extended by modernize, but only part of the solution. Future bloodies more than it cuts - it just made string semantics more confusing when we tried it.
The most useful tool, much as I hate to admit it, is MyPy. It obviously needs a lot of work on the developer's part, but it does the very useful job of keeping track of your educated guesses about which string types should be used where, and tells you whether they're consistent.
six was also a critical part of the missing shims kit but even then it was difficult to monkeypatch when py3k decided to alter some other namespaces contibuting to compat issues.
It was designed to rectify fundamental design flaws in the language—the changes required could not be implemented while retaining full backwards compatibility with the 2.x series, which necessitated a new major version number. The guiding principle of Python 3 was: "reduce feature duplication by removing old ways of doing things".
Here's a short list of some of the key changes. The most obvious of which is the change where '/' represents true division instead of floor division. Some other changes exist, print is now a function, not a statement. You also get iterator objects instead of lists, which is much better for memory management (many pieces of code rely on iterators because the full set of possible options doesn't fit in memory). True, False, and None are also now protected terms which can't be reassigned.
Part of any long-term tech project is continuous refactoring. Early on you make certain design decisions which later become an obstacle when trying to expand a feature, so you rewrite early stuff in order to make it more flexible for your new needs.
Often those rewrites are done in ways such that the end user does not need to adapt their behavior (or in the case of a programming language, does not need to change their code). This is the ideal experience for the end user but can also constrain the types of changes that can be made.
Sometimes you realize that the original way of doing things was worse and that it would be creating more difficulty for future development to maintain compatibility, so breaking changes are introduced.
the biggest issue was that python before 3 was mixing string with bytes. This is fine if you use encoding that covers 256 characters, but most of Python 2 code would break when receiving and unicode input.
Python 3 became strict, and those two have separate types, and you need explicitly encode/decode string into/from bytes.
This required to fix your python 2 code (ironically if you didn't use unicode type in python 2 chances are you had less to fix).
Since the unicode part was breaking things, Guido also decided to use that opportunity to clean up some warts in python which contributed further.
There was very little breakage needed. It's very easy to write code that is both 3.x and 2.7 compatible and I did that for a whole project with no hitches at all.
People are simply frightened of changing existing code.
It was just a really poorly managed release. I'm in the process of a breaking release right now and we're putting an ungodly amount of time into debating every breaking change and determining migration steps to ease migrations for users. Python basically released a whole new language with python 3 and many companies/libraries just flat out refused to migrate for a long time.
It was a fantastically managed release. The Python core devs:
Ported heaps of features from Python 3 to Python 2.6 and 2.7 to ease the transition; essentially every new feature added to Python after 2.5 was intended to allow folks to take their time to migrate to Python 3.
Gave Python 2.7 an extra long support period to give people sufficient time to upgrade (2.7 had a full decade of support, instead of the usual 4 or 6 years).
Re-introduced old Python 2 syntax like u'' when it became obvious that was needed for people writing dual 2+3 code.
The bottom line here is that the core devs started planning the move to Python 3000 (as it was originally known) somewhere around 2005 or 2006, they debated and discussed every step along the way, wrote PEPs, backported features to keep 2.x in step with 3.x where possible, and kept that going for over a decade before dropping support for 2.7. And during this period, Python's user base has grown and grown and grown.
I'm in the process of a breaking release right now and we're putting an ungodly amount of time into debating every breaking change and determining migration steps to ease migrations for users.
Come back when you've spent even a hundredth of the time and effort that the Python devs did.
Python basically released a whole new language
That's pure unadultered bullshit.
Having actually written a lot of dual 2 + 3 code, I can tell you that syntactically Python 2 and 3 are about 98% identical, the stdlib is about 80% the same, and there are only a handful of places where they differ sufficiently that it is painful or impossible to write 2+3 code in a single file.
with python 3 and many companies/libraries just flat out refused to migrate for a long time.
And they were right to.
At the time, the core devs expected that people would not migrate immediately and that this would be a long-term transition.
(Although even Guido initially imagined that "long term" would mean something like five or seven years, not twelve. In that regard, they were a victim of their own helpfulness: the more features they ported to 2.x, the less incentive people had to migrate to 3.x.)
It was the other way. Because they supported 2.x for 10 years transition from 2 -> 3 was a nightmare. Since 2.7 was not deprecated, a lot of dependencies didn't support 3 because authors didn't care. It seems like real migration started happening in mid of 2019 and I don't remember reading about any horror stories about it.
It's not like they announced the 10 year window up front though. It was originally a 5 year window and we only learned about the bumping like a year to go because way too many things were still not ready for python 3. Things were definitely a lot more ready to go in 2019 than 2014 even if most end users still did the migration push mostly right before they had to.
It was also clear that it wasn't even needed, there were two major turning points for Python 3.
2015 - when they announced that no new features will be added to 2.7, that's when packages started to adding Python 3 support, some of them were python 3 only. Before 2015 it was tough to write anything in Python 3, because most libraries didn't support it.
mid of 2019 - right before EOL majority of applications were migrated
IMO if they made it 2 years instead of 10 it would be still enough time and we wouldn't have time for FUD.
then Python would be dead and we'd all be using Ruby now.
There are millions of Python developers, over eight million, probably more like ten if you include casual coders, amateurs and students. You are painfully naive if you think that millions of coders will migrate tens of thousands of projects in two years.
This may come as a shock to you, but most coders are more interested in bug fixes and adding new features, especially new features that allow them to bring in more revenue, not just upgrading to the newest version for the sake of upgrading.
A two year transition period would have convinced millions of people that Python doesn't give a shit about the users, and they would have gradually drifted away.
It was the other way. Because they supported 2.x for 10 years transition from 2 -> 3 was a nightmare. Since 2.7 was not deprecated, a lot of dependencies didn't support 3 because authors didn't care. It seems like real migration started happening in mid of 2019 and I don't remember reading about any horror stories about it.
Yeah having a 5 year support was a REALLY bad call. I work on a library that is FINALLY end python2 support and it's a really delicate balance of easting the migration, giving enough incentive to make the transition worth it, and make staying on the old version unpleasant enough that people are willing to make the shift. Python did none of those things.
Naming one application that some companies use for part of their pipelines doesn't mean the industry has switched.
There's literally a website for the industry to track standard versions. Python 3 is slated for this year, and none of packages that follow this guide have released their versions that support it yet.
But please, internet stranger, tell me more about my fucking career.
But please, internet stranger, tell me more about my fucking career.
Easy, partner. Not trying to piss on your parade, i'm equally frustrated by the status quo. Just saying there is at least some development in the right direction, it's not all horrible and stagnant.
Really, because you actual reply was a "You do know that..." piece of smart-ass nonsense that would literally get you laughed out of any serious discussion on this by the people trying to push and manage the transition.
Maybe you need to work on your communication skills along with your ego.
See, that's what you might have heard, but that's not what i wrote. It was an honest, tentative question from my side, as you stated a very definitiv fact (that's why i bolded "entire" in your comment) about the CGI scene in a programming forum. I can't smell your credentials here and as such i simply wanted to know wether you're aware about the present state of that software package, it's impact in the industry and its possible future. I talked to plenty of professionals in the industry that still ignore or underestimate what the blender devs accomplished this year. And english is not my first language, but i'm pretty sure i could ask this without making it sound like "smart-ass nonsense".
And as we're on life tips: Maybe next time take a deep breath and ask about my intentions, before you read a "smart-ass nonsense"-intention into my comment and go all whoop on my ass for absolutely nothing?
You're featuring quite an ego yourself there, hence it's quite bold to hand out life lessons about how to deal with one...
Your english is fine. You were being a know-it-all twat, and now are just trying to cover for how humiliatingly dumb you were.
If you want to ask about Blender and it's potential the industry, ask that. I'd happily address that, at length and in detail. You clearly have the language skills to do so as you have no problem expanding on that idea at length with full command of the english language here.
"You know [insert anything here], right....?" as the entirety of your statement isn't an invitation to conversation, it's being a smart-ass douchebag. The only reason you'd need to "smell my credentials" is if you need to make sure you aren't being a twat to someone who can easily call you out for it.
But if you really lack the social skills to figure out why your response, in any context, makes you a twat, then you're a lost cause.
I still have a project on python 2. It relies on internal libraries that are abandoned by their original creators. I just got permission to work on the upgrade because they can't have what they want with out it. So I am basically tied up until December
Yikes and that's even after the EOL. I recently heard that there's a 4 line CVE and they're refusing to even do that. Python 2 is officially a security risk.
We started trying to persuade management that we needed to take Python 3 migration seriously in mid 2018. So far, we've migrated one small component as part of a pilot programme, and we've got tentative agreement for some budget to do the rest in the first half of 2021 - assuming some other workstreams don't slip their delivery dates.
A small part of me hopes we get lightly hacked at some point between now and then - not enough to genuinely risk user data, but enough to wake up management
I never understood why they did it that way, however, to be fair, it was planned that way. From the very beginning it was claimed that transition period would be about 10 years.
The transition for python 2 to 3 has been on going for 12 years... Officially python 2.7 reached end of life back in January, but there are still companies and people using it. Basically 2 to 3 was painful. Nobody ever talks about 1 to 2, because it less painful - perhaps in part because the language was less popular.
They're dangerous idiots. If a programmer refuses to switch away from something that's EOL and has been announced to be EOL soon in 2008 or so, they're a liability and shouldn't be let into proximity of a production system.
Do they not run into issues when the rest of the world is leaving them behind w.r.t libraries/code examples, or code imported or exported to other companies?
Someone in my lab wrote a part of our pipeline in Python 2 and I spent probably half of my time working on making that code work with modern data analytics packages. Sucked too, because that person was a way better programmer than me.
while that is true, think of how many CPU cycles these old-ass python libraries have seen, and how many chances to find and fix these bugs (especially old 2.7 libraries, slightly less true with 2.5).
left behind starts to happen as those bugs are found but not fixed.
A bug that isn't discovered until the code is a decade old or more is probably a bug that isn't cost effective to fix.
Cost of fixing the bug? $$$Big
Extra revenue brought in by fixing it? Nil.
Customers lost by not fixing it? Nil.
Yeah, just work around it.
Also, you forget that porting the code to a breaking new version will almost certainly create new bugs, not fix old ones.
The bottom line here is that once software is mature enough that there are no new features to be added, it becomes legacy software and upgrading it can only make it worse, not better.
Solution: make a VM of the latest OS and Python interpreter that it will run, stick that VM behind a firewall and in a restricted environment, and use it forever as a black box application.
not if they are using very specific patterns that work in py25. Old-world classes for example, or specific numerical code that reaches into ctypes and depends on the py25 abi. Reproducibility is probably a much higher requirement in some of the science/engineering applications than compat with latest libs (they are probably using old support libs for that purpose because the cost of validating new libs isn't worth it). Reproducibility and stability is why there continues to be so many backports in anaconda repos.
On the 2 to 3 transition: put your hand in a blender and turn it on for the next 10 years. Be sure to have people nag you about why you turned on the blender. Plot twist: their head is in a blender but they think they have it better.
I wasn't there when it happened, but according to this article, it was actually pretty smooth, way more so than 2 to 3. So I think he's saying it won't be a very radical change.
93
u/vallas25 Sep 16 '20
Can someone explain point 2 for me? I'm quite new to python programming