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

711–720 of 733 posts

Re: Sunsetting Python 2

#711

Post by greglindahl »

kstrauser wrote: post #560
privateSFacct wrote: post #453

Earlier quoted context omitted.

Anyone with a large python 2 codebase is going to want to stay behind if they could. People still run old FORTRAN from 20 years ago in production. I'm sure some old COBOL code is out there. The reality of not wanting to re-write working code is somewhat real.

Are people routinely still purposefully writing new code in 20 year old versions of FORTRAN, or just maintaining existing stuff?

Back when my startup had a Fortran compiler as one of its products, most of our customers were writing new code in modern Fortran, and modernizing old code. The folks who were just running what they had without updating it probably were using g77 or another free compiler.

Re: Sunsetting Python 2

#712

Post by speedplane »

DangerousPie wrote: post #253
drej wrote: post #159

What surprises me about this is that the documentation for Python 2 does not explicitly say that the language version is about to be unsupported, see e.g. https://docs.python.org/2/library/zipfile.html Contrast this with the Postgres website, which tells me I'm browsing old docs (because Google still offers old links), see e.g. https://www.postgresql.org/docs/9.2/tutorial-window.html Are there plans to add a banner t…

100% agree. I think every Python 2 doc page should have a big banner on top mentioning the EOL status of Python 2 and linking to the coresponding Python 3 page (if there is one). Googling "python + keyword" far too often still takes you to the Python 2 docs.

> I think every Python 2 doc page should have a big banner on top mentioning the EOL status of Python 2 and linking to the coresponding Python 3 page (if there is one).

I'd support that if every Python 3 page had a link saying "if you're still a sorry SOB stuck on Python 2, here's the link to the related library." It's just as bad for Python 2 developers, it's roughly a 50/50 shot of whether you get docs for 2 or 3.

Re: Sunsetting Python 2

#713

Post by bradenb »

normalhuman wrote: post #576
bradenb wrote: post #511

Earlier quoted context omitted.

What confuses you about what I said? “Not being reddit” and “not being elitist” are not mutually exclusive. EDIT: I think it's clear nothing more needs to be said. Feel free to respond to this comment or not. I've said my piece.

Come on now, don't be disingenuous. Of course they are mutually exclusive, because you mean "not being reddit" as in "we are better than reddit" -- an elitist stance.

I said I was done but I have to respond to this. Reddit prides itself on tangents and bickering and jokes. It’s great. I love Reddit. But I come to HN for focused technical discussion. I don’t believe one is inherently better than the other. Therefore, I believe it is not mutually exclusive.

Re: Sunsetting Python 2

#714

Post by Kaiyou »

ilikehurdles wrote: post #400
Kaiyou wrote: post #360

Earlier quoted context omitted.

You can do that, but then they won't accept your solution, so you just spend time developing a parallel system that you need to support yourself until the end of time. Been there, done that.

If there is significant demand for solving the problem your fork solves, others will migrate to it. This is made harder when the main solution gets to squeak along for 10 extra years on a version of the language that should no longer get first-party support. Of course there is going to be less demand for that Py3 solution when there is no immediate consequence for continuing on Py2. Killing security update support fo…

How are they supposed to migrate if I can't openly host my solution because it was developed on company time? Merging back into the original project is one thing, but making your solution available some other way is a whole other story.

Re: Sunsetting Python 2

#715

Post by andruby »

speedplane wrote: post #708
sametmax wrote: post #508

Earlier quoted context omitted.

By experience, people with large Python projects often overblown the difficulty of porting in their head. Unless you have a very rare irreplaceable dependency or some terrible C extension, porting is easy. It's tedious yes. Boring even. But most projects get away with 2 weeks of investment. And yes, it pays back. Python 3 is a vastly superior language when it's about introducing less bugs or debugging existing ones.…

> By experience, people with large Python projects often overblown the difficulty of porting in their head. ... most projects get away with 2 weeks of investment. Where did you come up with this "2 weeks" estimate? That has not at all been my experience.

What has been your experience?

Re: Sunsetting Python 2

#716

Post by gnulinux »

carapace wrote: post #703
gnulinux wrote: post #702

Earlier quoted context omitted.

Porting a python 2 project to Julia/Haskell/Prolog is rewriting the entire codebase. Porting py2 to py3 is a little more than a few men-month of work. In my company we have >2 million line of py2 code and we spent a few weeks converting all to py3 (biggest problems being str/unicode and None comparison) and less than a month later our prod runs py3. I don't want to come off condescending, I really want to understand…

