Good morning python-dev, PEP 291 (Backward Compatibility for Standard Library) does not seem to take Python 3 into account. Is this PEP only relevant for the 2.7 branch?* If it’s supposed to apply to 3.x too, despite the view that 3.0 was a clean break, what does it mean to have a module that is developed in the py3k branch and should retain compatibility with 2.3 or 1.5.2? * Tarek’s interpretation: “The 2.x needs to stay 2.3 compatible so we should keep the 3.x as similar as possible for bugfixes.” In the particular case of distutils (should be compatible with 2.3), we (including I) have been lax. Our tests for example use modern unittest features like skips, which makes them not runnable on old Pythons. I am very uncomfortable with code that seems to run fine but which tests (however few) cannot be run, so I think I’ll have to trade the skips for old-style “return” statements. The other way of solving that is to change the compat policy. If I remember correctly, the rationale for code compat in distutils is that people may copy distutils from Python x.y to their install of x.y-n; I don’t know if this is still an active practice, and if it is, I don’t know if it should be supported, considering that distutils2 (compatible with 2.4+ and available from PyPI) is coming. Regards
On Tue, Nov 30, 2010 at 7:33 AM, Éric Araujo <merwok@netwok.org> wrote:
Good morning python-dev,
PEP 291 (Backward Compatibility for Standard Library) does not seem to take Python 3 into account. Is this PEP only relevant for the 2.7 branch?* If it’s supposed to apply to 3.x too, despite the view that 3.0 was a clean break, what does it mean to have a module that is developed in the py3k branch and should retain compatibility with 2.3 or 1.5.2?
* Tarek’s interpretation: “The 2.x needs to stay 2.3 compatible so we should keep the 3.x as similar as possible for bugfixes.”
In the particular case of distutils (should be compatible with 2.3), we (including I) have been lax. Our tests for example use modern unittest features like skips, which makes them not runnable on old Pythons. I am very uncomfortable with code that seems to run fine but which tests (however few) cannot be run, so I think I’ll have to trade the skips for old-style “return” statements.
You shouldn't be uncomfortable with the current state of distutils and try to improve its tests (or improve any other nasty stuff you'll find in that code) Distutils is dead code. All we have to do is the bare minimum maintenance. Everything else is a waste of time.
The other way of solving that is to change the compat policy. If I remember correctly, the rationale for code compat in distutils is that people may copy distutils from Python x.y to their install of x.y-n; I don’t know if this is still an active practice, and if it is, I don’t know if it should be supported, considering that distutils2 (compatible with 2.4+ and available from PyPI) is coming.
Again, don't worry about these rules in Distutils now. The only rule that now apply to Distutils is that we do only bug fixing, and we should not waste our precious time to do other stuff in there. Plain python tests are fine for what we want to do and simplify our forward ports and backports. One thing we should do though, is fix those bugs in Distutils2 first when they exist there too. I really appreciate all the hard work your are doing in triaging the issues and bug fixing by the way ! Tarek
On 30/11/2010 06:33, Éric Araujo wrote:
Good morning python-dev,
PEP 291 (Backward Compatibility for Standard Library) does not seem to take Python 3 into account. Is this PEP only relevant for the 2.7 branch?* If it’s supposed to apply to 3.x too, despite the view that 3.0 was a clean break, what does it mean to have a module that is developed in the py3k branch and should retain compatibility with 2.3 or 1.5.2?
PEP 291 is very old and should probably be retired. I don't think anyone is maintaining standard libraries in py3k that are also compatible with Python 2.anything. (At least not in a single codebase.) For Python 2.7 that may not be true, but for Python 3 I think we can start with a clean slate on compatibility.
* Tarek’s interpretation: “The 2.x needs to stay 2.3 compatible so we should keep the 3.x as similar as possible for bugfixes.”
In the particular case of distutils (should be compatible with 2.3), we (including I) have been lax. Our tests for example use modern unittest features like skips, which makes them not runnable on old Pythons. They can be run on old Pythons with unittest2. This is what distutils2 is doing.
I am very uncomfortable with code that seems to run fine but which tests (however few) cannot be run, so I think I’ll have to trade the skips for old-style “return” statements. The other way of solving that is to change the compat policy.
This is only an issue for distutils in Python 2.7 right? Maintaining the compat policy for that will be a short-lived pain, and distutils itself is getting only infrequent bugfixes *anyway*, right? I defer to Tarek on that particular decision. All the best, Michael
If I remember correctly, the rationale for code compat in distutils is that people may copy distutils from Python x.y to their install of x.y-n; I don’t know if this is still an active practice, and if it is, I don’t know if it should be supported, considering that distutils2 (compatible with 2.4+ and available from PyPI) is coming.
Regards
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...
-- http://www.voidspace.org.uk/ READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On Nov 30, 2010, at 01:09 PM, Michael Foord wrote:
PEP 291 is very old and should probably be retired. I don't think anyone is maintaining standard libraries in py3k that are also compatible with Python 2.anything. (At least not in a single codebase.)
I agree. I think we should change the status of PEP 291 to Final, and add a few words to make it clear it applies only to Python 2. Since Neal owns the PEP, he should get first crack at doing the update, but I volunteer to make those changes if he declines (or does not respond). We may eventually need a similar document for Python 3, but it should be a new PEP. -Barry
On Tue, Nov 30, 2010 at 07:35, Barry Warsaw <barry@python.org> wrote:
On Nov 30, 2010, at 01:09 PM, Michael Foord wrote:
PEP 291 is very old and should probably be retired. I don't think anyone is maintaining standard libraries in py3k that are also compatible with Python 2.anything. (At least not in a single codebase.)
I agree.
Same here; I have purposefully ignored compatibility requirements because I always found those promises to be extremely annoying and somewhat painful to enforce.
I think we should change the status of PEP 291 to Final, and add a few words to make it clear it applies only to Python 2. Since Neal owns the PEP, he should get first crack at doing the update, but I volunteer to make those changes if he declines (or does not respond).
I will channel Neal: "I decline and/or do not want to respond". =)
We may eventually need a similar document for Python 3, but it should be a new PEP.
I hope not.
participants (5)
-
Barry Warsaw -
Brett Cannon -
Michael Foord -
Tarek Ziadé -
Éric Araujo