Re: Class Variable Access and Assignment

Op 2005-11-08, Magnus Lycka schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: >> Fine that goes both ways. I don't mind not being taken serious by people >> I have trouble taking serious my self. No doubt that goes for you too. > > You know Antoon, these internet communities aren't really like >

Re: Class Variable Access and Assignment

Antoon Pardon wrote: > Fine that goes both ways. I don't mind not being taken serious by people > I have trouble taking serious my self. No doubt that goes for you too. You know Antoon, these internet communities aren't really like Speaker Corner in Hyde Park. You earn respect based on your merits

Re: Class Variable Access and Assignment

Op 2005-11-07, Christopher Subich schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: >> Op 2005-11-04, Christopher Subich schreef <[EMAIL PROTECTED]>: >>>it's the Python >>>idiosyncracy about operations on mutable types. In this case, += >>>mutates an object, while + returns a new one -- as by

Re: Class Variable Access and Assignment

Antoon Pardon wrote: > Op 2005-11-04, Christopher Subich schreef <[EMAIL PROTECTED]>: >>it's the Python >>idiosyncracy about operations on mutable types. In this case, += >>mutates an object, while + returns a new one -- as by definition, for >>mutables. > > > It is the combination of the two

Re: Class Variable Access and Assignment

On 7 Nov 2005 08:38:49 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote: >Op 2005-11-04, Magnus Lycka schreef <[EMAIL PROTECTED]>: >> [...] >> Sure, Python has evolved and grown for about 15 years, and >> backward compatibility has always been an issue, but the >> management and development of Python

Re: Class Variable Access and Assignment

On Mon, 07 Nov 2005 12:05:40 +0100, Magnus Lycka <[EMAIL PROTECTED]> wrote: >First of all, I've still not heard any sensible suggestions >about a saner behaviour for augmented assignment or for the >way Python searches the class scope after the instance scope. A nit, but a sizeable one: For new-st

Re: Class Variable Access and Assignment

Op 2005-11-07, Steve Holden schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: >> Op 2005-11-05, Steven D'Aprano schreef <[EMAIL PROTECTED]>: >> >>>On Fri, 04 Nov 2005 12:10:11 +, Antoon Pardon wrote: >>> >>> >There are good usage cases for the current inheritance behaviour. I asked >

Re: Class Variable Access and Assignment

Antoon Pardon wrote: > Op 2005-11-05, Steven D'Aprano schreef <[EMAIL PROTECTED]>: > >>On Fri, 04 Nov 2005 12:10:11 +, Antoon Pardon wrote: >> >> There are good usage cases for the current inheritance behaviour. I asked before what usage case or cases you have for your desired behaviou

Re: Class Variable Access and Assignment

First of all, I've still not heard any sensible suggestions about a saner behaviour for augmented assignment or for the way Python searches the class scope after the instance scope. What do you suggest? Today, x += n acts just as x = x + n if x is immutable. Do you suggest that this should change

Re: Class Variable Access and Assignment

Op 2005-11-05, Steven D'Aprano schreef <[EMAIL PROTECTED]>: > On Fri, 04 Nov 2005 12:10:11 +, Antoon Pardon wrote: > >>> There are good usage cases for the current inheritance behaviour. I asked >>> before what usage case or cases you have for your desired behaviour, and >>> you haven't answere

Re: Class Variable Access and Assignment

Op 2005-11-04, Steven D'Aprano schreef <[EMAIL PROTECTED]>: > On Fri, 04 Nov 2005 10:48:54 +, Antoon Pardon wrote: > >> Please explain why this is illegal. >> >> x = 1 >> def f(): >> x += 1 > > Because names in function namespaces don't have inheritance. Your quibling about words. This cert

Re: Class Variable Access and Assignment

Op 2005-11-06, Steve Holden schreef <[EMAIL PROTECTED]>: > Steven D'Aprano wrote: > [...] >> >> But I can't understand the position of folks who want inheritance but >> don't want the behaviour that Python currently exhibits. >> instance.attribute sometimes reading from the class attribute is a fe

Re: Class Variable Access and Assignment

