Syntax modification idea: (classmethods, properties locking...)

[Ian Bicking]

On Thu, 2003-01-16 at 15:03, Arne Koewing wrote:
> class bar(object):
>     def foo(class,arg1) is classmethod:
>         pass
>     def bar(arg1) is staticmethod:
> 	pass


I really like the way this looks.  I think the use of "is" is really
important too, it makes it read well and fits in with Python syntax.  I
don't think Python really uses whitespace alone for much of anything
(i.e., the only place "word word" is valid is where one of those are a
keyword, as in "def foo").  So I think "foo(cls) classmethod:" is bad. 
Using "is" here is like "for x in y:" -- "for x y" would be more
compact, but reads horribly.

And I like that classmethod and staticmethod aren't given any special
privileges (i.e., you can do locking or other techniques as you
suggest).  It also doesn't make the code less readable, as "def
classmethod foo(...)" does -- that moves the function name to the third
word on the line, where it's always been the second up until now.  That
form wouldn't allow arguments either, as in locking("lockname") -- I
think that's a big feature.

But it doesn't address what I think would be the most common case of
"property".  Pre- and post-methods (as in Eiffel) also wouldn't be well
supported.  But I suppose it could be used for read-only properties,
which probably accounts for 75% of the uses of property.  For read-only
properties it also reads quite nicely (def foo(self) is property).  

The alternative of course is using a metaclass, which works right now. 
I've been using things like _set_attr(), but I think I prefer
attr__set(), which I saw someone use before (it looks sufficiently
magical).  Reads really poorly, though.  But it allows properties to be
used with their full functionality.  It doesn't make your locking
example work, though you could use function attributes for that, like:

    def g__locking(arg):
        ...
    g__locking.lock = threading.Lock()

The problem with metaclasses is that you have to make a choice.  It's
easy to add another type of function to your system orthogonally with
everything else.  But with metaclasses you'd have to somehow register
your function-constructor with the metaclass.  And we'd need some
canonical metaclass.

That's reasonable, but still leaves the problem of composing these
metaclasses.  I've begun using metaclasses in my library code, and I
like it -- but (I think) I'd need to make my metaclass a subclass of
this canonical metaclass in order for them to be compatible.  Unless
maybe you could do __metaclass__ = (PropMetaclass, SomeOtherMetaclass)
-- I haven't tested that (and metaclasses seem poorly documented right
now).  I still don't feel entirely comfortable with my understanding of
the semantics of metaclasses, so I couldn't quite predict what multiple
metaclasses would mean.

-- 
Ian Bicking           Colorstudy Web Development
ianb at colorstudy.com   http://www.colorstudy.com
PGP: gpg --keyserver pgp.mit.edu --recv-keys 0x9B9E28B7
4869 N Talman Ave, Chicago, IL 60625 / (773) 275-7241