Comment on PEP-0322: Reverse Iteration Methods

[John Roth]

I agree. Importing itertools to get at riter()
isn't a significant hardship.

John Roth

"Alex Martelli" <aleax at aleax.it> wrote in message
news:8RScb.169633$R32.5449258 at news2.tin.it...
> Raymond Hettinger wrote:
>
> >> And I still think you don't need it often enough to put it in the
> >> builtin namespace, so the function should go in the itertools module.
> >
> > If you have a magic method, __riter__, then the corresponding
> > function needs to be a builtin.  They go hand in hand.  The
> > core parts of the language need to be usable without having
> > to know about itertools.
>
> I have already seen module copy presented as a counter-example to
> your assertion, and I'd like to add module pickle as a second, and
> I hope decisive, counter-example.  It is, to put it simply, utterly
> false that functions corresponding to magic methods "need to be
> builtins": it's *perfectly* all right for such functions to live
> in standard library modules.  Oh, and let's not forget module sets:
> the __as_immutable__ and __as_temporarily_immutable__ magic methods,
> that are used when making a set of sets, or checking for a set's
> membership in another set, can be seen as yet another example (and
> in this case there is no wiggling out of it by claiming that the
> magicmethod/NON-builtin correspondence is a historical/legacy thing,
> as the BDFL approved module sets.py, with just this usage, so very
> recently).
>
> I second the motion that function riter, with check for __riter__
> and all, should live in module itertools.  Reverse iteration is a
> RARE need -- far rarer than copying or even pickling -- and there
> is no real reason to burden __builtins__ with a function for it.
>
>
> Alex
>