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 instances
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 not
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; if
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 functi
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:
>>
>>> NO
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
> m
To: Stefan Ram
From: "Bart"
To: Stefan Ram
From: Bart
On 23/06/2018 14:32, Stefan Ram wrote:
> 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":
>
>
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():
d
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
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 thi
From: "Chris Angelico"
From: Chris Angelico
On Sat, Jun 23, 2018 at 1:51 PM, 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 glo
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 that.
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. Giv
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
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
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
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 functi
From: Steven D'Aprano
On Sat, 23 Jun 2018 18:29:51 +0100, MRAB wrote:
> You can already do something similar like this:
>
> def f():
> f.x += 1
> return f.x
> f.x = 0
>
> [snip]
You can, but only as an illustration, not as a serious implementation.
The whole point of static local v
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()
>
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 i
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 obje
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 y
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 your
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 REFERENC
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 copi
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 functio
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():
>
From: MRAB
On 2018-06-23 05:16, Chris Angelico wrote:
> On Sat, Jun 23, 2018 at 1:51 PM, 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 sam
To: Stefan Ram
From: Bart
On 23/06/2018 14:32, Stefan Ram wrote:
> 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
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( g
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>
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
retur
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 th
From: Chris Angelico
On Sat, Jun 23, 2018 at 1:51 PM, 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 t
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
> n
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 o
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
On Sat, 23 Jun 2018 18:29:51 +0100, MRAB wrote:
> You can already do something similar like this:
>
> def f():
> f.x += 1
> return f.x
> f.x = 0
>
> [snip]
You can, but only as an illustration, not as a serious implementation.
The whole point of static local variables is that they
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 ca
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()
> )
>
>
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, essentiall
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 th
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:
>>>
>>>
>>>
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 REFERENC
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
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
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
>
On 2018-06-23 05:16, Chris Angelico wrote:
On Sat, Jun 23, 2018 at 1:51 PM, 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 variab
On 23/06/2018 14:32, Stefan Ram wrote:
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
return f.x
retu
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 digital
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. There
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.
Well,
On Sat, Jun 23, 2018 at 1:51 PM, 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
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 sufficient
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 pm, Antoon Pardon wrote:
> If you want your arguments
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 better should.
If you use
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 yo
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 it suits you and ignore it when
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
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 sho
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 argu
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 go around defining global variab
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 mak
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 they are the way to go. For exampl
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
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 variables.
--
Antoon.
--
https:
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, an
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.
Anyway, in practice I handle such "static" variables as module globals.
If you want a more puristic solution, you could do:
def _ma
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 whithin the body of your function, y
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 statement
> that is essentialy a decl
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
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.
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!
>
>> us
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 calle
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 bein
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:
>
> class Counter (object):
> def __i
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 the calls of a()
But
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
# -
--
ht
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 the calls of
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 function I have to renam
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.__di
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
--
https://mail.python.org/mail
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
In article <[EMAIL PROTECTED]>, kj wrote:
>
>
>Yet another noob question...
>
>Is there a way to mimic C's static variables in Python? Or something
>like it? The idea is to equip a given function with a set of
>constants that belong only to it, so as not to clutter the global
>namespace with vari
kj wrote:
> Yet another noob question...
>
> Is there a way to mimic C's static variables in Python? Or something
> like it? The idea is to equip a given function with a set of
> constants that belong only to it, so as not to clutter the global
> namespace with variables that are not needed el
On Jul 29, 2:40 pm, kj <[EMAIL PROTECTED]> wrote:
> Yet another noob question...
>
> Is there a way to mimic C's static variables in Python? Or something
> like it? The idea is to equip a given function with a set of
> constants that belong only to it, so as not to clutter the global
> namespace
kj was kind enough to say:
> In this case, foo is defined by assigning to it a closure that has
> an associated variable, $x, in its scope.
>
> Is there an equivalent in Python?
There've been plenty of answers, and I'm not absolutely sure about what you
want... but closures are available in Pyth
This is the solution I suggest. It is fairly trivial, and works by
introducing the "self.static" namespace for a class's static
variables, in contrast to "self" for the class's instance variables.
---
class Static(object): pass
personStatic = Static()
class Pers
On Jul 29, 8:38 pm, pigmartian <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > kj:
> >> OK, I guess that in Python the only way to do what I want to do
> >> is with objects...
>
> > There are other ways, like assigning the value out of the function,
> > because Python functions too are ob
On Jul 30, 11:57 am, "Russ P." <[EMAIL PROTECTED]> wrote:
> On Jul 29, 6:33 pm, "Russ P." <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Jul 29, 1:40 pm, kj <[EMAIL PROTECTED]> wrote:
>
> > > Yet another noob question...
>
> > > Is there a way to mimic C's static variables in Python? Or something
> > > l
On Jul 29, 6:33 pm, "Russ P." <[EMAIL PROTECTED]> wrote:
> On Jul 29, 1:40 pm, kj <[EMAIL PROTECTED]> wrote:
>
>
>
> > Yet another noob question...
>
> > Is there a way to mimic C's static variables in Python? Or something
> > like it? The idea is to equip a given function with a set of
> > const
[EMAIL PROTECTED] wrote:
kj:
OK, I guess that in Python the only way to do what I want to do
is with objects...
There are other ways, like assigning the value out of the function,
because Python functions too are objects:
...
But I suggest you to use a class in this situation, it's often th
On Jul 29, 1:40 pm, kj <[EMAIL PROTECTED]> wrote:
> Yet another noob question...
>
> Is there a way to mimic C's static variables in Python? Or something
> like it? The idea is to equip a given function with a set of
> constants that belong only to it, so as not to clutter the global
> namespace
On Tue, 29 Jul 2008 21:31:01 +, kj wrote:
> In <[EMAIL PROTECTED]> Larry Bates <[EMAIL PROTECTED]> writes:
>
> [snip]
>
> Maybe it's easier to see what I mean with JavaScript:
>
> function foo() {
> if (foo.x === undefined) foo.x = expensive_call();
> return do_stuff_with(foo.x);
> }
de
kj <[EMAIL PROTECTED]> writes:
> Is there a way to mimic C's static variables in Python? Or something
> like it?
A "static variable" in C is one that has access limited to the scope
in which it is declared.
Python approaches the same issue through namespaces: a name binding
made at a class or mo
kj:
> OK, I guess that in Python the only way to do what I want to do
> is with objects...
There are other ways, like assigning the value out of the function,
because Python functions too are objects:
def iamslow():
return 100
def foo(x):
return x + foo.y
foo.y = iamslow() # slow computat
kj wrote:
In <[EMAIL PROTECTED]> Larry Bates <[EMAIL PROTECTED]> writes:
kj wrote:
Yet another noob question...
Is there a way to mimic C's static variables in Python? Or something
like it? The idea is to equip a given function with a set of
constants that belong only to it, so as not to cl
In <[EMAIL PROTECTED]> Larry Bates <[EMAIL PROTECTED]> writes:
>kj wrote:
>> Yet another noob question...
>>
>> Is there a way to mimic C's static variables in Python? Or something
>> like it? The idea is to equip a given function with a set of
>> constants that belong only to it, so as not to
kj wrote:
Yet another noob question...
Is there a way to mimic C's static variables in Python? Or something
like it? The idea is to equip a given function with a set of
constants that belong only to it, so as not to clutter the global
namespace with variables that are not needed elsewhere.
Fo
[EMAIL PROTECTED] a écrit :
> Bruno Desthuilliers:
>> And this let you share state between functions:
>>
>> def make_counter(start_at=0, step=1):
>>count = [start_at]
>>def inc():
>> count[0] += step
>> return count[0]
>>def reset():
>> count[0] = [start_at]
>> retur
1 - 100 of 129 matches
Mail list logo
