1. How can these metaclasses actually help me implement the smart
dictionary given as an example? I mean, beyond just intercepting the
__getslot__ and __setslot__ meta-methods (meta-methods?). How can I
get this Bold-New-Python to parse "{'one':1, 'two':2}" and create a
smart dictionary instead of the standard not-so-smart dictionary?
(Display is easy: we already have __str__ and __repr__).
I'm talking about extending the syntax, and so extending the parser.
Can this be done through a metaclass specification? (This question is
starting to sound like a request for C++ operator overloading
features.) The issue here is: how to maintain readability. One of
Python's strengths is it's brevity, and to give that up in favor of
a more universal (and flexible) syntax will cause the language to look
more like Lisp or Scheme.
2. From the example/proposed metaclass syntax:
metaclass SmartClass:
def __init__(self): ...
It occurs to me that metaclasses can also be inherited, like so:
metaclass SmartClass(StandardClass):
def __init__(self): ...
So we get all the advantages of inheritance when defining metaclasses.
3. Inheritance and metaclass conflicts. The example/proposed new
class syntax is:
class SmartRect is SmartClass:
def ...
What would the restrictions be when classes are inherited? Can I do
this:
class SmartRect is SmartClass:
def ...
class SmartPoly(SmartRect) is DumbClass:
def ...
I can imagine arguments both for and against. I haven't worked with
metaclasses, so I'm asking out of ignorance. And, of course, to stir
up the hornet's nest.
4. Readability vs. Metaclass Proliferation: Will the ability to monkey
with class operation lead to less readable Python code? I mention
readability again because it is one of Python's strengths, and there
are plenty of languages that are less so. Imagine:
dict1['key'] = 1
dict2['key'] = 1
where "dict1" and "dict2" are of different classes and metaclasses.
They (hopefully) will do something similar, but may cause different
side effects. Is this desirable? Is this behavior similar to one of
C++'s good features, or one of it's bad features?
In the US, if I may delve into a figurative argument, we have a
saying: "Guns don't kill people, people kill people." Which is to say
that programmers should be responsible for their own confusion.
Although, a variation is "Guns don't kill people, bullets kill
people," which is an obfuscated way of saying "Tough shit", except
that people make bullets, so whose responsibile for that? Then
there's "Slogans don't confuse issues, people confuse issues..."
5. How metaclasses will help me: one of my peeves about (some)
object-oriented languages is the unnecessary distinction between
instance variable and method. Why must I write:
instance.calculated_value()
to cause some calculated value to be actually calculated from other
instance variables? It's a value! It may already *be* calculated!
What does the caller care how or when it comes into being? I would
prefer to leave the parentheses off, and leave the implementation,
whether it be dictionary look-up or method call, to the class
implementation. (This can be accomplished with something similar to
the notify-on-change functionality discussed in this thread.)
Well, that's what my code will look like in the future. Do you want
to read it?
How to differentiate between calling the method and returning the
method as a first-class object? Use "instance.calculated_value.im_func"
5. Metaclasses: do we need this? It makes the language more complex.
I was reading the Dylan language spec yesterday, and one of the design
goals specified was, "Make the language as simple as possible, and no
simpler." Well, I don't think they've accomplished that, and I can
use Python as an example of how things *could* be simpler. Should this
potentially trite phrase be part of Python's design goal?
-- Craig Lawson claw@rahul.net