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.o
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
[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 ca
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
> t
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 necess
In article ,
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
On Mon, 16 Mar 2009 09:31:59 -, Aaron Brady
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
( ). They're both b
On Mar 15, 9:54 pm, "Rhodri James"
wrote:
> On Sun, 15 Mar 2009 23:26:04 -, Aaron Brady
> wrote:
>
>
>
>
>
> > On Mar 15, 1:50 pm, "Rhodri James"
> > wrote:
> >> On Sun, 15 Mar 2009 17:55:25 -, Aaron Brady
> >> wrote:
>
> >> > On Mar 15, 12:39 pm, John Posner wrote:
> >> >> (My apo
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
inst
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()
Cls.
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 NameEr
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 Sun, 15 Mar 2009 23:26:04 -, Aaron Brady
wrote:
On Mar 15, 1:50 pm, "Rhodri James"
wrote:
On Sun, 15 Mar 2009 17:55:25 -, Aaron Brady
wrote:
> On Mar 15, 12:39 pm, John Posner wrote:
>> (My apologies if the thread has already covered this.) I believe I
>> understand the WH
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 se
John Posner 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 fundamental to Py
On Mar 15, 1:50 pm, "Rhodri James"
wrote:
> On Sun, 15 Mar 2009 17:55:25 -, Aaron Brady
> wrote:
>
> > On Mar 15, 12:39 pm, 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 WH
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 a
M R A Barnett 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 by-side-effect operation.
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 inst
"Rhodri James" 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 don't know how
> the
Rhodri James a écrit :
On Sun, 15 Mar 2009 17:55:25 -, Aaron Brady
wrote:
On Mar 15, 12:39 pm, John Posner wrote:
(snip)
Is there a beneficial effect of silently creating the instance
attribute, which outweighs the detrimental effects: (1)
inconsistency, (2) the "surprising" decoupli
John Posner 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
> Python 2
On Sun, 15 Mar 2009 17:55:25 -, Aaron Brady
wrote:
On Mar 15, 12:39 pm, 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
...
[snip]
My question is ... WHY does the interprete
On Mar 15, 12:39 pm, 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
(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
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
accur
On Mar 15, 8:56 am, "Rhodri James"
wrote:
> On Sun, 15 Mar 2009 13:26:17 -, Matthew Woodcraft
>
> 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
> >
Maxim Khitrov a écrit :
On Sat, Mar 14, 2009 at 2:07 PM, Gary Herron 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):
On Sun, 15 Mar 2009 15:05:04 -, Matthew Woodcraft
wrote:
"Rhodri James" 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 h
"Rhodri James" 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 immutable values).
>
> It
On Sun, 15 Mar 2009 13:26:17 -, Matthew Woodcraft
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 understand this subtlety to k
Gary Herron writes:
> Gary Herron 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 self.anything) attempts to find "count" in
> the inst
Maxim Khitrov wrote:
On Sat, Mar 14, 2009 at 5:38 PM, Matthew Woodcraft
wrote:
Gary Herron 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).
Careful now -- I didn't write that. (Although I ag
Maxim Khitrov wrote:
On Sat, Mar 14, 2009 at 4:31 PM, Gary Herron 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):
s
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
> ov
On Sat, Mar 14, 2009 at 5:38 PM, Matthew Woodcraft
wrote:
> Gary Herron 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 :)
- Max
--
http://mail.python.org/mailman/listin
On Sat, Mar 14, 2009 at 4:31 PM, Gary Herron 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):
>> sel
Gary Herron 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
difference.
> The difference
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
self.list.append(sel
Maxim Khitrov wrote:
On Sat, Mar 14, 2009 at 2:07 PM, Gary Herron 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__(se
On Sat, Mar 14, 2009 at 12:32 PM, 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
>
On Sat, Mar 14, 2009 at 2:07 PM, Gary Herron 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 wrote:
On Sat, Mar 14, 2009 at 12:50 PM, MRAB 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):
se
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:
> 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
--
ht
On Sat, Mar 14, 2009 at 12:50 PM, MRAB 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):
>> se
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
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 defi
48 matches
Mail list logo
