472,337 Members | 1,461 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,337 software developers and data experts.

creating many similar properties


I understand how to create a property like this:

class RC(object):
def _set_pwm(self, v):
self._pwm01 = v % 256
def _get_pwm(self):
return self._pwm01
pwm01 = property(_get_pwm, _set_pwm)
But what if I have a whole bunch of these pwm properties?

I made this:

class RC(object):
def _makeprop(name):
prop = '_%s' % name
def _set(self, v):
v_new = v % 256
setattr(self, prop, v_new)
def _get(self):
return getattr(self, prop)
return property(_get, _set)

pwm01 = _makeprop('pwm01')
pwm02 = _makeprop('pwm02')
Not too bad, except for having to repeat the name.

I would like to just have a list of pwm names and
have them all set up like that. It would be nice if
each one was set to a default value of 127 also....

Any thoughts?

Thanks for your time.
Oct 18 '06 #1
17 1812
Lee Harr wrote:
I understand how to create a property like this:

class RC(object):
def _set_pwm(self, v):
self._pwm01 = v % 256
def _get_pwm(self):
return self._pwm01
pwm01 = property(_get_pwm, _set_pwm)
But what if I have a whole bunch of these pwm properties?

I made this:

class RC(object):
def _makeprop(name):
prop = '_%s' % name
def _set(self, v):
v_new = v % 256
setattr(self, prop, v_new)
def _get(self):
return getattr(self, prop)
return property(_get, _set)

pwm01 = _makeprop('pwm01')
pwm02 = _makeprop('pwm02')
Not too bad, except for having to repeat the name.

I would like to just have a list of pwm names and
have them all set up like that. It would be nice if
each one was set to a default value of 127 also....

Any thoughts?

Thanks for your time.
You want a "class factory". This can either be the esoteric "metaclass"
(using "type"), which one can only understand for moments at a time, or
something more grounded in intuition, or, a combo (for fun). You can
probably tighten this a little, but this is the idea:

def c_factory(cname, pname, num, modulus, default):
def accessorize(prop):
def _get(self):
return getattr(self, prop)
def _set(self, v):
v_new = v % modulus
setattr(self, prop, v_new)
return (_get, _set)
def _init(self):
for i in xrange(num):
setattr(self, '%s%s' % (pname,i), default)
_C = type(cname, (object,), {'__init__':_init})
for i in xrange(num):
prop = '_%s%s' % (pname, i)
setattr(_C, '%s%s' % (pname, i), property(*accessorize(prop)))
return _C

E.g.:
pydef c_factory(cname, pname, num, modulus, default):
.... def accessorize(prop):
.... def _get(self):
.... return getattr(self, prop)
.... def _set(self, v):
.... v_new = v % modulus
.... setattr(self, prop, v_new)
.... return (_get, _set)
.... def _init(self):
.... for i in xrange(num):
.... setattr(self, '%s%s' % (pname,i), default)
.... _C = type(cname, (object,), {'__init__':_init})
.... for i in xrange(num):
.... prop = '_%s%s' % (pname, i)
.... setattr(_C, '%s%s' % (pname, i), property(*accessorize(prop)))
.... return _C
....
pyBob = c_factory('Bob', 'bob', 4, 256, 128)
pyb = Bob()
pyb.bob0
128
pyb.bob1
128
pyb.bob1 = 258
pyb.bob1
2
pyb.bob3
128
pydir(b)

['__class__',
'__delattr__',
'__dict__',
'__doc__',
'__getattribute__',
'__hash__',
'__init__',
'__module__',
'__new__',
'__reduce__',
'__reduce_ex__',
'__repr__',
'__setattr__',
'__str__',
'__weakref__',
'_bob0',
'_bob1',
'_bob2',
'_bob3',
'bob0',
'bob1',
'bob2',
'bob3']
pyBob
<class '__main__.Bob'>


