Bug in New Style Classes

[David MacQuigg]

I have what looks like a bug trying to generate new style classes with
a factory function.

class Animal(object): pass
class Mammal(Animal): pass

def newAnimal(bases =(Animal,), dict={}):
class C(object): pass
C.__bases__ = bases
dict['_count'] = 0
C.__dict__ = dict
return C

Canine = newAnimal((Mamm al,))
TypeError: __bases__ assignment: 'Mammal' deallocator differs from
'object'

If I remove the 'object' from the class C(object) statement, then I
get a different, equally puzzling error message:

TypeError: __bases__ items must be classes

The function works only if I remove 'object' from all base classes.

-- Dave

*************** *************** *************** *************** * *
* David MacQuigg, PhD * email: dmq at gain.com * *
* IC Design Engineer * phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* * 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. * Tucson, Arizona 85710 *
*************** *************** *************** *************** * *

[Leif K-Brooks]

David MacQuigg wrote:

I have what looks like a bug trying to generate new style classes with
a factory function.

IIRC, you can't assign to __bases__ of a new-style class. But you can
use type() instead of your home-made factory function.

[Yermat]

Leif K-Brooks wrote:

David MacQuigg wrote:

I have what looks like a bug trying to generate new style classes with
a factory function.

IIRC, you can't assign to __bases__ of a new-style class. But you can
use type() instead of your home-made factory function.

Even better:
see http://www.python.org/doc/current/lib/module-new.html and especially
classobj !

--
Yermat

[Michele Simionato]

David MacQuigg <dm*@gain.com > wrote in message news:<rm******* *************** **********@4ax. com>...

I have what looks like a bug trying to generate new style classes with
a factory function.

class Animal(object): pass
class Mammal(Animal): pass

def newAnimal(bases =(Animal,), dict={}):
class C(object): pass
C.__bases__ = bases
dict['_count'] = 0
C.__dict__ = dict
return C

Canine = newAnimal((Mamm al,))
TypeError: __bases__ assignment: 'Mammal' deallocator differs from
'object'

If I remove the 'object' from the class C(object) statement, then I
get a different, equally puzzling error message:

TypeError: __bases__ items must be classes

The function works only if I remove 'object' from all base classes.

-- Dave

This is not a bug. The developers removed the possibility to change
the bases of a new-style class. Probably because it could not be done
reliably (I don't know). But I am happy my base classes cannot
change under my feet ;)

You can just create a new class with new bases if you wish.
Michele Simionato

[Michael Hudson]

mi************* **@poste.it (Michele Simionato) writes:

David MacQuigg <dm*@gain.com > wrote in message news:<rm******* *************** **********@4ax. com>...

I have what looks like a bug trying to generate new style classes with
a factory function.

class Animal(object): pass
class Mammal(Animal): pass

def newAnimal(bases =(Animal,), dict={}):
class C(object): pass
C.__bases__ = bases
dict['_count'] = 0
C.__dict__ = dict
return C

Canine = newAnimal((Mamm al,))
TypeError: __bases__ assignment: 'Mammal' deallocator differs from
'object'

If I remove the 'object' from the class C(object) statement, then I
get a different, equally puzzling error message:

TypeError: __bases__ items must be classes

The function works only if I remove 'object' from all base classes.

-- Dave

This is not a bug. The developers removed the possibility to change
the bases of a new-style class.

Bad news for you: I put it back in for 2.3.

If you read the error message, you'll notice that it's phrased to
suggest that assignment to __bases__ is *sometimes* possible :-)

David's assignment probably should work -- there's a bug on sf about
this -- but there are definitely situations where assignment to bases
*shouldn't* be allowed -- e.g. when the so-called 'solid base' changes
-- but noone's put in the thinking time to make this precise in code.
Being over-restrictive seems the better course.

However, newAnimal could be written like this:

def newAnimal(bases =(Animal,), ns=None):
if ns is None:
ns = {}
ns['_count'] = 0
return type('C', bases, ns)

which

a) doesn't use the name of a builtin as a variable
b) doesn't suffer the 'mutable default arguments' problem
c) is rather less insane
d) actually works :-) (probably, haven't tested it)

Cheers,
mwh

--
Academic politics is the most vicious and bitter form of politics,
because the stakes are so low. -- Wallace Sayre

[Michele Simionato]

Michael Hudson <mw*@python.net > wrote in message news:<m3******* *****@pc150.mat hs.bris.ac.uk>. ..

mi************* **@poste.it (Michele Simionato) writes:

This is not a bug. The developers removed the possibility to change
the bases of a new-style class.
Bad news for you: I put it back in for 2.3.

It is back!
If you read the error message, you'll notice that it's phrased to
suggest that assignment to __bases__ is *sometimes* possible :-)

