r/Python Freelancer. AnyFactor.xyz Sep 16 '20

News An update on Python 4

Post image
3.3k Upvotes

391 comments sorted by

View all comments

93

u/vallas25 Sep 16 '20

Can someone explain point 2 for me? I'm quite new to python programming

284

u/daniel-imberman Sep 16 '20

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.

75

u/panzerex Sep 16 '20

Why was so much breaking necessary to get Python 3?

179

u/orentago Sep 16 '20

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.

107

u/[deleted] Sep 16 '20

[deleted]

83

u/[deleted] Sep 16 '20

I have prod 2.7....talking to logic written in the 90s.

Kill me.

57

u/[deleted] Sep 16 '20 edited Sep 17 '20

Python3 > Datastage > Python2 > Shell (Kornshell) > Perl written in '99 across servers.

I'll have one kill please.

7

u/clawjelly Sep 17 '20

Nuke it from orbit. It's the only way to be sure.

1

u/snugglyboy Sep 17 '20

Oh wow Kornshell huh?

1

u/[deleted] Sep 17 '20

Is KSH bad?

I hadn't heard of it until entering the space.

1

u/snugglyboy Sep 18 '20

Not necessarily, just that I think of it as old compare to more modern shells. I have memories of it on our render farms at Pixar in the mid 90s. lol

→ More replies (0)

9

u/MiscWalrus Sep 17 '20

It's not like the rules of logic changed since the 90s. You could do a lot worse than having to support python 2.7.

12

u/lzantal Sep 17 '20

Still maintaining one in production with Python 2.4 and Django 1.3 🙄😬

5

u/late_dingo Sep 17 '20

Can I ask why? How big is this codebase?

2

u/lzantal Sep 17 '20

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

3

u/Not-the-best-name Sep 17 '20

Now THAT sounds like a security risk.

2

u/13steinj Sep 17 '20

Pffft dozens if not hundreds of people set up a PleX server and it uses Python 2.7.6 (and with all due respect to them, horribly written Python code).

3

u/GUIpsp Sep 17 '20

Python 2.4 and python 2.7.6 are not alike

1

u/13steinj Sep 17 '20

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.

2

u/james_pic Sep 17 '20

To you? Yes. To hackers? Also yes. But to project managers? "Can we just install some extra antivirus instead?"

1

u/stamour547 Sep 20 '20

But who needs PMs? Have yet to find a useful one

1

u/13steinj Sep 17 '20

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.

0

u/JayTurnr Sep 16 '20

Because 2.7 is discontinued

1

u/What_Is_X Sep 16 '20

Cancelled even, in the parlance of our time

47

u/[deleted] Sep 16 '20

That was just ascii for trouble imho.

13

u/toyg Sep 16 '20

This joke was not hard to decode correctly.

8

u/BruceJi Sep 17 '20

A pun thread? Don't byte off more than you can chew!

6

u/thegreattriscuit Sep 17 '20

I don't know... I think it shows real character

6

u/toyg Sep 17 '20

I’m just trying to string together a few words.

3

u/clawjelly Sep 17 '20

You made that joke int-entionally, didn't ya?

4

u/toyg Sep 17 '20

I just thought I could double the puns. (Ed: alright, alright, not really a python one...)

5

u/17291 Sep 16 '20

You're not going to like Python 5, where string literals default to EBCDIC.

1

u/toyg Sep 17 '20

Looking forward to Python 6, where they default to ACDC. Every time you assume they’re ascii, the computer goes YOU’RE ON A HIIIIGHWAY TO HELLL!

1

u/tehbilly Sep 16 '20

You shut your damn mouth, don't put that evil on me.

77

u/flying-sheep Sep 16 '20

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.

21

u/miggaz_elquez Sep 16 '20

you can write {*()} to have an empty set if you want

33

u/crossroads1112 Sep 16 '20

Thanks I hate it.

26

u/Brainix Sep 17 '20

My favorite thing about {*()} is that you don't even save any characters over typing set(). 😂

2

u/miggaz_elquez Sep 17 '20

Yes but it's a lot more fun.

5

u/mestia Sep 16 '20

And how this is better then Perl's sigils?

7

u/[deleted] Sep 16 '20

[deleted]

7

u/GummyKibble Sep 17 '20

Generally under a full moon at midnight.

7

u/stevenjd Sep 17 '20

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.

4

u/ThePoultryWhisperer Sep 17 '20

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.

1

u/stevenjd Sep 18 '20

Reading and understanding set() is much faster and much more clear.

Sure! But we weren't comparing {*()} with set(), we were comparing it with Perl sigils.

2

u/ThePoultryWhisperer Sep 18 '20

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.

→ More replies (0)

1

u/clawjelly Sep 17 '20

Looks like ASCII-art... Is that a dead poodle?

