3 ms·

Sorry, no more breaking changes after 2->3.

by eternauta3k 6y ago

smcl 6y ago
Breaking changes will inevitably be necessary in any language. Take the recent-ish discussions about cleaning out the deadweight from the Python stdlib, there's a bunch of modules that are basically unused by users, untouched by maintainers and are therefore effectively deprecated. Taking a "no more breaking changes" philosophy means continuing to semi-support these into eternity, when realistically many can be cast off with a reasonable notice period and a well-documented migration path.
- selectnull 6y ago
  I think we should not think in absolutes! There are breaking changes that are small and acceptable, and there are those that will require unnecessary changes to source code to port them to new version. I don't think python community has yet recovered from 2to3; and I'm not saying it shouldn't have been done; I'm saying I wouldn't like a repeat in 3to4. As for stdlib, if I'm not mistaken, those packages will be published as standalone packages and simple `pip install` will be a migration path.
  - smcl 6y ago
    We are in complete agreement. However, while I’m undecided on “all strings should be f-strings” I do know that “no more breaking changes” is not realistic and is a good way to ensure either a dead language or one with a hell of a lot of baggage
    - selectnull 6y ago
      Personally, I'm against "all strings should be f-strings" just because it would cause changes to source code that I don't find necessary. When Python 3.0 came out, u"" prefix was abolished and every u-string had to be changed. That change was found later to be a mistake and was reverted (I'm not sure what python version reverted it, somewhere around 3.3 I think). This proposal reminds me of that: change that seemingly sound good at first, but is simply not worth it. Yes, there will be breaking changes and I'm not against them. I'm just against this one.

3 ms·

Sorry, no more breaking changes after 2->3.

by eternauta3k 6y ago

Sorry, no more breaking changes after 2->3.

smcl 6y ago
Breaking changes will inevitably be necessary in any language. Take the recent-ish discussions about cleaning out the deadweight from the Python stdlib, there's a bunch of modules that are basically unused by users, untouched by maintainers and are therefore effectively deprecated. Taking a "no more breaking changes" philosophy means continuing to semi-support these into eternity, when realistically many can be cast off with a reasonable notice period and a well-documented migration path.
- selectnull 6y ago
  I think we should not think in absolutes! There are breaking changes that are small and acceptable, and there are those that will require unnecessary changes to source code to port them to new version. I don't think python community has yet recovered from 2to3; and I'm not saying it shouldn't have been done; I'm saying I wouldn't like a repeat in 3to4. As for stdlib, if I'm not mistaken, those packages will be published as standalone packages and simple `pip install` will be a migration path.
  - smcl 6y ago
    We are in complete agreement. However, while I’m undecided on “all strings should be f-strings” I do know that “no more breaking changes” is not realistic and is a good way to ensure either a dead language or one with a hell of a lot of baggage
    - selectnull 6y ago
      Personally, I'm against "all strings should be f-strings" just because it would cause changes to source code that I don't find necessary. When Python 3.0 came out, u"" prefix was abolished and every u-string had to be changed. That change was found later to be a mistake and was reverted (I'm not sure what python version reverted it, somewhere around 3.3 I think). This proposal reminds me of that: change that seemingly sound good at first, but is simply not worth it. Yes, there will be breaking changes and I'm not against them. I'm just against this one.