On PEP 322 (ireverse)

[Gonçalo Rodrigues]

I've lost the original thread on my news reader so I'm opening a new
one.

First, i like the name ireverse, much better then inreverse (eek!).

Just a simple comment/question:

- Why a builtin function? Why not just stuff it in the itertools
module? The builtins is already fat as it is, making it fatter is not
the way to go, IMHO. I'd like to remeber the copy module as a case
where a fundamental protocol (__copy__ and __deepcop__) is not in the
builtins but in a standard module.

If it were to be put in itertools i'm definitely +1. On the builtins
-0 and lowering...

With my best regards,
G. Rodrigues

[Alex Martelli]

Gonçalo Rodrigues wrote:

I've lost the original thread on my news reader so I'm opening a new
one.

First, i like the name ireverse, much better then inreverse (eek!).
I still prefer Werner Schiendl's idea of iter.reversed, IF we find a
way to have builtin function iter grow a 'staticmethod' of sorts...!

Just a simple comment/question:

- Why a builtin function? Why not just stuff it in the itertools
It's inappropriate for itertools according to detailed criteria that
Raymond has recently posted here.
module? The builtins is already fat as it is, making it fatter is not

Yes, builtins should indeed be reserved strictly for the indispensable
cases (and trimmed a LOT in 3.0 -- but that's years away). Which is
why, e.g., list.sorted was made a classmethod of type list, rather
than a built-in. Similarly, IF iter was a type, iter.reversed would
be the "one obvious way to do it"...
Alex

[Raymond Hettinger]

> Gonçalo Rodrigues wrote:

First, i like the name ireverse, much better then inreverse (eek!).

Thanks.

[Alex] I still prefer Werner Schiendl's idea of iter.reversed, IF we find a
way to have builtin function iter grow a 'staticmethod' of sorts...!

No thanks. Yuck. Please do not twist this simple idea into knots.
This is supposed to be something you can teach in the first half-hour
and then use forever. I would sooner teach negative xrange()
indices than immediately launch into dotted references to a static
method attached to something that doesn't look like it should have
a method. This is a simplification, not an exercise in being cute
or clever just to avoid a builtin.
Raymond Hettinger

[Terry Reedy]

"Alex Martelli" <al***@aleax.it > wrote in message
news:4x******** *************** @news2.tin.it.. .

Gonçalo Rodrigues wrote:

First, i like the name ireverse, much better then inreverse

(eek!).
I still prefer Werner Schiendl's idea of iter.reversed, IF we find a
way to have builtin function iter grow a 'staticmethod' of sorts...!
As I suggested elsewhere, make iter() the type object for iterator.
Then iter.reversed is closely parallel to list.sorted.
Which is
why, e.g., list.sorted was made a classmethod of type list, rather
than a built-in. Similarly, IF iter was a type, iter.reversed would
be the "one obvious way to do it"...

Any good reason not to make iter so? int, str, and float were once
bifs also. I'm +1 on iter.reversed, along with list.sorted.

Terry J. Reedy

[Roy Smith]

"Terry Reedy" <tj*****@udel.e du> wrote:

As I suggested elsewhere, make iter() the type object for iterator.
Then iter.reversed is closely parallel to list.sorted.

I've got a question about list.sorted. I assume it's just a list that's
initialized to have its elements sorted when it's created? We're not
talking about some new magic container type which keeps its elements
sorted all the time?

In other words, I'm assuming that

l = list.sorted ((1, 2, 5, 3))
l.append (4)
print l

will print [1, 2, 3, 5, 4], right?

[Michael Hudson]

"Terry Reedy" <tj*****@udel.e du> writes:

"Alex Martelli" <al***@aleax.it > wrote in message
news:4x******** *************** @news2.tin.it.. .

Gonçalo Rodrigues wrote:

First, i like the name ireverse, much better then inreverse

(eek!).

I still prefer Werner Schiendl's idea of iter.reversed, IF we find a
way to have builtin function iter grow a 'staticmethod' of sorts...!

As I suggested elsewhere, make iter() the type object for iterator.

The what?

Cheers,
mwh

--
it's not that perl programmers are idiots, it's that the language
rewards idiotic behavior in a way that no other language or tool
has ever done -- Erik Naggum, comp.lang.lisp

[Terry Reedy]

"Roy Smith" <ro*@panix.co m> wrote in message
news:ro******** *************** @reader2.panix. com...

"Terry Reedy" <tj*****@udel.e du> wrote:

As I suggested elsewhere, make iter() the type object for iterator. Then iter.reversed is closely parallel to list.sorted.
I've got a question about list.sorted. I assume it's just a list

that's initialized to have its elements sorted when it's created?

Correct: As I understand it,
l=list.sorted(i terable) == l=list(iterable ); l.sort

tjr

[Raymond Hettinger]

[Terry Reedy]

Any good reason not to make iter so? int, str, and float were once
bifs also.
The C code for it has a split path, calling __iter__ for objects that
have it, building iterator wrappers for sequences that don't have
__iter__, or building another wrapper when the inputs are a
function and sentinel. IOW, it is a factory function capable
of constructor any of several different types.
I'm +1 on iter.reversed, along with list.sorted.

Please no.

list.sorted() is entirely unrelated. It is attached to lists because that
is what it generally returns and because its functionality is closely
tied to list.sort(). It is a class method because that gave it
richer functionality by taking any iterable as an argument:

list.sorted('a string').

When I posted the PEP for comment, I was looking for confirmation
that the underlying problem is real and for folks to look through their
own code to see if the proposed solution truly offered improvements
in terms of clarity and performance.

Grafting this onto iter is not an option; I would rather lose the
functionality than have the experts here twist it into something
I can't easily explain to a client.
Raymond Hettinger

[Terry Reedy]

"Raymond Hettinger" <vz******@veriz on.net> wrote in message
news:YS******** ***********@nwr dny01.gnilink.n et...

[Terry Reedy]

Any good reason not to make iter so? int, str, and float were once bifs also.
The C code for it has a split path, calling __iter__ for objects

that have it, building iterator wrappers for sequences that don't have
__iter__, or building another wrapper when the inputs are a
function and sentinel. IOW, it is a factory function capable
of constructor any of several different types.

Good reason acknowledged.

I'm +1 on iter.reversed,

rescinded.

tjr

[Paul Moore]

"Raymond Hettinger" <vz******@veriz on.net> writes:

[Alex]

I still prefer Werner Schiendl's idea of iter.reversed, IF we find a
way to have builtin function iter grow a 'staticmethod' of sorts...!
No thanks. Yuck. Please do not twist this simple idea into knots.

[...]
This is a simplification, not an exercise in being cute
or clever just to avoid a builtin.

Agreed. Keep it simple. For a name, I'd go for ireverse() if reverse()
is not possible. But not inreverse()...

Paul
--
This signature intentionally left blank