17 ms·

Raising severity to serious for some Python 2 leaf packages with no Python 3

217 points by mkesper 7y ago

sethish 7y ago
Can someone link the list of packages that needed to be ported? I get the impression from this thread that newly ported packages won't be included in the next testing release, but hey, there's always unstable.
- deckar01 7y ago
  Python 2 Removal (All): http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=py2removal;users=debian-python@lists.debian.org http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=py2removal;... No Python 3 Port: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=py3noport;users=debian-python@lists.debian.org https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=py3noport;...
- Denvercoder9 7y ago
  Newly ported packages can absolutely enter testing at this moment.
ahbyb 7y ago
The last thing I expected to see in 'lists.debian.org' was emojis.
- perch56 7y ago
  Do you mean the loupe magnifier? I wouldn’t consider it an emoji.
  - daxelrod 7y ago
    https://emojipedia.org/right-pointing-magnifying-glass/ https://emojipedia.org/right-pointing-magnifying-glass/ is part of Unicode Emoji 1.0 https://unicode.org/Public/emoji/1.0/emoji-data.txt https://unicode.org/Public/emoji/1.0/emoji-data.txt as 1F50E and it's represented on the page not via an image embed, but as a character. Why wouldn't you consider it an emoji?
    - true_religion 7y ago
      It barely shows any emotion to put a magnifier down, maybe?
      - TazeTSchnitzel 7y ago
        The word “emoji” does not come from “emotion”, unlike “emoticon”.
        tuukkah 7y ago
        Had to look it up as a reminder: > Originally meaning pictograph, the word emoji comes from Japanese e (絵, "picture") + moji (文字, "character"); the resemblance to the English words emotion and emoticon is purely coincidental. https://en.wikipedia.org/wiki/Emoji https://en.wikipedia.org/wiki/Emoji
        true_religion 7y ago
        That may very well be true, but wouldn’t really help in explaining why the OP said what they said.
- maxerickson 7y ago
  Have you updated your priors?
ridaj 7y ago
One can sense the frustration dripping from the thread. This feels like pretty aggressive communication ("frankly, I don't care", etc.)... it could've been a misunderstanding about what "removal from testing" means... In particular since the packages remain available in unstable, the argument raised about users paying the price isn't really valid.
- ldng 7y ago
  I think you're overreading it. Wanting to remove python2 dependancy now with the next Debian release as target (probably 2 year from now) seem reasonable to me. The aggressivity you perceive is to me just being firm. Refuse and push back any exceptions. The work has to be done, end of story. Personnally, I approve, otherwise it'll spiral down in nitpicking and special cases. Would not be the first time with Debian.
  - marcosdumay 7y ago
    There's this part: > If the package has still many users (popcon >= 300), or is needed to build another package which cannot be removed, document that by adding the "py2keep" user tag So they are not even that firm. Overall, it seems very well handled.
    - stOneskull 7y ago
      I am impressed by the leadership. It needs to happen and it needs a firm leadership like this. No dilly-dallying. On with the job.
  - ridaj 7y ago
    I agree it's the right call, my remark is only about the communication style (e.g. "frankly, I don't care") and how it comes off to an outsider to the community.
- nwmcsween 7y ago
  There honestly should be zero frustration, a lot of this is ran by people volunteering time.
