Live data from Hacker News

Why I'm Making Python 2.8

naftaliharris.com

181–190 of 392 posts

Re: Why I'm Making Python 2.8

#181
post #33

> And the majority of Python code written does not run under any of the 3.x interpreters. This makes it harder for its users to be productive. 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 writ…

I think after 5 years we should came to the realization that Python 3.x is not the future of Python. You can't blame people to try to find solution.

Re: Why I'm Making Python 2.8

#182

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…

This argument is a reasonable one and is why we all support IE6 for web dev. However, at a certain point it is worth your time to move forward instead of doing nothing, you gain a little time savings now and you run into few moments of "Oh @#$%^!!" later. Real world example: You don't bother updating ssl to deal with weak DHE and suddenly chrome users can't see your payment site. My approach has always been to try to…

Except Python 3.x is bringing controversial changes and was slower than Python 2.x for several years.

If IE7 was slower than IE6, you can't blame people to not move over.

Re: Why I'm Making Python 2.8

#183
post #37

Earlier quoted context omitted.

Python 2.7 is outdated by Python 3.5. The fact that there is a bugfix release doesn't change that. I mean look at other things. You can still program in C 89 or FORTRAN 77 or COBOL 74 (and no doubt there is somebody still supporting compilers and runtimes for those), but they are all obsolete standards. Addendum: I think for standards like programming language semantics (which in case of Python is directly embodied i…

> You can still program in C 89 or FORTRAN 77 or COBOL 74 (and no doubt there is somebody still supporting compilers and runtimes for those), but they are all obsolete standards. The situation with C89 and Fortran 77 is completely different than what you see today with Python 2 vs Python 3. For 99.9999% of C89 and Fortran 77 code you can build the old code with new C and Fortran compilers and use it from today's stan…

I don't disagree it is different. My argument was that a new release of compiler for an obsolete standard doesn't cause the standard not to be obsolete.

I am pretty sure there is theoretical way to run Python 2 code alongside Python 3 code, but they simply decided it's not worth the effort.

Edit: I think historically Python 2/3 divide is more akin to Maclisp/Common Lisp divide, but in the latter, the situation was even more complicated. But I doubt you can just take Maclisp code and run it on Common Lisp implementation, despite that fact that it was meant as a successor.

Re: Why I'm Making Python 2.8

#184

Earlier quoted context omitted.

>If they had have called Python 3.0 v2.9 instead everyone would have been clear they had to migrate. Massive breakage of backwards compatibility in a minor release is bad form. They absolutely did the right thing by naming it Python 3.0.

They could deprecate the breaking changes - for example Python 2.8 could make print statements needlessly more awkward to write but warn instead of error and Python 2.9/3.0 could make the changes permanent. Rather than have this huge break maybe just take the time to move all of Python forward rather than us still 8 years after Python 3 leave us still talking about it.

> They could deprecate the breaking changes - for example Python 2.8 could make print statements needlessly more awkward to write but warn instead of error

Interesting. Now I want to make my own Python 2.8 which is 2.7.latest with the "-3" command line argument hardcoded to always be set.

Re: Why I'm Making Python 2.8

#185
post #33

> And the majority of Python code written does not run under any of the 3.x interpreters. This makes it harder for its users to be productive. 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 writ…

I currently work for a client who has decided to shift away from PHP and towards Python. They had a monolithic PHP app with perhaps 250,000 lines of code. Now we are developing a series of Python apps in the microservices style. We've decided to develop everything as Python 2.7. We are not looking at Python 3.x. There are a few reasons. Some libraries that we want are in Python 2.7. And Amazon only supports 2.7. And…

If I was your client I'd be pissed that you decided to rewrite my code into a legacy version of Python. Make no mistake: Python 3 is the future of Python. There will be no version 2.8 and there is no going back to 2.7.

Also, I don't know what you mean by "Amazon only supports 2.7" because boto (the main client for Python) has supported Python 3 for 2 years now. Perhaps you mean Lambda?

Re: Why I'm Making Python 2.8

#186
> there are some python scripts that will run under both Python 2.7 and Python 3.x but produce different output

OK, so it may well be terrific, but it should really have a different name.

Re: Why I'm Making Python 2.8

#187

Earlier quoted context omitted.

> This should have been the approach to modernising python all along. The core driver for the Python 3 break was the fix in text model, this is what allowed literally everything else as it completely broke existing code. And I, for one, think it's one of the most important improvements of Python 3, the text model of Python 2 is a giant mess and makes it very hard to correctly deal with non-ascii text for any non-triv…

