Live data from Hacker News

Why I'm Making Python 2.8

naftaliharris.com

31–40 of 392 posts

Re: Why I'm Making Python 2.8

#31
post #29

Earlier quoted context omitted.

> Please, do not put obsolete software on life support. Downvoting because Python 2 is anything but obsolete. People still love using it.

I am glad that you explain why you downvote, but I disagree. The fact that people love and use something doesn't mean it cannot be obsolete. At work, I care about more than 35 years old software. It is obsolete (it's written in mainframe SAS with 3270 green screens and some assembly), but people still love using it, mainly because there is no good alternative and it does the job very well.

What makes something obsolete in your eyes then? Just because some people want A to replace B, that makes B obsolete?

For reference, Oxford dictionaries define (..."define"? are multiple dictionaries involved here?) "obsolete" as:

1. no longer produced or used; out of date.

Clearly Python 2.7 is in widespread use, and version 2.7.12 came out just a few months ago, so it's neither "no longer produced" nor "no longer used" nor "out of date"...

Re: Why I'm Making Python 2.8

#32

Python programmers and companies with python code should spend the time and effort to move to python 3 instead of spending that time and effort to backport stuff to python 2 because python 2 is deprecated and the future is python 3. Python 3 I think people and businesses with python 2 code would be better off moving their code bases to python 3 instead of doing things like this.

Companies with Python code are probably better off keeping their working, tested code than switching to an incompatible interpreter and set of libraries which among other things will print "b'Hello',b'World'" into their mission critical CSV files.

Yes, the built in csv module really does that in Python 3.

Re: Why I'm Making Python 2.8

#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 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 it, so the claimed loss of productivity is on you.

> Unlike 2.7 code, Python 2.8 wouldn't be able to guarantee exact 3.x compatibility, since there are some python scripts that will run under both Python 2.7 and Python 3.x but produce different output, and Python 2.8 chooses the 2.7 behavior in these cases.

What a terrible, terrible situation. Now you'll have "python" code that will neither run on 2.7 nor run compliantly on 3.x. As for the latter, please explain how that will alleviate anything on the following point, since behaviour at runtime will be subtly different:

> adding these remaining Python 3 features would greatly simplify running code targeting Python 3, and allow people to use Python 2.8 to run a mix of Python 2 and 3 code.

I don't know what recourse the PSF has but maybe they should even go all in and defend the "Python" name so as to prevent confusion and stop a potential community fracture. Just call it anything else but "Python 2.8" is not Python.

Re: Why I'm Making Python 2.8

#35

Earlier quoted context omitted.

> Python programmers and companies with python code should spend the time and effort to move to python 3 instead of spending that time and effort to backport stuff to python 2 because python 2 is deprecated and the future is python 3. I hate Python 3's removal of the (lambda (key, value): blah) tuple unpacking syntax, and the forcing of parentheses for print statements. They might seem minor but they aren't for me. S…

Benefits? Unicode. Async. Extended library. Required keywords. syntax inprovements (lots of m, many more than just the removal of the print statement). Type hinting.

> Benefits?

I meant I don't see any benefits for me, not benefits for other people. I assumed that was clear; sorry if it wasn't.

> Unicode.

Yeah, but some people have still been living without the changes, and it's hardly enough of a reason on its own (for me anyway) when there's other things I hate about the language.

> Async.

It's a nice feature, yeah. I can live without it, as people have for many years. Maybe if I was used to having it around I wouldn't want to go back, but I'm not.

> Extended library.

Cool! I'm not sure what exactly falls under this that I'm supposed to be missing, but pip install has sure been taking care of everything in the blink of an eye in version 2.

> Required keywords.

Cool! I need it about as much as I need a donut.

> syntax inprovements (lots of m, many more than just the removal of the print statement).

nonlocal is literally the only positive one I can think of right now that I'd actually care about. But then again, it comes up maybe 50x less often than the parentheses I have to write for print, or the tuple unpacking that I have to do. So yeah, it's hardly a reason to migrate.

> Type hinting.

Nice to have. I'm living just fine without it. Maybe I'd have migrated if it actually optimized things or did something more useful.