strenholme 7y ago
I have seen multiple people post to Ycombinator claiming that porting to Python3 is always trivial and easily done. And, yeah, sure, for a 380-line script written after Python3 came out, porting the code so it runs the same both in Python2 and Python3 is trivial. However, for an over 6000-line script written in the mid-2000s, before Python3 even existed, porting to Python3 is non trivial. Trust me, I tried. First, the syntax sugar stuff was easy enough to fix: Do a simple search and replace so that all cases of stuff like print "foo" Become print("foo") I had to do something similar with the way this script calls raise(). Not to mention adding a hack so Python2 uses “xrange” while Python3 uses “range”. After doing all of this, the code still does not run in Python3. As far as I can tell, the issue is that Python3 does implicit float-to-int conversions differently than Python2; the code will not raise an error in Python3, but it will silently run differently, until the state is different enough that the Python3 version raises an error while the Python2 version works as expected. At this point, I just threw my hands in the air and gave up. For reference, the offending code is here: https://github.com/samboy/misc-civ4-mapscripts/blob/master/TotestraRG32.py https://github.com/samboy/misc-civ4-mapscripts/blob/master/T...
- raverbashing 7y ago
  Well, yes, porting large projects to Py3 is not trivial. That's why they had, what, around 5 years to do it since the 2.7 EOL was extended to 2020? I think most of the problems you encountered would be solved by the six library, btw. But the most annoying bugs were those were some Python 2 quirk was "just working" (like comparing strings to integers in Python 2) or the conversion of ints and floats and then it correctly broke on Python 3.
  - strenholme 7y ago
    Using the six library is one way to make a large project being written from the ground up run in both Python2 and Python3. For this particular project, I would had needed to get the code to run in both Python3 and an ancient version of Python2 made back when boost.python was still a thing, so six would be out of the question.
- 7y ago
dooglius 7y ago
Why is Debian removing support for Python 2 at all? It's not like there are new releases they need to test against or updates they need to merge.
- Denvercoder9 7y ago
  Python 2 is obsolete. It won't have upstream support anymore when bullseye is released, which means that Debian has to do all the maintenance by themselves. Even if there are no updates, that still means fixing security vulnerabilities and keeping it compatible with changes in the environment (i.e. new packaging policy, new compilers, new hardening features, etc.). There's nothing to gain but work by keeping it.