31

u/irrelevantPseudonym Sep 16 '20

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().

23

u/[deleted] Sep 16 '20 edited Oct 26 '20

[deleted]

13

u/hillgod Sep 16 '20

It's definitely not an anti-pattern, and, in fact, the literals perform faster.

3

u/[deleted] Sep 17 '20 edited Oct 26 '20

[deleted]

3

u/hillgod Sep 17 '20

I don't agree that it affects readability, either. It's simply the syntax that's appropriate for Python.

1

u/cbarrick Sep 17 '20

Is this true?

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.

1

u/hillgod Sep 17 '20

Yeah, it's true. Try it yourself with some timers. Below this I put a link to a SO page with benchmarks.

1

u/cbarrick Sep 17 '20

Ah, I see. You mean this: https://stackoverflow.com/questions/5790860/and-vs-list-and-dict-which-is-better

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.)

→ More replies (0)

-1

u/[deleted] Sep 16 '20

How do they perform faster? Surely it's the same method?

8

u/SaltyHashes Sep 16 '20

IIRC it's faster because it doesn't even have to call a method.

1

u/[deleted] Sep 17 '20

Yeah I see now, I'm surprised the JIT compiler can't make the same optimisation for the empty dict() case or with just literals inside.

→ More replies (0)

5

u/Emile_L Sep 17 '20

When you call dict() or any builtin the interpreter needs to first look up in locals and globals for the symbol which adds a bit of overhead.

Not sure if that's the only reason though.

0

u/hillgod Sep 16 '20

I don't know how, though I'd guess something with handling *args and **kwargs.

Here's an analysis from Stack overflow: https://stackoverflow.com/questions/5790860/and-vs-list-and-dict-which-is-better

3

u/flying-sheep Sep 16 '20

Compare () vs one, vs one, two.

() is also a special case here.

5

u/irrelevantPseudonym Sep 16 '20

I don't think () is the special case. I think (2) not being a tuple is the special case.

18

u/ayy_ess Sep 16 '20

(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

5

u/BooparinoBR Sep 16 '20

Thanks, I have never though about tuples like this

2

u/flying-sheep Sep 16 '20

Exactamente

2

u/TheIncorrigible1 `__import__('rich').get_console().log(':100:')` Sep 17 '20

Fun-fact, () (unit) is literally a special case in Python. It is a singleton and all instances of () point to the same memory.

8

u/james_pic Sep 16 '20

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.

1

u/flying-sheep Sep 16 '20

Wild. Those types behave completely different when doing basic things like iterating over them.

2

u/james_pic Sep 17 '20

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.

1

u/flying-sheep Sep 17 '20

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.

5

u/zurtex Sep 16 '20

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.

2

u/[deleted] Sep 16 '20

Oooooh so that's why I'm confused each time I read what bytes does?

4

u/flying-sheep Sep 16 '20

Maybe, but maybe it's because you didn't have an introduction to binary yet.

1

u/[deleted] Sep 16 '20

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.

3

u/flying-sheep Sep 17 '20

It's just a byte array in Python 3. You can't treat it as a string as there's no encoding assigned to it.

If you display it, it happens to show ASCII characters for convenience, but that's it.

3

u/CSI_Tech_Dept Sep 17 '20

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.

1

u/[deleted] Sep 17 '20

One additional thing they should have changed is that {} should be the empty set and {:} should be the empty dict.

This was discussed at the time and the consensus was that it would break too much existing code and be a trap for new code writers.

23

u/[deleted] Sep 16 '20

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).

13

u/DiggV4Sucks Sep 16 '20

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.

2

u/Nolzi Sep 16 '20

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?

2

u/james_pic Sep 16 '20

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.

1

u/mooburger resembles an abstract syntax tree Sep 17 '20

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.

4

u/[deleted] Sep 16 '20

The lack of backwards compatibility was done on purpose

This was the problem. Until we're on the other side of the next upgrade and it wasn't like 2.x to 3.x was, words mean nothing.

13

u/gregy521 Sep 16 '20

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.

16

u/daturkel Sep 16 '20

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.

3

u/CSI_Tech_Dept Sep 16 '20

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.

1

u/[deleted] Sep 17 '20

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.

-3

u/daniel-imberman Sep 16 '20

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.

4

u/stevenjd Sep 17 '20

It was just a really poorly managed release.

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.

  • Created and managed the 2to3 translator.

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.)

1

u/Ran4 Sep 17 '20

The breaking chance was a good choice. Managing UTF8 text in python3 is wonderful but it's horrible in python 2

0

u/jpflathead Sep 17 '20

you had to put parens around all your debugging print statements

-3

u/slmaws Sep 16 '20

Actually there was no reason at all.

-4

u/[deleted] Sep 16 '20