> I don't want to come off condescending, I really want to understand your point. Same here! Well met. > But I have no idea what you're trying to say. Sorry, I'll try again. > Porting a python 2 project to Julia/Haskell/Prolog is rewriting the entire codebase. Sorry, I was thinking of new projects there. To understand my point keep in mind that I'm assuming a world where Python 2 stays stable and maintained (if only…

Yeah I see your point. To me it's all about trade-offs. A year from now Py3 will have a larger community than whatever replaces Py2. So, investing time to port my code to Py3 was worth it.

> In sum, the very fact that py2 is now stable and unchanging is a killer feature (IMO) that differentiates it from py3!

This is a good point, but I disagree. As long as they make future py3 versions backwards compatible, it doesn't affect me if they keep changing py3. To me, it's more important that the world will be operating on py3 as opposed to py2; this is the killer feature of py3.

Re: Sunsetting Python 2

#717

Post by wedesoft »

Really difficult to track are issues caused by things like the map function now returning an iterator object. I.e. the content of the iterator is empty on second use.

  Python 3.4.3 (default, Oct 14 2015, 20:28:29) 
  [GCC 4.8.4] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> x = map(lambda v: v + 1, [1, 2, 3])
  >>> list(x)
  [2, 3, 4]
  >>> list(x)
  []

Re: Sunsetting Python 2

#718

Post by richardboegli »

carapace wrote: post #421

Going forward, I'll be maintaining Python 2.7 for the indefinite future. This will be under project name "Bladders". (Python is named after Monty Python's Flying Circus. There is another fantastic British comedy called Black Adder, and the main character is sometimes called "Bladders" as a contraction of Black Adder.) Unlike Tauthon, I won't change the language at all, only maintenance. I'm also going to make a curat…

You've got no contact details on your profile....

Re: Sunsetting Python 2

#719

Post by carapace »

richardboegli wrote: post #718
carapace wrote: post #421

Going forward, I'll be maintaining Python 2.7 for the indefinite future. This will be under project name "Bladders". (Python is named after Monty Python's Flying Circus. There is another fantastic British comedy called Black Adder, and the main character is sometimes called "Bladders" as a contraction of Black Adder.) Unlike Tauthon, I won't change the language at all, only maintenance. I'm also going to make a curat…

You've got no contact details on your profile....

I suppose there's no point in putting this off any further, eh?

Project repo: https://git.sr.ht/~sforman/Bladders Mailing list: https://lists.sr.ht/~sforman/bladders-announce Subscribe: mailto:~sforman/bladders-announce+subscribe@lists.sr.ht

At this moment it is total vaporware. I should have some time this week to clone the Python 2 code and set up a virtual server farm to compile it and run test suite on some different platforms, as a start. (Or I just remembered srht has a "builds" tool that might be just the ticket.)

Re: Sunsetting Python 2

#720

Post by carapace »

gnulinux wrote: post #716
carapace wrote: post #703

Earlier quoted context omitted.

> I don't want to come off condescending, I really want to understand your point. Same here! Well met. > But I have no idea what you're trying to say. Sorry, I'll try again. > Porting a python 2 project to Julia/Haskell/Prolog is rewriting the entire codebase. Sorry, I was thinking of new projects there. To understand my point keep in mind that I'm assuming a world where Python 2 stays stable and maintained (if only…

Yeah I see your point. To me it's all about trade-offs. A year from now Py3 will have a larger community than whatever replaces Py2. So, investing time to port my code to Py3 was worth it. > In sum, the very fact that py2 is now stable and unchanging is a killer feature (IMO) that differentiates it from py3! This is a good point, but I disagree. As long as they make future py3 versions backwards compatible, it doesn'…

> A year from now Py3 will have a larger community than whatever replaces Py2.

> the world will be operating on py3 as opposed to py2

You're right, but like I said, for new stuff I'm using Haskell or Prolog or something, not Python {2,3}.

I don't want to advance Python 2 --well, by adding and improving libraries and tooling I do, but not because I plan to make new stuff in py2, rather to make maintenance cheaper-- I just want to prevent it from dying. I'm really only interested in maintenance. Otherwise I would just contribute to Tauthon, but they're modifying the interpreter/language whereas I just want to make the existing thing more solid.

Well met. :-)

Post reply on HN