- rlpb 7y ago
  Python 2 will not be maintained upstream beyond January 2020[1]. Therefore Debian will not include Python 2 in its next release since Python 2 will be already be EOL on the day of that next Debian release. Otherwise, who will fix the Debian Python packages when the next CVE comes out? [1] https://www.python.org/dev/peps/pep-0373/ https://www.python.org/dev/peps/pep-0373/
  - 0xADEADBEE 7y ago
    This isn't strictly true. The final cPython release (2.7.18) is slated for April next year [0], and PyPy has no such plans to drop support [1]. I don't honestly think Python 2 is going anywhere for a while yet (judging from some of the commercial codebases I've seen at least). I sometimes wonder if this mess would have dragged on quite so long if there'd been better features in Python 3. [0] - https://www.python.org/dev/peps/pep-0373/#maintenance-releases https://www.python.org/dev/peps/pep-0373/#maintenance-releas... [1] - https://doc.pypy.org/en/latest/faq.html#how-long-will-pypy-support-python2 https://doc.pypy.org/en/latest/faq.html#how-long-will-pypy-s...
    - rlpb 7y ago
      > The final cPython release (2.7.18) is slated for April next year [0]... Fair enough, but there is still no commitment from upstream for most of the supported release of the next Debian release, so that is moot. > ...PyPy has no such plans to drop support This isn't relevant to the CPython package dependencies which are the issue at matter for Debian on this matter. They haven't explicitly said CPython because it's implicit the way that Debian's Python packaging is structured.
mjw1007 7y ago
Historically, Debian hasn't particularly objected to packaging obsolete versions of programming languages without upstream support. I doubt anyone is checking for potential security problems in the Algol 68 and Fortran 77 implementations that Debian ships, and I don't think the people using those packages are particularly inconvenienced by that. It seems a shame that the social pressure to persuade people to port their code to Python 3 means that Debian is going to have weaker support for 10-year-old Python than 40-year-old Fortran. In particular, there are ongoing efforts to try to make it the normal thing for scientists to make the programs they ran on their data available so that their results can be reproduced; aggressively dropping older programming language implementations rather gets in the way of that.
- cptskippy 7y ago
  The implementations of Algol and Fortran for Debian are maintained.
- Certhas 7y ago
  Nothing about this is aggressive. And having maintained compilers for ancient languages is really really different from having an unmaintained, obsolete runtime/interpreter/ecosystem. And nothing is stopping you from installing Python 2. All scientists I know rely on anaconda to manage their Python environment, and couldn't care less what the system python does. I really _don't_ want to rely on system python for reproducing my old results.
  - semi-extrinsic 7y ago
    On the flipside: how useful is your code really if it's not reproducible with a modern Python version? From 3.3 to 3.8, there should be perfect backwards compatibility? For packages, I can understand it, sure. So include a requirements.txt, and just spin up a 3.8 virtualenv to reproduce, no?
    - samus 7y ago
      Backwards compatibility is there, but minor changes and patches might mean different things for certain users. One can never be sure without sifting throug changelogs and maintaining test suites. And that is for stuff you know you are looking for.
breatheoften 7y ago
How did a project like Babel not evolve to compile python2 into (horrific code) that runs with python2 compatible semantics on the python3 runtime ...? Is that not possible for some reason?
- _bxg1 7y ago
  There's this: https://docs.python.org/2/library/2to3.html https://docs.python.org/2/library/2to3.html But the thing with Babel is that it only adds features to JavaScript, it doesn't translate between two disjoint languages. I'd assume that has an effect on its viability as a project.
  - nickm12 7y ago
    2to3 is such a small part of the solution. It only takes care of basic stuff, but to really get things right you need to know the types.
- alangpierce 7y ago
  Python 2 and 3 are not compatible via syntax translation in the same way that many new JS features can be transpiled to old JS. In Python 3, strings work differently in subtle ways that force you to be more careful, and a source code translator doesn't have any reasonable way to know whether a variable is a string anyway. You also see this sort of thing in JS: Babel never tried to implement Proxy because it really needs runtime support and can't be implemented by syntax translation.
- chubot 7y ago
  It’s not possible in general because you can only do a syntactic translation of python. To preserve the meaning of the program you would have to statically know something about the data types used. This is one reason why Dropbox, Facebook, and google have developed their own python type checkers.
doubleunplussed 7y ago
I'm running Calibre on Python 3 (via an Arch package provided by one of the people working on the port). It and mercurial/tortoisehg and the only remaining reasons Python 2 is on my system. All of these things will be on Python 3 soon enough. Why doesn't Debian just ship the unreleased Python 3 port of Calibre? It's not like Debian restricts themselves to only formal upstream releases, they have never hesitated to backport patches to unreleased versions. If lacking Python 3 support is such a massive bug, wouldn't using patches that have not been officially released, that fix the bug, be acceptable? Debian testing isn't Debian stable, there is not a reasonable expectation that the code shipped is perfect. Mercurial also works on Python 3, though it's only a beta. I could understand not shipping it because version control bugs can be serious, but hey, someone's gotta test the beta. I've used it and it not encountered any bugs, but went back to py2 because tortoisehg won't work with Python 3 mercurial yet (and then bitbucket dropped mercurial support so now I'm moving everything to git, grumble grumble, probably will sadly stop using mercurial altogether within the next year).
- Mathnerd314 7y ago
  I think you mean this package? https://aur.archlinux.org/packages/calibre-python3-git/ https://aur.archlinux.org/packages/calibre-python3-git/ Judging from https://bugs.launchpad.net/calibre/+bug/1714107/comments/11 https://bugs.launchpad.net/calibre/+bug/1714107/comments/11 the Arch maintainer doesn't think highly of Debian as it has been buggy in the past. OTOH he's biased because he's on Arch. Here's a recent post from the Debian maintainer: https://www.preining.info/blog/2019/10/state-of-calibre-in-debian/ https://www.preining.info/blog/2019/10/state-of-calibre-in-d.... The tl;dr is that most/all of the work is done but he's holding off updating unstable to Python 3 because he doesn't want to break external plugins. He also mentions that he can't update to 4.0 or higher because Debian still hasn't updated Qt to 5.12. That seems slightly inaccurate as it's in experimental (https://packages.debian.org/experimental/qt5-default); https://packages.debian.org/experimental/qt5-default); I think the maintainer could do an upload of a Calibre 4.x using Qt 5.12 & Python 3 to experimental. But experimental is not in common use regardless. The post seems to be an extension of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936270#87 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936270#87
