PEP 322: Reverse Iteration (second revision, please comment)
Gonçalo Rodrigues
op73418 at mail.telepac.pt
Thu Oct 30 17:12:41 EST 2003
On Thu, 30 Oct 2003 08:00:08 GMT, "Raymond Hettinger"
<vze4rx4y at verizon.net> wrote:
>Based on the feedback here on comp.lang.python, the pep has been
>updated:
>
> www.python.org/peps/pep-0322.html
>
>
>The key changes are:
>
>* reversed() is being preferred to ireverse() as the best name.
>
Heh, I actually prefered ireverse. It conveys better that it produces
an iterator.
>* the sample implementation now clearly shows a check for a custom
> reverse method and a guard against being applied to a mapping.
>
>* added sample output for enumerate.__reversed__ to show
> how a custom reverse method would work
>
>* explained why the function is proposed as a builtin and why attachment
> to another module or type object is not being considered further.
>
>* expanded comments on the real world use cases to show what the
> replacement code would look like.
>
>
>Please continue to contribute your thoughts. I'm especially interested
>in people examining their own code to verify that the new function
>adds clarity and improves performance.
I have only a couple of cases where I've needed to use reversed
iteration and in all honesty I don't think that
for index in xrange(len(lst) - 1, -1 -1):
etc.
is all that unreadable. The use cases are so few that I can very well
live with them.
And since it cannot be put inside itertools, I'm -0 on the PEP. The
use cases are so few that I don't think it justifies being put in the
builtins or the growing of Yet Another Protocol.
Just two more notes:
- Making it a method of iter sure looks bizarre. And ugly.
- Shouldn't the implementation test for __contains__ instead of
has_key? e.g.
if hasattr(x, "__contains__"):
raise ValueError("mappings do not support reverse iteration")
etc.
All my mapping-like classes overload __contains__, never has_key, but
maybe that's just me.
With my best regards,
G. Rodrigues
More information about the Python-list
mailing list