"tomer filiba" <tomerfiliba@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