- 7y ago
jancsika 7y ago
Javascript: Hey you kids: quit doing cartwheels on the heads of 20 friends who are also all doing cartwheels twenty levels deep. No cartwheels more than 3 levels deep or someone's going to get hurt! You've been told over and over now. Python: Hey you kids: sit in this cubicle for the entire summer and do 20,000 long division problems just to keep the school's lights on. And don't get too encouraged because there's no way in hell we can finish all the long division before the beginning of the school year. Some of your classrooms will be dark. p.s. our principal got burned out and quit.
- 333c 7y ago
  Can you explain the JavaScript comment? I don't follow that world.
  - sciurus 7y ago
    https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/
    - onei 7y ago
      I never actually read the whole story behind this. To me, it looks like the original author of leftpad was in the right - radically changing a package can break someone's build. Maybe he went a bit too far with his next action, but if NPM don't care about its end-users enough to ensure packages remain relatively stable (within the limited control they have), why should an individual contributor?
philshem 7y ago
This is turning out to be the py2k bug
Congeec 7y ago
> No special pleading. No whining. No excuses. > No buts and no exceptions. No "middle ground". This sounds strong to me. Not to be provocative since I am not familiar with the mailing list, I would like to ask is it common to communicate this way in this Debian community? Is it effective to push things moving forward?
- _se 7y ago
  I think it's perfectly reasonable. Package maintainers are stomping their feet and huffing about making a change that is in everyone's best interest. Why shouldn't the distribution set strong guidelines and enforce them? Too much is often sacrificed at the altar of backward compatibility. Move forward and leave the laggards behind.
- abawany 7y ago
  I will never forget how Debian hijacked the real ffmpeg with their hobbled version until some point later [1]. Pretty disgusting. While I unfortunately use this distro fairly solely, I will move to other options at some point. Debian may be free but often it proves to be too expensive. Edit: reference. [1] https://stackoverflow.com/questions/9477115/what-are-the-differences-and-similarities-between-ffmpeg-libav-and-avconv https://stackoverflow.com/questions/9477115/what-are-the-dif...
sprash 7y ago
Has anybody interest in forking the python project and continuing to maintain 2.7 until forever? And by "maintain" I mean no new features, just bug fixes and performance improvements. Maybe if we find enough volunteers we can pull that off. There is still much useful and valuable legacy software out there that many people use which is getting abandoned for no other reason than some people (like the authors of calibre) are not very fond of the direction python is going. Others can't upgrade to 3.x because you have standard libraries especially in the academic sector that people literally put their whole phd into and that can not "easly" be upgraded just like that because of high complexity, lack of staff and time.
- carapace 7y ago
  I plan to do exactly that. It's vaporware at the moment, but uh: https://git.sr.ht/~sforman/Bladders https://git.sr.ht/~sforman/Bladders > Maintenance-mode fork of the officially-deprecated Python 2 interpreter and standard library. Bugs fixed, security holes patched, and maybe some performance improvements, but no changes to the syntax or semantics (for that see the Tauthon project, unaffiliated.) - - - Sometime between now and the end of the year I'm going to fork Py2 and set up build jobs to run the test suites. (Maybe later today, it's not hard, it just takes a few spare hours.) Going forward I plan to work on things like improvements to the docs, curating additional packages and libraries (additional to the standard lib), and language tooling (I'd like to keep things like Nuitka, Snakefood, etc. working.) I also want to run fuzzers and other code quality tools over it all.
  - sundarurfriend 7y ago
    Before it's too late, I'd like to humbly suggest a name change. Even as a Blackadder fan, the name sounds terrible at a glance, especially for such a (potentially) high profile project. Naming isn't everything, of course, but it has more significance than we consciously realize. It can subconsciously impact decisions in favour of or against the project, as irrational as that is.
    - carapace 7y ago
ridiculous_fish 7y ago
gclient (necessary for building chromium, among other things) got an "early version" working with Python3 just a few weeks ago. Apparently this stuff is still being ported. https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/Azd9hNkav6c https://groups.google.com/a/chromium.org/forum/#!topic/chrom...
olliej 7y ago
This is why I continue to think that Python 3 being needlessly backwards incompatible was one of the dumber things to happen. Think of the lost productivity that has resulted. People complain about JS all the time, but JS hasn’t broken existing code and has improved. JS supports ‘let’ declarations and variables named ‘let’, python could have improved without breaking everything.

