On PEP 322 (ireverse)

[Alex Martelli]

Aahz wrote:

> In article <VHQob.78295$e5.2907888 at news1.tin.it>,
> Alex Martelli  <aleaxit at 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