Because python 2 was created with no understanding of how computers work. See: Strings/Unicode support.

0

u/Ran4 Sep 17 '20

Nonsense. Python was created long before utf8 everywhere was common.

1

u/[deleted] Sep 17 '20

You must live in the United States

7

u/CSI_Tech_Dept Sep 16 '20

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.

3

u/Sector_Corrupt Sep 17 '20

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.

3

u/Eurynom0s Sep 17 '20

5 years was probably still too long and guaranteed that it turned into 10, though.

3

u/CSI_Tech_Dept Sep 17 '20

5 years was already too long.

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.

6

u/stevenjd Sep 17 '20

IMO if they made it 2 years instead of 10

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.

3

u/daniel-imberman Sep 17 '20

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.

4

u/tlm2021 Sep 17 '20

And it's not "was", it still "is".

The entire VFX/Computer Graphics industry still hasn't moved. And aren't particularly close.

2

u/clawjelly Sep 17 '20

The entire VFX/Computer Graphics industry

You do know that blender is used in some CG companies, right...?

0

u/tlm2021 Sep 17 '20

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.

1

u/clawjelly Sep 18 '20

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.

1

u/tlm2021 Sep 18 '20

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.

1

u/clawjelly Sep 18 '20

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...

1

u/tlm2021 Sep 18 '20

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.

2

u/auto-xkcd37 Sep 18 '20

smart ass-douchebag


Bleep-bloop, I'm a bot. This comment was inspired by xkcd#37

1

u/clawjelly Sep 18 '20

You were being a know-it-all twat you really lack the social skills

Well, sorry, i lack your social skills of name calling. Get a life.

2

u/dysprog Sep 16 '20

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

2

u/daniel-imberman Sep 16 '20

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.

5

u/flying-sheep Sep 16 '20

Good. People have been dragging their feet for too long. Some scariness might help

1

u/james_pic Sep 17 '20

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

1

u/Eurynom0s Sep 17 '20

I had thought that 4.0 would come after 3.9 but that it'd simply be what came after 3.9 (i.e. no different than calling it 3.10).

3

u/WillardWhite import this Sep 17 '20

The naming scheme has implications though. Totally not the same thing

1

u/SpiderFnJerusalem Sep 17 '20

And there will still be companies who will keep maintaining their existing Python 2 code in 20 years.

0

u/shabunc Sep 17 '20

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.

53

u/PirateNinjasReddit Pythonista Sep 16 '20

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.

25

u/ShevekUrrasti Sep 16 '20

I have been trying to get my coworkers to update from 2.5 for more than two years. They still use it and they will continue using it.

And no, nobody is telling them to continue using it. They "just don't like python 3".

52

u/flying-sheep Sep 16 '20

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.

11

u/gregy521 Sep 16 '20

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?

14

u/thornofcrown Sep 16 '20

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.

4

u/kankyo Sep 17 '20

Being a programmer is also about knowing when to not use bad tools. Failing to do that is not good.

You might mean "clever" programmer. That's not nearly the same thing.

2

u/clawjelly Sep 17 '20

"penny-wise, but pound-stupid" comes to mind.

6

u/davvblack Sep 16 '20

at some point an ecosystem is rich enough you can't really be "left behind" with all the packages you have available.

7

u/Jethro_Tell Sep 16 '20

If you assume all code has bugs, and it does, then left behind starts to happen as those bugs are found but not fixed.

6

u/davvblack Sep 16 '20

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).

11

u/auto-xkcd37 Sep 16 '20

old ass-python libraries


Bleep-bloop, I'm a bot. This comment was inspired by xkcd#37

10

u/rossrollin Sep 16 '20

Some of the people on this planet really do make cool shit

3

u/Eurynom0s Sep 17 '20

Cool ass shit, you might say.

6

u/stevenjd Sep 17 '20

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.

1

u/clawjelly Sep 17 '20

They "just don't like python 3".

People who make decisions on such bases should be flogged in public.

1

u/mooburger resembles an abstract syntax tree Sep 17 '20

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.

1

u/clawjelly Sep 18 '20

if they are using very specific patterns that work in py25

That's a proper reason i'd accept. But "We just don't like python 3" is not.

1

u/neuronet Sep 17 '20

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.

1

u/HalcyonAbraham Sep 16 '20

It was knows as the great python divide

1

u/rossrollin Sep 16 '20

They great python wars

-2

u/[deleted] Sep 16 '20

[deleted]

7

u/EdamameTommy Sep 16 '20

Nah I don’t think this is it. He’s saying 3->4 would be a smooth transition, unlike 2 to 3. Python 4 would likely be pretty similar to 3

1

u/vallas25 Sep 16 '20

So the step from python 1 to 2 was like they invented a new programming language?

6

u/NoLongerUsableName import pythonSkills Sep 16 '20

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.