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

Sunsetting Python 2

python.org

Post reply on HN
Print view View original

211–220 of 733 posts

Re: Sunsetting Python 2

#211

Post by CJefferson »

XCabbage wrote: post #52
CJefferson wrote: post #21

Earlier quoted context omitted.

The biggest problem is having a place to organise. The Python foundation is threatening to sue anyone continuing something called Python 2, or even a similar name. Finding volunteers who are willing to get sued to work on Python will be hard.

You've asserted this twice on this post, both times without any evidence. I Googled, couldn't find the threat you're basing the claim on, but DID find that the PSF Trademark Usage Policy ( https://www.python.org/psf/trademarks/ ) explicitly allows most sorts of freely distributed Python-related products to use the name without permission: > Use of the word "Python" in the names of freely distributed products like Iro…

Sorry, I shouldn't assume people know the same things I know.

I know this has come up at least three times I've seen, but I'm having trouble finding them all. Here's one:

https://github.com/naftaliharris/tauthon/issues/47

In this case there was plans to call something py28, to which Guido replied "OK, bring in the lawyers".

Re: Sunsetting Python 2

#212

Post by CJefferson »

rlayton2 wrote: post #34
CJefferson wrote: post #25

One missing question: Q) I like Python 2. Can I take over Python 2 maintenence? A) NO. Try it and we'll sue you.

Is that the stance? I haven't heard anything on that front. I'm sure there is a great market opportunity for some developers to do the migrations, or to alternative do backporting for some large companies not interested in mingrating.

https://github.com/naftaliharris/tauthon/issues/47

(I've definitely seem other cases, but I can't find them). Here is someone wanting to call something 'py28', and Guido replies "OK, bring in the lawyers".

Re: Sunsetting Python 2

#213

Post by zajio1am »

wongarsu wrote: post #45
CJefferson wrote: post #21

Earlier quoted context omitted.

The biggest problem is having a place to organise. The Python foundation is threatening to sue anyone continuing something called Python 2, or even a similar name. Finding volunteers who are willing to get sued to work on Python will be hard.

Continuing a fork under the original name would be confusing to everyone and bad manners, aside from infringing the trademark. But nobody is stopping people from organising around a fork called "Omphalos - a Python 2 fork" or whatever

It would not be fork when the original project (Python 2) is no longer developed. There are many cases of cooperative maintainership handover without name change and nobody cares.

I understand using trademark as an advantage in cases of a hostile fork, but if the original maintainer no longer plan to do any bugfixing then it seems like a dick move.

Re: Sunsetting Python 2

#214

Post by bigiain »

jacquesm wrote: post #150
vkazanov wrote: post #73

Earlier quoted context omitted.

Not really. :-) ANSI C is very different to the whole pre-ANSI zoo of C-like languages. Most of the code I saw from that age would never compile on modern post-ANSI compilers.

Nonsense. I just compiled a pretty large project from the stone age using a modern day compiler. It required a few lines of change in all to make it compile and it ran the first time it compiled. C has many warts and design errors but they got the portability bit down quite well, the biggest problems you will run into are assumptions by programmers rarely assumptions by the designers of the language. One major thing…

To be fair though, in 10 years time I'll still be able to build the last release version of Python2 (quite likely using a modern-in-2029-C-compiler) and use it to run whatever stone age Python2 code in need to run.

What people seem to be getting uptight about here, is that the volunteer Python language devs have collectively chosen to not fix any bugs or security problems discovered in the older Python2 language interpreter. I can't quite get my head around what the equivalent for that in C would be? There kinda _are_ no "language security features" in C, right? C is the archetype "How powerful a gun would you like to shoot yourself in the foot with today" language.

Re: Sunsetting Python 2

#215

Post by vkazanov »

jacquesm wrote: post #164
SiempreViernes wrote: post #160

Earlier quoted context omitted.

That you could easily port an old C code to modern compilers seems doesn't seem to be in contradiction to the statement that old code will not compile as is .

A couple of lines change does not qualify as a port to me. It was less of a change than from one minor release of a modern language to another.

Prior to the ANSI standard there were many C compilers on different machines with different architectures.

