instance as fake module (Re: why is there no class (static) methods in Python ?)

[James_Althoff at i2.com]

Alex Martelli wrote:
><James_Althoff at i2.com> wrote in message
>news:mailman.992978370.21848.python-list at python.org...
>    ...
>> But more to the point, I think that since in Python "everything is a
>> first-class object" -- which is great -- and since classes, therefore,
are
>> first-class objects it would be nice (and powerful) if you could define
>> methods that you could invoke on such class objects.  (And such methods
>> should support inheritance and override, of course.)
>
>Dictionaries, lists and functions are also first-class objects, by the
>same token.  If what you say IS indeed the rationale for having
>'methods that you could invoke' on class-objects, then by exactly
>the same rationale there must be the same ability on dictionaries,
>lists, and functions, right...?

Lists and dicts DO have methods, as you know.  And it appears that in the
future (once the class/type healing is done) we will be able to subclass
these and define/invoke new methods on instances of such subclasses.  So I
guess I am missing your point.  In any case, I wasn't trying to say that
class objects should have methods *merely* for the sake of some sense of
rigid consistency.  I was suggesting that invoking methods on class objects
would be useful in the same way that invoking methods on objects in general
is useful.  And that because classes in Python are already first-class
objects (unlike the case in some languages), it isn't a far stretch to
imagine the ability to invoke methods on them.

>That "something is a first-class object" doesn't mean you have to
>be able to apply *EVERY* operation to it -- you can't "call" a list
>nor can you "slice" a function, for example.  Rather, it means that
>operations *applicable to objects in general* can also be applied
>to that object: passing as function parameter, returning as function
>result, more generally binding to any generic kind of reference (item
>in a list or tuple, value in a dictionary) -- the ability of being the
>_key_ in a dictionary requires hashability (either immutability or
>not defining == as different from 'is', in practice:-).

I didn't say that it should be possible to invoke *every* method (or
operation) on *every* object.  That wouldn't make sense would it?

>Therefore it
>seems that your sillogism is invalid -- "classes are 1st class objs",
>"all 1st class objs can have methods defined on them", therefore
>"classes must be able to have methods defined on them" -- alas,
>or hurrah, the second premise does not hold.

Happily, I'm not trying to prove a theorem (it's "syllogism", btw --
unless, of course, you were making a pun on the "silli-ness" of the whole
point <wink>) -- just expressing my desire to see class methods in Python.
If, for whatever reason, you think that it is unreasonable for Python to
support methods on class objects, you are certainly entitled to think that
way.  My understanding, though, is that if/when the current class/type
healing stuff gets into Python, there might indeed be methods associated
with types.ClassType which could be invoked on its instances -- namely
class objects.  I guess we will have to wait and see.  :-)

>
>
>Alex

Jim