--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com/
Oct 18 '06 #2
In <n2*****************@news01.roc.ny>, Lee Harr wrote:
But what if I have a whole bunch of these pwm properties?

I made this:

class RC(object):
def _makeprop(name):
prop = '_%s' % name
def _set(self, v):
v_new = v % 256
setattr(self, prop, v_new)
def _get(self):
return getattr(self, prop)
return property(_get, _set)

pwm01 = _makeprop('pwm01')
pwm02 = _makeprop('pwm02')
Not too bad, except for having to repeat the name.

I would like to just have a list of pwm names and
have them all set up like that. It would be nice if
each one was set to a default value of 127 also....

Any thoughts?
Use `__getattr__()` and `__setattr__()` methods and a dictionary of names
mapped to values and another that maps the names to default values for the
modulo operation.

Ciao,
Marc 'BlackJack' Rintsch
Oct 18 '06 #3
Lee Harr wrote:
I understand how to create a property like this:

class RC(object):
def _set_pwm(self, v):
self._pwm01 = v % 256
def _get_pwm(self):
return self._pwm01
pwm01 = property(_get_pwm, _set_pwm)
But what if I have a whole bunch of these pwm properties?

I made this:

class RC(object):
def _makeprop(name):
prop = '_%s' % name
def _set(self, v):
v_new = v % 256
setattr(self, prop, v_new)
def _get(self):
return getattr(self, prop)
return property(_get, _set)

pwm01 = _makeprop('pwm01')
pwm02 = _makeprop('pwm02')
Not too bad, except for having to repeat the name.

I would like to just have a list of pwm names and
have them all set up like that. It would be nice if
each one was set to a default value of 127 also....

Any thoughts?
Yes, what about this?

import sys

def defprop(name, default=127):
loc = sys._getframe(1).f_locals
prop = '_%s' % name
def _set(self, v):
v_new = v % 256
setattr(self, prop, v_new)
def _get(self):
return getattr(self, prop, default)
loc[name] = property(_get, _set)

class RC(object):
defprop('pwm01')
defprop('pwm02')

rc = RC()

print rc.pwm01 # 127
print rc.pwm02 # 127
rc.pwm02 = 1312
print rc.pwm02 # 32

This is a bit hackish, but I would prefer this over a metaclass
solution. since it does not add
any hidden magic to your class.

Michele Simionato

Oct 18 '06 #4

Lee Harr wrote:
I understand how to create a property like this:

class RC(object):
def _set_pwm(self, v):
self._pwm01 = v % 256
def _get_pwm(self):
return self._pwm01
pwm01 = property(_get_pwm, _set_pwm)
But what if I have a whole bunch of these pwm properties?

I made this:

class RC(object):
def _makeprop(name):
prop = '_%s' % name
def _set(self, v):
v_new = v % 256
setattr(self, prop, v_new)
def _get(self):
return getattr(self, prop)
return property(_get, _set)

pwm01 = _makeprop('pwm01')
pwm02 = _makeprop('pwm02')
Not too bad, except for having to repeat the name.

I would like to just have a list of pwm names and
have them all set up like that. It would be nice if
each one was set to a default value of 127 also....

Any thoughts?

The metaclass solution. I use this idiom occasionally, whenever I want
to fiddle with the class dict before letting the type constructor at
it.

class mod256metatype(type):
def __new__(metatype,name,bases,clsdict):
for sym in clsdict.get('__mod256__',()):
prop = '_%s' % sym
def _set(self,v):
setattr(self,prop,v%256)
def _get(self):
return getattr(self,prop)
clsdict[sym] = property(_get,_set)
return type.__new__(metatype,name,bases,clsdict)

class RC(object):
__metaclass__ = mod256metatype
__mod256__ = ["pwm01","pwm02"]
Carl

Oct 18 '06 #5
Michele Simionato wrote:
Lee Harr wrote:
I understand how to create a property like this:

