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


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

static variables

Started byUlli Horlacher <framstag@rus.uni-stuttgart.de>
First post2015-11-30 17:15 +0000
Last post2015-12-01 11:47 +0000
Articles 11 on this page of 31 — 13 participants

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 2 of 2 — ← Prev page 1 [2]


#99897

FromAntoon Pardon <antoon.pardon@rece.vub.ac.be>
Date2015-12-02 16:30 +0100
Message-ID<mailman.136.1449070224.14615.python-list@python.org>
In reply to#99877
Op 02-12-15 om 15:15 schreef Ian Kelly:
> 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.

That is not true. I expect that the next time someone will try to
argue for private attributes or some such, Steven will be among
those that will support the "consenting adults" line. This view
of his, is not in the past, it is for all i know still in the
present. That his latest expression was in the past, doesn't make
his view something of the past.

If there was a reason to think he had changed his mind, you would
have been right. But I see no reason for that.

There is a difference between changing your mind and thus change
your arguments and using an argument selectively.

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


#99912

FromIan Kelly <ian.g.kelly@gmail.com>
Date2015-12-02 14:30 -0600
Message-ID<mailman.146.1449088276.14615.python-list@python.org>
In reply to#99877
On Wed, Dec 2, 2015 at 9:30 AM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> wrote:
> Op 02-12-15 om 15:15 schreef Ian Kelly:
>> 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.
>
> That is not true. I expect that the next time someone will try to
> argue for private attributes or some such, Steven will be among
> those that will support the "consenting adults" line. This view
> of his, is not in the past, it is for all i know still in the
> present. That his latest expression was in the past, doesn't make
> his view something of the past.
>
> If there was a reason to think he had changed his mind, you would
> have been right. But I see no reason for that.
>
> There is a difference between changing your mind and thus change
> your arguments and using an argument selectively.

A person can hold one opinion in some contexts and an opposing opinion
in others.

"Speak what you think now in hard words, and to-morrow speak what
to-morrow thinks in hard words again, though it contradict every thing
you said to-day."

"There will be an agreement in whatever variety of actions, so they be
each honest and natural in their hour. For of one will, the actions
will be harmonious, however unlike they seem. These varieties are lost
sight of at a little distance, at a little height of thought. One
tendency unites them all. The voyage of the best ship is a zigzag line
of a hundred tacks. See the line from a sufficient distance, and it
straightens itself to the average tendency. Your genuine action will
explain itself, and will explain your other genuine actions. Your
conformity explains nothing. Act singly, and what you have already
done singly will justify you now."

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


#99943

FromAntoon Pardon <antoon.pardon@rece.vub.ac.be>
Date2015-12-03 10:06 +0100
Message-ID<mailman.163.1449133621.14615.python-list@python.org>
In reply to#99877
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 sufficiently different from the other to support a different
opinion, people can be hypocritical, they can have different preference in
different contexts, they can be biased, they can be in a different mood,
there may be some misunderstanding. Aren't we allowed to probe for what
is behind these opposing opinions?

I know people who will defend a teacher leading a class in prayer in one
context and several months later fight it in an other context. The
difference being that in the first context the teacher's faith is compatible
with there own and in the second context it isn't. When others challenge
them on that and point this out, do you consider it an adequate response
should they react with the quote:

  A foolish consistency is the hobgoblin of little minds.

My opinion is that if one finds oneself in the situation that one comes
to different opinions in different contexts, one should try to find out
on what grounds one does so. And not let possible biases, misunderstandings,
... go unchallenged.

I also see nothing wrong with challenging someone's view when you notice
something like this is going on with them. But that seems to be something
the regulars here have problems with because all too often they respond with
the above quote and react as if that settles the question.

-- 
Antoon.

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


#99856

FromChris Angelico <rosuav@gmail.com>
Date2015-12-02 20:23 +1100
Message-ID<mailman.109.1449048206.14615.python-list@python.org>
In reply to#99841
On Wed, Dec 2, 2015 at 7:21 PM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> 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 statement
> that is essentialy a declaration instead of an executable statement.
> Which goes totally against the dynamic nature op python.

It ought to be initialized at the same time the function is defined -
just like argument defaults, only without them being visible as
arguments. If Python had a keyword that meant
"currently-executing-function", that would work out well for
attributes (and might also make recursion more optimizable);
otherwise, default args are probably the cleanest way we have.

ChrisA

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


#99861

FromAntoon Pardon <antoon.pardon@rece.vub.ac.be>
Date2015-12-02 10:47 +0100
Message-ID<mailman.113.1449049639.14615.python-list@python.org>
In reply to#99841
Op 02-12-15 om 10:23 schreef Chris Angelico:
> On Wed, Dec 2, 2015 at 7:21 PM, Antoon Pardon
> <antoon.pardon@rece.vub.ac.be> 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 statement
>> that is essentialy a declaration instead of an executable statement.
>> Which goes totally against the dynamic nature op python.
> It ought to be initialized at the same time the function is defined -
> just like argument defaults, only without them being visible as
> arguments.

