[Python-ideas] of properties and metaclasses

[Ron Adam]

tomer filiba wrote:
> first thing: properties. i prefer this approach to properties (example below).
> true, it involves some magic, but the magic is very restricted and contained.

Looks good, it also looks optional in that the old way still works.



Here are my recent thoughts on properties, which I believe would create 
more problems than not, but maybe someone can think of a nicer way to do 
the same thing? (shrug)  (This isn't thought out fully.)


Properties are magic anyways.  Yes, they can be implemented in pythons 
existing machinery, but that doesn't make them any less magical in what 
they do.

For example, *what if* properties could be defined independently of 
class's?     (possible?)  They would act something like a true variable or 
a unique mutable container of length one.  This is unique in python because 
in all other cases the expression (x = y) would be a name binding 
operation.  With a property, it's a closer to (x[0] = y).

Because it's behavior is unique, it would probably need it's own 
constructor syntax, as well as support by the interpreter to recognize them 
and call the setter and getter functions instead of rebinding the name.  It 
would need to convert (x = y) statements where x is a property to 
(x.__set__(y)).

So a global property definition might look something like...

property foo():
     __value__ = value
     def __get__():
         return __value__
     def __set__(value)
         __value__ = value


Of course that would be magic since it isn't a class and it isn't a 
function.  It's a mutable variable with definable input and output functions.

And it has a problem in that there is no way to create a lot of them 
without resorting to meta programming techniques.  So we are back to first 
creating a function or a class, and then converting it to a property in 
some *magical* way.


The same object in a class might look like...

property foo(self):
    self.__value__ = None
    def __get__(self):
        return self.__value__
    def __set__(self, value):
        self.__value__ = value


This is sort of the direction some of the other suggestions have been going 
in I think.  But how useful would it be?  In other words, would something 
like property objects be useful and beneficial behavior to the language?

My personal thoughts at this time are it would probably be more trouble 
than it's worth even thought there are certain aspects to the general idea 
I like.  There is more things about how to make it work I don't like.


> second -- metaclasses. there's some notion (Josiah et al) that metaclasses
> were introduced to make classes behave as generic attribute containers. this
> is not true. using metaclasses like so was not the original intent.
> 
> metaclasses are the types of types. they also happened to be executed
> before the class body is made into a class, which means they can be used
> to tweak class creation, but that's a technicality. using this feature to turn
> classes into anything you want is wrong: it's implicit, complex, and mostly
> unreadable by the common programmer. i'd guess 80% of python
> programmers have never used metaclasses. it's a difficult concept,
> and should be used sparsely.

I haven't needed them yet, but I do wonder how I might use them to 
generalize certain types of behaviors across a wider range of objects and 
situations.  So far though I've found it easier to just stay away from them.

> class decorators would cover ~70% of the use-cases for metaclasses,
> but for some reason, people insist on complicating even more the
> metaclass machinery in py3k. see my protest [1], which was silently ignored.
> 
> what you people are asking for is a new language construct which allows
> the definition of syntactic namespaces. much like the deceased make pep.
> (mis)using classes for this purpose is wrong. it's different -- it's
> not a class
> anymore. so why is it being defined by a class-clause?

I think I agree that there seems to be a indirect need if not desire to 
have an explicit name space type of object.  It seems like it may have the 
potential to improve some types of name space operations where dictionaries 
are currently used.

> @property
> namespace foo:
>     def get(self):
>         ....
>     def set(self):
>         ....

I think that should be...

     def set(self, value):
        ...

Then it's not too different from what I described above. ;-)

There may also be no requirement for a property type to have a single 
value.  So a property with child values could also be a name space or the 
other way around.  A name space with only it's primary value could be a 
property.

Cheers,
    Ron