class RC(object):
def _set_pwm(self, v):
self._pwm01 = v % 256
def _get_pwm(self):
return self._pwm01
pwm01 = property(_get_pwm, _set_pwm)
But what if I have a whole bunch of these pwm properties?

I made this:

class RC(object):
def _makeprop(name):
prop = '_%s' % name
def _set(self, v):
v_new = v % 256
setattr(self, prop, v_new)
def _get(self):
return getattr(self, prop)
return property(_get, _set)

pwm01 = _makeprop('pwm01')
pwm02 = _makeprop('pwm02')
Not too bad, except for having to repeat the name.

I would like to just have a list of pwm names and
have them all set up like that. It would be nice if
each one was set to a default value of 127 also....

Any thoughts?

Yes, what about this?

import sys

def defprop(name, default=127):
loc = sys._getframe(1).f_locals
prop = '_%s' % name
def _set(self, v):
v_new = v % 256
setattr(self, prop, v_new)
def _get(self):
return getattr(self, prop, default)
loc[name] = property(_get, _set)

class RC(object):
defprop('pwm01')
defprop('pwm02')

rc = RC()

print rc.pwm01 # 127
print rc.pwm02 # 127
rc.pwm02 = 1312
print rc.pwm02 # 32

This is a bit hackish, but I would prefer this over a metaclass
solution. since it does not add
any hidden magic to your class.
Why is this less hidden or magical than a metaclass ? I'd prefer the
following instead:

from itertools import chain, izip, repeat

def ByteProperties(*names, **defaulted_names):
def byte_property(name, default):
return property(lambda self: getattr(self, name, default),
lambda self,v: setattr(self, name, v%256))
def make_class(clsname, bases, dict):
for name,default in chain(izip(names, repeat(127)),
defaulted_names.iteritems()):
assert name not in dict # sanity check
dict[name] = byte_property('_'+name, default)
return type(clsname,bases,dict)
return make_class
class RC(object):
__metaclass__ = ByteProperties('pwm01', pwm02=64)

rc = RC()
print rc.pwm01, rc.pwm02 # 127 64
rc.pwm01 = 1312
print rc.pwm01, rc.pwm02 # 32 64
George

Oct 18 '06 #6
Carl Banks wrote:
Lee Harr wrote:
I understand how to create a property like this:

class RC(object):
def _set_pwm(self, v):
self._pwm01 = v % 256
def _get_pwm(self):
return self._pwm01
pwm01 = property(_get_pwm, _set_pwm)
But what if I have a whole bunch of these pwm properties?

I made this:

class RC(object):
def _makeprop(name):
prop = '_%s' % name
def _set(self, v):
v_new = v % 256
setattr(self, prop, v_new)
def _get(self):
return getattr(self, prop)
return property(_get, _set)

pwm01 = _makeprop('pwm01')
pwm02 = _makeprop('pwm02')
Not too bad, except for having to repeat the name.

I would like to just have a list of pwm names and
have them all set up like that. It would be nice if
each one was set to a default value of 127 also....

Any thoughts?


The metaclass solution. I use this idiom occasionally, whenever I want
to fiddle with the class dict before letting the type constructor at
it.

class mod256metatype(type):
def __new__(metatype,name,bases,clsdict):
for sym in clsdict.get('__mod256__',()):
prop = '_%s' % sym
def _set(self,v):
setattr(self,prop,v%256)
def _get(self):
return getattr(self,prop)
clsdict[sym] = property(_get,_set)
return type.__new__(metatype,name,bases,clsdict)

class RC(object):
__metaclass__ = mod256metatype
__mod256__ = ["pwm01","pwm02"]
There's a subtle common bug here: all _get and _set closures will refer
to the last property only. You have to remember to write "def
_set(self,v,prop=prop)" and similarly for _get to do the right thing.
By the way, I can't think of a case where the current behavior (i.e.
binding the last value only) is the desired one. Is this just an
implementation wart or am I missing something ?

