Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Is the Migration to Python 3 Taking So Long?

stackoverflow.blog

Post reply on HN
Print view View original

341–350 of 355 posts

Re: Why Is the Migration to Python 3 Taking So Long?

#341

Post by someguydave »

michaelmrose wrote: post #336
pbreit wrote: post #335

Earlier quoted context omitted.

Dropping support is about as user-hostile as it gets. Once again, how can you ask/require users to expend precious limited energy to re-program just to stay in place? It's totally obnoxious and completely unnecessary.

It's absolutely amazing to me that people can pay nothing for something and frame the party providing that software for free opting not to spend even more effort to provide bug fixes for an old version of their software as them effectively taxing them. This is especially true of python 2 which is was supported from the release of python 3 in 2008 until 2020 and further supported by red hat until 2024. This is exactly…

“ Nobody is after all taking away your version of python 2 or ability to use and maintain it” No, but they are taking away the right of anyone who does this to call the result “python”, and that is user-hostile.

Re: Why Is the Migration to Python 3 Taking So Long?

#342

Post by spronkey »

int_19h wrote: post #286
downerending wrote: post #181

Earlier quoted context omitted.

Note that the question is not "Shall we support Unicode?". Clearly we should. The question is rather whether it would have been better to gradually improve support for it in a Python2-esque way, rather than creating a discontinuity and a raft of new problems, some of which linger to this day. Also, for many purposes, there is wide agreement that ASCII is still the way to go. Even if Americans vanished tomorrow, the m…

There was no way to gradually improve Unicode support in Python without breaking things, because a big part of it was stuff like implicit str/unicode conversions - that were broken because they practically never use the right encoding, but that you can't remove without introducing as much breakage as Python 3 did.

You lack imagination here :) There are several solutions that could have been pursued, including introducing a completely new type and effectively duplicating the existing string library for it.

Re: Why Is the Migration to Python 3 Taking So Long?

#343

Post by coldtea »

voldacar wrote: post #280
coldtea wrote: post #98

Earlier quoted context omitted.

Java is nothing like a mess, and JS is going from strength to strength.

int max = new Max(10, 5).intValue();

Not sure what's that supposed to be. What's this "Max" class?

In any case, that's not some counter-argument, even if it points to a real wart.

It's "let me throw a random Java wart, as if it means something, and as if other languages don't have their own warts".

Re: Why Is the Migration to Python 3 Taking So Long?

#344

Post by test7777 »

kstrauser wrote: post #108
test7777 wrote: post #100

Earlier quoted context omitted.

unix pipes (stdin, stdout) are bytes, files are bytes, filenames are bytes. yet, for some reason python3 thinks al of those are text. its not the coders that are wrong, it is the language.

No, it's Python 2 that thinks those are all text. Python 3 makes you explicitly say "convert this stream of bytes into a text encoded string", and from then on it's a str object. Python 2 was happy to (try to) let you call text methods on a JPEG. Python 3 draws an appropriate distinction between the two.

Python 2's "str" is a bytestring. All of those are bytestrings in Python 2 as they should be. Python 3 makes them text and suddenly i can not output data over stdout anymore without extra steps of switching the mode of stdout from some arbitrary text default.

Re: Why Is the Migration to Python 3 Taking So Long?

#345

Post by test7777 »

joshuamorton wrote: post #120
test7777 wrote: post #100

Earlier quoted context omitted.

unix pipes (stdin, stdout) are bytes, files are bytes, filenames are bytes. yet, for some reason python3 thinks al of those are text. its not the coders that are wrong, it is the language.

kstrauer is right, but I'll elaborate and say that places where you are interfacing with Unix threads are input boundaries, so having the programmer make a choice makes sense. Arbitrary switching within a program does not.

the issue is that the language arbitrarily decides those things should be treated as text with some arbitrary encoding when all of them are decidedly not text.

Re: Why Is the Migration to Python 3 Taking So Long?

#346

Post by [deleted] »

klyrs wrote: post #260
user5994461 wrote: post #221

Earlier quoted context omitted.

I think pip can select the version automatically as long as you provide the right metadata with the package. Shouldn't matter much really. Maybe write in the README that the package is only tested on 3.7 and above so users can be aware of that and check. Bet they struggle to figure out what version to upgrade to as well.

> I think pip can select the version automatically as long as you provide the right metadata with the package. Shouldn't matter much really. I don't think pip can install new versions of python. This becomes burdensome, especially for novices. > Maybe write in the README that the package is only tested on 3.7 and above so users can be aware of that and check. Bet they struggle to figure out what version to upgrade to…

[deleted]

Re: Why Is the Migration to Python 3 Taking So Long?

#347

Post by pbreit »

michaelmrose wrote: post #336
pbreit wrote: post #335

Earlier quoted context omitted.

Dropping support is about as user-hostile as it gets. Once again, how can you ask/require users to expend precious limited energy to re-program just to stay in place? It's totally obnoxious and completely unnecessary.

It's absolutely amazing to me that people can pay nothing for something and frame the party providing that software for free opting not to spend even more effort to provide bug fixes for an old version of their software as them effectively taxing them. This is especially true of python 2 which is was supported from the release of python 3 in 2008 until 2020 and further supported by red hat until 2024. This is exactly…

Two of the worst responses ever:

1. it's free so it's OK to be user-hostile

2. if you don't like the direction, just fork/fix it

Re: Why Is the Migration to Python 3 Taking So Long?

#348

Post by int_19h »

spronkey wrote: post #342
int_19h wrote: post #286

Earlier quoted context omitted.

There was no way to gradually improve Unicode support in Python without breaking things, because a big part of it was stuff like implicit str/unicode conversions - that were broken because they practically never use the right encoding, but that you can't remove without introducing as much breakage as Python 3 did.

You lack imagination here :) There are several solutions that could have been pursued, including introducing a completely new type and effectively duplicating the existing string library for it.

It's not just the string library that is affected. It's literally every API in the stdlib that returns a string. You'd have to fork all of those, because changing any of them to return a completely new type would be a breaking change as well.

Re: Why Is the Migration to Python 3 Taking So Long?

#349

Post by takeda »

josefx wrote: post #311
c-cube wrote: post #263

Earlier quoted context omitted.

What kind of text do you have to process at your job, that you never meet any unicode in it? Nowadays unicode is everywhere, especially with emojis. Even a simple IRC bot needs to handle that.

I deal with file formats that like plain text files and zip do not specify an encoding and have different encodings depending on where they come from. I think the generic approach is to guess, which means trying encodings until one successfully converts unknown input to garbage unicode resulting in output that is both wrong and different from the original input. Most of the time I can just treat the text contents as…

In that case you should be opening files in binary mode "b", then you will be operating in bytes.

Also, there's no guessing happening in this instance. A locale configured in your environment variable are used if you open files using text mode.

Re: Why Is the Migration to Python 3 Taking So Long?

#350

Post by just_myles »

wvenable wrote: post #174
just_myles wrote: post #155

Earlier quoted context omitted.

This is true. But, I think he means syntactically you can make jumps from one dbms to another without much of a fuss. Obviously there are non-language features but, that is not what is being discussed here.

Dealing with Unicode in SQL has long been a backwards-compatibility nightmare.

In all fairness, dealing with unicode in general has been a pain point for me.
Post reply on HN