>
> A solution without changing the interpreter is to rename your class to
> _Iterator and have a (global) function as follows:
>
> def Iterator(list):
> return _Iterator(list).generator
>
> This can be called as in your first example.
>
> Your proposal violates a property that I quite like: if classname(...)
> returns, it returns an instance of class 'classname'. If you don't
> want that, it shouldn't be a class. Note that C++ constructors can't
> return a value either...
>
I quite agree with Guido here. We should be able to rely on the
consistant fact that an object of type class returns an object
of type instance of class.
However, a while back, I proposed *another* idea that would have a
similar utility, while preserving reasonable behaviour:
If an method "__func__" is defined for a class, then syntactically
calling an instance ( instance( ) ) would be equivalent to calling
instance.__func__().
Just as overloading of __getitem__, et.al., allows you to replace a
built-in data type (like sequences) with a user written class, this
would allow functions to be replaces by classes or instances without
requiring a 'helper' function.
However, I have to admit that I never got around to implementing this
particular hack, as I haven't yet found anything that I *can't* do
WITH a suitable helper function. ( And I wouldn't want it built-in
if it had a negative impact other function call overhead. - But I
haven't given up on the idea entirely - especially IF other callable
objects ( re: coroutine thread ) were added - but I didn't have
enough justification to argue strongly for it. But since Steve Miale
has brought up the subject... ...AND, the more "helper" functions
one is called on to write, the more one wishes to avoid what begins
to feel like an unnecessary chore! ;-)
- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics