On Tue, Apr 1, 2008 at 4:40 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I'm not sure that it's really a safe vs. non-safe issue. The OP's > concern is that the change affects behavior of keys() and friends that > people have internalized for the past 18 years. I certainly don't see > this is a reason to change it back (we knew this would be the case). I > do think it needs to be ephasized in every "What's New" doc. It's > already in the list of Common Stumbling Blocks, but the paragraph > there could be expanded a bit.
I agree that the 3.0 behavior is safe but surprising. So unless I am misinterpreting this, it sounds like the burden of proof now falls on the option to keep the status quo. The thing is that it seems to me that if that an outside observer were to look at this situation, then they might ask why the names are being changed when the current behavior is functional and no one is clamoring for the change. If you disagree, then I still don't understand the motivation on the PEP, and the current motivation, "being able to do set operations on keys and items without having to copy them" does not appear to pertain to the issue of which names should correspond to which behavior. Once viewitems() or itemview() gets backported to 2.6, then unless I am missing something, the PEP is concerned solely with changing the names. FWIW, there is a distinction between "loud" changes such as, say, "print" changing from a function to a statement or "except" blocks rejecting the "except TypeError, exc" syntax in favor of "except TypeError as exc" and "silent" changes such as the one under discussion; the change under discussion alters the meaning of an expression that is valid in both 2 and 3 whereas in the other cases the code will not compile in 3. David _______________________________________________ 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
