No announcement yet.

Ubuntu 16.04 LTS Will Try To Be Python-3-Only, No Python 2 By Default

  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    yes, I know this PEP and I will make sure Debian will not follow it :P

    /me co-maintains package that provides /usr/bin/python in Debian


    • #12
      Originally posted by chithanh View Post
      Python project makes this clear how they view the issue:
      • If your software requires a certain version of python, your shebang needs to be of the #!/usr/bin/pythonX (or #!/usr/bin/env pythonX) form.
      • Currently, /usr/bin/python should point to python2 in order to ensure backwards compatibility with legacy software that does not yet follow PEP-0394 recommendations, but that is not a hard requirement and not true for all distros/configurations (Arch and Gentoo point to python3 by default)
      • PEP-0394 makes provisions for eventually switching the recommendation for "python" to become "python3"
      • Once that happens, it is likely that the majority of distributions will switch python to mean python3, leaving Debian-based ones as the only ones where this is different.

      PEP-0394 sounds like a disaster from a software engineering standpoint.
      To have a good programming language you need to be able to change the language. Sometimes breaking changes which Python orderly introduced with the major version number.
      Now trying to change where a vague directive will point to a different python version is asking for trouble.
      What about all the software that won't be updated?
      Software should specify which version of python they use and "python" should be left as legacy and considered taken by python2.
      The move forward should be to tell developers you need to specify which version you use, no excuses, no buts, no whinings!

      What is it about software developpers they hate good versioning of software language compatibility?
      Why can't software packages just all specify what python language version they use explicitly?
      Last edited by plonoma; 05 November 2015, 04:22 PM.


      • #13
        On proprietary platforms where abandonware is the norm there is no other way but to keep old versions of libraries/interpreters around for as much as possible.
        Free software instead should be ported to the "new" version (by now almost 7 years old, btw) and be done with the legacy.


        • #14
          Why not consider /usr/bin/python taken by python 1.0? After all, there was a transition between when it meant python 1 and when it meant python 2.

          PEP-0394 just formalizes these kinds of transitions. Adapting old software to the new pythonX convention is trivial and given ample time.


          • #15
            Originally posted by chithanh View Post
            Why not consider /usr/bin/python taken by python 1.0? After all, there was a transition between when it meant python 1 and when it meant python 2.
            Because Python 2 can run most Python 1 code anyway.