Re: Why I'm Making Python 2.8

#36
post #32

Python programmers and companies with python code should spend the time and effort to move to python 3 instead of spending that time and effort to backport stuff to python 2 because python 2 is deprecated and the future is python 3. Python 3 I think people and businesses with python 2 code would be better off moving their code bases to python 3 instead of doing things like this.

Companies with Python code are probably better off keeping their working, tested code than switching to an incompatible interpreter and set of libraries which among other things will print "b'Hello',b'World'" into their mission critical CSV files. Yes, the built in csv module really does that in Python 3.

But people that have that csv issue have deeper lurker encoding issues they're probably not aware of.

Sure, don't change the stuff that works and cause yourself unnecessary pain, but don't blame python 3 for your misencoded data.

Re: Why I'm Making Python 2.8

#37
post #29

Earlier quoted context omitted.

I am glad that you explain why you downvote, but I disagree. The fact that people love and use something doesn't mean it cannot be obsolete. At work, I care about more than 35 years old software. It is obsolete (it's written in mainframe SAS with 3270 green screens and some assembly), but people still love using it, mainly because there is no good alternative and it does the job very well.

What makes something obsolete in your eyes then? Just because some people want A to replace B, that makes B obsolete? For reference, Oxford dictionaries define (..."define"? are multiple dictionaries involved here?) "obsolete" as: 1. no longer produced or used; out of date. Clearly Python 2.7 is in widespread use, and version 2.7.12 came out just a few months ago, so it's neither "no longer produced" nor "no longer u…

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 in the C implementation), "obsolete" means there is a new standard by some official body (say, the developer of the old standard) that addresses shortcomings of the old standard. So "out of date" is the fitting equivalent of "obsolete" from the Oxford definition.

Re: Why I'm Making Python 2.8

#38
post #21

I can't fault a single thing in his justification. This should have been the approach to modernising python all along.

This approach could not have worked for modernizing python. The whole point of the Python 3 thing was to be able to remove warts in the language that could not have been fixed without breaking backwards compatibility. One core part of this is unicode support -- Python had a horrible story for international text before this.

The fact that there are some parts of "modern" Python which could have been implemented in Python 2.7 backwards-compatibly is irrelevant.

Python 3 is not the language designers worrying about minor subjective issues in python like the print keyword or the design of iterators and deciding that they want to change it all. It is the language designers worrying about major issues like international text, realizing that they regrettably will have to break backwards compatibility to fix those, and then just taking the opportunity to revamp things like printing and iteration since they're breaking backcompat in some pretty major ways anyway.

Re: Why I'm Making Python 2.8

#39
post #20

I make software that people can write plugins for in Python. After months, years of struggle we finally dropped support for Python 2 because our small team could not bear the overhead of maintaining two bindings. We work a lot with researchers in signal processing domain and we have hard time as it is to get people to use Python 3. Please, do not put obsolete software on life support.

[deleted]

Re: Why I'm Making Python 2.8

#40
post #29

Earlier quoted context omitted.

I am glad that you explain why you downvote, but I disagree. The fact that people love and use something doesn't mean it cannot be obsolete. At work, I care about more than 35 years old software. It is obsolete (it's written in mainframe SAS with 3270 green screens and some assembly), but people still love using it, mainly because there is no good alternative and it does the job very well.

What makes something obsolete in your eyes then? Just because some people want A to replace B, that makes B obsolete? For reference, Oxford dictionaries define (..."define"? are multiple dictionaries involved here?) "obsolete" as: 1. no longer produced or used; out of date. Clearly Python 2.7 is in widespread use, and version 2.7.12 came out just a few months ago, so it's neither "no longer produced" nor "no longer u…

I'd argue Python 2.7 counts as no longer produced. The 2.7.x releases with their bugfixes are akin to an electronics company still honoring the warranty of tape recorders and still repairing them. That doesn't mean tape recorders are not obsolete, especially since the company is not making them anymore. I consider the parallel 'making software' to be the process of

    feature proposal -> patch -> review -> merge
Post reply on HN