George

Oct 18 '06 #7
George Sakkis wrote:
>
Why is this less hidden or magical than a metaclass ?
Because it does not use inheritance. It is not going to create
properties on subclasses without
you noticing it. Also, metaclasses are brittle: try to use them with
__slots__, or with non-standard
classes (i.e. extensions classes), or try to use multiple metaclasses.
I wrote a paper
about metaclasses abuses which should be published soon or later; you
can see the draft
here:
http://www.phyast.pitt.edu/~micheles...itializer.html

Michele Simionato

Oct 18 '06 #8
George Sakkis wrote:
>
from itertools import chain, izip, repeat

def ByteProperties(*names, **defaulted_names):
def byte_property(name, default):
return property(lambda self: getattr(self, name, default),
lambda self,v: setattr(self, name, v%256))
def make_class(clsname, bases, dict):
for name,default in chain(izip(names, repeat(127)),
defaulted_names.iteritems()):
assert name not in dict # sanity check
dict[name] = byte_property('_'+name, default)
return type(clsname,bases,dict)
return make_class
class RC(object):
__metaclass__ = ByteProperties('pwm01', pwm02=64)
Notice that you are NOT using a custom metaclass here, you are just
using the metaclass hook
and you will avoid all issues of custom metaclasses. This is exactly
the approach I advocate
in the paper I referred before, so I think your solution is pretty safe
in that respect. Still I
think in this particular problem avoiding the __metaclass__ at all is
possible and it should be
preferred, just for sake of simplicity, not of safety).

Michele Simionato

M

Oct 18 '06 #9

George Sakkis wrote:
Michele Simionato wrote:
import sys

def defprop(name, default=127):
loc = sys._getframe(1).f_locals
prop = '_%s' % name
def _set(self, v):
v_new = v % 256
setattr(self, prop, v_new)
def _get(self):
return getattr(self, prop, default)
loc[name] = property(_get, _set)

class RC(object):
defprop('pwm01')
defprop('pwm02')

rc = RC()

print rc.pwm01 # 127
print rc.pwm02 # 127
rc.pwm02 = 1312
print rc.pwm02 # 32

This is a bit hackish, but I would prefer this over a metaclass
solution. since it does not add
any hidden magic to your class.

Why is this less hidden or magical than a metaclass ?
Devil's Advocate: he did say "hidden magic TO YOUR CLASS".

If you use a (real) metaclass, then you have the icky feeling of a
class permanently tainted by the unclean metaclass (even though the
metaclass does nothing other than touch the class dict upon creation);
whereas if you use Michele Simionato's hack, the icky feeling of using
a stack frame object goes away after the property is created: you are
left with a clean untainted class.

Personally, the former doesn't make me feel icky at all.
Carl Banks

Oct 18 '06 #10
Carl Banks wrote:
Devil's Advocate: he did say "hidden magic TO YOUR CLASS".

If you use a (real) metaclass, then you have the icky feeling of a
class permanently tainted by the unclean metaclass (even though the
metaclass does nothing other than touch the class dict upon creation);
whereas if you use Michele Simionato's hack, the icky feeling of using
a stack frame object goes away after the property is created: you are
left with a clean untainted class.
Yep, exactly.
Personally, the former doesn't make me feel icky at all.
Please, do this experiment: take all classes defined in the Python
standard library and add
to them a custom do-nothing metaclass. See what happens.
Michele Simionato

Oct 18 '06 #11
George Sakkis wrote:
There's a subtle common bug here: all _get and _set closures will refer
to the last property only. You have to remember to write "def
_set(self,v,prop=prop)" and similarly for _get to do the right thing.
Sorry. My mistake.

By the way, I can't think of a case where the current behavior (i.e.
binding the last value only) is the desired one. Is this just an
implementation wart or am I missing something ?
def some_function(a):
def printvars():
print "DEBUG: %r,%r,%r" % (a,b,i)
for i in some_range():
b = something(i)
printvars()

