Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop python2 support after 3.1 #6537

Closed
faho opened this issue Jan 25, 2020 · 13 comments
Closed

Drop python2 support after 3.1 #6537

faho opened this issue Jan 25, 2020 · 13 comments

Comments

@faho
Copy link
Member

faho commented Jan 25, 2020

As we all probably know, python 2 is EOL, so it might be time to drop support for it.

We currently use python in a few places:

  • webconfig
  • manpage completion generation
  • the docs (sphinx + configuration + our fish_indent_lexer)
  • littlecheck
  • some completion scripts (npm, bower, yarn, composer - anything that needs json)

All of which are optional and should fail cleanly if python isn't installed.

What I am proposing is that we stop explicitly checking and supporting python 2, and we start recommending python 3 (we already use it over 2 if available), after 3.1 is released. Nothing too rash, if an issue pops up we can still fix it, and if it's just cosmetics we should still prefer allowing python 2 to work.

Or we could take a more extreme stance and improve our code actively with things that don't work in py2, or only do that for some things.

@faho faho added this to the fish 3.2.0 milestone Jan 25, 2020
@faho faho added the RFC label Jan 25, 2020
@zanchey
Copy link
Member

zanchey commented Jan 26, 2020

To inform the decision, on our current platforms that I would consider "tier 1":

Other platforms are fine on cursory inspection, with a general minimum of Python 3.5 available.

@geoff-nixon
Copy link
Contributor

macOS does not ship with Python 3 anywhere, as far as I can tell - and it sounds like all Python versions will go in the future

The OS proper may not, but Xcode 11 ships with a full Python 3.7 at /Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework.

@floam
Copy link
Member

floam commented Jan 31, 2020

Yes - with Xcode you get python3 now on macOS.

@geoff-nixon
Copy link
Contributor

Yes - with Xcode you get python3 now on macOS.

Yes, and double-checking now, it's included in the "Command Line Tools" package as well: there's even python3 (etc.) shims at /usr/bin/python3 which call xcrun. So if a user doesn't have Xcode or the CLI tools installed, the first time the binary is called, it walks you through a painless download/install. So I'd definitely say macOS is good to go with Python 3.

@mqudsi
Copy link
Contributor

mqudsi commented Feb 2, 2020

We call python in the background at first startup, the xcrun hack is insufficient.

@zanchey
Copy link
Member

zanchey commented Feb 3, 2020

The non-availability of Python in macOS is a problem regardless of whether we proceed to drop Python 2.7 support; I think we can explore that separately. For now, it certainly doesn't sound like there's any direct opposition to focusing on Python 3.

I suggest a minimum target of Python 3.5.

@mqudsi
Copy link
Contributor

mqudsi commented Feb 3, 2020

Can someone more familiar with Python than myself explain the backwards compatibility story there? Do minor increments within the Python 3.x family introduce any language changes or is it just the availability of APIs in the standard library? Or are they merely indicative of completely backwards-compatible improvements, fixes, optimizations, etc. to the runtime?

@faho
Copy link
Member Author

faho commented Feb 3, 2020

Do minor increments within the Python 3.x family introduce any language changes

They can remove deprecated stuff. E.g. there was some hubbub regarding python 3.9 doing that

or is it just the availability of APIs in the standard library?

APIs and syntax. E.g. python 3.6 introduced "f-strings", so you can format strings like

animal='fish'
print(f'My favorite animal is the {animal}')

instead of

animal='fish'
print('My favorite animal is the {animal}'.format(animal = animal))

Running this on older python would trigger a syntax error.

@mqudsi
Copy link
Contributor

mqudsi commented Feb 3, 2020

Thanks for the info!

@faho
Copy link
Member Author

faho commented May 30, 2020

Okay, I'm pretty sure I dropped the last mention of python 2 from the documentation (in a broader sense).

That means the only remnants of python 2 are the completions for python2, which is entirely harmless and non-critical, and the __fish_anypython function.

That would be the step where we drop python 2 support. Our scripts might still be compatible, but running them with py2 would require hacks - making your own __fish_anypython function.

So: All aboard the py3 train?

@zanchey
Copy link
Member

zanchey commented May 31, 2020

I'd leave it. It does not have significant performance impact or particularly complicate the implementation - as I understand it python may be Python 2 or 3 on some platforms, so I think the __fish_anypython function needs to remain for a while anyway.

@faho
Copy link
Member Author

faho commented Sep 4, 2020

Should we add anything to the CHANGELOG here? What do we say?

"Support for python2 has been dropped. It might continue to work but will not be fixed if it breaks. Upgrade to python3"

?

@ridiculousfish
Copy link
Member

Perhaps just "Support for Python2 has been dropped. Python 3.5 or later is required."

@faho faho closed this as completed in 68ab016 Sep 11, 2020
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants