run pylint over a bit of
> code and it complains that Foo is old-school, I make the obvious
> change to inherit from object. While I do this mostly to shut up
> pylint so I can focus on more serious messages, I must admit I have
> never experienced any problem changing from old-styl
over a bit of
> code and it complains that Foo is old-school, I make the obvious
> change to inherit from object. While I do this mostly to shut up
> pylint so I can focus on more serious messages, I must admit I have
> never experienced any problem changing from old-style to new-style
to inherit from object. While I do this mostly to shut up
pylint so I can focus on more serious messages, I must admit I have
never experienced any problem changing from old-style to new-style
classes. Under what circumstances might this be problematic?
Thx,
Skip
--
https://mail.python.org/mailman
On 6/20/2011 9:26 PM, John Salerno wrote:
I can't quite seem to find the answer to this anywhere. The book I'm
reading right now was written for Python 3.1 and doesn't use (object),
so I'm thinking that was just a way to force new-style classes in 2.x
and is no longer neces
John Salerno writes:
> I can't quite seem to find the answer to this anywhere. The book I'm
> reading right now was written for Python 3.1 and doesn't use (object),
> so I'm thinking that was just a way to force new-style classes in 2.x
> and is no longer necessar
7;m thinking that was just a way to force new-style classes in 2.x
> > and is no longer necessary in 3.x. Is that right?
>
> > (The documentation doesn't mention object anymore, but elsewhere on
> > the Python website it says the documentation hasn't been updated for
&
On Mon, Jun 20, 2011 at 6:26 PM, John Salerno wrote:
> I can't quite seem to find the answer to this anywhere. The book I'm
> reading right now was written for Python 3.1 and doesn't use (object),
> so I'm thinking that was just a way to force new-style classes in 2.x
I can't quite seem to find the answer to this anywhere. The book I'm
reading right now was written for Python 3.1 and doesn't use (object),
so I'm thinking that was just a way to force new-style classes in 2.x
and is no longer necessary in 3.x. Is that right?
(The documenta
mk a écrit :
class Person(object):
> ... pass
> ...
class Friendly(object):
> ... def hello(self):
> ... print 'hello'
> ...
Person.__bases__ += (Friendly,)
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: Cannot create a consistent
>>> class Person(object):
... pass
...
>>> class Friendly(object):
... def hello(self):
... print 'hello'
...
>>>
>>> Person.__bases__ += (Friendly,)
Traceback (most recent call last):
File "", line 1, in
TypeError: Cannot create a consistent method resolution
order (MRO) fo
Torsten Mohr wrote:
I just found an article that describes it better, this example works:
class C2(object):
def __new__(cls, a):
obj = object.__new__(cls)
print "new called"
obj.a = 8
return obj
__new__ = staticmethod(__new__)
Staticmethod isnt' requir
Hello,
> This way __new__ is not called, if i remove __init__ then
> there are too many parameters to __new__, if i add a parameter
> to __new__ then it says that __new__ does not take arguments.
I just found an article that describes it better, this example works:
class C2(object):
def __ne
Torsten Mohr wrote:
Hi,
i have some questions related to new style classes, they look
quite useful but i wonder if somebody can give me an example
on constructors using __new__ and on using __init__ ?
I just see that when using it i can't give parameters to __new__
and when i additio
Hi,
i have some questions related to new style classes, they look
quite useful but i wonder if somebody can give me an example
on constructors using __new__ and on using __init__ ?
I just see that when using it i can't give parameters to __new__
and when i additionally define __init__
samwyse a écrit :
On Jul 8, 4:56 pm, Joseph Barillari <[EMAIL PROTECTED]> wrote:
My question is: did something about the way the special method names are
implemented change for new-style classes?
Just off the top of my head, I'd guess that it's due to classes
already
On Tue, 08 Jul 2008 17:56:45 -0400, Joseph Barillari wrote:
> Hi python-list,
>
> I've just started using new-style classes and am a bit confused as to
> why I can't seem to alter methods with special names (__call__, etc.) of
> new-style class instances.
[deploy weapo
samwyse wrote:
On Jul 8, 4:56 pm, Joseph Barillari <[EMAIL PROTECTED]> wrote:
My question is: did something about the way the special method names are
implemented change for new-style classes?
I believe the difference is that for new-style classes, when special
methods are called &
On Jul 8, 4:56 pm, Joseph Barillari <[EMAIL PROTECTED]> wrote:
> My question is: did something about the way the special method names are
> implemented change for new-style classes?
Just off the top of my head, I'd guess that it's due to classes
already having a default
>
> My question is: did something about the way the special method names are
> implemented change for new-style classes?
>
>>> class old:
pass
>>> class new(object):
pass
>>> testone = old()
>>> testone.__call__ = lambda : 33
Hi python-list,
I've just started using new-style classes and am a bit confused as to
why I can't seem to alter methods with special names
(__call__, etc.) of new-style class instances. In other words, I
can do this:
>>> class Z:
... pass
...
>>> z = Z()
>&g
On Jul 3, 3:11 pm, Bruno Desthuilliers wrote:
> Quek a écrit :
>
> > Hi all,
>
> > I'm reallynewto Python and I've been reading up some texts on older
> > versions of Python (2.2 to be specific).
>
> > The text briefly mentionednewstyleand classic classes.
>
> > I'd really like to know in the curr
cases of multi-inheritance, where would I use new style
classes?
Everywhere you don't have to support compat with ages-old versions of
Python. MI is not the main point of newstyle classes (FWIW, you can do
MI with old-style classes too), they have quite a lot more to offer.
Consider "cla
Quek <[EMAIL PROTECTED]> writes:
> I'd really like to know in the current context of Python 2.5,
> besides in the cases of multi-inheritance, where would I use new
> style classes? Is it a norm to use more new style classes even if I
> don't have multi-inheritance
he cases of multi-inheritance, where would I use new style
> classes? Is it a norm to use more new style classes even if I don't
> have multi-inheritance in the industry, open source projects, etc
> today?
>
> If this isn't the right place to ask these questions, could some one
, where would I use new style
classes? Is it a norm to use more new style classes even if I don't
have multi-inheritance in the industry, open source projects, etc
today?
If this isn't the right place to ask these questions, could some one
point me somewhere more appropriat
Alan Isaac <[EMAIL PROTECTED]> writes:
I take it from this thread that in Python 3 the following are
equivalent:
class Test: pass
class Test(object): pass
Arnaud Delobelle wrote:
I don't know where it is stated, but how could they *not* be
equivalent?
The most obvious wa
In article <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>
>Anyway, I am posting to ask about the current status of new style
>classes. I am planning to present only one style in the book, because
>the differences between them don't matter for anything I am doin
"Eduardo O. Padoan" <[EMAIL PROTECTED]> writes:
> On Thu, May 29, 2008 at 3:06 PM, Jason <[EMAIL PROTECTED]> wrote:
>> I've got Python 3.0 alpha 2. In this version, it looks like you can
>> define classes in either the old style or new style. (I snipped the
>> top line a bit in the following exa
On Thu, May 29, 2008 at 3:06 PM, Jason <[EMAIL PROTECTED]> wrote:
> I've got Python 3.0 alpha 2. In this version, it looks like you can
> define classes in either the old style or new style. (I snipped the
> top line a bit in the following example):
Wrong. Py3k Classes are always new-style. They
version at thinkpython.com; I am revising now,
so
I welcome all comments, suggestions, corrections, etc.
Anyway, I am posting to ask about the current status of new style
classes.
I am planning to present only one style in the book, because the
differences
between them don't matter for anything
On May 29, 6:07 pm, [EMAIL PROTECTED] wrote:
> The current edition of the book presents old style classes. I am
> considering
> switching to new style classes on the assumption that this should be
> the default
> choice for new programs. The drawback is that a lot of the online
On May 29, 12:07 pm, [EMAIL PROTECTED] wrote:
> The current edition of the book presents old style classes. I am
> considering
> switching to new style classes on the assumption that this should be
> the default
> choice for new programs. The drawback is that a lot of the online
ass
>
>
>
> Is that correct, and if so, where is it stated explicitly?
>
> (I know about the "all classes are new style classes" statement.)
>
All classes are new style classes, and the usual
class MyClass(object) pass
should be replaced by the first
class MyClass: pass
where is it stated explicitly?
> (I know about the "all classes are new style classes" statement.)
I don't know where it is stated, but how could they *not* be
equivalent?
> 2. I take it from this thread that in Python 2.2+ if I put the
> following at the top of a module
This thread raises two questions for me.
1. I take it from this thread that in Python 3 the
following are equivalent:
class Test: pass
class Test(object): pass
Is that correct, and if so, where is it stated explicitly?
(I know about the "all classes are new
Cambridge
>> University Press, but there will still be a free version under the GNU
>> FDL.
>>
>> You can see the latest version at thinkpython.com; I am revising now,
>> so
>> I welcome all comments, suggestions, corrections, etc.
>>
>> Anyway, I am
n under the GNU
> FDL.
>
> You can see the latest version at thinkpython.com; I am revising now,
> so
> I welcome all comments, suggestions, corrections, etc.
>
> Anyway, I am posting to ask about the current status of new style
> classes.
> I am planning to present only
ill still be a free version under the GNU
> FDL.
>
> You can see the latest version at thinkpython.com; I am revising now,
> so
> I welcome all comments, suggestions, corrections, etc.
>
> Anyway, I am posting to ask about the current status of new style
> classes.
> I am p
Hi,
New style classes should be put as the default. This is what I did, based on
the principle that new classes were introduces in Python 2.2 and that we are
now at 2.5 and soon 2.6.
Tutorials that use old style classes may be old and perhaps won't be updated
ever. That's not a problem.
revising now,
so
I welcome all comments, suggestions, corrections, etc.
Anyway, I am posting to ask about the current status of new style
classes.
I am planning to present only one style in the book, because the
differences
between them don't matter for anything I am doing in the book.
The cu
"David Coffin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Is it possible to add an attribute to a new style class where the name of
| that attribute is determined at runtime?
>>> class C(object): pass
>>> setattr(C,'a',1)
>>> C.a
1
And hasattr, getattr work also.
--
htt
Is it possible to add an attribute to a new style class where the name of
that attribute is determined at runtime? In other words, is there an new
style class alternative to adding items to a classes __dict__ ?
Thanks.
--
http://mail.python.org/mailman/listinfo/python-list
On Wed, 12 Sep 2007 14:28:15 +, agupta0318 wrote:
> I am trying unsuccessfully to remove some methods from an instance,
> based on values passed in to the constructor as in the following
> example:
[snip]
>>> class C(object):
... def method(self):
... return "method exists"
On Sep 12, 4:28 pm, [EMAIL PROTECTED] wrote:
> I am trying unsuccessfully to remove some methods from an instance,
Usuall one does not remove methods, but wraps the object and delegates
only to
a restricted number of methods. Is this solution viable? If not, you
may be
forced to change the class o
[EMAIL PROTECTED] writes:
> I am trying unsuccessfully to remove some methods from an instance,
You can't remove the method from an instance because the method is
stored in its class.
> With the older python classes I could have done:
> self.__class__.__dict__[''test1"] to achieve the desire
I am trying unsuccessfully to remove some methods from an instance,
based on values passed in to the constructor as in the following
example:
#===
class A(object):
def __init__(self, id):
self._id = id
Whats the point of object? How do I actually use it. I'm not understanding
correctly from the python site located:
http://www.python.org/download/releases/2.2.3/descrintro/
class C(object):
def __init__(self):
self.__x = 0
def getx(self):
return self.__x
def setx(s
Raj B wrote:
> > Yes, special methods populate the slots in the structures which Python
> > uses to represent types. Objects/typeobject.c in the Python source
> > distribution does the hard work, particularly in function type_new
>
>
>
> Thanks for that quick response. I am quite comfortable
Raj B <[EMAIL PROTECTED]> wrote:
> > Yes, special methods populate the slots in the structures which
> Python
> > uses to represent types. Objects/typeobject.c in the Python source
> > distribution does the hard work, particularly in function type_new
>
>
>
> Thanks for that quick respons
> Yes, special methods populate the slots in the structures which
Python
> uses to represent types. Objects/typeobject.c in the Python source
> distribution does the hard work, particularly in function type_new
Thanks for that quick response. I am quite comfortable with C code
and am try
Raj B <[EMAIL PROTECTED]> wrote:
> Hi
>
> My question is about how special methods are stored internally in
> Python objects.
> Consider a new-style class which implements special methods such as
> __call__ and __new__
>
> class C(type):
> def __call__(...):
>
>
> class
Hi
My question is about how special methods are stored internally in
Python objects.
Consider a new-style class which implements special methods such as
__call__ and __new__
class C(type):
def __call__(...):
class B:
__metaclass__ = C
b= B()
The ty
, everything will be new-style classes. In Python 2.X, it
is extremely unlikely that anything will be upgraded to a new-style
class. That would raise a number of backwards incompatibilities with
relatively little benefit.
STeVe
--
http://mail.python.org/mailman/listinfo/python-list
Gabriel Genellina wrote:
> En Mon, 19 Feb 2007 22:30:59 -0300, GiBo <[EMAIL PROTECTED]> escribió:
>
>> Is there a reason why some classes distributed with Python 2.5 are not
>> new-style classes? For instance StringIO is apparently "old-style" class
>>
En Mon, 19 Feb 2007 22:30:59 -0300, GiBo <[EMAIL PROTECTED]> escribió:
> Is there a reason why some classes distributed with Python 2.5 are not
> new-style classes? For instance StringIO is apparently "old-style" class
> i.e. not inherited from "object". Can I s
son why some classes distributed with Python 2.5 are not
new-style classes? For instance StringIO is apparently "old-style" class
i.e. not inherited from "object". Can I somehow turn an existing
old-style class to a new-style one? I tried for example:
class MyStreamIO(Stre
On Sun, 31 Dec 2006 03:57:04 -0800, Isaac Rodriguez wrote:
> Hi,
>
> This is probably a very basic question, but I've been playing with new
> style classes, and I cannot see any difference in behavior when a
> declare a class as:
>
> class NewStyleClass(object):
>
On 31 Dec 2006 03:57:04 -0800, Isaac Rodriguez
<[EMAIL PROTECTED]> wrote:
> I am using Python 2.4, and I was wondering if by default, all
> classes are assumed to be derived from "object".
This won't tell you advantages or disadvantages, but will show you
that the default still is the old-style:
ctionality" seems to work
the same at first glance (i.e. you don't need to learn alot of new
syntax in order to switch from old-style to new-style classes).
Play around with things like dir() and type() on old-style and new-style
classes, and you will soon see differences.
> If not, ca
Isaac Rodriguez wrote:
> This is probably a very basic question, but I've been playing with
> new style classes, and I cannot see any difference in behavior
> when a declare a class as:
>
> class NewStyleClass(object):
>
> or
>
> class NewStyleClass:
Try mu
Hi,
This is probably a very basic question, but I've been playing with new
style classes, and I cannot see any difference in behavior when a
declare a class as:
class NewStyleClass(object):
or
class NewStyleClass:
I declare property members in both and it seems to work the exact same
w
;
> >> reg = []
> >>> def __metaclass__(name, bases, dict):
> ... reg.append(name)
> ...
> >>> class A: pass
> ...
> >>> reg
> ['A']
> >>> A is None
> True # oops!
>
> > This would correctly print [ 'c1
reg.append(name)
...
>>> class A: pass
...
>>> reg
['A']
>>> A is None
True # oops!
> This would correctly print [ 'c1', 'c2' ]. Now I would like to switch
> to new style classes but replacing class c1: and class c2: by class
> c1(obj
reg.append( name )
> return _meta
>
> reg = [ ]
> __metaclass__ = meta( reg )
>
> class c1:
> pass
>
> class c2:
> pass
>
> print reg
>
> This would correctly print [ 'c1', 'c2' ]. Now I would like to switch
> to
:
pass
print reg
This would correctly print [ 'c1', 'c2' ]. Now I would like to switch
to new style classes but replacing class c1: and class c2: by class
c1(object): and class c2(object): doesn't work because the metaclass
associated with object will be called and
will be in the wrong hash bucket).
>
> now, with new style classes, the class will have __hash__, whatever i
> do. (well, i assume i could play with __getattribute__...).
There is a proposal to fix this, though I don't think we'll see it for
a while.
class CantHash(object):
hat a key's hash value is immutable
(if the object's hash value changes, it will be in the wrong hash bucket).
====
now, with new style classes, the class will have __hash__, whatever i
do. (well, i assume i could play with __getattribute__...).
so is that part of the documentation
Peter Maas schrieb:
> 1 runs of nbody.py, time in sec
Correction: 1 iterations of advance().
--
Regards/Gruesse,
Peter Maas, Aachen
E-mail 'cGV0ZXIubWFhc0B1dGlsb2cuZGU=\n'.decode('base64')
--
http://mail.python.org/mailman/listinfo/python-list
Richard Jones wrote:
> Giovanni Bajo wrote:
[...]
>> Anyway, this is a bug on its own I believe. I don't think new-style
>> classes are meant to be 25% slower than old-style classes. Can any guru
>> clarify this?
>
> Please try 2.5 - there's been signific
Ah yes. Years ago when I first saw this test it was still using new-style
> classes.
>
> Anyway, this is a bug on its own I believe. I don't think new-style
> classes are meant to be 25% slower than old-style classes. Can any guru
> clarify this?
Please try 2.5 - there'
using new-style
classes.
Anyway, this is a bug on its own I believe. I don't think new-style classes are
meant to be 25% slower than old-style classes. Can any guru clarify this?
--
Giovanni Bajo
--
http://mail.python.org/mailman/listinfo/python-list
The metaclass approach seems to be the one I was looking for. Thanks!
Bert
--
http://mail.python.org/mailman/listinfo/python-list
Ben Cartwright wrote:
> [EMAIL PROTECTED] wrote:
> > Hey, I have the following code that has to send every command it
> > receives to a list of backends.
>
> > I would like to write each method like:
> >
> > flush = multimethod()
>
> Here's one way, using a metaclass:
Or if you don't mind a
[EMAIL PROTECTED] wrote:
> Hey, I have the following code that has to send every command it
> receives to a list of backends.
> I would like to write each method like:
>
> flush = multimethod()
Here's one way, using a metaclass:
class multimethod(object):
def transform(self, attr):
Scott David Daniels wrote:
>
> class Forwards(object):
>
> to_forward = set(['flush', 'read', 'write', 'close'])
>
> def __init__(self, backends):
> self.backends = backends
>
> def forwarder(self, methodname):
> def method(*args, **kwargs):
> for b in se
[EMAIL PROTECTED] wrote:
> Hey, I want to send commands to a list of backends:
How about something like:
class Forwards(object):
to_forward = set(['flush', 'read', 'write', 'close'])
def __init__(self, backends):
self.backends = backends
def forwarder(self, methodname)
self, backends):
> self.backends = backends
>
> def flush(self):
> for b in self.backends:
> b.flush()
>
> def draw(self):
> for b in self.backends:
> b.draw()
>
>
> I would like to write each method like:
>
for b in self.backends:
b.flush()
def draw(self):
for b in self.backends:
b.draw()
I would like to write each method like:
flush = multimethod()
Is that possible using new-style classes?
Bert
--
http://mail.python.org/mailman/listinfo/python-list
Michael Spencer wrote:
> >>> class A(object):
> ...
> >>> b = object.__new__(A)
Note that you'll need to be a bit cleverer if the
class might be derived from some other built-in
type:
>>> class A(list):
... pass
...
>>> b = object.__new__(A)
Traceback (most recent call last):
File "", li
gt; code (ignoring, for now, malicious code involving attribute access) as
> > shown below.
> >
[snip my example]
> >
> > I'm not sure how to do the same for new-style classes, if it's at all
> > possible to do from within Python. Is there any way to accompl
quot;
> ...
>>>> f = Foo('spam','eggs','ham','bacon') # This would be in a restricted
>>>> environment, though.
> Your code didn't expect the Spanish inquisition!
>>>> types.InstanceType(Foo, f.__dict__) # Thi
thout touching the actual old-style class code, but I'm not
sure how, if it's possible, to do the same with new-style classes
- Devan
--
http://mail.python.org/mailman/listinfo/python-list
"Devan L" <[EMAIL PROTECTED]> writes:
> Is there any safe way to create an instance of an untrusted class
Why are you instantiating classes you don't trust?
> without consulting the class in any way?
If you don't "consult the class", how can the instance be created
properly?
--
\ "It's
#x27;ham','bacon') # This would be in a restricted
>>> environment, though.
Your code didn't expect the Spanish inquisition!
>>> types.InstanceType(Foo, f.__dict__) # This wouldn't, but we never run that
>>> code, anyways.
<__main__.Foo ins
Ben Finney <[EMAIL PROTECTED]> wrote:
> "Panos Laganakos" <[EMAIL PROTECTED]> writes:
>
> > Is there a way to have a whole module package use the new-style
> > classes, without having to specify it per module-file or even worse,
> > per class defi
"Panos Laganakos" <[EMAIL PROTECTED]> writes:
> Is there a way to have a whole module package use the new-style
> classes, without having to specify it per module-file or even worse,
> per class definition?
TTBOMK, you do that with a single statement per module, bef
Is there a way to have a whole module package use the new-style
classes, without having to specify it per module-file or even worse,
per class definition?
Maybe by declaring the __metaclass__ in the module's __init__.py?
--
http://mail.python.org/mailman/listinfo/python-list
Thomas Girod wrote:
> It's alright I found where my mistake came from. I was misunderstanding
> the meaning of "classmethod", thinking of it as an instance method.
Given that 'instance methods' being most of the time attributes of the
class object, such a confusion is not so surprising !-)
--
br
Thomas Girod wrote:
> Or maybe I'm mixing up what we call a "classmethod" with what we could
> call an "instance method" ?
>
That's what I was about to point out !-)
> class Data(list):
> __slots__ = ["width", "height", "label"]
>
> def __init__(self,width,height,label=None):
> l
It's alright I found where my mistake came from. I was misunderstanding
the meaning of "classmethod", thinking of it as an instance method.
--
http://mail.python.org/mailman/listinfo/python-list
On 2006-04-13, Thomas Girod <[EMAIL PROTECTED]> wrote:
> Hi there.
>
> I'm trying to use new-style classes, but there is something i'm
> obviously missing
>
> here it is :
>
> class Data(list):
> __slots__ = ["width", "height&qu
"Thomas Girod" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi there.
>
> I'm trying to use new-style classes, but there is something i'm
> obviously missing
>
> here it is :
>
> class Data(list):
> __slots__ = ["
Or maybe I'm mixing up what we call a "classmethod" with what we could
call an "instance method" ?
--
http://mail.python.org/mailman/listinfo/python-list
Hi there.
I'm trying to use new-style classes, but there is something i'm
obviously missing
here it is :
class Data(list):
__slots__ = ["width", "height", "label"]
def __init__(self,width,height,label=None):
list.__init__(self)
Hi,
I have a fairly sizable body of python code that I'm in the process of
modernizing.
One of the modernization steps is converting to use new-style classes,
and this is leading to problems with pickle. What's happening is that
part of the test suite for this code includes pickled in
L.C. Rees wrote:
> Can custom __setattr__ methods and properties be mixed in new style
> classes?
>
> I experimented with a new style class with both a custom __setattr__
> method and a property. Attributes controlled by the __setattr__ method
> work fine. When I attempt
"L.C. Rees" wrote:
> This is the code for the property at the end of the class definition:
>
> def _settext(self, txt):
> self._tree.text = txt
>
> def _gettext(self, txt):
> return self._tree.text
>
> def _deltext(self, txt):
> self._tree.text = ''
>
> text
I see the error: the get and set properties are inverted. Now it works.
--
http://mail.python.org/mailman/listinfo/python-list
Can custom __setattr__ methods and properties be mixed in new style
classes?
I experimented with a new style class with both a custom __setattr__
method and a property. Attributes controlled by the __setattr__ method
work fine. When I attempt to set or get the property it raises the
error
On Fri, 30 Dec 2005 13:23:30 +, Jon Guyer wrote:
> Steven D'Aprano REMOVETHIScyber.com.au> writes:
>
>>
>> On Fri, 30 Dec 2005 03:47:30 +, Jon Guyer wrote:
>>
>> > We have a rather complicated class that, under certain circumstances, knows
>> > that it cannot perform various arithmetic
1 - 100 of 166 matches
Mail list logo