Op 2005-11-04, Christopher Subich schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: >> Well maybe because as far as I understand the same kind of logic >> can be applied to something like >> >> lst[f()] += foo >> >> In order to decide that this should be equivallent to >> >> lst[f()] = lst[f()

Re: Class Variable Access and Assignment

Op 2005-11-04, Steven D'Aprano schreef <[EMAIL PROTECTED]>: > On Fri, 04 Nov 2005 09:07:38 +, Antoon Pardon wrote: > Now the b.a on the right hand side refers to A.a the first time through the loop but not the next times. I don't think it is sane that which object is refered to d

Re: Class Variable Access and Assignment

Op 2005-11-04, Steven D'Aprano schreef <[EMAIL PROTECTED]>: > On Fri, 04 Nov 2005 08:08:42 +, Antoon Pardon wrote: > >> One other way, to implement the += and likewise operators would be >> something like the following. >> >> Assume a getnsattr, which would work like getattr, but would also >>

Re: Class Variable Access and Assignment

Op 2005-11-04, Magnus Lycka schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: > > I have looked and didn't find it in the language reference. >> >> This is what I have found: >> >> An augmented assignment expression like x += 1 can be rewritten >> as x = x + 1 to achieve a similar, but not exa

Re: Class Variable Access and Assignment

Op 2005-11-04, Christopher Subich schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: >> Well I wonder. Would the following code be considered a name binding >> operation: >> >> b.a = 5 > > Try it, it's not. > > Python 2.2.3 (#1, Nov 12 2004, 13:02:04) > [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-

Re: Class Variable Access and Assignment

Op 2005-11-04, Steven D'Aprano schreef <[EMAIL PROTECTED]>: > On Fri, 04 Nov 2005 09:03:56 +, Antoon Pardon wrote: > >> Op 2005-11-03, Steven D'Aprano schreef <[EMAIL PROTECTED]>: >>> On Thu, 03 Nov 2005 13:01:40 +, Antoon Pardon wrote: >>> > Seems perfectly sane to me. > > Wha

Re: Class Variable Access and Assignment

Op 2005-11-04, Christopher Subich schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: > >> Except when your default is a list >> >> class foo: >> x = [] # default >> >> a = foo() >> a.x += [3] >> >> b = foo() >> b.x >> >> This results in [3]. So in this case using a class variable x to >> pro

Re: Class Variable Access and Assignment

On Sun, 06 Nov 2005 12:23:02 -0500, Christopher Subich <[EMAIL PROTECTED]> wrote: >Bengt Richter wrote: >> On Fri, 04 Nov 2005 10:28:52 -0500, Christopher Subich <[EMAIL PROTECTED]> >> wrote: > >>>is very much within the language specification. Indeed, the language >>>specification dictates th

Re: Class Variable Access and Assignment

Bengt Richter wrote: > On Fri, 04 Nov 2005 10:28:52 -0500, Christopher Subich <[EMAIL PROTECTED]> > wrote: >>is very much within the language specification. Indeed, the language >>specification dictates that an instance variable b.a is created if one >>didn't exist before; this is true no matt

Re: Class Variable Access and Assignment

On Sun, 06 Nov 2005 08:40:00 +, Bengt Richter wrote: >>Pre-conditions: class.a exists and is mutable; instance.a does >>not exist. >>Post-conditions: class.a modified; instance.a does not exist. >> > Are you saying the above is what happens or what should happen or not happen? Er, it's what I

Re: Class Variable Access and Assignment

On Sun, 06 Nov 2005 15:17:18 +1100, Steven D'Aprano <[EMAIL PROTECTED]> wrote: >On Sat, 05 Nov 2005 18:14:03 -0800, Paul Rubin wrote: > >>> instance.attribute sometimes reading from the class attribute is a feature >>> of inheritance; instance.attribute always writing to the instance is a >>> feat

Re: Class Variable Access and Assignment

On Sat, 05 Nov 2005 18:14:03 -0800, Paul Rubin wrote: >> instance.attribute sometimes reading from the class attribute is a feature >> of inheritance; instance.attribute always writing to the instance is a >> feature of OOP; instance.attribute sometimes writing to the instance and >> sometimes wri

Re: Class Variable Access and Assignment

Steven D'Aprano wrote: [...] > > But I can't understand the position of folks who want inheritance but > don't want the behaviour that Python currently exhibits. > instance.attribute sometimes reading from the class attribute is a feature > of inheritance; instance.attribute always writing to the

Re: Class Variable Access and Assignment

Steven D'Aprano <[EMAIL PROTECTED]> writes: > > It never occurred to me that immutable objects could implement __iadd__. > > If they can, I'm puzzled as to why. > I'm surprised that it never occurred to you that people might > want to do something like x = 1; x += 1 in Python, But I wouldn't ex

Re: Class Variable Access and Assignment

On Sat, 05 Nov 2005 16:27:00 -0800, Paul Rubin wrote: > Steven D'Aprano <[EMAIL PROTECTED]> writes: >> But do you want x += y to work for immutable objects as well? Then >> __iadd__ cannot be a statement, because x can't be modified in place. > > It never occurred to me that immutable objects cou

Re: Class Variable Access and Assignment

Steven D'Aprano <[EMAIL PROTECTED]> writes: > But do you want x += y to work for immutable objects as well? Then > __iadd__ cannot be a statement, because x can't be modified in place. It never occurred to me that immutable objects could implement __iadd__. If they can, I'm puzzled as to why. >

Re: Class Variable Access and Assignment

On Fri, 04 Nov 2005 22:19:39 -0800, Paul Rubin wrote: > Steven D'Aprano <[EMAIL PROTECTED]> writes: >> > Next you get some performance gain by using gmpy to handle the long int >> > arithmetic, >> >> Then whatever happens next will be my own stupid fault for prematurely >> optimising code. > >

Re: Class Variable Access and Assignment

On Sat, 05 Nov 2005 21:26:22 +, Bengt Richter wrote: > BTW, semantically does/should not __iadd__ really implement a _statement_ and > therefore > have no business returning any expression value to bind anywhere? We get to practicality versus purity here. Consider x += y for some object typ

Re: Class Variable Access and Assignment

On Sat, 05 Nov 2005 14:37:19 +1100, Steven D'Aprano <[EMAIL PROTECTED]> wrote: >On Sat, 05 Nov 2005 00:25:34 +, Bengt Richter wrote: > >> On Fri, 04 Nov 2005 02:59:35 +1100, Steven D'Aprano <[EMAIL PROTECTED]> >> wrote: >> >>>On Thu, 03 Nov 2005 14:13:13 +, Antoon Pardon wrote: >>>

Re: Class Variable Access and Assignment

On Fri, 04 Nov 2005 21:14:17 -0500, Mike Meyer <[EMAIL PROTECTED]> wrote: >[EMAIL PROTECTED] (Bengt Richter) writes: >> On Thu, 03 Nov 2005 13:37:08 -0500, Mike Meyer <[EMAIL PROTECTED]> wrote: >> [...] I think it even less sane, if the same occurce of b.a refers to two different objects

Re: Class Variable Access and Assignment

Steven D'Aprano <[EMAIL PROTECTED]> writes: > > Next you get some performance gain by using gmpy to handle the long int > > arithmetic, > > Then whatever happens next will be my own stupid fault for prematurely > optimising code. Huh? There's nothing premature about using gmpy if you need bett

Re: Class Variable Access and Assignment

On Fri, 04 Nov 2005 20:41:31 -0800, Paul Rubin wrote: > Steven D'Aprano <[EMAIL PROTECTED]> writes: >> It also allows you to do something like this: >> >> class ExpertGame(Game): >> current_level = 100 > >> and then use ExpertGame anywhere you would have used Game with no problems. > > Well

Re: Class Variable Access and Assignment

Paul Rubin wrote: > Steven D'Aprano <[EMAIL PROTECTED]> writes: > >>It also allows you to do something like this: >> >>class ExpertGame(Game): >>current_level = 100 > > >>and then use ExpertGame anywhere you would have used Game with no problems. > > > Well, let's say you set, hmm, current

Re: Class Variable Access and Assignment

Paul Rubin writes: > Steven D'Aprano <[EMAIL PROTECTED]> writes: >> It also allows you to do something like this: >> class ExpertGame(Game): >> current_level = 100 > >> and then use ExpertGame anywhere you would have used Game with no problems. > Well, let's say you s

Re: Class Variable Access and Assignment

[EMAIL PROTECTED] (Bengt Richter) writes: > On 04 Nov 2005 17:53:34 -0800, Paul Rubin wrote: >>[EMAIL PROTECTED] (Bengt Richter) writes: >>> Hm, "the" fix? Why wouldn't e.g. treating augassign as shorthand for >>> a source transformation (i.e., asstgt = expr becomes by si

Re: Class Variable Access and Assignment

Steven D'Aprano <[EMAIL PROTECTED]> writes: > It also allows you to do something like this: > > class ExpertGame(Game): > current_level = 100 > and then use ExpertGame anywhere you would have used Game with no problems. Well, let's say you set, hmm, current_score = 100 instead of current_lev

Re: Class Variable Access and Assignment

-- http://mail.python.org/mailman/listinfo/python-list

Re: Class Variable Access and Assignment

On Fri, 04 Nov 2005 12:10:11 +, Antoon Pardon wrote: >> There are good usage cases for the current inheritance behaviour. I asked >> before what usage case or cases you have for your desired behaviour, and >> you haven't answered. Perhaps you missed the question? Perhaps you haven't >> had a c

Re: Class Variable Access and Assignment

On Fri, 04 Nov 2005 13:52:22 -0800, Paul Rubin wrote: > Steven D'Aprano <[EMAIL PROTECTED]> writes: >> Follow the logical implications of this proposed behaviour. >> >> class Game: >> current_level = 1 >> # by default, games start at level one > > That's bogus. Initialize the current

Re: Class Variable Access and Assignment

On Sat, 05 Nov 2005 00:25:34 +, Bengt Richter wrote: > On Fri, 04 Nov 2005 02:59:35 +1100, Steven D'Aprano <[EMAIL PROTECTED]> wrote: > >>On Thu, 03 Nov 2005 14:13:13 +, Antoon Pardon wrote: >> >>> Fine, we have the code: >>> >>> b.a += 2 >>> >>> We found the class variable, because t

Re: Class Variable Access and Assignment

On Fri, 04 Nov 2005 10:28:52 -0500, Christopher Subich <[EMAIL PROTECTED]> wrote: >Antoon Pardon wrote: >>>Since ints are immutable objects, you shouldn't expect the value of b.a >>>to be modified in place, and so there is an assignment to b.a, not A.a. >> >> >> You are now talking implementati

Re: Class Variable Access and Assignment

On 04 Nov 2005 17:53:34 -0800, Paul Rubin wrote: >[EMAIL PROTECTED] (Bengt Richter) writes: >> Hm, "the" fix? Why wouldn't e.g. treating augassign as shorthand for >> a source transformation (i.e., asstgt = expr becomes by simple >> text substitution asstgt = asstgt exp

Re: Class Variable Access and Assignment

On Fri, 04 Nov 2005 16:06:45 -0800, Paul Rubin wrote: > Steven D'Aprano <[EMAIL PROTECTED]> writes: >> A basic usage case: >> >> class Paper: >> size = A4 >> def __init__(self, contents): >> # it makes no sense to have class contents, >> # so contents go straight into the

Re: Class Variable Access and Assignment

On Fri, 04 Nov 2005 09:24:41 -0500, Christopher Subich <[EMAIL PROTECTED]> wrote: >Steven D'Aprano wrote: >> On Thu, 03 Nov 2005 14:13:13 +, Antoon Pardon wrote: >> >> >>>Fine, we have the code: >>> >>> b.a += 2 >>> >>>We found the class variable, because there is no instance variable, >>>

Re: Class Variable Access and Assignment

On Fri, 04 Nov 2005 18:20:56 -0500, Mike Meyer wrote: > Steven D'Aprano <[EMAIL PROTECTED]> writes: >> equal? Some things are a matter of objective fact: should CPython use a >> byte-code compiler and virtual machine, or a 1970s style interpreter that >> interprets the source code directly? > > F

Re: Class Variable Access and Assignment

[EMAIL PROTECTED] (Bengt Richter) writes: > On Thu, 03 Nov 2005 13:37:08 -0500, Mike Meyer <[EMAIL PROTECTED]> wrote: > [...] >>> I think it even less sane, if the same occurce of b.a refers to two >>> different objects, like in b.a += 2 >> >>That's a wart in +=, nothing less. The fix to that is to

Re: Class Variable Access and Assignment

On 4 Nov 2005 11:09:36 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote: [...] > >Take the code: > > lst[f()] += 1 > >Now let f be a function with a side effect, that in succession >produces the positive integers starting with one. > >What do you think this should be equivallent to: > > t = f() > ls

Re: Class Variable Access and Assignment

[EMAIL PROTECTED] (Bengt Richter) writes: > Hm, "the" fix? Why wouldn't e.g. treating augassign as shorthand for > a source transformation (i.e., asstgt = expr becomes by simple > text substitution asstgt = asstgt expr) be as good a fix? Then > we could discuss what Consider "a[f()] += 3". You d

Re: Class Variable Access and Assignment

On 04 Nov 2005 11:04:58 +0100, Stefan Arentz <[EMAIL PROTECTED]> wrote: >Antoon Pardon <[EMAIL PROTECTED]> writes: > >> Op 2005-11-03, Mike Meyer schreef <[EMAIL PROTECTED]>: >> > Antoon Pardon <[EMAIL PROTECTED]> writes: >> >>> What would you expect to get if you wrote b.a = b.a + 2? >> >> I woul

Re: Class Variable Access and Assignment

On Thu, 03 Nov 2005 13:37:08 -0500, Mike Meyer <[EMAIL PROTECTED]> wrote: [...] >> I think it even less sane, if the same occurce of b.a refers to two >> different objects, like in b.a += 2 > >That's a wart in +=, nothing less. The fix to that is to remove += >from the language, but it's a bit late

Re: Class Variable Access and Assignment

On Fri, 04 Nov 2005 02:59:35 +1100, Steven D'Aprano <[EMAIL PROTECTED]> wrote: >On Thu, 03 Nov 2005 14:13:13 +, Antoon Pardon wrote: > >> Fine, we have the code: >> >> b.a += 2 >> >> We found the class variable, because there is no instance variable, >> then why is the class variable not i

Re: Class Variable Access and Assignment

Steven D'Aprano <[EMAIL PROTECTED]> writes: > A basic usage case: > > class Paper: > size = A4 > def __init__(self, contents): > # it makes no sense to have class contents, > # so contents go straight into the instance > self.contents = contents So add: s

Re: Class Variable Access and Assignment

Paul Rubin wrote: > Steven D'Aprano <[EMAIL PROTECTED]> writes: > >>Follow the logical implications of this proposed behaviour. >> >>class Game: >>current_level = 1 >># by default, games start at level one > > > That's bogus. Initialize the current level in the __init__ method > where

Re: Class Variable Access and Assignment

Steven D'Aprano <[EMAIL PROTECTED]> writes: > equal? Some things are a matter of objective fact: should CPython use a > byte-code compiler and virtual machine, or a 1970s style interpreter that > interprets the source code directly? For the record, I've only seen one interpreter that actually inte

Re: Class Variable Access and Assignment

Antoon Pardon <[EMAIL PROTECTED]> writes: > Op 2005-11-04, Mike Meyer schreef <[EMAIL PROTECTED]>: >> Antoon Pardon <[EMAIL PROTECTED]> writes: >>> Op 2005-11-03, Mike Meyer schreef <[EMAIL PROTECTED]>: Antoon Pardon <[EMAIL PROTECTED]> writes: >> What would you expect to get if you wrote

Re: Class Variable Access and Assignment

Antoon Pardon <[EMAIL PROTECTED]> writes: > Op 2005-11-04, Mike Meyer schreef <[EMAIL PROTECTED]>: >> >>> Would it be too much to ask that in a line like. >>> >>> x = x + 1. >>> >>> both x's would resolve to the same namespace? >> >> Yes. That's to much bondage for programmers who've become ac

Re: Class Variable Access and Assignment

Paul Rubin writes: > Mike Meyer <[EMAIL PROTECTED]> writes: >> I've already argued that the kludges suggested to "solve" this problem >> create worse problems than this. > The most obvious solution is to permit (or even require) the > programmer to list the instance varia

Re: Class Variable Access and Assignment

Steven D'Aprano <[EMAIL PROTECTED]> writes: > Follow the logical implications of this proposed behaviour. > > class Game: > current_level = 1 > # by default, games start at level one That's bogus. Initialize the current level in the __init__ method where it belongs. -- http://mail.pyt

Re: Class Variable Access and Assignment

Bengt Richter wrote: > > It might be interesting to have a means to push and pop objects > onto/off-of a name-space-shadowing stack (__nsstack__), such that the first > place > to look up a bare name would be as an attribute of the top stack object, i.e., > > name = name + 1 > Don't be

Re: Class Variable Access and Assignment

On 4 Nov 2005 08:23:05 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote: >Op 2005-11-03, Magnus Lycka schreef <[EMAIL PROTECTED]>: >> Antoon Pardon wrote: >>> There is no instance variable at that point. How can it add 2, to >>> something that doesn't exist at the moment. >> >> Because 'a += 1' is onl

Re: Class Variable Access and Assignment

On Fri, 04 Nov 2005 04:42:54 -0800, Paul Rubin wrote: > Steven D'Aprano <[EMAIL PROTECTED]> writes: >> There are good usage cases for the current inheritance behaviour. > > Can you name one? Any code that relies on it seems extremely dangerous to me. Dangerous? In what way? A basic usage case

Re: Class Variable Access and Assignment

On Fri, 04 Nov 2005 08:08:42 +, Antoon Pardon wrote: > One other way, to implement the += and likewise operators would be > something like the following. > > Assume a getnsattr, which would work like getattr, but would also > return the namespace where the name was found. The implementation >

Re: Class Variable Access and Assignment

On Fri, 04 Nov 2005 07:46:45 +, Antoon Pardon wrote: >> Because b.a += 2 expands to b.a = b.a + 2. Why would you want b.a = >> to correspond to b.__class__.a = ? > > That is an implemantation detail. The only answer that you are given > means nothing more than: because it is implemented that

Re: Class Variable Access and Assignment

On Fri, 04 Nov 2005 09:07:38 +, Antoon Pardon wrote: >>> Now the b.a on the right hand side refers to A.a the first time through >>> the loop but not the next times. I don't think it is sane that which >>> object is refered to depends on how many times you already went through >>> the loop. [

Re: Class Variable Access and Assignment

On Fri, 04 Nov 2005 10:48:54 +, Antoon Pardon wrote: > Please explain why this is illegal. > > x = 1 > def f(): > x += 1 Because names in function namespaces don't have inheritance. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list

Re: Class Variable Access and Assignment

Antoon Pardon wrote: > Op 2005-11-04, Steve Holden schreef <[EMAIL PROTECTED]>: > >>Antoon Pardon wrote: >> >>>Op 2005-11-04, Steve Holden schreef <[EMAIL PROTECTED]>: >> >>[...] >> I suppose ultimately I'm just more pragmatic than you. >>> >>> >>>It has nothing to do with being more pragmatic

Re: Class Variable Access and Assignment

Antoon Pardon wrote: > Well maybe because as far as I understand the same kind of logic > can be applied to something like > > lst[f()] += foo > > In order to decide that this should be equivallent to > > lst[f()] = lst[f()] + foo. > > But that isn't the case. Because, surprisingly enough, Pyt

Re: Class Variable Access and Assignment

Antoon Pardon wrote: > Except when your default is a list > > class foo: > x = [] # default > > a = foo() > a.x += [3] > > b = foo() > b.x > > This results in [3]. So in this case using a class variable x to > provide a default empty list doesn't work out in combination > with augmented oper

Re: Class Variable Access and Assignment

Antoon Pardon wrote: > I have looked and didn't find it in the language reference. > > This is what I have found: > > An augmented assignment expression like x += 1 can be rewritten > as x = x + 1 to achieve a similar, but not exactly equal effect. It's just a little further down. I'll post th

Re: Class Variable Access and Assignment

Graham wrote: > My question remains however, i suppose i'm not familiar with how this > functions in > other languages, but what is the common way of referring to a class > variable. > > is . the norm? > or . the norm. It's not always that easy, due to inheritance. You might want the defined in

Re: Class Variable Access and Assignment

Antoon Pardon wrote: > Well I wonder. Would the following code be considered a name binding > operation: > > b.a = 5 Try it, it's not. Python 2.2.3 (#1, Nov 12 2004, 13:02:04) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-42)] on linux2 Type "help", "copyright", "credits" or "license" for more info

Re: Class Variable Access and Assignment

Antoon Pardon wrote: >>Since ints are immutable objects, you shouldn't expect the value of b.a >>to be modified in place, and so there is an assignment to b.a, not A.a. > > > You are now talking implementation details. I don't care about whatever > explanation you give in terms of implementation

Re: Class Variable Access and Assignment

On Fri, 04 Nov 2005 09:03:56 +, Antoon Pardon wrote: > Op 2005-11-03, Steven D'Aprano schreef <[EMAIL PROTECTED]>: >> On Thu, 03 Nov 2005 13:01:40 +, Antoon Pardon wrote: >> Seems perfectly sane to me. What would you expect to get if you wrote b.a = b.a + 2? >>> >>> I woul

Re: Class Variable Access and Assignment

Op 2005-11-04, Christopher Subich schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: >> Op 2005-11-03, Stefan Arentz schreef <[EMAIL PROTECTED]>: >>>The model makes sense in my opinion. If you don't like it then there are >>>plenty of other languages to choose from that have decided to implement >

Re: Class Variable Access and Assignment

Op 2005-11-04, Christopher Subich schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: >> Op 2005-11-03, Stefan Arentz schreef <[EMAIL PROTECTED]>: >>>The model makes sense in my opinion. If you don't like it then there are >>>plenty of other languages to choose from that have decided to implement >

Re: Class Variable Access and Assignment

Steven D'Aprano wrote: > On Thu, 03 Nov 2005 14:13:13 +, Antoon Pardon wrote: > > >>Fine, we have the code: >> >> b.a += 2 >> >>We found the class variable, because there is no instance variable, >>then why is the class variable not incremented by two now? > > > Because b.a += 2 expands to

Re: Class Variable Access and Assignment

Antoon Pardon wrote: > Op 2005-11-03, Stefan Arentz schreef <[EMAIL PROTECTED]>: >>The model makes sense in my opinion. If you don't like it then there are >>plenty of other languages to choose from that have decided to implement >>things differently. > > > And again this argument. Like it or lea

Re: Class Variable Access and Assignment

Op 2005-11-04, Magnus Lycka schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: >> Would it be too much to ask that in a line like. >> >> x = x + 1. >> >> both x's would resolve to the same namespace? > > They always do Antoon. There is no such issue for > local (or global) varibles. I meant t

Re: Class Variable Access and Assignment

Antoon Pardon wrote: > Would it be too much to ask that in a line like. > > x = x + 1. > > both x's would resolve to the same namespace? They always do Antoon. There is no such issue for local (or global) varibles. The issue has to do with c.x = c.x + 1. In this case it's clearly designed and

Re: Class Variable Access and Assignment

Op 2005-11-04, Steven D'Aprano schreef <[EMAIL PROTECTED]>: > On Fri, 04 Nov 2005 07:31:46 +, Antoon Pardon wrote: > >>> The model makes sense in my opinion. If you don't like it then there are >>> plenty of other languages to choose from that have decided to implement >>> things differently. >

Re: Class Variable Access and Assignment

Steven D'Aprano <[EMAIL PROTECTED]> writes: > There are good usage cases for the current inheritance behaviour. Can you name one? Any code that relies on it seems extremely dangerous to me. -- http://mail.python.org/mailman/listinfo/python-list

Re: Class Variable Access and Assignment

Op 2005-11-04, Steve Holden schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: >> Op 2005-11-04, Steve Holden schreef <[EMAIL PROTECTED]>: > [...] >>>I suppose ultimately I'm just more pragmatic than you. >> >> >> It has nothing to do with being more pragmatic. Being pragmatic >> is about how yo

Re: Class Variable Access and Assignment

Paul Rubin wrote: > Stefan Arentz <[EMAIL PROTECTED]> writes: > >>>Are you seriously saying there's lots of Python projects that would >>>break if this particular weirdness were fixed? >> >>I have no numbers of course. But, why is this a weirdness? > > > Do you seriously think the number is lar

Re: Class Variable Access and Assignment

Antoon Pardon wrote: > Op 2005-11-04, Steve Holden schreef <[EMAIL PROTECTED]>: [...] >>I suppose ultimately I'm just more pragmatic than you. > > > It has nothing to do with being more pragmatic. Being pragmatic > is about how you handle things with real life projects. It has > little to do with

Re: Class Variable Access and Assignment

On Fri, 04 Nov 2005 07:31:46 +, Antoon Pardon wrote: >> The model makes sense in my opinion. If you don't like it then there are >> plenty of other languages to choose from that have decided to implement >> things differently. > > And again this argument. Like it or leave it, as if one can't

Re: Class Variable Access and Assignment

Op 2005-11-04, Graham schreef <[EMAIL PROTECTED]>: > Once again, many thanks, your explainations are very detailed and i > think i'm in full understanding of the what/when/why of it all. > > And with further introspection i can see why its done this way from a > language processing point of view ra

Re: Class Variable Access and Assignment

Op 2005-11-04, Mike Meyer schreef <[EMAIL PROTECTED]>: > Antoon Pardon <[EMAIL PROTECTED]> writes: >> Op 2005-11-03, Mike Meyer schreef <[EMAIL PROTECTED]>: >>> Antoon Pardon <[EMAIL PROTECTED]> writes: > What would you expect to get if you wrote b.a = b.a + 2? I would expect a result cons

Re: Class Variable Access and Assignment

Mike Meyer <[EMAIL PROTECTED]> writes: > I've already argued that the kludges suggested to "solve" this problem > create worse problems than this. The most obvious solution is to permit (or even require) the programmer to list the instance variables as part of the class definition. Anything not i

Re: Class Variable Access and Assignment

Op 2005-11-04, Stefan Arentz schreef <[EMAIL PROTECTED]>: > Antoon Pardon <[EMAIL PROTECTED]> writes: > >> Op 2005-11-03, Mike Meyer schreef <[EMAIL PROTECTED]>: >> > Antoon Pardon <[EMAIL PROTECTED]> writes: >> >>> What would you expect to get if you wrote b.a = b.a + 2? >> >> I would expect a res

Re: Class Variable Access and Assignment

Op 2005-11-04, Mike Meyer schreef <[EMAIL PROTECTED]>: > >> Would it be too much to ask that in a line like. >> >> x = x + 1. >> >> both x's would resolve to the same namespace? > > Yes. That's to much bondage for programmers who've become accustomed > to freedom. Explain why this should be ill

Re: Class Variable Access and Assignment

Op 2005-11-04, Magnus Lycka schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: >>>Because b.a += 2 expands to b.a = b.a + 2. Why would you want b.a = >>> to correspond to b.__class__.a = ? >> >> >> That is an implemantation detail. The only answer that you are given >> means nothing more than: b

Re: Class Variable Access and Assignment

Stefan Arentz <[EMAIL PROTECTED]> writes: > > Are you seriously saying there's lots of Python projects that would > > break if this particular weirdness were fixed? > > I have no numbers of course. But, why is this a weirdness? Do you seriously think the number is larger than zero? Do you think

Re: Class Variable Access and Assignment

> Would it be too much to ask that in a line like. > > x = x + 1. > > both x's would resolve to the same namespace? Yes. That's to much bondage for programmers who've become accustomed to freedom. Explain why this should be illegal: >>> class C: ... def __getattr__(self, name): ... x = 1

Re: Class Variable Access and Assignment

Antoon Pardon <[EMAIL PROTECTED]> writes: > Op 2005-11-03, Mike Meyer schreef <[EMAIL PROTECTED]>: >> Antoon Pardon <[EMAIL PROTECTED]> writes: What would you expect to get if you wrote b.a = b.a + 2? >>> I would expect a result consistent with the fact that both times >>> b.a would refer to t

Re: Class Variable Access and Assignment

Antoon Pardon wrote: >>Because b.a += 2 expands to b.a = b.a + 2. Why would you want b.a = >> to correspond to b.__class__.a = ? > > > That is an implemantation detail. The only answer that you are given > means nothing more than: because it is implemented that way. Something that is written in

Re: Class Variable Access and Assignment

Paul Rubin writes: > Stefan Arentz <[EMAIL PROTECTED]> writes: > > > Would it be too much to ask that in a line like. > > > x = x + 1. > > > both x's would resolve to the same namespace? > > ... > > Consider changing the semantics of what you are proposing and > > thin

Re: Class Variable Access and Assignment

Stefan Arentz <[EMAIL PROTECTED]> writes: > > Would it be too much to ask that in a line like. > > x = x + 1. > > both x's would resolve to the same namespace? > ... > Consider changing the semantics of what you are proposing and > think about all those Python projects that will break because the

Re: Class Variable Access and Assignment

Op 2005-11-04, Stefan Arentz schreef <[EMAIL PROTECTED]>: > Antoon Pardon <[EMAIL PROTECTED]> writes: > > ... > >> > Ah yes. Well, good luck with that. You seem to have decided that it is not >> > sane and who am I to argue with that. It depends on your state of mind :-) >> >> I can just say the o

  1   2   >