On 10Mar2014 14:55, Victor Stinner <victor.stin...@gmail.com> wrote: > Last 5 years, I spend significant time to port a lot of Python 2 code > on Python 3. [... troubles ...] > So can we please try to stop scheduling another major Python version > breaking almost all modules and all applications just to be pendantic? > No, we should not remove any old feature in Python 4. Python 4 should > be just a minor release following the previous 3.x release.
Maybe that will be the case, when it rolls around in the ordinary sequence of things. Assuming nothing groundbreaks shows up. > I don't want another six, nine or whatever module to fill the gap > between Python 3 and Python 4. But this I do not understand. If 4.0 is in your vision to be a regular release, why should you care that it may be years off? > For example, I propose to release the next major Python version (3.5) > with the version 4.0 but without removing anything. (It's just an > example, it can wait another release.) Just in case this is not a joke or hyperbole: I am -1 on this. Just stick with the expected numbering scheme. If there are no incompatible but desired changes queued up by the time 4.0, perhaps that will be a normal release also. If not, perhaps it will be a good time to bite the bullet. > I mean that any incompatible > change must following the classic transition plan: tag the feature as > deprecated and wait at least one major version before dropping it, or > just keep it forever. We can expect that just changing the major > version (3 => 4) will already break enough applications (where > "python3" or "version == 3" is hardcoded")... I tend to spell this >= 3, etc. Maybe I'm being simplistic. > Instead of asking application developers to try to follow each major > Python release, we should try to keep the maintaince pain in Python > core. > > What do you think? I agree there shouldn't be a major porting pain release just for the sake of a number change; anything like that should need justification. But conversely, I'm dead against bringing forward version 4.0 just to break the expectation of breakage. Cheers, -- Cameron Simpson <c...@zip.com.au> The nice thing about standards is that you have so many to choose from; furthermore, if you do not like any of them, you can just wait for next year's model. - Andrew S. Tanenbaum _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com