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((Mammal,))
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 *
************************************************** *********** * 12 3784
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.
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
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((Mammal,)) 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 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((Mammal,)) 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
Michael Hudson <mw*@python.net> wrote in message news:<m3************@pc150.maths.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 ExtensionClasses 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
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((Mammal,)) > 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(name, 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 mi***************@poste.it (Michele Simionato) writes: Michael Hudson <mw*@python.net> wrote in message news:<m3************@pc150.maths.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 ExtensionClasses 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
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((Mammal,)) > 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(name, 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
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((Mammal,)) > 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(name, 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
Michael Hudson <mw*@python.net> wrote in message news:<m3************@pc150.maths.bris.ac.uk>... Michele Simionato wrote: 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 ExtensionClasses and replacing normal bases with C-coded ones?
You get an exception. Obviously. Did you actually read what I said?
Actually that paragraph was not aimed to you. It was just to
clarify to the OP why there could be issues when changing __bases__.
What could be addressed to you is the question "why make your life
so difficult and force yourself to think to all possible things that
can go wrong when you could just make __bases__ read-only and be done
with it?" ;) 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
Touche' ;)
Michael Hudson <mw*@python.net> writes: 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 :-)
I seem to recall that it was possible but Guido removed it at some point
because he felt it was not needed (I've occasionally found this restriction to
be a minor annoyance).
'as
On Fri, 18 Jun 2004 10:18:06 GMT, Michael Hudson <mw*@python.net>
wrote: 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((Mammal,)) >> > 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.
I have no desire to muck with things. The main challenge I face in
teaching Python to non-CIS engineering students, is separating the
useful, simple stuff from the unecessary complexities. Originally, I
had just a simple hierarchy of Animal classes, with each __init__
calling its parent, and a variable _count in each class to keep track
of the total number of instances. This was criticised on another
thread for being not "robust" and a terrible example to show students.
The alternatives offered included factory functions, metaclasses, weak
references, and other complexities, all of which I felt would distract
from the basic presentation, but did have some value in solving
particular problems. So I included them in the Advanced Topics
section. The example above is attempt to generate a class that
automatically includes some attributes like _count, and thus make the
creation of new animal classes more "robust".
The "mucking" is a result of trying to solve a simple problem using
what we already know (__bases__, __dict__, etc.), and avoiding the
introduction of metaclasses. The resulting error messages are
confusing, and in many cases incorrect. class Animal(object): pass class C: pass C.__bases__ = (Animal,)
TypeError: __bases__ items must be classes class C(object): pass C.__bases__ = (Animal,)
TypeError: __bases__ assignment: 'Animal' deallocator differs from
'object' class ClassicAnimal: pass C.__bases__ = (ClassicAnimal,)
TypeError: a new-style class can't have only classic bases C.__bases__
(<type 'object'>,) C.__bases__ = (object, Animal)
TypeError: Cannot create a consistent method resolution
order (MRO) for bases object, Animal C.__bases__ = (Animal,object)
TypeError: __bases__ assignment: 'Animal' deallocator differs from
'object' C.__bases__ = Animal
TypeError: can only assign tuple to C.__bases__, not type
Clarifying patches welcome :-)
I can't even begin to figure out the complexities of what leads to
these strange messagea, but I can provide some test cases like the
above. My general recommedation would be, if you are unsure that the
error message will be understood, provide a more general message and a
unique error number. Something like:
TypeError: Illegal __bases__ assignment: Err#32175
Then the user can either try something different, or search the docs
and comp.lang.python for something very specific. He won't waste time
when the message says "items must be classes" and they already are
classes.
>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(name, bases, nsdict)
Ugh!
Is there a better way to avoid spelling out the classname twice. I
worry about subtle errors that could result from simple typos like
BoaConstrictor = newAnimal('BoaConstritcor', bases, nsdict) 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.
Yes, I do mean metaclasses, and this is one of the few applications I
have found that make sense for non-experts. I've been back-and-forth
a couple of times on the question whether to include metaclasses in my
OOP chapter. Most experts say no. Alex Martelli seems to think this
is an over-reaction. His example in Nutshell is the best I've seen,
however, I just modified it to move his metaclass methods, __init__
and __repr__ to the parent class, MetaBunch, and it runs just fine
using normal inheritance rather than metaclassing. It also seems to
be more efficient in memory usage, although I can't verify that. I'm
just assuming that you get one copy of a method when you use
inheritance, and multiple copies when you put the method in 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
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 don't see how this avoids the need to define a temporary function at
the module level:
def bmr(t,p,r):
... some complex function of temperature, pulse, and respiration
BoaConstrictor =
newAnimal('BoaConstrictor',(Reptile,),temperature= 102, pulse=82,
repsiration=36, bmr=bmr)
del bmr
Compare this mess to:
class BoaConstrictor(Reptile):
temperature = 102
pulse = 82
respiration = 36
def bmr(t,p,r):
...
Reptile inherits from Animal, which has a metaclass providing all the
common class variables, like _count. All the data and methods unique
to BoaConstrictor are in a normal class definition, not cluttering 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(name, 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.
Then we need a note saying this in section 3.27 of the Library
Reference. Otherwise new code will continue to use these functions
instead of type().
-- Dave This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Eric Wilhelm |
last post by:
Hi,
By new-style classes, I'm referring to the changes which came into 2.2 as
a result of PEP 252 and 253. I discovered this problem when trying to
use the Perl Inline::Python module with a...
|
by: Tuure Laurinolli |
last post by:
Someone pasted the original version of the following code snippet on
#python today. I started investigating why the new-style class didn't
work as expected, and found that at least some instances...
|
by: Vaibhav |
last post by:
I recently heard about 'new-style classes'. I am very sorry if this
sounds like a newbie question, but what are they? I checked the Python
Manual but did not find anything conclusive. Could someone...
|
by: Kalle Anke |
last post by:
I'm confused by the concepts of old-style vs new-style classes, I've read
most of the documents I found about this but it doesn't "click". Probably
because I wasn't around before 2.2.
Anyway,...
|
by: ankit |
last post by:
Hello,
Please put some light on, What are new style classes and classic style
classes in python. The basic differences in them. And How can I decide
to choose one.
|
by: Jeff Rush |
last post by:
While I have a reasonable understanding of the differences in new-style versus
old-style classes, tonight while working a C extension module I realized I
don't know how to indicate which style my C...
|
by: momobear |
last post by:
hi, I am puzzled about how to determine whether an object is
initilized in one class, anyone could give me any instructions?
here is an example code:
class coffee:
def boil(self):
self.temp =...
|
by: stephenpas |
last post by:
We are trying to monkey-patch a third-party library that mixes new and
old-style classes with multiple inheritance. In so doing we have
uncovered some unexpected behaviour:
<quote>
class Foo:...
|
by: allendowney |
last post by:
Hi All,
I am working on a revised edition of How To Think Like a Computer
Scientist,
which is going to be called Think Python. It will be published by
Cambridge
University Press, but there...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |