On 2021-05-27 14:33, Steven D'Aprano wrote:
But even if we did have actual constants, how does that help get static
*variables*, you know, things that aren't constant but can vary?
All of those use cases can already be handled with a class that stores
its data in an attribute.
--
Brendan Ba
Greetings!
The Flag type in the enum module has had some improvements, but I find it necessary to move one of those improvements
into a decorator instead, and I'm having a hard time thinking up a name.
What is the behavior? Well, a name in a flag type can be either canonical (it represents on
On Thu, May 27, 2021 at 7:24 PM Chris Angelico wrote:
> But `len_ = len` does work. However, that doesn't change the
> > calculus at all for me. My point wasn't about using the exact same
> > variable name. It's that ANY ability to create a local variable that is
> > a fast-lookup shortcut f
> > My concern about thread safety is about how easy it would be to make it
> > thread unsafe accidentally.
>
> I'm intrigued what gives you the impression that Python functions and
> classes are, by default, thread safe.
Well, there is thread safe, and there is thread dangerous. I have an
enormo
On 2021-05-28 at 12:22:22 +1000,
Chris Angelico wrote:
> [...] calculate something once and reuse the value, because you know
> that it won't change (or don't care if it changes) [...]
> (Some day I'll learn how to do this in real life. Why can't I buy just
> one egg, and then reuse the same egg
On Fri, May 28, 2021 at 12:13 PM Brendan Barnwell wrote:
>
> On 2021-05-27 13:15, Chris Angelico wrote:
> > H let's see.
> >
> def merge_shortest(things):
> > ... len=len
> > ... ...
> > ...
> merge_shortest([])
> > Traceback (most recent call last):
> >File "", l
On 2021-05-27 13:15, Chris Angelico wrote:
H let's see.
def merge_shortest(things):
... len=len
... ...
...
merge_shortest([])
Traceback (most recent call last):
File "", line 1, in
File "", line 2, in merge_shortest
UnboundLocalError: local variable 'len' referenc
On Thu, May 27, 2021 at 02:02:11PM -0700, Christopher Barker wrote:
> My concern about thread safety is about how easy it would be to make it
> thread unsafe accidentally.
I'm intrigued what gives you the impression that Python functions and
classes are, by default, thread safe.
The FAQ is a li
On 2021-05-27 21:02, Brendan Barnwell wrote:
On 2021-05-27 12:33, Chris Angelico wrote:
With statics, you could write it like this:
def merge_shortest(things):
static len=len
...
Simple. Easy. Reliable. (And this usage would work with pretty much
any of the defined semantics.) There'
On Fri, May 28, 2021 at 7:04 AM Christopher Barker wrote:
>
> My concern about thread safety is about how easy it would be to make it
> thread unsafe accidentally.
>
> Sure, global is not thread safe, but it is well known that use of global is,
> to newbies, “bad”, and to more experienced progra
On Thu, May 27, 2021 at 01:02:15PM -0700, Brendan Barnwell wrote:
> You can already do that:
>
> def merge_shortest(things):
> len=len
> ...
>
> Yes, it does require a single global lookup on each function call,
> but if that's really a bottleneck for you I don't thi
>
> I am confused why you are okay with
> @decorator var: bool
>
> but not
>
> @decorator var
>
> Yes, a bare name is currently an error while just a name and a type hint
> is valid,
> but the latter doesn't bind anything to the name, and using that
> identifier is still
> a NameError. So a decorat
My concern about thread safety is about how easy it would be to make it
thread unsafe accidentally.
Sure, global is not thread safe, but it is well known that use of global
is, to newbies, “bad”, and to more experienced programmers, “to be used
with caution, understanding the risks”.
But particul
On Fri, May 28, 2021 at 6:04 AM Brendan Barnwell wrote:
>
> On 2021-05-27 12:33, Chris Angelico wrote:
> > With statics, you could write it like this:
> >
> > def merge_shortest(things):
> > static len=len
> > ...
> >
> > Simple. Easy. Reliable. (And this usage would work with pretty muc
On 2021-05-27 12:33, Chris Angelico wrote:
With statics, you could write it like this:
def merge_shortest(things):
static len=len
...
Simple. Easy. Reliable. (And this usage would work with pretty much
any of the defined semantics.) There's no more confusion.
You can already
Reply to Chris:
Also it's rarely the case where it can become thread unsafe suddenly. 1 /
10*something chances. Because I've repeatedly run a thread-unsafe code and have
not encountered thread unsafe state yet. GIL executes the code to a very good
extent. And is it hypothetically even possible
Whoops, replying all this time.
On Thu, May 27, 2021 at 2:32 PM micro codery wrote:
>
>
> On Thu, May 27, 2021 at 10:40 AM Matt del Valle
> wrote:
>
> I am still very confused as to the scope of this counter proposal re
> variable
> decorating. I have only seen two such examples here
>
> @decor
On Fri, May 28, 2021 at 5:25 AM Shreyan Avigyan
wrote:
>
> Chris wrote:
> > This is thread-safe:
> >
> > from threading import Lock
> >
> > lock = Lock()
> > counter = 0
> > def get_next():
> >with lock:
> >global counter
> >counter += 1
> >my_counter = counter
>
> This
On Fri, May 28, 2021 at 5:19 AM Brendan Barnwell wrote:
>
> On 2021-05-27 05:18, Steven D'Aprano wrote:
> > On Thu, May 27, 2021 at 07:56:16AM -, Shreyan Avigyan wrote:
> >
> >> Lot of programming languages have something known as static variable
> >> storage in *functions* not *classes*. Stat
Chris wrote:
> This is thread-safe:
>
> from threading import Lock
>
> lock = Lock()
> counter = 0
> def get_next():
>with lock:
>global counter
>counter += 1
>my_counter = counter
This is a great workaround. I can try to improve this. But first of all should
we depen
On 2021-05-27 05:18, Steven D'Aprano wrote:
On Thu, May 27, 2021 at 07:56:16AM -, Shreyan Avigyan wrote:
Lot of programming languages have something known as static variable
storage in *functions* not *classes*. Static variable storage means a
variable limited to a function yet the data it
On 2021-05-26 09:43, Ricky Teachey wrote:
These two ideas of a decorator syntax result are not the same:
RESULT A: function decorator
# func = decorator("spam")(func)
RESULT B: variable decorator
# name = decorator("spam")("name")
...because func is passed as an object, but "name" a string rep
On Fri, May 28, 2021 at 4:49 AM Shreyan Avigyan
wrote:
>
> Reply to Chris:
>
> The only problem is that with that approach that we can't understand if
> that's the last yield statement. To achieve that we need to keep going until
> we encounter a StopIteration. And the value of x would 3. Becaus
On Fri, May 28, 2021 at 4:49 AM Shreyan Avigyan
wrote:
>
> Reply to Chris:
>
> The only problem is that with that approach that we can't understand if
> that's the last yield statement. To achieve that we need to keep going until
> we encounter a StopIteration. And the value of x would 3. Becaus
Reply to Chris:
The only problem is that with that approach that we can't understand if that's
the last yield statement. To achieve that we need to keep going until we
encounter a StopIteration. And the value of x would 3. Because we're not
iterating over a particular generator. We're creating
On Thu, May 27, 2021 at 10:40 AM Matt del Valle
wrote:
> Bikesheddable, but I don't know why having these two be equivalent:
>>
>> @decorator var
>> @decorator var = None
>>
>> ..would be a problem. Having an implied default of None for var above
>> makes sense to my brain. Do you have an example
On Thu, May 27, 2021 at 2:00 PM micro codery wrote:
> ...
>
By providing the name as the first argument, all
> of my examples of callables currently in the standard library will work as
> you
> say out of the box. If it were to be passed in last, this new syntax would
> not be
> usable by any sta
On Fri, May 28, 2021 at 4:14 AM Shreyan Avigyan
wrote:
>
> > A context switch can happen between any two of those instructions.
> > That means one thread could load the global, then another thread could
> > load the same value, resulting in both of them writing back the same
> > incremented value.
> A context switch can happen between any two of those instructions.
> That means one thread could load the global, then another thread could
> load the same value, resulting in both of them writing back the same
> incremented value. Or, between opcodes 6 and 8 (between the lines of
> Python code),
On Thu, May 27, 2021 at 9:34 AM Ricky Teachey wrote:
> On Thu, May 27, 2021 at 10:25 AM Steven D'Aprano
> wrote:
>
> No, I understood the OP's proposal perfectly. I was agreeing with you
> implicitly when you previously said the inconsistency between the OP's
> proposal and current decorator is
On Thu, May 27, 2021 at 1:40 PM Matt del Valle wrote:
> ...
Oh, and I think I've just discovered another thing that I'm not 100% sure I
> like. Even putting aside that I'm not a fan of decorators on the same line
> as the statement they are decorating (as I mentioned in an earlier
> response),
>
> Bikesheddable, but I don't know why having these two be equivalent:
>
> @decorator var
> @decorator var = None
>
> ..would be a problem. Having an implied default of None for var above
> makes sense to my brain. Do you have an example in mind where you think it
> would create a problem?
>
I do
On Thu, 27 May 2021 at 10:39, Paul Moore wrote:
[...]
> the performance aspect, function
> attributes provide this functionality, but there's a significant
> problem with using them because you can't access them other than by
> referencing the *name* of the function being defined.
> [...]
>
> It
You can just use nonlocal variables:
def stator():
static_var_1 = 0
def myfunc(n):
nonlocal static_var_1
static_var_1 += n
return static_var_1
return myfunc
myfunc = stator()
del stator
Or you can attach any variable to the function itself:
def myfunc(n):
On 2021-05-27 17:44, Shreyan Avigyan wrote:
My proposal is somewhat the sum of all of your ideas. Well I propose there
should a STORE_STATIC_FAST opcode that stores a static variable. Static
variable will be declared only once and will be initialized to None (statement
syntax will be similar t
On Fri, May 28, 2021 at 2:44 AM Shreyan Avigyan
wrote:
>
> My proposal is somewhat the sum of all of your ideas. Well I propose there
> should a STORE_STATIC_FAST opcode that stores a static variable. Static
> variable will be declared only once and will be initialized to None
> (statement synt
On Thu, May 27, 2021 at 11:09 AM Matt del Valle
wrote:
>
>> I'm not the OP, but the way I understand the proposal __decoration_call__
> is only invoked when you actually *use an object to decorate something*.
> That means that a decorator factory will just invoke __call__ as normal,
> because it'
My proposal is somewhat the sum of all of your ideas. Well I propose there
should a STORE_STATIC_FAST opcode that stores a static variable. Static
variable will be declared only once and will be initialized to None (statement
syntax will be similar to that of global). It will be initialized in
On Thu, May 27, 2021 at 10:25 AM Steven D'Aprano
wrote:
> On Wed, May 26, 2021 at 12:43:48PM -0400, Ricky Teachey wrote:
>
> [...]
> > These two ideas of a decorator syntax result are not the same:
> >
> > RESULT A: function decorator
> > # func = decorator("spam")(func)
> >
> > RESULT B: variabl
On Fri, May 28, 2021 at 2:03 AM Steven D'Aprano wrote:
> I'll admit I'm not an expert on the various LOAD_* bytecodes, but I'm
> pretty sure LOAD_FAST is used for local variables. Am I wrong?
You're correct, but I dispute that that's the best way to do things.
> Right. In principle we could just
On Thu, May 27, 2021 at 04:53:17PM +0200, Ronald Oussoren via Python-ideas
wrote:
> Statics are still hidden global state
How are they *global* state when they are specific to an individual
function?
We can already get the basic behaviour of statics right now, only with
an ugly hack that poll
On Thu, May 27, 2021 at 11:21:26PM +1000, Chris Angelico wrote:
> On Thu, May 27, 2021 at 10:20 PM Steven D'Aprano wrote:
> > Here is a sketch of how this could work, given a function like this:
> >
> > def func(arg):
> > static spam, eggs
> > static cheese = expression
> >
On Fri, May 28, 2021 at 1:17 AM Christopher Barker wrote:
>>
>>
>> Statics are still hidden global state, and those can be problematic
>> regardless of being function local or module global. Having global state
>> like this affects testability and can affect threading as well.
>
>
> I think this
On Thu, 27 May 2021 at 15:49, Chris Angelico wrote:
>
> On Fri, May 28, 2021 at 12:25 AM Paul Moore wrote:
> >
> > On Thu, 27 May 2021 at 15:04, Chris Angelico wrote:
> > def static(**statics):
> > def deco(func):
> > for name, value in statics.items():
> > setattr(func,
On Thu, May 27, 2021 at 04:37:10PM +0200, Ronald Oussoren wrote:
> > One common use for function defaults is to optimize function lookups to
> > local variables instead of global or builtins:
> >
> >def func(arg, len=len):
> ># now len is a fast local lookup instead of a slow name lo
I'll try to implement the idea roughly and I'll try to observe how much
performance improvements (or the opposite) will occur.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://
>
>
> Statics are still hidden global state, and those can be problematic
> regardless of being function local or module global. Having global state
> like this affects testability and can affect threading as well.
>
I think this is a very good point. I'm no expert, but I know a HUGE amount
of old
>
> What happens if the decorator factory has `__decoration_call__` and the
> object it returns only has `__call__`? I presume you get this:
>
> func = decorator.__decoration_call__("spam this",
> "func").__call__(func)
>
> And let's not forget the other two combinations:
>
> func = decorat
> On 27 May 2021, at 11:42, Chris Angelico wrote:
>
> On Thu, May 27, 2021 at 7:20 PM Ronald Oussoren via Python-ideas
> wrote:
>> On 27 May 2021, at 09:56, Shreyan Avigyan wrote:
>>
>>> Static should behave much like Python's for loop variables.
>
> I have no idea what this means.
>>
>> F
On Thu, May 27, 2021 at 08:46:03AM -0400, Ricky Teachey wrote:
> Couldn't you already get pretty close to this by attaching your static
> values to the function __dict__?
Sure, we can use function attributes as a form of static storage, and I
have done that. It is sometimes quite handy. But it'
oops, forgot to include the list.
i really hate lists that don't have the the list as the default reply
setting :-(
(Yes, I know that goes against the conventional wisdom)
On Wed, May 26, 2021 at 9:14 AM Shreyan Avigyan
> wrote:
>
>> Well. How can I go beyond why constant was invented in the fi
On Fri, May 28, 2021 at 12:25 AM Paul Moore wrote:
>
> On Thu, 27 May 2021 at 15:04, Chris Angelico wrote:
> > Hmm.
> >
> > def static(**kw):
> > def deco(func):
> > statics = types.SimpleNamespace(**kw)
> > @functools.wraps(func)
> > def f(*a, **kw):
> > f
> On 27 May 2021, at 14:18, Steven D'Aprano wrote:
>
> On Thu, May 27, 2021 at 07:56:16AM -, Shreyan Avigyan wrote:
>
>> Lot of programming languages have something known as static variable
>> storage in *functions* not *classes*. Static variable storage means a
>> variable limited to a
On Thu, 27 May 2021 at 15:04, Chris Angelico wrote:
> Hmm.
>
> def static(**kw):
> def deco(func):
> statics = types.SimpleNamespace(**kw)
> @functools.wraps(func)
> def f(*a, **kw):
> func(*a, **kw, _statics=statics)
> return f
> return deco
>
>
On Wed, May 26, 2021 at 12:43:48PM -0400, Ricky Teachey wrote:
[...]
> These two ideas of a decorator syntax result are not the same:
>
> RESULT A: function decorator
> # func = decorator("spam")(func)
>
> RESULT B: variable decorator
> # name = decorator("spam")("name")
>
> ...because func is
On Thu, May 27, 2021 at 11:38 PM Paul Moore wrote:
>
> This reminds me, if we ignore the performance aspect, function
> attributes provide this functionality, but there's a significant
> problem with using them because you can't access them other than by
> referencing the *name* of the function be
On Thu, 27 May 2021 at 14:22, Chris Angelico wrote:
> Note that the statics *must* be defined on the function, NOT on the
> code object. Just like function defaults, they need to be associated
> with individual instances of a function.
>
> >>> f = []
> >>> for n in range(10):
> ... def spam(n
On Thu, May 27, 2021 at 10:20 PM Steven D'Aprano wrote:
> Here is a sketch of how this could work, given a function like this:
>
> def func(arg):
> static spam, eggs
> static cheese = expression
> ...
>
>
> At function declaration time, the two static statements tell th
For the implementation I had the same idea as Steven. And I don't think static
variables should stored in __dict__ or __defaults__. Instead to increase
efficiency (more importantly not to decrease current efficiency) it should be
stored as a dict in __static__ or some other dunder member.
__
On Thu, May 27, 2021 at 8:19 AM Steven D'Aprano wrote:
> On Thu, May 27, 2021 at 07:56:16AM -, Shreyan Avigyan wrote:
>
> > This idea proposes to add a keyword
> > (static, maybe?) that can create static variables that can persist
> > throughout the program yet only accessible through the fun
On 2021-05-27 at 22:33:25 +1000,
Steven D'Aprano wrote:
> Aside from globals, which we agree are Considered Harmful, you've
> suggested two alternative implementations:
>
> - something with closures;
>
> - hidden state in an object with a `__call__` method.
>
> Closures are cool, but the hidd
On Thu, May 27, 2021 at 11:17:18AM +0200, Ronald Oussoren via Python-ideas
wrote:
> For this particular question/proposal: “static” variables in functions
> in C like languages are basically hidden global variables, and global
> variables are generally a bad idea.
Python is not required to use
On Thu, May 27, 2021 at 07:56:16AM -, Shreyan Avigyan wrote:
> Lot of programming languages have something known as static variable
> storage in *functions* not *classes*. Static variable storage means a
> variable limited to a function yet the data it points to persists
> until the end of
Reply to Chris:
I'm proposing a way to do this officially in Python. For example I know another
hack,
def count(cur={"cur":0}):
cur["cur"] += 1
return cur
>> Static should behave much like Python's for loop variables.
> I have no idea what this means.
That's a bad example. I was just t
On 2021-05-27 10:39, Shreyan Avigyan wrote:
Well sometimes we don't want to pollute the module namespace. Two functions can
have two variables with the same name but with different values that we want to
be static. And this functionality already exists in Python but as a *hack*.
This idea prop
On Thu, May 27, 2021 at 7:20 PM Ronald Oussoren via Python-ideas
wrote:
> On 27 May 2021, at 09:56, Shreyan Avigyan wrote:
>
> > Static should behave much like Python's for loop variables.
I have no idea what this means.
>
> For this particular question/proposal: “static” variables in functions
Well sometimes we don't want to pollute the module namespace. Two functions can
have two variables with the same name but with different values that we want to
be static. And this functionality already exists in Python but as a *hack*.
This idea proposes to add a new dunder member and a keyword
> I should probably explain (again) why I am not a fan of such a change.
We have read your blog, Guido:-) Yet, this "feature" is one of top Python's
misfeatures, ex. for Fernando Perez. I share his opinion too.
The numbers module borrowed from the Scheme numbers tower, yet it doesn't use
the
On 26/05/2021 08:25, Shreyan Avigyan wrote:
Reply to Chris:
There are two things I want to say about constants :-
1) Global-Local Constants - The ALL_CAPS convention variables should become
constant.
Good luck enforcing that on every Python programmer. Should it apply to
variable names lik
> On 27 May 2021, at 09:56, Shreyan Avigyan wrote:
>
> Lot of programming languages have something known as static variable storage
> in *functions* not *classes*. Static variable storage means a variable
> limited to a function yet the data it points to persists until the end of the
> progr
Lot of programming languages have something known as static variable storage in
*functions* not *classes*. Static variable storage means a variable limited to
a function yet the data it points to persists until the end of the program.
Well Python also kind of has that functionality. Python's def
> Yes, but having a faster fraction type would be great. SymPy doesn't
> actually use the fractions module because it's too slow. Instead SymPy
> has its own pure Python implementation
Oscar, I think now (3.10) the stdlib implementation arithmetics is optimized
like the SymPy's pure Python fallba
72 matches
Mail list logo
