Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #99746 > unrolled thread

static variables

Back to article view | Back to comp.lang.python

Contents

  static variables Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-30 17:15 +0000
    Re: static variables Terry Reedy <tjreedy@udel.edu> - 2015-11-30 12:38 -0500
    Re: static variables BartC <bc@freeuk.com> - 2015-11-30 20:32 +0000
      Re: static variables Steven D'Aprano <steve@pearwood.info> - 2015-12-01 12:01 +1100
        Re: static variables Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-12-01 08:26 +0000
          Re: static variables Peter Otten <__peter__@web.de> - 2015-12-01 10:01 +0100
          Re: static variables Grobu <snailcoder@retrosite.invalid> - 2015-12-01 10:15 +0100
            Re: static variables Steven D'Aprano <steve@pearwood.info> - 2015-12-02 12:02 +1100
              Re: static variables Erik <python@lucidity.plus.com> - 2015-12-02 01:16 +0000
                Re: static variables Steven D'Aprano <steve@pearwood.info> - 2015-12-02 12:24 +1100
                  Re: static variables Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-12-02 09:21 +0100
                  Re: static variables Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-12-02 09:34 +0100
                    Re: static variables Steven D'Aprano <steve@pearwood.info> - 2015-12-02 21:22 +1100
                      Re: static variables Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-12-02 12:09 +0100
                        Re: static variables Steven D'Aprano <steve@pearwood.info> - 2015-12-03 00:11 +1100
                          Re: static variables Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-12-02 14:41 +0100
                          Re: static variables Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-12-02 13:48 +0000
                          Re: static variables Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-12-02 15:07 +0100
                          Re: static variables Ian Kelly <ian.g.kelly@gmail.com> - 2015-12-02 08:15 -0600
                          Re: static variables Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-12-02 14:31 +0000
                          Re: static variables Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-12-02 16:30 +0100
                          Re: static variables Ian Kelly <ian.g.kelly@gmail.com> - 2015-12-02 14:30 -0600
                          Re: static variables Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-12-03 10:06 +0100
                  Re: static variables Chris Angelico <rosuav@gmail.com> - 2015-12-02 20:23 +1100
                  Re: static variables Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-12-02 10:47 +0100
                    Re: static variables Marko Rauhamaa <marko@pacujo.net> - 2015-12-02 12:18 +0200
                      Re: static variables Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-12-02 11:56 +0100
                        Re: static variables Marko Rauhamaa <marko@pacujo.net> - 2015-12-02 13:30 +0200
                          Re: static variables Steven D'Aprano <steve@pearwood.info> - 2015-12-03 00:17 +1100
          Re: static variables Wolfgang Maier <wolfgang.maier@biologie.uni-freiburg.de> - 2015-12-01 10:58 +0100
            Re: static variables Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-12-01 11:47 +0000

Page 1 of 2  [1] 2  Next page →

#99746 — 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, I get:

: 1
: 2
: 2
2

This is exactly what I expect.
But what is a.x?
It is neither a variable in globals() nor in locals()


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum IZUS/TIK         E-Mail: horlacher@tik.uni-stuttgart.de
Universitaet Stuttgart         Tel:    ++49-711-68565868
Allmandring 30a                Fax:    ++49-711-682357
70550 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [next] | [standalone]

#99753

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: a.x = x
>    print(':',a.x)
>
> main()
>
> When I run this code, I get:
>
> : 1
> : 2
> : 2
> 2
>
> This is exactly what I expect.
> But what is a.x?
> It is neither a variable in globals() nor in locals()

a.x is an attribute of the object a.


-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#99758

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

[toc] | [prev] | [next] | [standalone]

#99760

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 a.__dict__:  print('attribute of a')


That will work in this specific case, but it isn't guaranteed to always
work. Not all objects have a __dict__, even if they can hold attributes,
and not all attributes are stored in a __dict__.

A better and more general test is:

if hasattr(a, 'x'): print('attribute of a')

 

-- 
Steven

[toc] | [prev] | [next] | [standalone]

#99775

Steven D'Aprano <steve@pearwood.info> 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 function I have to rename the attribute also.
Is it possible to refer the attribute automatically to its function?
Something like:

def a(x=None):
  if not hasattr(_function_,'x'): _function_.x = 0
  _function_.x += 1
  print('%d:' % _function_.x,x)


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum IZUS/TIK         E-Mail: horlacher@tik.uni-stuttgart.de
Universitaet Stuttgart         Tel:    ++49-711-68565868
Allmandring 30a                Fax:    ++49-711-682357
70550 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#99779

Ulli Horlacher wrote:

> Steven D'Aprano <steve@pearwood.info> 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 function I have to rename the attribute also.
> Is it possible to refer the attribute automatically to its function?
> Something like:
> 
> def a(x=None):
>   if not hasattr(_function_,'x'): _function_.x = 0
>   _function_.x += 1
>   print('%d:' % _function_.x,x)

Not directly, but there are workarounds:

def with_function(f):
    return functools.partial(f, f)