217 points by mkesper 7y ago

Can someone link the list of packages that needed to be ported? I get the impression from this thread that newly ported packages won't be included in the next testing release, but hey, there's always unstable.

deckar01 7y ago
Python 2 Removal (All): http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=py2removal;users=debian-python@lists.debian.org http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=py2removal;... No Python 3 Port: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=py3noport;users=debian-python@lists.debian.org https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=py3noport;...
Denvercoder9 7y ago
Newly ported packages can absolutely enter testing at this moment.

ahbyb 7y ago

The last thing I expected to see in 'lists.debian.org' was emojis.

perch56 7y ago
Do you mean the loupe magnifier? I wouldn’t consider it an emoji.
- daxelrod 7y ago
  https://emojipedia.org/right-pointing-magnifying-glass/ https://emojipedia.org/right-pointing-magnifying-glass/ is part of Unicode Emoji 1.0 https://unicode.org/Public/emoji/1.0/emoji-data.txt https://unicode.org/Public/emoji/1.0/emoji-data.txt as 1F50E and it's represented on the page not via an image embed, but as a character. Why wouldn't you consider it an emoji?
  - true_religion 7y ago
    It barely shows any emotion to put a magnifier down, maybe?
    - TazeTSchnitzel 7y ago
      The word “emoji” does not come from “emotion”, unlike “emoticon”.
      - tuukkah 7y ago
        Had to look it up as a reminder: > Originally meaning pictograph, the word emoji comes from Japanese e (絵, "picture") + moji (文字, "character"); the resemblance to the English words emotion and emoticon is purely coincidental. https://en.wikipedia.org/wiki/Emoji https://en.wikipedia.org/wiki/Emoji
      - true_religion 7y ago
        That may very well be true, but wouldn’t really help in explaining why the OP said what they said.
maxerickson 7y ago
Have you updated your priors?

ridaj 7y ago

One can sense the frustration dripping from the thread. This feels like pretty aggressive communication ("frankly, I don't care", etc.)... it could've been a misunderstanding about what "removal from testing" means... In particular since the packages remain available in unstable, the argument raised about users paying the price isn't really valid.

ldng 7y ago
I think you're overreading it. Wanting to remove python2 dependancy now with the next Debian release as target (probably 2 year from now) seem reasonable to me. The aggressivity you perceive is to me just being firm. Refuse and push back any exceptions. The work has to be done, end of story. Personnally, I approve, otherwise it'll spiral down in nitpicking and special cases. Would not be the first time with Debian.
- marcosdumay 7y ago
  There's this part: > If the package has still many users (popcon >= 300), or is needed to build another package which cannot be removed, document that by adding the "py2keep" user tag So they are not even that firm. Overall, it seems very well handled.
  - stOneskull 7y ago
    I am impressed by the leadership. It needs to happen and it needs a firm leadership like this. No dilly-dallying. On with the job.
- ridaj 7y ago
  I agree it's the right call, my remark is only about the communication style (e.g. "frankly, I don't care") and how it comes off to an outsider to the community.
nwmcsween 7y ago
There honestly should be zero frustration, a lot of this is ran by people volunteering time.

strenholme 7y ago

I have seen multiple people post to Ycombinator claiming that porting to Python3 is always trivial and easily done. And, yeah, sure, for a 380-line script written after Python3 came out, porting the code so it runs the same both in Python2 and Python3 is trivial. However, for an over 6000-line script written in the mid-2000s, before Python3 even existed, porting to Python3 is non trivial. Trust me, I tried. First, the syntax sugar stuff was easy enough to fix: Do a simple search and replace so that all cases of stuff like print "foo" Become print("foo") I had to do something similar with the way this script calls raise(). Not to mention adding a hack so Python2 uses “xrange” while Python3 uses “range”. After doing all of this, the code still does not run in Python3. As far as I can tell, the issue is that Python3 does implicit float-to-int conversions differently than Python2; the code will not raise an error in Python3, but it will silently run differently, until the state is different enough that the Python3 version raises an error while the Python2 version works as expected. At this point, I just threw my hands in the air and gave up. For reference, the offending code is here: https://github.com/samboy/misc-civ4-mapscripts/blob/master/TotestraRG32.py https://github.com/samboy/misc-civ4-mapscripts/blob/master/T...