Some compilers included support for architecture-specific things, like segmented memory, etc. Others allowed to do cross-function gotos. Types were not very well defined. Event the original language grammar from the book is only useful as an idea of what the language should be like, not as a proper syntax definition, I am not even talking about semantics here.

The code I had to deal with (written for 16-bit x86) had to be rewritten, it was definitely not a "fix-here-and-there" thing. It was fine, written by reasonable programmer and completely readable so I was able to understand and rewrite it in a week.

You probably were very lucky with that project of yours.

Even the way we have it nowadays C is... hard to formalise.

Re: Sunsetting Python 2

#216

Post by oblio »

mantap wrote: post #165
shakna wrote: post #124

Earlier quoted context omitted.

Python 2's EOL was first announced in 2008, it was extended in 2014. That's more than a decade of forewarning that this was coming down the line. A decade of Python2 receiving security fixes. Were I a commercial customer, and had been told to switch to the new version ten years ago, then it's on me if I still have started the migration yet.

You couldn't switch to Python 3 until the middle part of this decade unless the stars aligned with your dependencies, the library support wasn't there. And the first releases of Python 3 were glorified betas, the first "usable" version of Python 3 is often considered to be version 3.3 released in 2012.

2012 was 7 years ago.

Re: Sunsetting Python 2

#217

Post by [deleted] »

marsokod wrote: post #4
coldtea wrote: post #3

> If people find catastrophic security problems in Python 2, or in software written in Python 2, then volunteers will not help you. If you need help with Python 2 software, then volunteers will not help you. Well, isn't it the benefit of FOSS, that volunteers can, and in the case of such a critical piece, so much used as Python 2, in all probability will, step up. Doesn't have to be the same people as the core team i…

No, the benefit of FOSS is that if the group developing a product does not support it anymore, you are free to fork it and support it yourself. And I am sure we will see a fair share of people doing that. What I am not sure is of anyone doing so will have the shoulders to actually support it. Python 2.7 was released 1 decade ago. That's quite a long transition time.

[deleted]

Re: Sunsetting Python 2

#218

Post by peterwwillis »

jwr wrote: post #161

When people mock me for writing long-term projects in Perl 5 ( https://github.com/jwr/ccheck ), I point them to the Python2/3 change. From an outsider's point of view, this change was not coordinated well and the timeline is too short. To clarify: long-term means automotive time scales: I want to be able to run my software in 10 years.

> I want to be able to run my software in 10 years

You can! Just buy 10 year old hardware, and run a 10 year old operating system. That's how banks, schools, governments, etc are running 40 year old software.

Re: Sunsetting Python 2

#219

Post by wongarsu »

zajio1am wrote: post #213
wongarsu wrote: post #45

Earlier quoted context omitted.

Continuing a fork under the original name would be confusing to everyone and bad manners, aside from infringing the trademark. But nobody is stopping people from organising around a fork called "Omphalos - a Python 2 fork" or whatever

It would not be fork when the original project (Python 2) is no longer developed. There are many cases of cooperative maintainership handover without name change and nobody cares. I understand using trademark as an advantage in cases of a hostile fork, but if the original maintainer no longer plan to do any bugfixing then it seems like a dick move.

The original project (Python) is still developed however. If a handoff to some other team occurs and the new maintainers do a bad job this reflects negatively on Python 3.

Re: Sunsetting Python 2

#220

Post by bigiain »

leejo wrote: post #8
mrweasel wrote: post #5

Earlier quoted context omitted.

I honestly don't believe that many will step up and take over. Many will complain, but few will do the actual work. Even if it's just security fixes, there's still the process of testing and release management, and honestly, I don't blame the core Python team for no longer wanting to do release management of both Python 2 and 3.

> Many will complain, but few will do the actual work. That's opensource in a nutshell. If there are any big shops stuck on Python 2 then they will probably throw a resource or two at this. If there are big dists using Python 2 they will do the same.

> then they will probably throw a resource or two at this

Which, I'd guess, is probably gonna be 3 or 4 orders of magnitude more money than they've ever spent supporting Python2 (or 3) devs in the 10+ years they've built their own businesses on it while they sat on their hands and ignored the project's urging to upgrade to Python3...

Not a lot of sympathy from me for "big shops stuck on Python2"...

Post reply on HN