A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2009-June/090142.html below:

[Python-Dev] draft pep: backwards compatibility

[Python-Dev] draft pep: backwards compatibilityRaymond Hettinger python at rcn.com
Fri Jun 19 21:06:27 CEST 2009
Not sure why we need yet another pep on the subject.  Just update PEP 5 if needed.

Also, I think there is a certain amount of wishful thinking here.  Ideally, we could approve a tiny PEP with just a few bullet 
points and it would eliminate the need for all of the complicated decision making that we usually go through.  Ideally, we could 
make all decisions in advance of seeing the facts for a given situation.  ISTM, this pep is wishing away the actual complexity of 
making software design decisions.

The policy for 2.x should probably be different than for 3.x.  ISTM that 3.x has not been fully shaken out and that possibly many 
things will need to change as users start to report problems.  The text vs bytes issue is lurking throughout the release.  The JSON 
module in particular was affected by a half thought out port to 3.0.  And yesterday on #python IRC, one developer reported the email 
package in 3.1 to be unusable and one of its maintainers characterized it as being in need of a serious overhaul (meaning major API 
changes).  In the end, there is going to have to be some thoughtful balancing between making the needed changes and not hurting the 
existing users.  I don't think a small, general purpose PEP like this one can wish that away.

Another sticking point about preserving features across releases arises if the feature itself is hazardous in some way (like have a 
security hole or some such).  The contextlib.nested() function was an example.  It didn't ever really work as advertised for its 
intended purpose (it wasn't truly equivalent to two nested with-statements) and it presented users with the possibility of 
hard-to-spot bugs.  The bugfix for it was to replace it with new syntax.  Unfortunately, the new syntax didn't provide all of the 
functionality of the original.  So, the question arises about whether this particular mine should be left on the battlefield.  We 
resolved the question after a long and thoughtful discussion; I don't think that decision making process could have been solved in 
advance by a bullet-point in a general purpose process PEP.


Raymond

More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4