David's assignment probably should work -- there's a bug on sf about
this -- but there are definitely situations where assignment to bases
*shouldn't* be allowed -- e.g. when the so-called 'solid base' changes
-- but noone's put in the thinking time to make this precise in code.
Being over-restrictive seems the better course.

Uhm, I can see that in certain cases it may work, both what if a class
has "object" as base and we change it to "type" ? What if we change
the base class from new style to old style? What if we change one of
the base classes with another one which is instance of a different
metaclass? How do you solve the conflicts? What about ExtensionClasse s and
replacing normal bases with C-coded ones? I see a recipe for disasters here,
so that's why I thought the developer removed the option of changing the bases.
That would be understable. What I do not understand is why I cannot
change the __name__ of a function, what could possible go wrong with that??
Michele

[David MacQuigg]

On Thu, 17 Jun 2004 11:05:58 GMT, Michael Hudson <mw*@python.net >
wrote:

mi************ ***@poste.it (Michele Simionato) writes:

David MacQuigg <dm*@gain.com > wrote in message news:<rm******* *************** **********@4ax. com>...

> I have what looks like a bug trying to generate new style classes with
> a factory function.
>
> class Animal(object): pass
> class Mammal(Animal): pass
>
> def newAnimal(bases =(Animal,), dict={}):
> class C(object): pass
> C.__bases__ = bases
> dict['_count'] = 0
> C.__dict__ = dict
> return C
>
> Canine = newAnimal((Mamm al,))
> TypeError: __bases__ assignment: 'Mammal' deallocator differs from
> 'object'
>
> If I remove the 'object' from the class C(object) statement, then I
> get a different, equally puzzling error message:
>
> TypeError: __bases__ items must be classes
>
> The function works only if I remove 'object' from all base classes.
>
> -- Dave
This is not a bug. The developers removed the possibility to change
the bases of a new-style class.

Bad news for you: I put it back in for 2.3.

If you read the error message, you'll notice that it's phrased to
suggest that assignment to __bases__ is *sometimes* possible :-)

David's assignment probably should work -- there's a bug on sf about
this -- but there are definitely situations where assignment to bases
*shouldn't* be allowed -- e.g. when the so-called 'solid base' changes
-- but noone's put in the thinking time to make this precise in code.
Being over-restrictive seems the better course.

This may be just a documentation problem then. The error message is
definitely misleading.
However, newAnimal could be written like this:

def newAnimal(bases =(Animal,), ns=None):
if ns is None:
ns = {}
ns['_count'] = 0
return type('C', bases, ns)

which

a) doesn't use the name of a builtin as a variable
b) doesn't suffer the 'mutable default arguments' problem
c) is rather less insane
d) actually works :-) (probably, haven't tested it)

It works great. The only thing I would change is the return line,
making that

globals()[name] = type('C', bases, ns)

so we don't have to type the name twice when creating a new class.
I've also added an __init__ function. Using the factory is now very
easy:

newAnimal('Dog' ,(Mammal,))
dog1 = Dog() Hello from __init__ in Dog Dog._count

1

The main limitation I see in using a factory function like this,
instead of a metaclass, is that I can't customize the new animal as
easily, because I don't have an indented block like in a class
definition. I've got to call the newAnimal function, then add a bunch
of attributes one at a time, with fully-qualified names.

Dog.temperature = 102
Dog.pulse = 82
Dog.respiration = 36

If I'm adding methods, it gets even messier, because I've got to
define functions at the module level, then assign them to attributes
of Dog, then maybe delete all the excess names from the module
namespace.

I have one last question. In reviewing all the ways to solve the
problem of creating specialized classes, I see there is a function
new.classobj(na me, bases, dict) which appears to do the same thing as
type(name, bases, dict). What is the purpose of classobj()? The name
is a little more self-explanatory than 'type', but using it requires a
module import.

- Dave

[Michael Hudson]

mi************* **@poste.it (Michele Simionato) writes:

Michael Hudson <mw*@python.net > wrote in message news:<m3******* *****@pc150.mat hs.bris.ac.uk>. ..

mi************* **@poste.it (Michele Simionato) writes:

This is not a bug. The developers removed the possibility to change
the bases of a new-style class.
Bad news for you: I put it back in for 2.3.

It is back!

If you read the error message, you'll notice that it's phrased to
suggest that assignment to __bases__ is *sometimes* possible :-)

