[Python-ideas] of properties and metaclasses

[Josiah Carlson]

"tomer filiba" <tomerfiliba at gmail.com> 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.
[snip]

I'm not a big fan of the style that you propose.  It doesn't fit my
aesthetics.  I'd rather introduce another level of indentation with a
class statement than to confuse myself with generic-like decoration that
aren't actually generics.


> 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.

I have never made any claim that they were introduced to offer that
functionality (incidentally, I don't believe anyone else has claimed as
much on this list either), I stated that they *could be used* to offer
that functionality, expressed that I had done so, and in my opinion,
using them as a generic container was obvious. If others disagree with
my opinions, that's fine, but please don't put words into my mouth.


> 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.

If metaclasses are rarely used by users, then where is the problem of 
using (and abusing) them if a person desires?


> 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.

Don't get me wrong, I've been pushing for class decorators for a couple
years now (after 2.4 was released without them), and also generally
dislike the uglification of metaclass semantics, but every extra
argument to 'class foo(<arguments>):' necessarily makes it an uglier
mess than it already is.  Yes, overloading metaclasses to return a
dictionary-like object as a namespace is ugly, but getting the 'order'
list in '(name, bases, attrs, order)' to be correct when confronted with
'del' is tricky, and will necessarily require an extra line of
boilerplate.  Of course whether this is a bigger issue than everyone
writing their own ordered dict, is another dicussion (that I don't
particularly want to participate in).


> 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?

Because it offers everything necessary for certain higher order
functionality without needing to change the base language.  I don't know
about others, but I am conservative about language change. I believe
that Python should be no simpler and no more complex than necessary.
Adding yet another way of defining a namespace (with a namespace
construct as you propose) won't offer us anything that we don't already
have with 'class namespace'.


 - Josiah