If you fix the value of the closure at function definition time,
printvars() above doesn't work. One way or another, someone's going to
get surprised. Better to let it be the experts.
Carl

Oct 18 '06 #12

Michele Simionato wrote:
Carl Banks wrote:
Devil's Advocate: he did say "hidden magic TO YOUR CLASS".

If you use a (real) metaclass, then you have the icky feeling of a
class permanently tainted by the unclean metaclass (even though the
metaclass does nothing other than touch the class dict upon creation);
whereas if you use Michele Simionato's hack, the icky feeling of using
a stack frame object goes away after the property is created: you are
left with a clean untainted class.

Yep, exactly.
Personally, the former doesn't make me feel icky at all.

Please, do this experiment: take all classes defined in the Python
standard library and add
to them a custom do-nothing metaclass. See what happens.
Do you expect the result to be better or worse than if you applied
stack frame hacks to the whole library?

Come on, I don't think anyone's under the impression we're being
indiscriminate here.
Carl Banks

(BTW, most of the standard library still uses old-style classes.)

Oct 18 '06 #13
Carl Banks wrote:
Come on, I don't think anyone's under the impression we're being
indiscriminate here.
Ok, but I don't think that in the case at hand we should recommend a
metaclass
solution.

Michele Simionato

Oct 18 '06 #14
Michele Simionato wrote:
Carl Banks wrote:
Come on, I don't think anyone's under the impression we're being
indiscriminate here.

Ok, but I don't think that in the case at hand we should recommend a
metaclass
solution.
You sound as if you're avoiding metaclasses just for the sake of
avoiding them, which is just as bad as using them for the sake of using
them.

Here's how I see it: either it's ok to fiddle with the class dict, or
it isn't. If it's ok, then a metaclass is the way to do it. If it's
not ok to fiddle with the class dict, then he should be using
__setattr__, or creating properties longhand. Messing with frames is
not the answer for production code.

....

Just for the hell of it, I decided to accept your challenge to run the
standard library with a different metaclass applied to all new-style
classes. I ran the 2.4.3 regression test, replacing the builtin object
with a class that used the mod256metaclass I presented in this thread.
The results:

229 tests OK.
34 tests failed:
test___all__ test_asynchat test_cgi test_cookielib test_copy
test_copy_reg test_cpickle test_decimal test_descr test_descrtut
test_email test_email_codecs test_httplib test_imaplib
test_inspect test_logging test_mailbox test_mimetools
test_mimetypes test_minidom test_pickle test_pyclbr
test_robotparser test_sax test_sets test_socket test_socket_ssl
test_sundry test_timeout test_urllib test_urllib2 test_urllib2net
test_urllibnet test_xpickle

Not A-OK, but not exactly mass-pandemonium either. There were plenty
of modules used the the new base object and worked fine.

There were only two causes for failure:
1. A class attempting to use __weakref__ slot.
2. There were also a few metaclass conflicts.

IMO, neither of these failure modes argues against using a metaclass to
preprocess the class dict. The __weakref__ error is not applicable;
since it's an error to use it on any class with an instance dict. (In
fact, the metaclass wasn't even causing the error: the same error would
have occurred if I had replaced builtin object with an empty subclass
of itself, without the metaclass.)

The metaclass conflict would only occur in the present case only if
someone wanted to subclass it AND specify a different metaclass.
Arguing that metaclasses should be avoided just to guard against this
rare possibility is defensive to the extreme.

I did not uncover any kinds of subtle, unexpected behavior that can
occur when metaclasses do weird things. I know such things are
possible; how likely they are is another question. The tests I ran
didn't uncover any. So for now, the results of these tests don't seem
to support your point very well.

Carl
Appendix: Here's how I ran the test. I inserted the following code at
the top of Lib/test/regrtest.py, and
ran make test. I ran the tests on the Python 2.4.3 source tree, in
Linux.

