Hacker News Reader

Comment by drej | Hacker News Reader

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 to Python 2's docs? I think it would be quite instructive.

View on HN

I cannot agree enough.

As a casual python user, it is quite common to stumble in some issue, after somme googling land in a doc page, try my solution, and find it does not work. Then googling after the failed solution, noticing that the previous doc page was describing a Python 2 feature that do not exists (or works different) in Python 3.

This issue is part of why Haskell is so hard to learn. Haskell's package database Hackage keeps all old deprecated incompatible versions of packages, with documentation pages all well indexed by Google, with higher page rank because they are longer lived than the current package version, with no indication that they are deprecated and incompatible with current Haskell deployments.

Try Hoogle.

Hoogle has its own problems...

This is also the problem haskell stack solves

"Haskell. The cause of, and solution to, all of life's problems."

"Stack" is the name of a product; it wasn't a generic reference to "the Haskell stack".

It really shouldn't be beyond the wits of the hackage developers to include a normative URL in old docs...

Me three! It happens all too often that an example Python script fails in one, then succeeds in the other. I'm also a casual Python user, trying to ramp up because of its obvious popularity and utility. I wish that the basic syntactical changes could have been designed to be more backward-compatible. But, eventually I suppose, python2 will just be a footnote in history.

Same situation here. Trying to jump on this bandwagon and finding it's a slithering target.

I just wish they'd named it something different. If there's neither forward nor backward compatibility, I'd argue they're not the same language and should not have the same name.

Most languages have had breaking changes at some point in their history. Even the language known as "Perl 5" had them in almost every version.

In the real world, I've found Perl scripts written in 1999 (and poorly - as they were written by me in my teens) will still run in 2019. It's basically the policy that even language mistakes won't be undone:

https://perldoc.perl.org/perlpolicy.html#BACKWARD-COMPATIBIL...

I'm afraid it will forever remembered as a cautionary tale of a bad transition.

I keep forgetting how have python one liner of a http server. And always when Google the python2 version will appear and always to play with the search term to get it.

python3 -m http.server

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.

I'm not sure this is the right place, but maybe open an issue here?

https://bugs.python.org/

Or email the mailing list for more help?

https://mail.python.org/mailman/listinfo/python-list

I was about to file a bug, but they found out it already exists, just hasn't been merged into the 2.x tree.

- https://github.com/python/cpython/commit/46ed90dd014010703c7... - https://github.com/python/cpython/pull/13638 - https://github.com/python/cpython/blob/master/Doc/README.rst...

Python 2.7 isn't yet unsupported, so it doesn't compare to the deprecated Postgres version you linked to. Click through to the oldest _supported_ Postgres version, and it isn't clear when _it_ will lose support - no banners at all - , just like the currently supported Py 2.7.

That's true.

And because of changes in PostgreSQL versioning, people don't release that the oldest support version (9.3) is rather old.

PostgreSQL 9.6 was released in 2016, 10 in 2017, and 11 in 2018.

But PostgreSQL 9.3 was released way back in 2013...not quite as old as Python 2.7 but close.

Django has a similar banner at the top if you (perhaps via Google) get to a page about a feature in a deprecated version. So it's not like this is uncommon in the Python world. Hopefully they get that fixed soon.

HL7.org has a banner on every version of the FHIR spec with a different message depending on the version. http://hl7.org/fhir/

I would discourage this, as it will lead to banner blindness. Only pop a banner up if you want the user to read and react to it. Otherwise, they'll just get used to the banner being there and will often times not read it at all.

It seems to work pretty well for everyone. FHIR developers are keenly aware of the version of the spec they are (currently) targeting.

Also they are color coded.

Reply on news.ycombinator.com