Re: musings on static variables

r...@zedat.fu-berlin.de (Stefan Ram) writes: > This C program use a local /static/ variable. > > main.c > > #include > > int f( void ) > { static int i = 0; > return i++; } > > int main( void ) > { printf( "%d\n", f() ); > printf( "%d\n", f() ); > printf( "%d\n", f() ); } > >

Re: Static variables [was Re: syntax difference]

To: Ben Bacarisse From: "Bart" To: Ben Bacarisse From: Bart On 24/06/2018 01:53, Ben Bacarisse wrote: > Bart writes: >> Wow. (Just think of all the times you write a function containing a >> neat bunch of local functions, every time it's called it has to create >> a new function

Re: Static variables [was Re: syntax difference]

To: Bart From: "Gregory Ewing" To: Bart From: Gregory Ewing Bart wrote: > Wow. (Just think of all the times you write a function containing a neat > bunch of local functions, every time it's called it has to create a new > function instances for each of those functions, even if they are

Re: Static variables [was Re: syntax difference]

To: Bart From: "Ben Bacarisse" To: Bart From: Ben Bacarisse Bart writes: > On 23/06/2018 23:25, Ben Bacarisse wrote: >> Bart writes: >> >>> On 23/06/2018 21:13, Chris Angelico wrote: On Sat, Jun 23, 2018 at 10:41 PM, Bart wrote: >>> > (At what point would that happen anyway;

Re: Static variables [was Re: syntax difference]

To: Bart From: "Ben Bacarisse" To: Bart From: Ben Bacarisse Bart writes: > On 23/06/2018 21:13, Chris Angelico wrote: >> On Sat, Jun 23, 2018 at 10:41 PM, Bart wrote: > >>> (At what point would that happen anyway; if you do this: > >> NONE of your examples are taking copies of the

Re: Static variables [was Re: syntax difference]

To: Ben Bacarisse From: "Bart" To: Ben Bacarisse From: Bart On 23/06/2018 23:25, Ben Bacarisse wrote: > Bart writes: > >> On 23/06/2018 21:13, Chris Angelico wrote: >>> On Sat, Jun 23, 2018 at 10:41 PM, Bart wrote: >> (At what point would that happen anyway; if you do this: >> >>>

Re: Static variables [was Re: syntax difference]

To: Chris Angelico From: "Bart" To: Chris Angelico From: Bart On 23/06/2018 21:13, Chris Angelico wrote: > On Sat, Jun 23, 2018 at 10:41 PM, Bart wrote: >> (At what point would that happen anyway; if you do this: > NONE of your examples are taking copies of the function. They all are >

Re: Static variables [was Re: syntax difference]

eturn g > >Or, "for all g to share the same x": > >main.py > > def f(): > def g(): > f.x += 1 > return f.x > return g > f.x = 0 OK, problem solved: we just use attributes of function objects rather than locally static

Re: Static variables [was Re: syntax difference]

To: Stefan Ram From: "Stefan Ram" To: Stefan Ram From: r...@zedat.fu-berlin.de (Stefan Ram) r...@zedat.fu-berlin.de (Stefan Ram) writes: >def f(): >def g(): >g.x += 1 >return g.x >g.x = 0 >return g Or, "for all g to share the same x": main.py def f():

Re: Static variables [was Re: syntax difference]

To: Steven D'Aprano From: "Stefan Ram" To: Steven D'Aprano From: r...@zedat.fu-berlin.de (Stefan Ram) Steven D'Aprano writes: >def f(): >static x = 0 >def g(): >x += 1 >return x >return g What one can do today: main.py def g(): g.x += 1 return g.x

Re: Static variables [was Re: syntax difference]

To: Steven D'Aprano From: "Bart" To: Steven D'Aprano From: Bart On 23/06/2018 04:51, Steven D'Aprano wrote: > On Wed, 20 Jun 2018 14:18:19 +1000, Chris Angelico wrote: > >> Ah. Yeah, that would be a plausible feature to add to Python. But in C, >> a static variable is basically the same

Re: Static variables [was Re: syntax difference]

ables len, int, str to the function, with the given > values, and transforms all the bytecode LOAD_NAME len to LOAD_FAST len > (or whatever). > > (We might need a new bytecode to SET_STATIC.) > > That would be a nice bytecode hack to prove the usefulness of the concept! > Ok

Re: Static variables [was Re: syntax difference]

From: "Chris Angelico" From: Chris Angelico On Sat, Jun 23, 2018 at 2:16 PM, Chris Angelico wrote: > For getting rid of the "len=len" trick, though, I would REALLY like to > transform those into LOAD_CONST. That'd be a fun bytecode hack all on > its own. In fact, I'm gonna have a shot at

Static variables [was Re: syntax difference]

From: "Steven D'Aprano" From: Steven D'Aprano On Wed, 20 Jun 2018 14:18:19 +1000, Chris Angelico wrote: > Ah. Yeah, that would be a plausible feature to add to Python. But in C, > a static variable is basically the same thing as a global variable, > except that its name is scoped to the

Re: Static variables [was Re: syntax difference]

On Mon, 25 Jun 2018 18:22:56 +, Grant Edwards wrote: > On 2018-06-24, Steven D'Aprano wrote: > >> Building functions is cheap. Cheap is not free. >> >> Inner functions that aren't exposed to the outside cannot be tested in >> isolation, you can't access them through help() interactively.

Re: Static variables [was Re: syntax difference]

Grant Edwards : > IOW, you use a local function instead of a global one for the exact > same reasons you use local "variables" instead of global ones. > > In Python, functions are first class objects. Binding a name to a > function is no different than binding it to an integer, list, string, > or

Re: Static variables [was Re: syntax difference]

On 2018-06-24, Steven D'Aprano wrote: > Building functions is cheap. Cheap is not free. > > Inner functions that aren't exposed to the outside cannot be tested > in isolation, you can't access them through help() > interactively. Given the choice between: [...] > so not expensive, but not free

Re: Static variables [was Re: syntax difference]

To: Ben Bacarisse From: Bart On 24/06/2018 01:53, Ben Bacarisse wrote: > Bart writes: >> Wow. (Just think of all the times you write a function containing a >> neat bunch of local functions, every time it's called it has to create >> a new function instances for each of those functions, even

Re: Static variables [was Re: syntax difference]

From: Steven D'Aprano On Sun, 24 Jun 2018 11:23:12 +0100, Bart wrote: > On 24/06/2018 01:53, Ben Bacarisse wrote: >> Bart writes: > >>> Wow. (Just think of all the times you write a function containing a >>> neat bunch of local functions, every time it's called it has to create >>> a new

Re: Static variables [was Re: syntax difference]

nce even slower); - f.x is not encapsulated inside the function. It requires initialisation outside the function. The attribute f.x is easily visible to the caller. (Technically, so probably would static variables, but only by inspecting the function's internals. People know they're on thin-ice if

Re: Static variables [was Re: syntax difference]

From: Steven D'Aprano On Sat, 23 Jun 2018 21:44:00 +0100, Bart wrote: > Since these references are created via the return g statement here: > > def f(): > def g(): > > return g > > (say to create function references i and j like this: > > i = f() >

Re: Static variables [was Re: syntax difference]

From: Steven D'Aprano On Sun, 24 Jun 2018 00:37:36 +0100, Bart wrote: > Do you mean that if the same 'def' block is re-executed, it will create > a different instance of the function? (Same byte-code, but a different > set of everything else the function uses.) That's not as slow as you think

Re: Static variables [was Re: syntax difference]

To: Bart From: Gregory Ewing Bart wrote: > Wow. (Just think of all the times you write a function containing a neat > bunch of local functions, every time it's called it has to create a new > function instances for each of those functions, even if they are not used.) Fortunately, function

Re: Static variables [was Re: syntax difference]

From: Chris Angelico On Sun, Jun 24, 2018 at 9:37 AM, Bart wrote: > On 23/06/2018 23:25, Ben Bacarisse wrote: >> >> Bart writes: >> >>> On 23/06/2018 21:13, Chris Angelico wrote: On Sat, Jun 23, 2018 at 10:41 PM, Bart wrote: >>> >>> > (At what point would that happen anyway; if

Re: Static variables [was Re: syntax difference]

To: Bart From: Ben Bacarisse Bart writes: > On 23/06/2018 23:25, Ben Bacarisse wrote: >> Bart writes: >> >>> On 23/06/2018 21:13, Chris Angelico wrote: On Sat, Jun 23, 2018 at 10:41 PM, Bart wrote: >>> > (At what point would that happen anyway; if you do this: >>> NONE of

Re: Static variables [was Re: syntax difference]

To: Bart From: Ben Bacarisse Bart writes: > On 23/06/2018 21:13, Chris Angelico wrote: >> On Sat, Jun 23, 2018 at 10:41 PM, Bart wrote: > >>> (At what point would that happen anyway; if you do this: > >> NONE of your examples are taking copies of the function. They all are >> making

Re: Static variables [was Re: syntax difference]

To: Ben Bacarisse From: Bart On 23/06/2018 23:25, Ben Bacarisse wrote: > Bart writes: > >> On 23/06/2018 21:13, Chris Angelico wrote: >>> On Sat, Jun 23, 2018 at 10:41 PM, Bart wrote: >> (At what point would that happen anyway; if you do this: >> >>> NONE of your examples are taking

Re: Static variables [was Re: syntax difference]

To: Chris Angelico From: Bart On 23/06/2018 21:13, Chris Angelico wrote: > On Sat, Jun 23, 2018 at 10:41 PM, Bart wrote: >> (At what point would that happen anyway; if you do this: > NONE of your examples are taking copies of the function. They all are > making REFERENCES to the same

Re: Static variables [was Re: syntax difference]

From: Chris Angelico On Sat, Jun 23, 2018 at 10:41 PM, Bart wrote: > This is an example of a simple concept getting so out of hand that it will > either never be implemented, or the resulting implementation becomes > impractical to use. > > This is what we're trying to do: > > def nextx():

Re: Static variables [was Re: syntax difference]

tr=str >> >> But I think nicer than that would be a decorator: >> >> @static(len=len, int=int, str=str) >> def function(real, arguments): >> ... >> >> which adds local variables len, int, str to the function, with the given >> valu

Re: Static variables [was Re: syntax difference]

l g to share the same x": > >main.py > > def f(): > def g(): > f.x += 1 > return f.x > return g > f.x = 0 OK, problem solved: we just use attributes of function objects rather than locally static variables (I didn't even know that was possible). T

Re: Static variables [was Re: syntax difference]

To: Steven D'Aprano From: r...@zedat.fu-berlin.de (Stefan Ram) Steven D'Aprano writes: >def f(): >static x = 0 >def g(): >x += 1 >return x >return g What one can do today: main.py def g(): g.x += 1 return g.x g.x = 0 print( g() ) print( g() ) print(

Re: Static variables [was Re: syntax difference]

98ecd8c1-13b7-8317-8177-6a3592171...@kellett.im> Subject: Re: Static variables [was Re: syntax difference] References: <72edc16a-69e0-41a2-bec3-290083f6e...@googlegroups.com> <01092eb6-172f-5ee0-91fb-4e3e1df99...@gmail.com> <6eUVC.491716$Qg7.378011@fx08.am4>

Re: Static variables [was Re: syntax difference]

To: Stefan Ram From: r...@zedat.fu-berlin.de (Stefan Ram) r...@zedat.fu-berlin.de (Stefan Ram) writes: >def f(): >def g(): >g.x += 1 >return g.x >g.x = 0 >return g Or, "for all g to share the same x": main.py def f(): def g(): f.x += 1

Re: Static variables [was Re: syntax difference]

To: Steven D'Aprano From: Bart On 23/06/2018 04:51, Steven D'Aprano wrote: > On Wed, 20 Jun 2018 14:18:19 +1000, Chris Angelico wrote: > >> Ah. Yeah, that would be a plausible feature to add to Python. But in C, >> a static variable is basically the same thing as a global variable, >> except

Re: Static variables [was Re: syntax difference]

e function, with the given > values, and transforms all the bytecode LOAD_NAME len to LOAD_FAST len > (or whatever). > > (We might need a new bytecode to SET_STATIC.) > > That would be a nice bytecode hack to prove the usefulness of the concept! > Okay, that makes sense. So in a way, stati

Static variables [was Re: syntax difference]

From: Steven D'Aprano On Wed, 20 Jun 2018 14:18:19 +1000, Chris Angelico wrote: > Ah. Yeah, that would be a plausible feature to add to Python. But in C, > a static variable is basically the same thing as a global variable, > except that its name is scoped to the function. There is only one of

Re: Static variables [was Re: syntax difference]

From: Chris Angelico On Sat, Jun 23, 2018 at 2:16 PM, Chris Angelico wrote: > For getting rid of the "len=len" trick, though, I would REALLY like to > transform those into LOAD_CONST. That'd be a fun bytecode hack all on > its own. In fact, I'm gonna have a shot at that. An "early bind these >

Re: Static variables [was Re: syntax difference]

On Sun, 24 Jun 2018 11:23:12 +0100, Bart wrote: > On 24/06/2018 01:53, Ben Bacarisse wrote: >> Bart writes: > >>> Wow. (Just think of all the times you write a function containing a >>> neat bunch of local functions, every time it's called it has to create >>> a new function instances for each

Re: Static variables [was Re: syntax difference]

On 24/06/2018 01:53, Ben Bacarisse wrote: Bart writes: Wow. (Just think of all the times you write a function containing a neat bunch of local functions, every time it's called it has to create a new function instances for each of those functions, even if they are not used.) I am surprised

Re: Static variables [was Re: syntax difference]

f.x is not encapsulated inside the function. It requires initialisation outside the function. The attribute f.x is easily visible to the caller. (Technically, so probably would static variables, but only by inspecting the function's internals. People know they're on thin-ice if they mess with them.

Re: Static variables [was Re: syntax difference]

On Sun, 24 Jun 2018 00:37:36 +0100, Bart wrote: > Do you mean that if the same 'def' block is re-executed, it will create > a different instance of the function? (Same byte-code, but a different > set of everything else the function uses.) That's not as slow as you think it is. Everything that

Re: Static variables [was Re: syntax difference]

On Sat, 23 Jun 2018 21:44:00 +0100, Bart wrote: > Since these references are created via the return g statement here: > > def f(): > def g(): > > return g > > (say to create function references i and j like this: > > i = f() > j = f() > ) > >

Re: Static variables [was Re: syntax difference]

Bart wrote: Wow. (Just think of all the times you write a function containing a neat bunch of local functions, every time it's called it has to create a new function instances for each of those functions, even if they are not used.) Fortunately, function objects are small and cheap,

Re: Static variables [was Re: syntax difference]

Bart writes: > On 23/06/2018 23:25, Ben Bacarisse wrote: >> Bart writes: >> >>> On 23/06/2018 21:13, Chris Angelico wrote: On Sat, Jun 23, 2018 at 10:41 PM, Bart wrote: >>> > (At what point would that happen anyway; if you do this: >>> NONE of your examples are taking copies of

Re: Static variables [was Re: syntax difference]

On Sun, Jun 24, 2018 at 9:37 AM, Bart wrote: > On 23/06/2018 23:25, Ben Bacarisse wrote: >> >> Bart writes: >> >>> On 23/06/2018 21:13, Chris Angelico wrote: On Sat, Jun 23, 2018 at 10:41 PM, Bart wrote: >>> >>> > (At what point would that happen anyway; if you do this: >>> >>>

Re: Static variables [was Re: syntax difference]

On 23/06/2018 23:25, Ben Bacarisse wrote: Bart writes: On 23/06/2018 21:13, Chris Angelico wrote: On Sat, Jun 23, 2018 at 10:41 PM, Bart wrote: (At what point would that happen anyway; if you do this: NONE of your examples are taking copies of the function. They all are making

Re: Static variables [was Re: syntax difference]

Bart writes: > On 23/06/2018 21:13, Chris Angelico wrote: >> On Sat, Jun 23, 2018 at 10:41 PM, Bart wrote: > >>> (At what point would that happen anyway; if you do this: > >> NONE of your examples are taking copies of the function. They all are >> making REFERENCES to the same function. That is

Re: Static variables [was Re: syntax difference]

On 23/06/2018 21:13, Chris Angelico wrote: On Sat, Jun 23, 2018 at 10:41 PM, Bart wrote: (At what point would that happen anyway; if you do this: NONE of your examples are taking copies of the function. They all are making REFERENCES to the same function. That is all. This is about your

Re: Static variables [was Re: syntax difference]

On Sat, Jun 23, 2018 at 10:41 PM, Bart wrote: > This is an example of a simple concept getting so out of hand that it will > either never be implemented, or the resulting implementation becomes > impractical to use. > > This is what we're trying to do: > > def nextx(): > static x = 0

Re: Static variables [was Re: syntax difference]

the given values, and transforms all the bytecode LOAD_NAME len to LOAD_FAST len (or whatever). (We might need a new bytecode to SET_STATIC.) That would be a nice bytecode hack to prove the usefulness of the concept! Okay, that makes sense. So in a way, static variables would be like closure

Re: Static variables [was Re: syntax difference]

return f.x return g f.x = 0 OK, problem solved: we just use attributes of function objects rather than locally static variables (I didn't even know that was possible). These apparently can be created, accessed and modified from anywhere in the program. The only provisos are that functions wi

Re: Static variables [was Re: syntax difference]

On 2018-06-23 06:21, Chris Angelico wrote: > Let's start finding all the edge cases that don't work, so I can work > on fixing them :) Very long functions (or, more specifically, functions with a very large number of consts) will likely prove annoying. signature.asc Description: OpenPGP

Re: Static variables [was Re: syntax difference]

On 23/06/2018 04:51, Steven D'Aprano wrote: On Wed, 20 Jun 2018 14:18:19 +1000, Chris Angelico wrote: Ah. Yeah, that would be a plausible feature to add to Python. But in C, a static variable is basically the same thing as a global variable, except that its name is scoped to the function.

Re: Static variables [was Re: syntax difference]

On Sat, Jun 23, 2018 at 2:16 PM, Chris Angelico wrote: > For getting rid of the "len=len" trick, though, I would REALLY like to > transform those into LOAD_CONST. That'd be a fun bytecode hack all on > its own. In fact, I'm gonna have a shot at that. An "early bind these > names" decorator.

Re: Static variables [was Re: syntax difference]

en > values, and transforms all the bytecode LOAD_NAME len to LOAD_FAST len > (or whatever). > > (We might need a new bytecode to SET_STATIC.) > > That would be a nice bytecode hack to prove the usefulness of the concept! > Okay, that makes sense. So in a way, static variables would

Static variables [was Re: syntax difference]

On Wed, 20 Jun 2018 14:18:19 +1000, Chris Angelico wrote: > Ah. Yeah, that would be a plausible feature to add to Python. But in C, > a static variable is basically the same thing as a global variable, > except that its name is scoped to the function. There is only one of it. > What happens in

Re: static variables

Op 02-12-15 om 21:30 schreef Ian Kelly: > A person can hold one opinion in some contexts and an opposing opinion > in others. Yes people are capable of that. It doesn't mean we shouldn't challenge them on that. There are many possibilities for people to act like that. One context can be

Re: static variables

On 02/12/2015 14:07, Antoon Pardon wrote: Op 02-12-15 om 14:48 schreef Mark Lawrence: Would the pair of you, Antoon and Steven, be kind enough to take your bickering offline, thanks. Mark, you are in no position to make such a request of others. I am, I'm sat perfectly comfortably thank

Re: static variables

On Wed, Dec 2, 2015 at 7:41 AM, Antoon Pardon wrote: > Op 02-12-15 om 14:11 schreef Steven D'Aprano: >> On Wed, 2 Dec 2015 10:09 pm, Antoon Pardon wrote: >> >>> If you want your arguments to be taken seriously, then you better should. >>> If you use an argument when

Re: static variables

Op 02-12-15 om 15:15 schreef Ian Kelly: > On Wed, Dec 2, 2015 at 7:41 AM, Antoon Pardon > wrote: >> Op 02-12-15 om 14:11 schreef Steven D'Aprano: >>> On Wed, 2 Dec 2015 10:09 pm, Antoon Pardon wrote: >>> If you want your arguments to be taken seriously, then you

Re: static variables

On Wed, Dec 2, 2015 at 9:30 AM, Antoon Pardon wrote: > Op 02-12-15 om 15:15 schreef Ian Kelly: >> On Wed, Dec 2, 2015 at 7:41 AM, Antoon Pardon >> wrote: >>> Op 02-12-15 om 14:11 schreef Steven D'Aprano: On Wed, 2 Dec 2015 10:09

Re: static variables

Op 02-12-15 om 02:24 schreef Steven D'Aprano: > Python has three not-entirely-awful solutions to the problem of static > locals, but no really great or obvious one. I think python is unsuited for an obvious solution for static locals. Because you need to initialise your static variable somewhere.

Re: static variables

are consenting adults here. Static variables, are just a feature to protect what is essentially a global variable against messing from somewhere else. So why is this feature worthy of discussion and others are not? -- Antoon. -- https://mail.python.org/mailman/listinfo/python-list

Re: static variables

On Wed, Dec 2, 2015 at 7:21 PM, Antoon Pardon wrote: > I think python is unsuited for an obvious solution for static locals. > Because you need to initialise your static variable somewhere. If you > initialise whithin the body of your function, you will have a

Re: static variables

Op 02-12-15 om 10:23 schreef Chris Angelico: > On Wed, Dec 2, 2015 at 7:21 PM, Antoon Pardon > wrote: >> I think python is unsuited for an obvious solution for static locals. >> Because you need to initialise your static variable somewhere. If you >> initialise

Re: static variables

ain things are acceptable for consenting adults and others are not. But if it makes you feel better, if I were to champion this feature, I would suggest that the initialised static variable be stored in a writable dunder attribute of the function, just like default values are today. If you wanted t

Re: static variables

Antoon Pardon <antoon.par...@rece.vub.ac.be>: > def foo() >foo.attr > > changes nothing about foo.attr being globally accessible. I don't know why global accessibility is such a problem. Anyway, in practice I handle such "static" variables as module globals.

Re: static variables

Op 02-12-15 om 11:18 schreef Marko Rauhamaa: > Antoon Pardon : > >> def foo() >>foo.attr >> >> changes nothing about foo.attr being globally accessible. > I don't know why global accessibility is such a problem. Some people seem to have a problem with global

Re: static variables

at way/ or /we don't have a problem with that./ > But if it makes you feel better, if I were to champion this feature, I would > suggest that the initialised static variable be stored in a writable dunder > attribute of the function, just like default values are today. If you > wanted to

Re: static variables

Antoon Pardon : > Op 02-12-15 om 11:18 schreef Marko Rauhamaa: >> I don't know why global accessibility is such a problem. > > Some people seem to have a problem with global variables. Well, *I* don't go around defining global variables, but there are times when

Re: static variables

Op 02-12-15 om 14:11 schreef Steven D'Aprano: > On Wed, 2 Dec 2015 10:09 pm, Antoon Pardon wrote: > >> If you want your arguments to be taken seriously, then you better should. >> If you use an argument when it suits you and ignore it when it doesn't >> you are showing you don't really have an

Re: static variables

On Wed, 2 Dec 2015 10:09 pm, Antoon Pardon wrote: > If you want your arguments to be taken seriously, then you better should. > If you use an argument when it suits you and ignore it when it doesn't > you are showing you don't really have an argument. You are just showing > your preference and

Re: static variables

On Wed, 2 Dec 2015 10:30 pm, Marko Rauhamaa wrote: > Antoon Pardon : > >> Op 02-12-15 om 11:18 schreef Marko Rauhamaa: >>> I don't know why global accessibility is such a problem. >> >> Some people seem to have a problem with global variables. > > Well, *I* don't

Re: static variables

On 02/12/2015 13:41, Antoon Pardon wrote: Op 02-12-15 om 14:11 schreef Steven D'Aprano: On Wed, 2 Dec 2015 10:09 pm, Antoon Pardon wrote: If you want your arguments to be taken seriously, then you better should. If you use an argument when it suits you and ignore it when it doesn't you are

Re: static variables

Op 02-12-15 om 14:48 schreef Mark Lawrence: > > Would the pair of you, Antoon and Steven, be kind enough to take your > bickering offline, thanks. > Mark, you are in no position to make such a request of others. -- Antoon. -- https://mail.python.org/mailman/listinfo/python-list

Re: static variables

On Tue, 1 Dec 2015 08:15 pm, Grobu wrote: > Perhaps you could use a parameter's default value to implement your > static variable? > > Like : > # - > >>> def test(arg=[0]): > ... print arg[0] > ... arg[0] += 1 > ... Awesome! I'm not

Re: static variables

On 02/12/15 01:02, Steven D'Aprano wrote: On Tue, 1 Dec 2015 08:15 pm, Grobu wrote: # - >>> def test(arg=[0]): ... print arg[0] ... arg[0] += 1 Awesome! Hideous! using a mutable default as static storage. Exposing something a

Re: static variables

On Wed, 2 Dec 2015 12:16 pm, Erik wrote: > On 02/12/15 01:02, Steven D'Aprano wrote: >> On Tue, 1 Dec 2015 08:15 pm, Grobu wrote: >>> # - >>> >>> def test(arg=[0]): >>> ... print arg[0] >>> ... arg[0] += 1 >> Awesome! > > Hideous! > >>

Re: static variables

Perhaps you could use a parameter's default value to implement your static variable? Like : # - >>> def test(arg=[0]): ... print arg[0] ... arg[0] += 1 ... >>> test() 0 >>> test() 1 # - --

Re: static variables

Steven D'Aprano wrote: > A better and more general test is: > > if hasattr(a, 'x'): print('attribute of a') Fine! I have now: def a(x=None): if not hasattr(a,'x'): a.x = 0 a.x += 1 print('%d:' % a.x,x) This simply counts the calls of a() But, when I rename the

Re: static variables

Ulli Horlacher wrote: > Steven D'Aprano wrote: > >> A better and more general test is: >> >> if hasattr(a, 'x'): print('attribute of a') > > Fine! > > I have now: > > def a(x=None): > if not hasattr(a,'x'): a.x = 0 > a.x += 1 > print('%d:' % a.x,x) > > This

Re: static variables

On 01.12.2015 09:26, Ulli Horlacher wrote: Steven D'Aprano wrote: A better and more general test is: if hasattr(a, 'x'): print('attribute of a') Fine! I have now: def a(x=None): if not hasattr(a,'x'): a.x = 0 a.x += 1 print('%d:' % a.x,x) This simply counts

Re: static variables

Wolfgang Maier wrote: > I'm wondering whether you have a good reason to stick with a function. Easy handling, no programming overhead. Clean, orthogonal code. > What you are trying to achieve seems to be easier and cleaner to > implement as a class:

static variables

I try to to implement a "static variable" inside a function: def main(): a(1) a(2) a() print(a.x) if 'a.x' in globals(): print('global variable') if 'a.x' in locals(): print('local variable') def a(x=None): if not x is None: a.x = x print(':',a.x) main() When I run this code,

Re: static variables

On 11/30/2015 12:15 PM, Ulli Horlacher wrote: I try to to implement a "static variable" inside a function: def main(): a(1) a(2) a() print(a.x) if 'a.x' in globals(): print('global variable') if 'a.x' in locals(): print('local variable') def a(x=None): if not x is None:

Re: static variables

On 30/11/2015 17:15, Ulli Horlacher wrote: def main(): a(1) a(2) a() print(a.x) if 'a.x' in globals(): print('global variable') if 'a.x' in locals(): print('local variable') Try this: if 'x' in a.__dict__: print('attribute of a') -- Bartc --

Re: static variables

On Tue, 1 Dec 2015 07:32 am, BartC wrote: > On 30/11/2015 17:15, Ulli Horlacher wrote: >> def main(): >>a(1) >>a(2) >>a() >>print(a.x) >>if 'a.x' in globals(): print('global variable') >>if 'a.x' in locals(): print('local variable') > > Try this: > > if 'x' in

Reset static variables or a workaround

Hi Guys, I have a custom user form class, it inherits my own custom Form class: class UserForm(Form): first_name = TextField(attributes={id='id_firstname'}) Now, everytime UserForm() is instantiated it saves the attributes of each form members and passes it on to the new instance. I

Re: Reset static variables or a workaround

On Thu, Feb 23, 2012 at 1:26 AM, Nav navkir...@gmail.com wrote: Hi Guys, I have a custom user form class, it inherits my own custom Form class: class UserForm(Form):    first_name = TextField(attributes={id='id_firstname'}) Now, everytime UserForm() is instantiated it saves the attributes

Re: Reset static variables or a workaround

Nav wrote: Hi Guys, I have a custom user form class, it inherits my own custom Form class: class UserForm(Form): first_name = TextField(attributes={id='id_firstname'}) Now, everytime UserForm() is instantiated it saves the attributes of each form members and passes it on to the new

Re: having both dynamic and static variables

On Mar 5, 9:44 pm, John Nagle na...@animats.com wrote:     All functions in Python can be replaced dynamically. While they're running. From another thread.  Really. Indeed, and I find this feature VERY useful when coding. Two places I've used it are: 1) in GUI coding (say, when I have a

Re: having both dynamic and static variables

Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote in message news:4d743f70$0$29984$c3e8da3$54964...@news.astraweb.com... On Sun, 06 Mar 2011 12:59:55 -0800, Westley Martínez wrote: I'm confused. Can someone tell me if we're talking about constant as in 'fixed in memory' or as in

Re: having both dynamic and static variables

BartC b...@freeuk.com wrote: Another example: pi=3.141592654 print (pi is:,pi) pi=42 print (pi is now:,pi) which is clearly undesirable. Maybe not if you're the state of Indiana :) -- http://mail.python.org/mailman/listinfo/python-list

Re: having both dynamic and static variables

Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes: but I call that a feature, not a bug. If you want an immutable constant, use a tuple, not a list. Nope: L = ([1,2],[3,4]) # tuple L[0].append(5) # mutate L, in some reasonable sense of mutate --

Re: having both dynamic and static variables

Now you're just muddying the terminology! ~/santa On Mon, Mar 7, 2011 at 1:20 PM, Paul Rubin no.email@nospam.invalid wrote: Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes: but I call that a feature, not a bug. If you want an immutable constant, use a tuple, not a list.

Re: having both dynamic and static variables

On Mon, 07 Mar 2011 13:20:39 -0800, Paul Rubin wrote: Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes: but I call that a feature, not a bug. If you want an immutable constant, use a tuple, not a list. Nope: L = ([1,2],[3,4]) # tuple L[0].append(5) # mutate L, in

Re: having both dynamic and static variables

Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes: L[0].append(5) # mutate L, in some reasonable sense of mutate You haven't mutated the tuple called L. You've mutated its internal components, which are lists. If you wanted them to also be immutable, you should have used

Re: having both dynamic and static variables

On Sat, 05 Mar 2011 20:33:49 -0800, Westley Martínez wrote: On Sat, 2011-03-05 at 18:37 -0800, John Nagle wrote: It's worth having some syntax for constants. I'd suggest using let: +1 on syntax for constants. -0 for let. I'd prefer something more explicit, like const. I'm against

Re: having both dynamic and static variables

On Sun, 2011-03-06 at 07:58 +, Steven D'Aprano wrote: On Sat, 05 Mar 2011 20:33:49 -0800, Westley Martínez wrote: On Sat, 2011-03-05 at 18:37 -0800, John Nagle wrote: It's worth having some syntax for constants. I'd suggest using let: +1 on syntax for constants. -0 for let.

  1   2   3   >