On 19 Apr 2014 00:27, "Steven D'Aprano" <st...@pearwood.info> wrote: > > On Fri, Apr 18, 2014 at 10:31:29PM -0400, Nick Coghlan wrote: > > After spending some time talking to the folks at the PyCon Twisted > > sprints, they persuaded me that adding back the iterkeys/values/items > > methods for mapping objects would be a nice way to eliminate a key > > porting hassle for them (and likely others), without significantly > > increasing the complexity of Python 3. > > It would also considerable add to the cruft of Python 3. One motive for > going through the pain of Python 2 to 3 migration was to remove cruft. > Adding it back in again is not just an aid to porting but actively > making Python 3 a worse (well, "less better") experience.
The cruft is unavoidable in this case. The decision we face is *where the cruft lives*, and *how much work is involved* in creating that cruft. Status quo: we preserve the "purity" of the Python 3 mapping API, and require every developer making the transition from Python 2 to Python 3 replace every occurrence of these methods with a helper function that is not idiomatic code in either language. My proposal: we add three trivial helper methods to the Python 3 mapping API. For the cost of 3 additional methods that are easily explained in terms of combining a builtin with other existing methods, a whole pile of work just evaporates for affected segments of the community. > > So while I'm sympathetic to wanting to ease the 2/3 transition, even at > the expense of re-introducing some cruft when unavoidable, I don't think > that the difficulty of dealing with dict items|iteritems|viewitems etc. > justifies re-adding cruft. The cruft will be there regardless, the only question is whether it exists in the definition of Python 3 or is distributed across all of the single source projects supporting both 2 & 3. > [...] > > Rationale > > ========= > > > > Similar in spirit to PEP 414 (which restored explicit Unicode literal > > support in Python 3.3), this PEP is aimed primarily at helping users > > that currently feel punished for making use of a feature that needed to be > > requested explicitly in Python 2, but was effectively made the default > > behaviour in Python 3. > > "Feel punished"? That's awfully strong language. It may even be true, in > the sense that some people *feel* that they are being punished, but I > think the barrier to doing something about that needs to be a bit > higher, namely that they *actually are* being punished. Yes, they are *actually* being punished for using the memory efficient APIs that were being added in Python 2.2. That's why the PEP covers how the transition to Python 3 is harder for them than if they just hadn't cared about memory efficiency in the first place. They're Pythonistas too - they care about readability, and they *don't like* having to add crufty helper functions to all their mapping manipulation code. They also legitimately don't want to put up with all the code churn that results from doing so, requiring additional reviews and retesting of currently working code. I spend a fair bit of time talking to users that have put a lot of work into supporting a language transition that doesn't really help them personally. A non-trivial number of them are deeply, viscerally angry about what they see as pointlessly changing the spelling of a core language feature for no real technical gain. So let me be clear: this is *not* a proposal driven primarily by technical considerations. Rather, it is a social one, where we do something simple and easy and low cost for us to send a clear message to a set of users that feel justifiably angry about the amount of work we imposed on other members of the community by putting Python 2 into maintenance mode that we do value their time and energy, and are willing to show some flexibility in adding "not harmful" changes to Python 3 that don't significantly increase the complexity of the language, while making it easier to write single source code that looks like idiomatic Python code. > I think that if "write a helper function" is punishment, then nearly > every programmer is being punished *all the time*. No, the punishment is "replace every usage of the memory efficient iterator based APIs that have existed since Python 2.2 with a helper function because we think that is a reasonable burden to place on you just so we can avoid adding three trivial helper methods in Python 3". Regards, Nick.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
