Live data from Hacker News

Why I'm Making Python 2.8

naftaliharris.com

361–370 of 392 posts

Re: Why I'm Making Python 2.8

#361
I hope I don't come across as too obtuse, but it might still make economical sense for the PSF to backpedal on their decision: even if Python3 is a good solution for the future, it's caused years of arguments and still hasn't been adopted by the majority[1].

Ridiculous as it might sound, that implies it would actually take less work to devise a path for Python2 that's backwards compatible but still has a future, and invest the time to backport all 3-only code, than it would to proceed with killing off 2 and porting everything over. It's also nothing more than everyone whose code is 2-only is being asked to do sometime in the future (they chose "the wrong competing standard" and have to pay the cost). Either way someone has to foot the bill for a unified Python but couldn't it just be that the early adopters of 3 could pay that cost if it saves updating (say) twice as much legacy code in favour of backporting the 3-only code?

Of course, the future version of Python should be the best form of the language with the right features, and that's why it was decided to kill off 2, but if after this many years the initiative hasn't completely succeeded, there's always the option to reverse course.

Heck, in the time until Python 2 is officially gone, maybe this new fork will evolve into a better language than 3 and still be backwards-compatible with 2!

For now I'm sticking with 2.7 for as long as I can but will just accept it when the time comes.

[1]: https://mobile.twitter.com/vlasovskikh/status/80172061331236... for example (I don't think I've made a controversial claim here but could be wrong)

Re: Why I'm Making Python 2.8

#362
post #334
post #321

Earlier quoted context omitted.

