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() ); }
>
> transcri
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
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 var
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
gt;
> which adds local variables 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 usefu
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.
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 functi
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
; (hence 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
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():
>
static len=len, int=int, str=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
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 possibl
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
les 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!
>
Okay, that m
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 i
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
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
w
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
>
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!
Okay, that makes sense. So in a way, static variab
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 functio
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,
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
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 Pyt
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
othing
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 defaul
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:
nity) 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 a
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 solu
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
n, 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.
--
https://mail.python.org/mailman/listinfo/python-list
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
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,
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 instanc
On Thu, Feb 23, 2012 at 1:26 AM, 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 fo
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 understa
On Mar 5, 9:44 pm, John Nagle 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 panel of buttons, an
"BartC" 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
"Steven D'Aprano" 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 'you can't reassign' or both?
Python
Steven D'Aprano 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 tuples :)
Obviously you are
On Mon, 07 Mar 2011 13:20:39 -0800, Paul Rubin wrote:
> Steven D'Aprano 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 "
Now you're just muddying the terminology!
~/santa
On Mon, Mar 7, 2011 at 1:20 PM, Paul Rubin wrote:
> Steven D'Aprano 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(
Steven D'Aprano 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"
--
http://mail.python.org/mailman/listinfo/python-list
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 'you can't reassign' or both?
Python already has fixed in memory constants. They are immutable objects
like strings, ints, floats, et
John Nagle wrote:
"let" allows the usual optimizations - constant folding, hoisting
out of loops, compile time arithmetic, unboxing, etc.
Only if the compiler knows the value of the constant,
which it won't if it's defined in a different module.
--
Greg
--
http://mail.python.org/mailman/listi
1 - 100 of 217 matches
Mail list logo