=======================
import sys

class mod256metatype(type):
def __new__(metatype,name,bases,clsdict):
print >sys.__stdout__, \
"++++++++ Creating class %s of type mod256metatype" %
name
def makeprop(sym):
prop = '_%s' % sym
def _set(self,v):
setattr(self,prop,v%256)
def _get(self):
return getattr(self,prop)
return property(_get,_set)
for sym in clsdict.get('__mod256__',()):
clsdict[sym] = makeprop(sym)
return super(metatype
return type.__new__(metatype,name,bases,clsdict)

class _object:
__metaclass__ = mod256metatype

import __builtin__
__builtin__.object = _object
=======================

Oct 18 '06 #15
Michele Simionato wrote:
George Sakkis wrote:
>>Why is this less hidden or magical than a metaclass ?


Because it does not use inheritance. It is not going to create
properties on subclasses without
you noticing it. Also, metaclasses are brittle: try to use them with
__slots__, or with non-standard
classes (i.e. extensions classes), or try to use multiple metaclasses.
I wrote a paper
about metaclasses abuses which should be published soon or later; you
can see the draft
here:
http://www.phyast.pitt.edu/~micheles...itializer.html
I am in the midst of reading this paper, and, while I don't share your
level of expertise, I modestly share your opinion that solving problems
with dynamically generated classes unnecessarily complicates code. For
example, the problem of the OP could be solved easily with a dictionary
and two functions used to access the dictionary and then, if making a
class was truely necessary, including these functions as members of the
class. But the OP mentioned something about "properties" and all hell
broke loose.

However, I think that what you are saying about metaclasses being
brittle relates more to implementation than language. In theory, these
should be equivalent:

(1) class Bob(object): pass
(2) Bob = type('Bob', (), {})

And indeed a cursory inspection of the resulting classes show that they
are indistinguishable.

That they wouldn't be seems an implementation bug and perhaps that bug
should be fixed rather than promoting the avoidance of (2) because it
does not create classes that behave as number (1).

James
--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com/
Oct 18 '06 #16
Carl Banks wrote:
You sound as if you're avoiding metaclasses just for the sake of
avoiding them, which is just as bad as using them for the sake of using
them.
Do you realize that you are effectively saying "avoiding a complex
tool in favor of a simpler one is just as bad as avoing the simple tool
in favor of the complex one" ?
Here's how I see it: either it's ok to fiddle with the class dict, or
it isn't. If it's ok, then a metaclass is the way to do it. If it's
not ok to fiddle with the class dict, then he should be using
__setattr__, or creating properties longhand. Messing with frames is
not the answer for production code.
I agree that messing with frames is not nice (however I should notice
that
this is how Zope interfaces are implemented, and they have been in
production use for years) but I disagree with your point about the
class dict. You should use a custom metaclass *only if you want to
mess with the class dict of all subclasses at each derivation*: this is

rarely the case, and definitely was not requested for the OP problem.
>
Just for the hell of it, I decided to accept your challenge to run the
standard library with a different metaclass applied to all new-style
classes. I ran the 2.4.3 regression test, replacing the builtin object
with a class that used the mod256metaclass I presented in this thread.
The results:

229 tests OK.
34 tests failed:
test___all__ test_asynchat test_cgi test_cookielib test_copy
test_copy_reg test_cpickle test_decimal test_descr test_descrtut
test_email test_email_codecs test_httplib test_imaplib
test_inspect test_logging test_mailbox test_mimetools
test_mimetypes test_minidom test_pickle test_pyclbr
test_robotparser test_sax test_sets test_socket test_socket_ssl
test_sundry test_timeout test_urllib test_urllib2 test_urllib2net
test_urllibnet test_xpickle
34 tests failed, worse than I expected.
Not A-OK, but not exactly mass-pandemonium either. There were plenty
of modules used the the new base object and worked fine.

There were only two causes for failure:
1. A class attempting to use __weakref__ slot.
2. There were also a few metaclass conflicts.
Yes, this agree with my findings. I was curious to know if there were
additional issues.
IMO, neither of these failure modes argues against using a metaclass to
preprocess the class dict.
But they argue against using metaclasses in general, IMO! (or at least,
against using them for users that are not aware of all the potential
pittfalls).
The __weakref__ error is not applicable;
since it's an error to use it on any class with an instance dict. (In
fact, the metaclass wasn't even causing the error: the same error would
have occurred if I had replaced builtin object with an empty subclass
of itself, without the metaclass.)
Correct, this more of a problems of __slots__ that play havoc with
inheritance
than a problem of metaclasses.
The metaclass conflict would only occur in the present case only if
someone wanted to subclass it AND specify a different metaclass.
Arguing that metaclasses should be avoided just to guard against this
rare possibility is defensive to the extreme.
Not too extreme in my opinion. Real life example: I had a debugging
tool
using a custom metaclass, I tried to run it on Zope 2.7 classes and I
have got segmentation faults. In Zope 2.8 I get "only" metatype
conflicts, and to avoid that I had to rewrite the tool :-(
I did not uncover any kinds of subtle, unexpected behavior that can
occur when metaclasses do weird things. I know such things are
possible; how likely they are is another question. The tests I ran
didn't uncover any. So for now, the results of these tests don't seem
to support your point very well.
Well, this is a matter of opinion. In my opinion your tests support my
point pretty well, better than I expected ;)
>
Appendix: Here's how I ran the test. I inserted the following code at
the top of Lib/test/regrtest.py, and
ran make test. I ran the tests on the Python 2.4.3 source tree, in
Linux.

