Le 21/02/2012 03:04, Benjamin Peterson a écrit : > 2012/2/20 Antoine Pitrou <solipsis at pitrou.net>: >> Changing the sequence size of sys.flags can break existing code (e.g. >> tuple-unpacking). > > I told George I didn't think it was a major problem. How much code > have you seen trying to upack sys.flags? (Moreover, such code would > have been broken by previous minor releases.) If by “minor” you mean the Y in Python X.Y.Z, then I think the precedent does not apply here: people expect to have to check their code when going from X.Y to X.Y+1, but not when they update X.Y.Z to X.Y.Z+1. But I agree this is rather theoretical, as I don’t see why anyone would iterate over sys.flags. The important point IMO is having clear policies for us and our users and sticking with them; here the decision was that adding a new flag in a bugfix release was needed, so it’s fine. Regards
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