@with_function
def foo(self, x=None):
    if not hasattr(self, "x"):
        self.x = 0
    self.x += 1
    print("{} called {} times".format(self.__name__, self.x))

[toc] | [prev] | [next] | [standalone]

#99780

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
# -------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#99838

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 being sarcastic, I'm serious. Thank you Grobu, for demonstrating the
existence of something we debated a few days ago.

In another *painfully* long thread about mutable default arguments, I
suggested the same idea: using a mutable default as static storage. It is
very gratifying to see that other people have independently come up with
the same idea.




-- 
Steven

[toc] | [prev] | [next] | [standalone]

#99840

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 caller can override as a local, static, supposedly 
"private" value is IMHO a tad ... ugly? (*)

E.

(*) No I don't want to resurrect that thread.

[toc] | [prev] | [next] | [standalone]

#99841

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!
> 
>> using a mutable default as static storage.
> 
> Exposing something a caller can override as a local, static, supposedly
> "private" value is IMHO a tad ... ugly? (*)


Heh, I agree, and as I suggested, it might be good to have an actual
mechanism for static locals. But using a class is no better: your "static
storage" is exposed as an instance attribute, and even if you flag it
private, *somebody* is going to mess with it.

A closure works, but that obfuscates the code:

def make_test():
    arg = [0]
    def test():
        print arg[0]
        arg[0] += 1
    return test

test = make_test()

Or in Python 3:

def make_test():
    arg = 0
    def test():
        nonlocal arg
        print arg
        arg += 1
    return test

test = make_test()


Python has three not-entirely-awful solutions to the problem of static
locals, but no really great or obvious one.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#99848

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. If you
initialise whithin the body of your function, you will have a statement
that is essentialy a declaration instead of an executable statement.
Which goes totally against the dynamic nature op python.

-- 
Antoon

[toc] | [prev] | [next] | [standalone]

#99850

Op 02-12-15 om 02:24 schreef Steven D'Aprano:
> Heh, I agree, and as I suggested, it might be good to have an actual
> mechanism for static locals. But using a class is no better: your "static
> storage" is exposed as an instance attribute, and even if you flag it
> private, *somebody* is going to mess with it.

Why don't you invoke the consenting adults now? People have come here
arguing for all kind of extra features, which would somehow defend
against messing with certain variable or attributes the author wants
protected. The general respons has always been, that we 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.

[toc] | [prev] | [next] | [standalone]

#99865

On Wed, 2 Dec 2015 07:34 pm, Antoon Pardon wrote:

> Op 02-12-15 om 02:24 schreef Steven D'Aprano:
>> Heh, I agree, and as I suggested, it might be good to have an actual
>> mechanism for static locals. But using a class is no better: your "static
>> storage" is exposed as an instance attribute, and even if you flag it
>> private, *somebody* is going to mess with it.
> 
> Why don't you invoke the consenting adults now? 

Because I don't wish to.

I can invoke consenting adults to defend people drinking soft drinks and
eating chocolate, doesn't mean I have to invoke consenting adults to defend
the practice of middle-class film-makers goading homeless people into
fighting and other dangerous acts for trivial amounts of money.

https://en.wikipedia.org/wiki/Bumfights


> People have come here 
> arguing for all kind of extra features, which would somehow defend
> against messing with certain variable or attributes the author wants
> protected. The general respons has always been, that we are consenting
> adults here.

Yes, and that's fine. Consider the word *judgement* -- in our (the
collective community) judgement, certain 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 to inspect, or even modify, the static variables, you could access
function.__static__[x].


> Static variables, are just a feature to protect what is essentially
> a global variable against messing from somewhere else.

No, that's not the reason for static variables. The primary reasons for
static variables are efficiency and encapsulation.

Efficiency: consider a function that requires a considerable amount of
initialisation, which only needs to be done once. In older languages like
Pascal which lack static variables, you might perform that initialisation
every time you call the function. Or, you might break encapsulation by
storing something that belongs with the function outside the function.
Static variables let you have your cake and eat it too: you can keep the
variable with the function, avoiding namespace pollution, which still
allowing the efficiency of having that variable calculated once only.


> So why is 
> this feature worthy of discussion and others are not?

Because I say so. Since it's my suggestion, that's the only reason I need.

 

-- 
Steven

[toc] | [prev] | [next] | [standalone]

#99869

Op 02-12-15 om 11:22 schreef Steven D'Aprano:
> On Wed, 2 Dec 2015 07:34 pm, Antoon Pardon wrote:
>
>> Op 02-12-15 om 02:24 schreef Steven D'Aprano:
>>> Heh, I agree, and as I suggested, it might be good to have an actual
>>> mechanism for static locals. But using a class is no better: your "static
>>> storage" is exposed as an instance attribute, and even if you flag it
>>> private, *somebody* is going to mess with it.
>> Why don't you invoke the consenting adults now? 
> Because I don't wish to.
>
> I can invoke consenting adults to defend people drinking soft drinks and
> eating chocolate, doesn't mean I have to invoke consenting adults to defend
> the practice of middle-class film-makers goading homeless people into
> fighting and other dangerous acts for trivial amounts of money.
>
> https://en.wikipedia.org/wiki/Bumfights

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 making it sound like an argument.