raverbashing 7y ago
Well, yes, porting large projects to Py3 is not trivial. That's why they had, what, around 5 years to do it since the 2.7 EOL was extended to 2020? I think most of the problems you encountered would be solved by the six library, btw. But the most annoying bugs were those were some Python 2 quirk was "just working" (like comparing strings to integers in Python 2) or the conversion of ints and floats and then it correctly broke on Python 3.
- strenholme 7y ago
  Using the six library is one way to make a large project being written from the ground up run in both Python2 and Python3. For this particular project, I would had needed to get the code to run in both Python3 and an ancient version of Python2 made back when boost.python was still a thing, so six would be out of the question.
7y ago

dooglius 7y ago

Why is Debian removing support for Python 2 at all? It's not like there are new releases they need to test against or updates they need to merge.

Denvercoder9 7y ago
Python 2 is obsolete. It won't have upstream support anymore when bullseye is released, which means that Debian has to do all the maintenance by themselves. Even if there are no updates, that still means fixing security vulnerabilities and keeping it compatible with changes in the environment (i.e. new packaging policy, new compilers, new hardening features, etc.). There's nothing to gain but work by keeping it.
rlpb 7y ago
Python 2 will not be maintained upstream beyond January 2020[1]. Therefore Debian will not include Python 2 in its next release since Python 2 will be already be EOL on the day of that next Debian release. Otherwise, who will fix the Debian Python packages when the next CVE comes out? [1] https://www.python.org/dev/peps/pep-0373/ https://www.python.org/dev/peps/pep-0373/
- 0xADEADBEE 7y ago
  This isn't strictly true. The final cPython release (2.7.18) is slated for April next year [0], and PyPy has no such plans to drop support [1]. I don't honestly think Python 2 is going anywhere for a while yet (judging from some of the commercial codebases I've seen at least). I sometimes wonder if this mess would have dragged on quite so long if there'd been better features in Python 3. [0] - https://www.python.org/dev/peps/pep-0373/#maintenance-releases https://www.python.org/dev/peps/pep-0373/#maintenance-releas... [1] - https://doc.pypy.org/en/latest/faq.html#how-long-will-pypy-support-python2 https://doc.pypy.org/en/latest/faq.html#how-long-will-pypy-s...
  - rlpb 7y ago
    > The final cPython release (2.7.18) is slated for April next year [0]... Fair enough, but there is still no commitment from upstream for most of the supported release of the next Debian release, so that is moot. > ...PyPy has no such plans to drop support This isn't relevant to the CPython package dependencies which are the issue at matter for Debian on this matter. They haven't explicitly said CPython because it's implicit the way that Debian's Python packaging is structured.

mjw1007 7y ago

Historically, Debian hasn't particularly objected to packaging obsolete versions of programming languages without upstream support. I doubt anyone is checking for potential security problems in the Algol 68 and Fortran 77 implementations that Debian ships, and I don't think the people using those packages are particularly inconvenienced by that. It seems a shame that the social pressure to persuade people to port their code to Python 3 means that Debian is going to have weaker support for 10-year-old Python than 40-year-old Fortran. In particular, there are ongoing efforts to try to make it the normal thing for scientists to make the programs they ran on their data available so that their results can be reproduced; aggressively dropping older programming language implementations rather gets in the way of that.

cptskippy 7y ago
The implementations of Algol and Fortran for Debian are maintained.
Certhas 7y ago
Nothing about this is aggressive. And having maintained compilers for ancient languages is really really different from having an unmaintained, obsolete runtime/interpreter/ecosystem. And nothing is stopping you from installing Python 2. All scientists I know rely on anaconda to manage their Python environment, and couldn't care less what the system python does. I really _don't_ want to rely on system python for reproducing my old results.
- semi-extrinsic 7y ago
  On the flipside: how useful is your code really if it's not reproducible with a modern Python version? From 3.3 to 3.8, there should be perfect backwards compatibility? For packages, I can understand it, sure. So include a requirements.txt, and just spin up a 3.8 virtualenv to reproduce, no?
  - samus 7y ago
    Backwards compatibility is there, but minor changes and patches might mean different things for certain users. One can never be sure without sifting throug changelogs and maintaining test suites. And that is for stuff you know you are looking for.

breatheoften 7y ago

How did a project like Babel not evolve to compile python2 into (horrific code) that runs with python2 compatible semantics on the python3 runtime ...? Is that not possible for some reason?

_bxg1 7y ago
There's this: https://docs.python.org/2/library/2to3.html https://docs.python.org/2/library/2to3.html But the thing with Babel is that it only adds features to JavaScript, it doesn't translate between two disjoint languages. I'd assume that has an effect on its viability as a project.
- nickm12 7y ago
  2to3 is such a small part of the solution. It only takes care of basic stuff, but to really get things right you need to know the types.
alangpierce 7y ago
Python 2 and 3 are not compatible via syntax translation in the same way that many new JS features can be transpiled to old JS. In Python 3, strings work differently in subtle ways that force you to be more careful, and a source code translator doesn't have any reasonable way to know whether a variable is a string anyway. You also see this sort of thing in JS: Babel never tried to implement Proxy because it really needs runtime support and can't be implemented by syntax translation.
chubot 7y ago
It’s not possible in general because you can only do a syntactic translation of python. To preserve the meaning of the program you would have to statically know something about the data types used. This is one reason why Dropbox, Facebook, and google have developed their own python type checkers.

doubleunplussed 7y ago

I'm running Calibre on Python 3 (via an Arch package provided by one of the people working on the port). It and mercurial/tortoisehg and the only remaining reasons Python 2 is on my system. All of these things will be on Python 3 soon enough. Why doesn't Debian just ship the unreleased Python 3 port of Calibre? It's not like Debian restricts themselves to only formal upstream releases, they have never hesitated to backport patches to unreleased versions. If lacking Python 3 support is such a massive bug, wouldn't using patches that have not been officially released, that fix the bug, be acceptable? Debian testing isn't Debian stable, there is not a reasonable expectation that the code shipped is perfect. Mercurial also works on Python 3, though it's only a beta. I could understand not shipping it because version control bugs can be serious, but hey, someone's gotta test the beta. I've used it and it not encountered any bugs, but went back to py2 because tortoisehg won't work with Python 3 mercurial yet (and then bitbucket dropped mercurial support so now I'm moving everything to git, grumble grumble, probably will sadly stop using mercurial altogether within the next year).

