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

[Aahz]

In article <gD************ ********@news1. tin.it>,
Alex Martelli <al***@aleax.it > wrote:

Aahz wrote:

In article <4x************ ***********@new s2.tin.it>,
Alex Martelli <al***@aleax.it > wrote:

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...!

Raymond has vetoed this, but I don't understand why iter() needs to grow
a staticmethod. After all, it's just a function that can be decorated
with attributes....

built-in functions normally can't, and in that way they differ from
C-coded functions. So, iter would have to be changed into a different
type that _does_ support some attributes.

Did you mean "Python-coded"? Anyway, I doubt that adding an attribute
to iter() would cause problems the way changing it to a type constructor
would. I'm not suggesting this, mind, just curious why nobody else
mentioned the possibility.
--
Aahz (aa**@pythoncra ft.com) <*> http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan

[Alex Martelli]

Aahz wrote:
...

built-in functions normally can't, and in that way they differ from
C-coded functions. So, iter would have to be changed into a different
type that _does_ support some attributes.
Did you mean "Python-coded"? Anyway, I doubt that adding an attribute

Yep.
to iter() would cause problems the way changing it to a type constructor
would. I'm not suggesting this, mind, just curious why nobody else
mentioned the possibility.

I think one needs *more* work to add an attribute to a C-coded function:
it needs to be made into a different type. To add a classmethod to a type
one only needs to supply the classmethod flag in one's C sources -- hard
to see how that might be more troublesome...?
Alex

[Aahz]

In article <VH************ ********@news1. tin.it>,
Alex Martelli <al*****@yahoo. com> wrote:

I think one needs *more* work to add an attribute to a C-coded function:
it needs to be made into a different type. To add a classmethod to a type
one only needs to supply the classmethod flag in one's C sources -- hard
to see how that might be more troublesome...?

Someone claimed that making iter() a type constructor would not be
backward-compatible. This certainly would be.
--
Aahz (aa**@pythoncra ft.com) <*> http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan

[Alex Martelli]

Aahz wrote:

In article <VH************ ********@news1. tin.it>,
Alex Martelli <al*****@yahoo. com> wrote:

I think one needs *more* work to add an attribute to a C-coded function:
it needs to be made into a different type. To add a classmethod to a type
one only needs to supply the classmethod flag in one's C sources -- hard
to see how that might be more troublesome...?

Someone claimed that making iter() a type constructor would not be
backward-compatible. This certainly would be.

Only if we propagated the [expletive deleted] hack whereby, these days,
int(...) is NOT guaranteed something that's an instance of int. We do
need that hack as a prop on the way to int/long unification, I guess
(sigh), but getting MORE such cases is an icky prospect.

If type iter is an abstract baseclass, calling iter should fail -- that
is what calling basestring does, for example, and AFAIK it's the only
precedent in Python, but it's the common meaning of abstract baseclasses.

If type iter is instantiable, right after "x=iter(... )" I'd really
want to be able to "assert type(x) is iter" -- and of course I can't.

I can't even assert the weaker isinstance(x, iter), not in a backwards
compatible manner, since e.g. iter(x) will gladly return x any time x
is an iterator (def __iter__(self): return self), and iterators need not
subclass a hypothetical type iter.

So, "makint iter() a type constructor" while remaining backwards
compatible would mean "makint iter() a type constructor which hardly
ever returns an instance of iter" -- barf.

Nope -- even though I'd STILL like "iter.reversed" , we can't make
iter a type, backwards compatibly, in a DECENT way; we'd really need
a new subtype of "builtin function" which can have attributes.
Alex

[Dave Benjamin]

In article <xx************ ********@news1. tin.it>, Alex Martelli wrote:

Nope -- even though I'd STILL like "iter.reversed" , we can't make
iter a type, backwards compatibly, in a DECENT way; we'd really need
a new subtype of "builtin function" which can have attributes.

Pardon me for missing this, but what was the rationale for not just calling
it "reverse" and putting it in builtins? And likewise for "sort"?

--
..:[ dave benjamin (ramenboy) -:- www.ramenfest.com -:- www.3dex.com ]:.
: d r i n k i n g l i f e o u t o f t h e c o n t a i n e r :

[Anna]

On Mon, 03 Nov 2003 05:01:10 +0000, Dave Benjamin wrote:

Pardon me for missing this, but what was the rationale for not just calling
it "reverse" and putting it in builtins? And likewise for "sort"?

reverse and sort already exist in Python, as list methods.

L.reverse() reverses, in-place, the items of list L.
L.sort([f]) Sorts, in-place, the items of L, comparing items by f;
if f is ommitted, cmp is used as comparison function.
(pg 49, _Python in a Nutshell_)

Anna

[Alex Martelli]

Anna wrote:

On Mon, 03 Nov 2003 05:01:10 +0000, Dave Benjamin wrote:

Pardon me for missing this, but what was the rationale for not just
calling it "reverse" and putting it in builtins? And likewise for "sort"?

reverse and sort already exist in Python, as list methods.

L.reverse() reverses, in-place, the items of list L.
L.sort([f]) Sorts, in-place, the items of L, comparing items by f;
if f is ommitted, cmp is used as comparison function.
(pg 49, _Python in a Nutshell_)

Yes, the risk of confusion between the existing list methods and the
new functions does play a role in wanting to differentiate their names.

As to whether the new functions (by whatever names) must become
built-ins, that's a separate controversy. Raymond is keen to have
them as built-ins because he views them as "fundamenta l looping
constructs". Guido has decided that list.sorted will be a
classmethod of list instead (more general, one less built-in),
but has essentially approved some reverse-iterating function as a
built-in (and Raymond has vetoed having it as _anything BUT_ a
built-in) so the only issue where debate is allowed (at least
according to Raymond) is on the exact name -- almost.

Almost, because one alternative may still be open: having a
"reversed range" iterator. I think a built-in 'irange' with an
option to reverse would end up as more generally useful than a
"reverse iterator". But if the choice is only between either
the reverse iterator, or a revrange iterator builtin, I would
be roughly neutral -- having _three_ built-ins for arithmetic
progressions, with range returning a list, xrange a "neither
fish nor fowl" ``almost but not quite a list // almost but not
quite an iterator'', revrange an iterator, is just too messy to
feel comfortable. If we introduced a general irange instead
we'd be ready to deprecate xrange soon, _and_ eventually change
range into a simple list(irange(... -- ah BLISS. Therefore,
to me, introducing irange sounds like a general, clean, wise,
far-seeing approach, while revrange feels too specialized to
"pull its weight" as a built-in. Oh well.
Alex