> the text model of Python 2 is a giant mess and makes it very hard to correctly deal with non-ascii text for any non-trivial software There are counter-arguments to this. Armin Ronacher, author of (among other software) the excellent Flask web framework, thinks that Python 2's system of codecs and byte streams is better in practice [1][2]. Reasons include: You can do byte -> byte conversions with codecs that are no…

Armin has backed off of this stance since then. And for good reason.

As someone who works with Python text processing extensively, I can tell you that the Python 2.7 text model is broken and dangerous, due to the silent bytes-unicode coercion and misguided use of ascii instead of UTF-8 as the default text encoding. Many people don't realize this and will argue that it's not broken, because they have never fed non-ascii text through their app to watch it blow up! And once they realize that they have a problem, they then have to deal with a rat's nest of silent bytes-unicode coercions happening implicitly all over their app, sometimes impossible to deal with due to library code outside their control.

There is a good discussion to be had on whether a language should prioritize bytes or unicode strings as the main data type, but there is no excuse for the "ticking timebomb" string data type design that pre-3 Python has with strings and the default encoding.

For this reason alone I'm very happy that 2.7 is starting to lose its grip. Its continued support is a problem, and I have no love for people who are trying to hold on to it.

There are many other features in 3 that I can no longer live without - most of them now available through backports modules - but types and asyncio can't be easily backported either, and people are starting to use them extensively.

Re: Why I'm Making Python 2.8

#188
post #54

Earlier quoted context omitted.

Tape recorders are not still being made; verdict: obsolete T-shirts are still being made; verdict: not obsolete Python 2 is not still being made; verdict: obsolete

That's not for the manufacturer to decide. Python 3 is like Coca Cola declaring that the New Coke is all people should drink, and stopping production of classic coke. Python 2 is still being "worn" by millions of programmers, and is what runs in the biggest installations. This includes new code written for those installations, that it's written to run in the same 2.x environment.

> That's not for the manufacturer to decide. Python 3 is like Coca Cola declaring that the New Coke is all people should drink, and stopping production of classic coke.

That is within the rights of a manufacturer though. Coca Cola can continue to produce classic coke because it isn't any more or less complicated to produce than New Coke. The PSF's opinion is the new features they develop are best developed on top of the core changes in Python3, and that adding new features to Python2 is too expensive to maintain in addition to Python3. I feel like the cases are too different to work.

Re: Why I'm Making Python 2.8

#189
post #163

Earlier quoted context omitted.

> Since Python strings have no fixed encoding, but choose "the most efficient one" (heuristically) when decoding, they can cope better than a fixed UTF-8 encoding in these cases. That is wrong. Python can never pick the most efficient encoding unless you decode from latin1.

PEP 393

That's why I said it can use the most appropriate encoding in the latin1 case. Before that it would never have the right encoding.

Re: Why I'm Making Python 2.8

#190
post #37

Earlier quoted context omitted.

Python 2.7 is outdated by Python 3.5. The fact that there is a bugfix release doesn't change that. I mean look at other things. You can still program in C 89 or FORTRAN 77 or COBOL 74 (and no doubt there is somebody still supporting compilers and runtimes for those), but they are all obsolete standards. Addendum: I think for standards like programming language semantics (which in case of Python is directly embodied i…

> Python 2.7 is outdated by Python 3.5. The fact that there is a bugfix release doesn't change that. That's just what the lead project team declared. Not what the user base asked for or wants. > You can still program in C 89 or FORTRAN 77 or COBOL 74 (and no doubt there is somebody still supporting compilers and runtimes for those), but they are all obsolete standards. That's because people stopped using them organic…

> That's just what the lead project team declared. Not what the user base asked for or wants.

You think they are doing it just for kicks? There are no issues with Python 2? They are also part of the user base, and they did it for a reason.

> That's because people stopped using them organically. That's not the case with Python 2 -- Python 3 was declared "the new hotness" with a decree from above.

Well, I for instance stopped using Python 2 when Python 3 came out, if it was possible for me to do so (I had all the libraries I needed). I understand that many people can't do it, but people are organically moving from Python 2 to Python 3, not the other way around.

Nobody is really forcing you to not use Python 2, just as nobody is forcing you not to use FORTRAN 77 or COBOL 74. It's just that the language will not evolve anymore, and as far as runtime goes, you will be on your own eventually.

> It's like as if the W3C comes out with some incompatible HTML NG on their own and says that HMTL 5 is "end of line", giving billions of webpages the middle finger.

I think I already addressed this in my other comments.

Post reply on HN