I am not talking about the time. That could be done with something
declarative too. I am talking about where to put in the code.

>  If Python had a keyword that meant
> "currently-executing-function", that would work out well for
> attributes (and might also make recursion more optimizable);
> otherwise, default args are probably the cleanest way we have.

No it wouldn't. Lets call that keyword cef. The fact that you
can write:

def foo():
   cef.attr

instead of

def foo()
   foo.attr

changes nothing about foo.attr being globally accessible.

-- 
Antoon. 

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


#99864

FromMarko Rauhamaa <marko@pacujo.net>
Date2015-12-02 12:18 +0200
Message-ID<87a8ptcfvz.fsf@elektro.pacujo.net>
In reply to#99861
Antoon Pardon <antoon.pardon@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.
If you want a more puristic solution, you could do:

   def _make_f():
       x = 0
       def f():
           nonlocal x
           x += 1
           return x
       return f

   f = _make_f()

   print(f())
   => 1
   print(f())
   => 2
   print(f())
   => 3


Marko

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


#99867

FromAntoon Pardon <antoon.pardon@rece.vub.ac.be>
Date2015-12-02 11:56 +0100
Message-ID<mailman.116.1449053839.14615.python-list@python.org>
In reply to#99864
Op 02-12-15 om 11:18 schreef Marko Rauhamaa:
> Antoon Pardon <antoon.pardon@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.

Some people seem to have a problem with global variables.

-- 
Antoon.

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


#99870

FromMarko Rauhamaa <marko@pacujo.net>
Date2015-12-02 13:30 +0200
Message-ID<8737vlccko.fsf@elektro.pacujo.net>
In reply to#99867
Antoon Pardon <antoon.pardon@rece.vub.ac.be>:

> 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 they are the way to go. For example, if a module function uses a
regular expression, the regular expression should be compiled into a
(module) global variable.

Module functions and classes are global variables as well:

    >>> import math
    >>> def f(x): return -1
    ...
    >>> math.sqrt = f
    >>> math.sqrt(3)
    -1


Marko

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


#99879

FromSteven D'Aprano <steve@pearwood.info>
Date2015-12-03 00:17 +1100
Message-ID<565eef5f$0$1619$c3e8da3$5496439d@news.astraweb.com>
In reply to#99870
On Wed, 2 Dec 2015 10:30 pm, Marko Rauhamaa wrote:

> Antoon Pardon <antoon.pardon@rece.vub.ac.be>:
> 
>> 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 they are the way to go. For example, if a module function uses a
> regular expression, the regular expression should be compiled into a
> (module) global variable.
> 
> Module functions and classes are global variables as well:

Actually, those examples are more usually global *constants* (or at least
the closest thing that Python has to constants). While we can rebind
math.sqrt, as in your example, treating it as a variable, we normally would
not do so. We would normally treat such module level objects as constants.



-- 
Steven

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


#99783

FromWolfgang Maier <wolfgang.maier@biologie.uni-freiburg.de>
Date2015-12-01 10:58 +0100
Message-ID<mailman.60.1448963939.14615.python-list@python.org>
In reply to#99775
On 01.12.2015 09:26, 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)
>
>


I'm wondering whether you have a good reason to stick with a function. 
What you are trying to achieve seems to be easier and cleaner to 
implement as a class:

class Counter (object):
     def __init__ (self, start_value=0):
         self.x = start_value

     def __call__ (self):
         self.x += 1

1) solves the renaming problem
2) allows you to have several counters around:

counter1 = Counter()
counter2 = Counter()
counter3 = Counter(35)
counter1()
counter2()
counter1()
print (counter1.x, counter2.x, counter3.x)

Cheers,
Wolfgang

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


#99792

FromUlli Horlacher <framstag@rus.uni-stuttgart.de>
Date2015-12-01 11:47 +0000
Message-ID<n3k1df$scd$1@news2.informatik.uni-stuttgart.de>
In reply to#99783
Wolfgang Maier <wolfgang.maier@biologie.uni-freiburg.de> 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:
> 
> class Counter (object):
>     def __init__ (self, start_value=0):
>         self.x = start_value
> 
>     def __call__ (self):
>         self.x += 1
> 
> 1) solves the renaming problem
> 2) allows you to have several counters around:
> 
> counter1 = Counter()
> counter2 = Counter()
> counter3 = Counter(35)
> counter1()
> counter2()
> counter1()
> print (counter1.x, counter2.x, counter3.x)

Implementing a counter was only an example for a static variable, not the
primary goal.

With a class, I find it irritating the first function call have to be
different than the subsequent ones:


def main():
  a=A(1)
  a(1)
  a(5)
  a(0)
  print(a.n)

class A(object):
  def __init__ (self,*arg):
    self.n = 0

  def __call__(self,x):
    self.n += 1
    print('%d:' % self.n,x)

main()



-- 
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] | [standalone]


Page 2 of 2 — ← Prev page 1 [2]

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


csiph-web