On 3/24/06, Steven Bethard <[EMAIL PROTECTED]> wrote: > On 3/24/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > > I'm well aware that Python 3000 doesn't aim to be backwards compatible, > > but I would prefer if we could refrain from subtly changing the behaviour > > of existing constructs in way that breaks all existing use, and makes it un- > > necessarily hard to convert old code (whether by hand or by machine). > > Agreed. I wonder what the plan is for the transition?
That's the agenda of this list! The users need to speak up. > Things like > changing the semantics of the for-loop else-clause are actually > relatively easy to flag since they can be spotted easily with the AST, > and *all* current uses of the else-clause would be wrong. Regarding this particular feature proposal, I'd like to strongly discourage it. I don't think it's well thought out; it looks more like an ad-hoc response to the issue brought up by Ian Bicking. If you disagree, please write a well-argued PEP. > However, flagging things like "expects a list from dict.items instead > of an iterator" might be harder to do. Some uses (for-loops, > list-comps and genexps) are still perfectly fine while other uses > (indexing, getting the len) aren't. I think most of these should > raise an exception pretty quickly, but if any of them don't, that > would make me pretty nervous when transitioning code. Right. Unfortunately we're already bound to have incompatibilities that will give existing code new meanings that are hard to detect by source code inspection only -- e.g. i/j will return a float when i and j are ints, and you can't always tell whether any particular use of x/y will ever involve two ints. Python 3000 *will* be backwards incompatible, and sometimes it will be awkward to convert code. The question I lay in front of the community is, how much incompatibility can we handle? And what will the transition strategy be? Someone needs to own this discussion topic, start collecting ideas and feedback, and draft a PEP that will guide the Python 3000 feature specification process. One possibility is that every feature PEP is required to contain a section on compatibility issues and how the transition is handled. Sometimes the only reasonable answer will be "Some fraction of code will break and users will have to debug this on a per-case basis." (I imagine this is the most sensible approach in the case of the elimination of classic classes, which have a subtly different multiple inheritance pattern.) But hopefully in most cases we can provide tools to scan old code for potential issues (e.g. I wrote one long ago for int division) or even a conversion tool. But all this needs to be guided by an explicit policy, which hasn't been defined yet. Without an explicit policy we'll have never-ending discussions about whether a particular incompatibility is acceptable or not. > I wonder if it would be worth having a branch of python-3000 at some > point that inserts warning code on all constructs that changed (e.g. > all calls to dict.items). I have a suspicion that this would generate > a lot of false-positives, but maybe it would still be worthwhile... That's one proposal. I don't know how feasible it is, or if there are better solutions. Clearly we need to think about this more. Perhaps you would like to (co-)own the transition strategy topic? -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