Mathnerd314 7y ago
I think you mean this package? https://aur.archlinux.org/packages/calibre-python3-git/ https://aur.archlinux.org/packages/calibre-python3-git/ Judging from https://bugs.launchpad.net/calibre/+bug/1714107/comments/11 https://bugs.launchpad.net/calibre/+bug/1714107/comments/11 the Arch maintainer doesn't think highly of Debian as it has been buggy in the past. OTOH he's biased because he's on Arch. Here's a recent post from the Debian maintainer: https://www.preining.info/blog/2019/10/state-of-calibre-in-debian/ https://www.preining.info/blog/2019/10/state-of-calibre-in-d.... The tl;dr is that most/all of the work is done but he's holding off updating unstable to Python 3 because he doesn't want to break external plugins. He also mentions that he can't update to 4.0 or higher because Debian still hasn't updated Qt to 5.12. That seems slightly inaccurate as it's in experimental (https://packages.debian.org/experimental/qt5-default); https://packages.debian.org/experimental/qt5-default); I think the maintainer could do an upload of a Calibre 4.x using Qt 5.12 & Python 3 to experimental. But experimental is not in common use regardless. The post seems to be an extension of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936270#87 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936270#87
7y ago

jancsika 7y ago

Javascript: Hey you kids: quit doing cartwheels on the heads of 20 friends who are also all doing cartwheels twenty levels deep. No cartwheels more than 3 levels deep or someone's going to get hurt! You've been told over and over now. Python: Hey you kids: sit in this cubicle for the entire summer and do 20,000 long division problems just to keep the school's lights on. And don't get too encouraged because there's no way in hell we can finish all the long division before the beginning of the school year. Some of your classrooms will be dark. p.s. our principal got burned out and quit.

