> On 29 Nov 2022, at 14:34, Anony Mous wrote:
>
>
> As it stands now, to create a local scope, you must define a function.
>
> However, there are many cases where various things can reasonably be done
> inline. Preparatory code is often done this way.
>
> Good coding practice is generally
Barry wrote:
> The ways scoping works in python is very hard to change as you are asking
for i think was a major reason to reject.
Perhaps it isn't all that difficult;
For instance, a "local:" declaration could be treated as if it were "def
function()" with an immediately succeeding call as far
Dear Mous[e],
On 29/11/2022 14.49, Anony Mous wrote:
As it stands now, to create a local scope, you must define a function.
...
Good coding practice is generally accepted to be that variables are
local if at all possible. However, in direct, inline Python code, we're
inherently creating var
On Wed, 30 Nov 2022 at 18:02, Anony Mous wrote:
> For instance, a "local:" declaration could be treated as if it were "def
> function()" with an immediately succeeding call as far as the interpreter
> is concerned. That buys the scoping for (nearly) free.
>
That would make "return" in the local
On Thu, 1 Dec 2022 at 05:03, Anony Mous wrote:
>
> Barry wrote:
>
> > The ways scoping works in python is very hard to change as you are asking
> > for i think was a major reason to reject.
>
> Perhaps it isn't all that difficult;
>
> For instance, a "local:" declaration could be treated as if it
On Thu, 1 Dec 2022 at 05:13, dn wrote:
> > This is the scoping equivalent of a pair of curly braces in c and c++. I
> > would like to see it be nestable, as scopes are in c/c++:
>
> Aside: statements seeking justification from other languages invite an
> obvious retort, along the lines of 'use [wh
A context manager could be used for this. On exit it should delete the
variables created inside it. Someting like this:
class Scope:
def __enter__(self):
self._globals = list(globals().keys())
return self
def __exit__(self, exc_type, exc_value, traceback):
del_var
On Thu, 1 Dec 2022 at 06:47, Benedict Verhegghe wrote:
>
> A context manager could be used for this. On exit it should delete the
> variables created inside it. Someting like this:
>
> class Scope:
> def __enter__(self):
> self._globals = list(globals().keys())
> return self
It seems to me it would safer to do this in conjunction with
contextvars.ContextVar.
On Wed, Nov 30 2022 at 08:44:50 PM +0100, Benedict Verhegghe
wrote:
A context manager could be used for this. On exit it should delete the
variables created inside it. Someting like this:
class Scope:
de
Danceswithmice wrote:
> The larger criticism of the above is the chosen-name
The name is irrelevant; an extremely minor implementation detail, and one
that is meaningless if the idea itself does not pass muster. Users would
not see the name in any case; it's an interpreter level issue. So on with
On Wed, Nov 30, 2022 at 01:27:32PM -0700, Anony Mous wrote:
> the string class, which has some annoying tight couplings to "string" and
> 'string')
What does that mean?
It sounds like you are complaining that the syntax for creating strings
creates strings. Or possibly the other way around: tha
On 1/12/22 6:58 am, Anony Mous wrote:
local:
for MyVal in range(0,10)
pass
provides scoping, making it
easier for us to code, debug, and document, while significantly
decreasing the likelihood of variable collisions.
I'm not convinced it would be beneficial in Python. In C
you
12 matches
Mail list logo