>> People have come here 
>> arguing for all kind of extra features, which would somehow defend
>> against messing with certain variable or attributes the author wants
>> protected. The general respons has always been, that we are consenting
>> adults here.
> Yes, and that's fine. Consider the word *judgement* -- in our (the
> collective community) judgement, certain things are acceptable for
> consenting adults and others are not.

Which makes "consenting adults" just empty posturing that means nothing
more than /we like it that 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 inspect, or even modify, the static variables, you could access
> function.__static__[x].
>
>
>> Static variables, are just a feature to protect what is essentially
>> a global variable against messing from somewhere else.
> No, that's not the reason for static variables. The primary reasons for
> static variables are efficiency and encapsulation.

No it isn't. Global variables are just as efficient and encapsulation
is just one means to protect a variable against messing.

Efficiency: consider a function that requires a considerable amount of
initialisation, which only needs to be done once. In older languages like
Pascal which lack static variables, you might perform that initialisation
every time you call the function. Or, you might break encapsulation by
storing something that belongs with the function outside the function.
Static variables let you have your cake and eat it too: you can keep the
variable with the function, avoiding namespace pollution, which still
allowing the efficiency of having that variable calculated once only.


>> So why is 
>> this feature worthy of discussion and others are not?
> Because I say so. Since it's my suggestion, that's the only reason I need.
>
>  
>

[toc] | [prev] | [next] | [standalone]

#99877

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 making it sound like an argument.

"A foolish consistency is the hobgoblin of little minds."

Thank you for your feedback. If you ever decide to post here to make
constructive comments or to help others, instead of just flaunting your
imagined superiority and whinging and moaning about the rest of us, then
I'll start to take your arguments seriously too.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#99883

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 argument. You are just showing
>> your preference and making it sound like an argument.
> "A foolish consistency is the hobgoblin of little minds."

So? That doesn't show that we are talking about a foolish consistency here.

This pseudo kind of arguing happens a lot on this list. A lot of the times
one just throws out some proverb as if it is at all clear that the proverb
applies.

Somebody points out an inconsistency and out comes the above proverb, without
much arguments that this inconsisty has advantages over a more consistent
approach.

> Thank you for your feedback. If you ever decide to post here to make
> constructive comments or to help others, instead of just flaunting your
> imagined superiority and whinging and moaning about the rest of us, then
> I'll start to take your arguments seriously too.

Oh come of your high horse. If people use arguments in a selective way,
I can point that out. If you selectively apply an argument so you ignore
the counter arguments when it suits you, that is not a constructive comment
either and you can expect people to point out when that first argument can
be used against you in the same way.

Then going on to complain about non constructive comments seems a bit
disingenous.

-- 
Antoon.

[toc] | [prev] | [next] | [standalone]

#99884

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 showing you don't really have an argument. You are just showing
>>> your preference and making it sound like an argument.
>> "A foolish consistency is the hobgoblin of little minds."
>
> So? That doesn't show that we are talking about a foolish consistency here.
>
> This pseudo kind of arguing happens a lot on this list. A lot of the times
> one just throws out some proverb as if it is at all clear that the proverb
> applies.
>
> Somebody points out an inconsistency and out comes the above proverb, without
> much arguments that this inconsisty has advantages over a more consistent
> approach.
>
>> Thank you for your feedback. If you ever decide to post here to make
>> constructive comments or to help others, instead of just flaunting your
>> imagined superiority and whinging and moaning about the rest of us, then
>> I'll start to take your arguments seriously too.
>
> Oh come of your high horse. If people use arguments in a selective way,
> I can point that out. If you selectively apply an argument so you ignore
> the counter arguments when it suits you, that is not a constructive comment
> either and you can expect people to point out when that first argument can
> be used against you in the same way.
>
> Then going on to complain about non constructive comments seems a bit
> disingenous.
>

Would the pair of you, Antoon and Steven, be kind enough to take your 
bickering offline, thanks.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#99887

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.

[toc] | [prev] | [next] | [standalone]

#99888

On Wed, Dec 2, 2015 at 7:41 AM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> 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 showing you don't really have an argument. You are just showing
>>> your preference and making it sound like an argument.
>> "A foolish consistency is the hobgoblin of little minds."
>
> So? That doesn't show that we are talking about a foolish consistency here.

It's actually the truest use of the quote that I've yet seen on this
list. Emerson was complaining about those who adhere to opinions that
they've expressed in the past solely for the sake of appearing
consistent in their values, which is basically what you're accusing
Steven of not doing.

If you haven't previously read Self-Reliance, I would recommend it as
a good (and short) read.

[toc] | [prev] | [next] | [standalone]

#99889

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 you.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web