333c 7y ago
Can you explain the JavaScript comment? I don't follow that world.
- sciurus 7y ago
  https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/
  - onei 7y ago
    I never actually read the whole story behind this. To me, it looks like the original author of leftpad was in the right - radically changing a package can break someone's build. Maybe he went a bit too far with his next action, but if NPM don't care about its end-users enough to ensure packages remain relatively stable (within the limited control they have), why should an individual contributor?

philshem 7y ago

This is turning out to be the py2k bug

Congeec 7y ago

> No special pleading. No whining. No excuses. > No buts and no exceptions. No "middle ground". This sounds strong to me. Not to be provocative since I am not familiar with the mailing list, I would like to ask is it common to communicate this way in this Debian community? Is it effective to push things moving forward?

_se 7y ago
I think it's perfectly reasonable. Package maintainers are stomping their feet and huffing about making a change that is in everyone's best interest. Why shouldn't the distribution set strong guidelines and enforce them? Too much is often sacrificed at the altar of backward compatibility. Move forward and leave the laggards behind.
abawany 7y ago
I will never forget how Debian hijacked the real ffmpeg with their hobbled version until some point later [1]. Pretty disgusting. While I unfortunately use this distro fairly solely, I will move to other options at some point. Debian may be free but often it proves to be too expensive. Edit: reference. [1] https://stackoverflow.com/questions/9477115/what-are-the-differences-and-similarities-between-ffmpeg-libav-and-avconv https://stackoverflow.com/questions/9477115/what-are-the-dif...

sprash 7y ago

Has anybody interest in forking the python project and continuing to maintain 2.7 until forever? And by "maintain" I mean no new features, just bug fixes and performance improvements. Maybe if we find enough volunteers we can pull that off. There is still much useful and valuable legacy software out there that many people use which is getting abandoned for no other reason than some people (like the authors of calibre) are not very fond of the direction python is going. Others can't upgrade to 3.x because you have standard libraries especially in the academic sector that people literally put their whole phd into and that can not "easly" be upgraded just like that because of high complexity, lack of staff and time.

carapace 7y ago
I plan to do exactly that. It's vaporware at the moment, but uh: https://git.sr.ht/~sforman/Bladders https://git.sr.ht/~sforman/Bladders > Maintenance-mode fork of the officially-deprecated Python 2 interpreter and standard library. Bugs fixed, security holes patched, and maybe some performance improvements, but no changes to the syntax or semantics (for that see the Tauthon project, unaffiliated.) - - - Sometime between now and the end of the year I'm going to fork Py2 and set up build jobs to run the test suites. (Maybe later today, it's not hard, it just takes a few spare hours.) Going forward I plan to work on things like improvements to the docs, curating additional packages and libraries (additional to the standard lib), and language tooling (I'd like to keep things like Nuitka, Snakefood, etc. working.) I also want to run fuzzers and other code quality tools over it all.
- sundarurfriend 7y ago
  Before it's too late, I'd like to humbly suggest a name change. Even as a Blackadder fan, the name sounds terrible at a glance, especially for such a (potentially) high profile project. Naming isn't everything, of course, but it has more significance than we consciously realize. It can subconsciously impact decisions in favour of or against the project, as irrational as that is.
  - carapace 7y ago

ridiculous_fish 7y ago

gclient (necessary for building chromium, among other things) got an "early version" working with Python3 just a few weeks ago. Apparently this stuff is still being ported. https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/Azd9hNkav6c https://groups.google.com/a/chromium.org/forum/#!topic/chrom...

olliej 7y ago

This is why I continue to think that Python 3 being needlessly backwards incompatible was one of the dumber things to happen. Think of the lost productivity that has resulted. People complain about JS all the time, but JS hasn’t broken existing code and has improved. JS supports ‘let’ declarations and variables named ‘let’, python could have improved without breaking everything.