David's assignment probably should work -- there's a bug on sf about
this -- but there are definitely situations where assignment to bases
*shouldn't* be allowed -- e.g. when the so-called 'solid base' changes
-- but noone's put in the thinking time to make this precise in code.
Being over-restrictive seems the better course.

Uhm, I can see that in certain cases it may work, both what if a
class has "object" as base and we change it to "type" ? What if we
change the base class from new style to old style? What if we change
one of the base classes with another one which is instance of a
different metaclass? How do you solve the conflicts? What about
ExtensionClasse s and replacing normal bases with C-coded ones?

You get an exception. Obviously. Did you actually read what I said?
I see a recipe for disasters here, so that's why I thought the
developer removed the option of changing the bases. That would be
understable. What I do not understand is why I cannot change the
__name__ of a function, what could possible go wrong with that??

Beats me too! Maybe it's because you haven't written a patch yet :-)

Cheers,
mwh

--
I think if we have the choice, I'd rather we didn't explicitly put
flaws in the reST syntax for the sole purpose of not insulting the
almighty. -- /will on the doc-sig

[Michael Hudson]

David MacQuigg <dm*@gain.com > writes:

On Thu, 17 Jun 2004 11:05:58 GMT, Michael Hudson <mw*@python.net >
wrote:

mi************ ***@poste.it (Michele Simionato) writes:

David MacQuigg <dm*@gain.com > wrote in message news:<rm******* *************** **********@4ax. com>...
> I have what looks like a bug trying to generate new style classes with
> a factory function.
>
> class Animal(object): pass
> class Mammal(Animal): pass
>
> def newAnimal(bases =(Animal,), dict={}):
> class C(object): pass
> C.__bases__ = bases
> dict['_count'] = 0
> C.__dict__ = dict
> return C
>
> Canine = newAnimal((Mamm al,))
> TypeError: __bases__ assignment: 'Mammal' deallocator differs from
> 'object'
>
> If I remove the 'object' from the class C(object) statement, then I
> get a different, equally puzzling error message:
>
> TypeError: __bases__ items must be classes
>
> The function works only if I remove 'object' from all base classes.
>
> -- Dave

This is not a bug. The developers removed the possibility to change
the bases of a new-style class.
Bad news for you: I put it back in for 2.3.

If you read the error message, you'll notice that it's phrased to
suggest that assignment to __bases__ is *sometimes* possible :-)

David's assignment probably should work -- there's a bug on sf about
this -- but there are definitely situations where assignment to bases
*shouldn't* be allowed -- e.g. when the so-called 'solid base' changes
-- but noone's put in the thinking time to make this precise in code.
Being over-restrictive seems the better course.

This may be just a documentation problem then. The error message is
definitely misleading.

Well, possibly. It's generally assumed that you know what you're
doing if you want to muck with things on this level.

Clarifying patches welcome :-)

However, newAnimal could be written like this:

def newAnimal(bases =(Animal,), ns=None):
if ns is None:
ns = {}
ns['_count'] = 0
return type('C', bases, ns)

which