> So I hope "Python 2.8" gets a cool name, perhaps even some funding from a company who wants to keep their Py2.7 code alive and invigorated, and the community part as friends. It has already been explained elsewhere in this discussion by other people, I would strongly advise against that. If you for whatever reason have to stay on 2.7, then make sure your new code is 2.7 only (and best if it works with 3 without cha…

What I was hoping for was a sane migration path to prevent the split you talk about in 2020...somebody made a superset of both py2 and py3 that lets one move gradually. If support ends/project dies one would bite the bullet and move all the way to py3 I guess. My py2 code uses unicode properly which may color my view a bit... But I don't really disagree with what you say.

Clearly, "sane" is up for argument. My understanding is that 2.6 was the last version to get major features. Python 2.7's goal was to be a bridge between 2x and 3x[1]--it was that superset where code can run in both. It back ported many of the popular Python3 features (at the time). But that was 6 years ago and Python 3 has had new features since then.

(Looking at this from the perspective of the "Python Community" or someone who's goal is to adopt Python3) His focus is to back port newer Python 3 features developed since then. Does this help people move to Python 3?

Good on him for digging into cpython. While there's __future__ and the backports module, he seems to have focused on features that aren't just new libraries (which is cool). A few years ago I was trying to backport Python 3's Namespace Packages for my company since our internal import tools effectively do the same thing (except our's had bugs).

[1] https://docs.python.org/dev/whatsnew/2.7.html#the-future-for...

Re: Why I'm Making Python 2.8

#363

Earlier quoted context omitted.

I say this as someone who uses the latest version of Python available in every new project or script. Text encoding issues are absolute garbage in Python 3.x I fucking hate the way that csv module works with text encodings. As soon as I can figure out a reliable way to take latin-1 and save it as UTF-8 without breaking everything, I will try to shoehorn in a PR. Right now, it's fucking awful. My ETL pipeline hates it…

with open('some latin-1 file', 'rb) as f: text = f.read().decode('latin-1') with open('some utf8 file', 'wb') as f: f.write(text.encode('utf-8')) Python 3's string encoding support is super good. I've said it before and I'll say it again: if you use bytes as a string you are Doing It Wrong. If you use bytes as a string you are Doing It Wrong. If you use bytes as a string you are Doing It Wrong.

Allow me to rephrase.

I do that operation on a file I get from an API. I know for a fact that the encoding I'm receiving is latin-1.

I run exactly that operation on the file that you wrote out in code.

When I try to read that file back in as UTF-8, I get encoding errors. That does not make for "super good." That makes me want to scream.

I do not have this problem when I use Python 2.7.x

Re: Why I'm Making Python 2.8

#364

Earlier quoted context omitted.

There is a clear selection bias here, which is revealed in the first response (unless that was what you're pointing people towards). IDEs are a lot more common on Windows, which has the best adoption rate. The data from the two sources in that comment point towards a large majority of users still using 2.7, which agrees with my experience (which is in the scientific community). The number one reason being that there…

While the claim of selection bias in JetBrains' survey may be argued, it is still a valid data source, which is what the gp was asking for. Also, your anecdotal data is arguably biased as well. My take is that many sources, including the ones linked to in the tweet's replies point to solid growth in Python 3 adoption. Python3 might not have overtaken Python 2 overall, but it's very far from being "dead".

>While the claim of selection bias in JetBrains' survey may be argued, it is still a valid data source, which is what the gp was asking for.

No, I asked for a representative data source (representative was implied: a biased data source is as good as no data source at all).

Re: Why I'm Making Python 2.8

#365
post #214

Earlier quoted context omitted.

> Or how it is inhibiting or preventing the expression or awareness of your thoughts or desires. How's that difficult to parse? It is stomping on the desire to keep my 2.x userbase AND receive updates for the language.

Oh, but you're expressing your thoughts and desires perfectly well though. You want someone else (not you, of course) to maintain Python 2 for you for the princely sum of of £0.00, so that you don't have to do any work on upgrading to Python 3. And when the time finally comes around that those people, who have been maintaining Python 2 for many many years (for free), want to focus their efforts on an easier to mainta…

>Oh, but you're expressing your thoughts and desires perfectly well though. You want someone else (not you, of course) to maintain Python 2 for you for the princely sum of of £0.00, so that you don't have to do any work on upgrading to Python 3.

That's how it works with programming language communities.

Not everybody is directly involved in maintaining the language, but the whole community has a stake (and a say) in the future of the language.

Furthermore, it's not just the core team that's responsible for the success of the language, but also the users and the companies that adopted it. Without those, Python would be some obscure toy language by a Dutch academic, and he wouldn't have a job in Dropbox etc.

There are lots of people that have been major contributors to Python's success, including large businesses that employed people like Guido, which also have concerns regarding the switch.

Re: Why I'm Making Python 2.8

#366

Earlier quoted context omitted.

We have several large projects that are written in Python. Most of these aee production applications that are critical to what we do, and the others are libraries and tools for internal work. We haven't even started thinking about porting these to python3. We have so many other things to worry about (but fixes, new features, etc) that it's hard to justify the time investment to port these now. I can't imagine we're t…

You're not, of course. And there are similarly many people running production critical code written in Perl 5 on RedHat 9 or something like that. "If it's not broken, don't touch it" is a wise rule to follow for that kind of stuff. But to keep it running, you don't really need Python 2.8 with new features , right? You need extended support for Python 2.7 - basically, making sure that it keeps working with updated ver…

>But to keep it running, you don't really need Python 2.8 with new features, right? You need extended support for Python 2.7 - basically, making sure that it keeps working with updated versions of other software (like OSes), and that bugs are fixed.

Those systems are not just sitting there untouched.

Heck, not even 70s COBOL systems are "just sitting there" (they are hooked to newer systems, get new forms, have alterations, etc. all the time), and those Python 2.7 systems have been written 10-15 years before or less.

And they continue to get new subsystems, new features, alterations, etc. In 2.7.

So, yes, people would very much like to get not just "extended support for 2.7" but also the ability to keep running it in newer versions, and be able to take piecemeal adoption of new features to make their life better and eventually organically refactor in their own timeline.

Re: Why I'm Making Python 2.8

#367

Earlier quoted context omitted.

> What a load of bollocks. For new projects this only matters if libraries aren't ported, which they are for the most part. For old projects, either you're in a situation where you can spend time porting your code to Python 3, or you don't; but as TFA mentioned pep-404, the writing has been officially on the wall ever since 2011 so at that point you have to admit you did choose to incur tech debt and do nothing about…

The "writing has been on the wall" is not an excuse, it's mostly blackmail ("port or else you wont run on 3, and we'll stop the 2.x line"). And most people didn't (and shouldn't) fall for that. So let me get this straight. 1. A bunch of people you've never met and probably have never paid or financially supported, 2. Gave you a high-quality programming language, for free, to use for any purpose you liked, 3. And then…

Let me get this straight:

1) You frame this as some single random individual on HN is the only one that is concerned with the switch.

2) You seem to have missed that companies and individuals that do dislike the switch have contributed to the Python ecosystem, from employing core developers in the past, to creating frameworks, libraries etc that helped Python succeed.

3) You have missed the fact that some (a lot? most?) of the concerned people have actually donated to the PSF through its PayPal donate link (as I've done in the past, and I've used Python since 1998).