=======================
import sys

class mod256metatype(type):
def __new__(metatype,name,bases,clsdict):
print >sys.__stdout__, \
"++++++++ Creating class %s of type mod256metatype" %
name
def makeprop(sym):
prop = '_%s' % sym
def _set(self,v):
setattr(self,prop,v%256)
def _get(self):
return getattr(self,prop)
return property(_get,_set)
for sym in clsdict.get('__mod256__',()):
clsdict[sym] = makeprop(sym)
return super(metatype
return type.__new__(metatype,name,bases,clsdict)

class _object:
__metaclass__ = mod256metatype

import __builtin__
__builtin__.object = _object
=======================
I used a similar approach. I added in sitecustomize.py the following
lines:
import __builtin__

class chatty_creation(type):
"Print a message every time a class is created"
def __new__(mcl, name, bases, dic):
try:
cls = super(chatty_creation, mcl).__new__(mcl, name, bases,
dic)
except Exception, e:
print e
print 'Could not enhance class %s' % name
cls = type(name, tuple(b for b in bases if b is not
Object), dic)
# removing Object from the bases is enough only in the
trivial
# cases :-(
else:
print 'Creating class %s.%s' % (dic.get('__module__'),
name)
return cls

class Object:
__metaclass__ = chatty_creation

__builtin__.object = Object

Now it is impossible to run both Zope and Twisted due to metatype
conflicts.
I haven't looked in detail, but the first conflict in Twisted is due
to a metaclass-enhanced class which is setting properties. This is
the typical example of what I call metaclass *abuse* in my paper, since
the custom metaclass could have been avoided (for instance using George
Sakkis trick) and the conflict could have been avoided.

Now, I know how to solve the conflict
(http://aspn.activestate.com/ASPN/Coo.../Recipe/204197) but I
would rather avoid it altogether.

The problem with metaclasses is that you are adding magic to the
classes of
your USERS, and the users are known to play any kind of dirty tricks.
You
(speaking in general of you as the author of a framework) should strive
to keep things clean as much as possible.

I agree that the problems are rare: but just for this reason they are
prone to very subtle bugs, the hardest to find. And there is no
documentation of metaclass pittfall AFAIK :-(
Michele Simionato

Oct 19 '06 #17
James Stroud wrote:
However, I think that what you are saying about metaclasses being
brittle relates more to implementation than language. In theory, these
should be equivalent:

(1) class Bob(object): pass
(2) Bob = type('Bob', (), {})

And indeed a cursory inspection of the resulting classes show that they
are indistinguishable.

That they wouldn't be seems an implementation bug and perhaps that bug
should be fixed rather than promoting the avoidance of (2) because it
does not create classes that behave as number (1).
You got something wrong ;)

'type' is the builtin metaclass, it works, I have nothing against it,
and (1) and (2) are *exactly*
equivalent. My gripe is against *custom* metaclasses, i.e. subclasses
of 'type'. The paper is
all about avoiding custom metaclasses and using 'type' instead (i.e.
use the __metaclass__
hook, but not custom metaclasses). It is the same trick used by George
Sakkis in this same
thread.

Michele Simionato

Oct 19 '06 #18

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

7
by: Simon Edwards | last post by:
Something thats been bugging me for a while... how do you create a namespace that has many children (namespaces) I.e system.io.blah.blah ...
4
by: Altramagnus | last post by:
I have 30 - 40 type of different window. For each type I need about 20 instances of the window. When I try to create them, I get "Error creating...
0
by: Sergej Pioch | last post by:
Hello everybody, im trying hard to automate some tasks in a huge windows environment. This lend me to bigger problems while trying to create new...
1
by: Neil Robbins | last post by:
I have been wondering recently how I would go about creating a control that when selected from the toolbox for use in an application either autoran...
2
by: Terrance | last post by:
Can someone please help with a problem that I'm having? I'm trying to create a linklabel in VB.NET 2003 at runtime when a user clicks a button. The...
26
by: nyathancha | last post by:
Hi, How Do I create an instance of a derived class from an instance of a base class, essentially wrapping up an existing base class with some...
0
by: ronscottlangham | last post by:
I am working on a custom WCF EndpoingBehavior that will modify the messages coming in and out of my Service. I am having an error related to the...
1
by: MMAS | last post by:
I've seen a similar post about this problem but still cannot find an automated solution. Below is the code I'm using to create a website (for IIS...
2
by: adwest | last post by:
Forgive me if this is a foolish question. I "play" in Access and have only created a few rather simple relational databases. My knowledge and...
0
by: teenabhardwaj | last post by:
How would one discover a valid source for learning news, comfort, and help for engineering designs? Covering through piles of books takes a lot of...
0
by: Kemmylinns12 | last post by:
Blockchain technology has emerged as a transformative force in the business world, offering unprecedented opportunities for innovation and...
0
by: CD Tom | last post by:
This happens in runtime 2013 and 2016. When a report is run and then closed a toolbar shows up and the only way to get it to go away is to right...
0
by: Naresh1 | last post by:
What is WebLogic Admin Training? WebLogic Admin Training is a specialized program designed to equip individuals with the skills and knowledge...
0
jalbright99669
by: jalbright99669 | last post by:
Am having a bit of a time with URL Rewrite. I need to incorporate http to https redirect with a reverse proxy. I have the URL Rewrite rules made...
0
by: antdb | last post by:
Ⅰ. Advantage of AntDB: hyper-convergence + streaming processing engine In the overall architecture, a new "hyper-convergence" concept was...
0
by: Matthew3360 | last post by:
Hi there. I have been struggling to find out how to use a variable as my location in my header redirect function. Here is my code. ...
0
by: AndyPSV | last post by:
HOW CAN I CREATE AN AI with an .executable file that would suck all files in the folder and on my computerHOW CAN I CREATE AN AI with an .executable...
0
hi
by: WisdomUfot | last post by:
It's an interesting question you've got about how Gmail hides the HTTP referrer when a link in an email is clicked. While I don't have the specific...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.