a) doesn't use the name of a builtin as a variable
b) doesn't suffer the 'mutable default arguments' problem
c) is rather less insane
d) actually works :-) (probably, haven't tested it)

It works great. The only thing I would change is the return line,
making that

globals()[name] = type('C', bases, ns)

Ugh!
so we don't have to type the name twice when creating a new class.
I've also added an __init__ function. Using the factory is now very
easy:

newAnimal('Dog' ,(Mammal,))
dog1 = Dog() Hello from __init__ in Dog Dog._count

1

The main limitation I see in using a factory function like this,
instead of a metaclass,

^^^^^^^^^^^^^^^ ^^^^^^^
What a what? I _really_ don't think you mean metaclass here.
is that I can't customize the new animal as easily, because I don't
have an indented block like in a class definition. I've got to call
the newAnimal function, then add a bunch of attributes one at a
time, with fully-qualified names.

Dog.temperature = 102
Dog.pulse = 82
Dog.respiration = 36
Well, there are ways around that, too, eg:

def newAnimal(bases =(Animal,), **kw):
kw['_count'] = 0
return type('C', bases, kw)

Dog = newAnimal('Dog' , (Mammal,), temperature=102 , respiration=36)
If I'm adding methods, it gets even messier, because I've got to
define functions at the module level, then assign them to attributes
of Dog, then maybe delete all the excess names from the module
namespace.
Well, not necessarily. Use the third parameter to the call to type().
I have one last question. In reviewing all the ways to solve the
problem of creating specialized classes, I see there is a function
new.classobj(na me, bases, dict) which appears to do the same thing as
type(name, bases, dict).
new.classobj() is a holdover from the days of old-style classes,
though I see it creates new-style classes if passed new-style bases...
What is the purpose of classobj()? The name is a little more
self-explanatory than 'type', but using it requires a module import.

Historical cruft, more-or-less.

Cheers,
mwh

--
ARTHUR: Why should a rock hum?
FORD: Maybe it feels good about being a rock.
-- The Hitch-Hikers Guide to the Galaxy, Episode 8

[Michele Simionato]

David MacQuigg <dm*@gain.com > wrote in message news:<gi******* *************** **********@4ax. com>...

On Thu, 17 Jun 2004 11:05:58 GMT, Michael Hudson <mw*@python.net >
wrote:

mi************ ***@poste.it (Michele Simionato) writes:

David MacQuigg <dm*@gain.com > wrote in message news:<rm******* *************** **********@4ax. com>...
> I have what looks like a bug trying to generate new style classes with
> a factory function.
>
> class Animal(object): pass
> class Mammal(Animal): pass
>
> def newAnimal(bases =(Animal,), dict={}):
> class C(object): pass
> C.__bases__ = bases
> dict['_count'] = 0
> C.__dict__ = dict
> return C
>
> Canine = newAnimal((Mamm al,))
> TypeError: __bases__ assignment: 'Mammal' deallocator differs from
> 'object'
>
> If I remove the 'object' from the class C(object) statement, then I
> get a different, equally puzzling error message:
>
> TypeError: __bases__ items must be classes
>
> The function works only if I remove 'object' from all base classes.
>
> -- Dave

This is not a bug. The developers removed the possibility to change
the bases of a new-style class.

Bad news for you: I put it back in for 2.3.

If you read the error message, you'll notice that it's phrased to
suggest that assignment to __bases__ is *sometimes* possible :-)

David's assignment probably should work -- there's a bug on sf about
this -- but there are definitely situations where assignment to bases
*shouldn't* be allowed -- e.g. when the so-called 'solid base' changes
-- but noone's put in the thinking time to make this precise in code.
Being over-restrictive seems the better course.

This may be just a documentation problem then. The error message is
definitely misleading.

However, newAnimal could be written like this:

def newAnimal(bases =(Animal,), ns=None):
if ns is None:
ns = {}
ns['_count'] = 0
return type('C', bases, ns)

which

a) doesn't use the name of a builtin as a variable
b) doesn't suffer the 'mutable default arguments' problem
c) is rather less insane
d) actually works :-) (probably, haven't tested it)

It works great. The only thing I would change is the return line,
making that

globals()[name] = type('C', bases, ns)

so we don't have to type the name twice when creating a new class.
I've also added an __init__ function. Using the factory is now very
easy:

newAnimal('Dog' ,(Mammal,))
dog1 = Dog() Hello from __init__ in Dog Dog._count 1

The main limitation I see in using a factory function like this,
instead of a metaclass, is that I can't customize the new animal as
easily, because I don't have an indented block like in a class
definition. I've got to call the newAnimal function, then add a bunch
of attributes one at a time, with fully-qualified names.

Dog.temperature = 102
Dog.pulse = 82
Dog.respiration = 36

If I'm adding methods, it gets even messier, because I've got to
define functions at the module level, then assign them to attributes
of Dog, then maybe delete all the excess names from the module
namespace.

I have one last question. In reviewing all the ways to solve the
problem of creating specialized classes, I see there is a function
new.classobj(na me, bases, dict) which appears to do the same thing as
type(name, bases, dict). What is the purpose of classobj()? The name
is a little more self-explanatory than 'type', but using it requires a
module import.

- Dave

I heard somebody saying that the module 'new' will be deprecated
at some moment. new.classobj returns old-style classes:

import new
new.classobj("C ",(),{}) <class __main__.C at 0x403afd1c> type(_)

<type 'classobj'>

whereas type returns new style ones. You can create oldstyle classes
even without recurring to new.classobj.
Michele Simionato