4) You seem to think that an open source community project is pretty much "anything goes" and end users be damned. And then the team can complain about "lack of adoption" for the new version.

Do I have those right?

Re: Why I'm Making Python 2.8

#368

Earlier quoted context omitted.

The "writing has been on the wall" is not an excuse, it's mostly blackmail ("port or else you wont run on 3, and we'll stop the 2.x line"). And most people didn't (and shouldn't) fall for that. So let me get this straight. 1. A bunch of people you've never met and probably have never paid or financially supported, 2. Gave you a high-quality programming language, for free, to use for any purpose you liked, 3. And then…

Let me get this straight: 1) You frame this as some single random individual on HN is the only one that is concerned with the switch. 2) You seem to have missed that companies and individuals that do dislike the switch have contributed to the Python ecosystem, from employing core developers in the past, to creating frameworks, libraries etc that helped Python succeed. 3) You have missed the fact that some (a lot? mos…

So, do you still think it's "blackmail" when something you were getting for free decides to no longer support the version you like?

Python 3 adoption has been rising for a couple years now as people realize that A) Python 3 is a quite nice language, B) porting to Python 3 is not as hard as people keep claiming it is, and C) Python 2 is going to run out of zero-dollar-cost support one day as the number of people willing to support it without being paid for their trouble diminishes.

If someone does want to commit to supporting Python 2 + backported Python 3 features, they are of course welcome to do so provided they observe the license and trademark terms (not terribly hard to do). But I suspect it won't last very long, at least not as a small-team zero-dollar-cost project. Between Python 3 gaining steam and people staying on 2 in order to avoid work and expense, I just don't think it's going to work out on the kind of decades-long horizon the Python 2 die-hards seem to want.

Re: Why I'm Making Python 2.8

#369

Earlier quoted context omitted.

Except if you make an exception for bytes, what about other types that might get passed into a CSV writer, whose __str__ is something "wrong" for CSV purposes? Do they also get auto-detected? Do we add a new __csv__() method just for when outputting to CSV (since it might not be "wrong" for other output formats)? Or do we ditch str()-ifying altogether, but then add back in a bunch of special cases for numeric types a…

`bytes` is plainly special case for historical reasons here - it's something that is not a string, but that so many people assume to be a string. So yeah, I would be fine with making an exception for it (and providing some kind of option to disable that exception, for that incredibly rare case where someone really does need b"foo" in their CSV output). And then in 5 years, flip the default of that switch, and depreca…

The entire problem, though, is people assuming bytes and strings are interchangeable. Anything which allows that assumption to go unquestioned, or without program-wrecking consequences, leads right back to where we were. And the "phase it out" model doesn't work; you proposed a ten-year phase-out, but in ten years people are just going to say "we never updated our code, we're not ready, keep it this way another ten years and we'll think about fixing our code". The only thing that works is actively breaking people's programs when they try to intermix bytes and strings.

Re: Why I'm Making Python 2.8

#370
post #158

Earlier quoted context omitted.

If you have several large software products rolled out and churning away at hundreds of customer sites, moving from Python 2.x all the way to 2.7 alone is a slow and tedious process of tests and deliberations. And we're still not talking about going all the way to 3.x which breaks things in even more new and exciting ways. So scoff all you want, but Python 2.x isn't going away that soon.

If moving to a 2010 version of your programming language is slow and tedious you're doing something very wrong. In the Java world (conservative and slow-moving) JRE 7 (2011) is considered the absolute minimum, and if you're not targeting JRE 8 (2014) you have to have a very good reason.

Try to move with half a million LoC of dynamically typed code with a handful of developers with not a single update breaking for any customer and I will be impressed.
Post reply on HN