I said:
My intent was to fix an obvious omission: a special case
was discussed in
the Augmented assignment statements section, but an
almost-identical
special case was omitted from the Assignment statements section.
After finally getting registered at bugs.python.org (as described
John Posner wrote:
[snip]
If the object is a class instance and the attribute reference
occurs
on both sides of the assignment operator; for example::
self.x = self.x + 1
... in the RHS expression, ``self.x`` is evaluated with
``getattr()``,
[snip]
If the object is a class instance and the attribute reference
occurs
on both sides of the assignment operator; for example::
self.x = self.x + 1
... in the RHS expression, ``self.x`` is evaluated with
``getattr()``, which can access either an
On Mon Mar 16 03:42:42, I said:
RTFM, in section Augmented assignment statements of python301.chm:
---
For targets which are attribute references, the initial value is retrieved
with a getattr() and the result is assigned with a setattr(). Notice that
the
two methods do not necessarily
John Posner wrote:
On Mon Mar 16 03:42:42, I said:
RTFM, in section Augmented assignment statements of python301.chm:
---
For targets which are attribute references, the initial value is retrieved
with a getattr() and the result is assigned with a setattr(). Notice that
the
two
In article mailman.1847.1237048379.11746.python-l...@python.org,
Maxim Khitrov mkhit...@gmail.com wrote:
Very simple question on the preferred coding style. I frequently write
classes that have some data members initialized to immutable values.
For example:
class Test(object):
def
John Posner wrote:
Matthew Woodcraft said:
I doubt it's because anyone particularly wanted this
behaviour; it just
falls out of the way '+=' is defined.
At the point where 'inst.x += 1' is compiled,
Python doesn't know
whether 'inst.x' is going to turn out to be a class
attribute or an
On Mar 15, 9:54 pm, Rhodri James rho...@wildebst.demon.co.uk
wrote:
On Sun, 15 Mar 2009 23:26:04 -, Aaron Brady castiro...@gmail.com
wrote:
On Mar 15, 1:50 pm, Rhodri James rho...@wildebst.demon.co.uk
wrote:
On Sun, 15 Mar 2009 17:55:25 -, Aaron Brady castiro...@gmail.com
On Mon, 16 Mar 2009 09:31:59 -, Aaron Brady castiro...@gmail.com
wrote:
[snippety snip]
Otherwise, either /1, every instance has its own entries for class
functions, and subsequent changes to the class don't affect existing
instances, or /2, every method call is of the form x.__class__.foo
Gary Herron gher...@islandtraining.com writes:
Gary Herron gher...@islandtraining.com wrote:
No, you are still misinterpreting your results. But you can be forgiven
because this is quite a subtle point about Python's attribute access.
Here's how it works:
On access, self.count (or
On Sun, 15 Mar 2009 13:26:17 -, Matthew Woodcraft
matt...@woodcraft.me.uk wrote:
[snip Gary Herron's explanation of instance attribute lookup
falling back to class attribute lookup]
It seems clear to me that Maxim understood all this when he asked his
original question (you need to
Rhodri James rho...@wildebst.demon.co.uk writes:
On Sun, 15 Mar 2009 13:26:17 -, Matthew Woodcraft
It seems clear to me that Maxim understood all this when he asked his
original question (you need to understand this subtlety to know why
the trick he was asking about only works for
On Sun, 15 Mar 2009 15:05:04 -, Matthew Woodcraft
matt...@woodcraft.me.uk wrote:
Rhodri James rho...@wildebst.demon.co.uk writes:
On Sun, 15 Mar 2009 13:26:17 -, Matthew Woodcraft
It seems clear to me that Maxim understood all this when he asked his
original question (you need to
Maxim Khitrov a écrit :
On Sat, Mar 14, 2009 at 2:07 PM, Gary Herron gher...@islandtraining.com wrote:
Maxim Khitrov wrote:
Very simple question on the preferred coding style. I frequently write
classes that have some data members initialized to immutable values.
For example:
class
On Mar 15, 8:56 am, Rhodri James rho...@wildebst.demon.co.uk
wrote:
On Sun, 15 Mar 2009 13:26:17 -, Matthew Woodcraft
matt...@woodcraft.me.uk wrote:
[snip Gary Herron's explanation of instance attribute lookup
falling back to class attribute lookup]
It seems clear to me that Maxim
Aaron Brady wrote:
[snip]
However, in my (opined) interpretation, 'list.append(...) is an in-
place operation' is a factual error. In-place operations -also-
rebind their 'argument' (FLOBW for lack of better words). 'append' is
a by-side-effect operation. However colloquially it's mostly
(My apologies if the thread has already covered this.) I believe I understand
the WHAT in this situation, but I don't understand the WHY ...
Given this class definition:
class Cls(object):
x = 345
... I observe the following, using IDLE 2.6.1:
inst = Cls()
Cls.x is inst.x
True
On Mar 15, 12:39 pm, John Posner jjpos...@snet.net wrote:
(My apologies if the thread has already covered this.) I believe I understand
the WHAT in this situation, but I don't understand the WHY ...
Given this class definition:
class Cls(object):
x = 345
... I observe the
On Sun, 15 Mar 2009 17:55:25 -, Aaron Brady castiro...@gmail.com
wrote:
On Mar 15, 12:39 pm, John Posner jjpos...@snet.net wrote:
(My apologies if the thread has already covered this.) I believe I
understand the WHAT in this situation, but I don't understand the WHY
...
[snip]
My
John Posner jjpos...@snet.net writes:
My question is ... WHY does the interpreter silently create the
instance attribute at this point, causing a surprising decoupling
from the class attribute? WHY doesn't the interpreter behave as it
would with a simple, non-instance variable:
python
Rhodri James a écrit :
On Sun, 15 Mar 2009 17:55:25 -, Aaron Brady castiro...@gmail.com
wrote:
On Mar 15, 12:39 pm, John Posner jjpos...@snet.net wrote:
(snip)
Is there a beneficial effect of silently creating the instance
attribute, which outweighs the detrimental effects: (1)
Rhodri James rho...@wildebst.demon.co.uk writes:
But do you, though? The only occasion I can think of that I'd want
the search to go past the instance is this auto-initialisation,
and frankly I'd rather do that in an __init__ anyway. Perhaps
static methods or class methods work that way, I
John Posner a écrit :
(My apologies if the thread has already covered this.) I believe I
understand the WHAT in this situation, but I don't understand the WHY
...
Given this class definition:
class Cls(object): x = 345
... I observe the following, using IDLE 2.6.1:
inst = Cls() Cls.x is
M R A Barnett p...@mrabarnett.plus.com wrote:
Aaron Brady wrote:
[snip]
However, in my (opined) interpretation, 'list.append(...) is an in-
place operation' is a factual error. In-place operations -also-
rebind their 'argument' (FLOBW for lack of better words). 'append' is
a
Matthew Woodcraft said:
I doubt it's because anyone particularly wanted this
behaviour; it just
falls out of the way '+=' is defined.
At the point where 'inst.x += 1' is compiled,
Python doesn't know
whether 'inst.x' is going to turn out to be a class
attribute or an
instance attribute
On Mar 15, 1:50 pm, Rhodri James rho...@wildebst.demon.co.uk
wrote:
On Sun, 15 Mar 2009 17:55:25 -, Aaron Brady castiro...@gmail.com
wrote:
On Mar 15, 12:39 pm, John Posner jjpos...@snet.net wrote:
(My apologies if the thread has already covered this.) I believe I
understand the
John Posner jjpos...@snet.net wrote:
Summary: I no longer suspect that Python is broken. I *do* think that
there's a situation that is potentially quite confusing:
* In the statement self.x = self.x + 1, the two self.x names can
sometimes refer to different objects.
But this is
Earlier, I said:
I'll look into what the standard Python doc set says on this
matter.
RTFM, in section Augmented assignment statements of python301.chm:
---
For targets which are attribute references, the initial value is retrieved with
a getattr() and the result is assigned with a
On Sun, 15 Mar 2009 23:26:04 -, Aaron Brady castiro...@gmail.com
wrote:
On Mar 15, 1:50 pm, Rhodri James rho...@wildebst.demon.co.uk
wrote:
On Sun, 15 Mar 2009 17:55:25 -, Aaron Brady castiro...@gmail.com
wrote:
On Mar 15, 12:39 pm, John Posner jjpos...@snet.net wrote:
(My
On Sun, 2009-03-15 at 10:39 -0700, John Posner wrote:
(My apologies if the thread has already covered this.) I believe I understand
the WHAT in this situation, but I don't understand the WHY ...
Is there a beneficial effect of silently creating the instance attribute,
which outweighs the
On Mon, 2009-03-16 at 04:02 +, Tim Wintle wrote:
On Sun, 2009-03-15 at 10:39 -0700, John Posner wrote:
Doh, reply out of thread there - I meant to reply to Rhodi's comment
further down.
Is there any actual advantage to self.attribute picking up
Class.attribute instead of raising a
John Posner wrote:
(My apologies if the thread has already covered this.) I believe I understand
the WHAT in this situation, but I don't understand the WHY ...
Given this class definition:
class Cls(object):
x = 345
... I observe the following, using IDLE 2.6.1:
inst = Cls()
Very simple question on the preferred coding style. I frequently write
classes that have some data members initialized to immutable values.
For example:
class Test(object):
def __init__(self):
self.some_value = 0
self.another_value = None
Similar effect can be achieved by
Maxim Khitrov wrote:
Very simple question on the preferred coding style. I frequently write
classes that have some data members initialized to immutable values.
For example:
class Test(object):
def __init__(self):
self.some_value = 0
self.another_value = None
Similar effect
On Sat, Mar 14, 2009 at 12:50 PM, MRAB goo...@mrabarnett.plus.com wrote:
Maxim Khitrov wrote:
Very simple question on the preferred coding style. I frequently write
classes that have some data members initialized to immutable values.
For example:
class Test(object):
def __init__(self):
Maxim Khitrov:
When the types are immutable, there is no difference.
But you may want different instances to have different immutable data.
Generally if the data (immutable or not) is the same for all the
instances, use class attributes, otherwise use instance attributes.
Bye,
bearophile
--
Maxim Khitrov wrote:
Very simple question on the preferred coding style. I frequently write
classes that have some data members initialized to immutable values.
For example:
class Test(object):
def __init__(self):
self.some_value = 0
self.another_value = None
Similar effect
Maxim Khitrov wrote:
On Sat, Mar 14, 2009 at 12:50 PM, MRAB goo...@mrabarnett.plus.com wrote:
Maxim Khitrov wrote:
Very simple question on the preferred coding style. I frequently write
classes that have some data members initialized to immutable values.
For example:
class Test(object):
On Sat, Mar 14, 2009 at 2:07 PM, Gary Herron gher...@islandtraining.com wrote:
Maxim Khitrov wrote:
Very simple question on the preferred coding style. I frequently write
classes that have some data members initialized to immutable values.
For example:
class Test(object):
def
On Sat, Mar 14, 2009 at 12:32 PM, Maxim Khitrov mkhit...@gmail.com wrote:
Very simple question on the preferred coding style. I frequently write
classes that have some data members initialized to immutable values.
For example:
class Test(object):
def __init__(self):
Maxim Khitrov wrote:
On Sat, Mar 14, 2009 at 2:07 PM, Gary Herron gher...@islandtraining.com wrote:
Maxim Khitrov wrote:
Very simple question on the preferred coding style. I frequently write
classes that have some data members initialized to immutable values.
For example:
class
Maxim Khitrov wrote:
Perhaps a different example would help explain what I'm trying to do:
class Case1(object):
def __init__(self):
self.count = 0
self.list = []
def inc(self):
self.count += 1
Gary Herron gher...@islandtraining.com writes:
But now you are not listening to what people are telling you. It has
*nothing* to do with the mutability/immutability of the integer and the list
your two classes create.
No! Did you run the code he posted? The immutability makes all the
On Sat, Mar 14, 2009 at 4:31 PM, Gary Herron gher...@islandtraining.com wrote:
Perhaps a different example would help explain what I'm trying to do:
class Case1(object):
def __init__(self):
self.count = 0
self.list = []
def inc(self):
On Sat, Mar 14, 2009 at 5:38 PM, Matthew Woodcraft
matt...@woodcraft.me.uk wrote:
Gary Herron gher...@islandtraining.com writes:
I think this code is in poor taste: it's clear that it will confuse
people (which is what Maxim was asking about in the first place).
Yes, I see that now, thanks :)
Hallöchen!
Maxim Khitrov writes:
[...]
The advantage of doing this is that the assignments are evaluated
once and thus the creation of that class is a bit faster. Access
is still performed through self.some_value and
self.another_value. Is there a reason to prefer the first style
over the
Maxim Khitrov wrote:
On Sat, Mar 14, 2009 at 4:31 PM, Gary Herron gher...@islandtraining.com wrote:
Perhaps a different example would help explain what I'm trying to do:
class Case1(object):
def __init__(self):
self.count = 0
self.list = []
def
Maxim Khitrov wrote:
On Sat, Mar 14, 2009 at 5:38 PM, Matthew Woodcraft
matt...@woodcraft.me.uk wrote:
Gary Herron gher...@islandtraining.com writes:
I think this code is in poor taste: it's clear that it will confuse
people (which is what Maxim was asking about in the first place).
48 matches
Mail list logo
