> . . .
> ... for _var in list(globals()):
> . . .
> ... exec(f"del {_var}", globals())
> . . .
> ...globals()...
There's a more complicated solution that uses only the locals that requires
getting the previous frame and using `ctypes.pythonapi.PyFrame_LocalsToFast`,
On Sun, Dec 04, 2022 at 01:34:13PM -0800, Bruce Leban wrote:
> I agree with most criticism of this proposal, although I'll note that
> the one place where I'd like something like this is at top level. I
> often write something like this at top level:
>
> __part1 = (some calculation)
> __part2
On Mon, 5 Dec 2022 at 08:34, Bruce Leban wrote:
>
>
> I can put that in a function which still leaves the function in scope:
>
> def __create_thing():
> part1 = (some calculation)
> part2 = (some other calculation)
> return combine(part1, part2)
> THING = __create_thing()
>
> If we
On Sun, Dec 4, 2022 at 11:08 AM Chris Angelico wrote:
>
>
> You're not the first to try to use globals() for this, but it means
> that the context manager works ONLY at top-level.
>
I agree with most criticism of this proposal, although I'll note that the
one place where I'd like something
On 04/12/2022 17:08, Chris Angelico wrote:
On Mon, 5 Dec 2022 at 04:07, Rob Cliffe via Python-ideas
wrote:
On 30/11/2022 20:27, Anony Mous wrote:
Danceswithmice wrote:
The idea is that YOU write "local:", and the interpreter, without you
ever seeing it, promotes that into a hidden
On Mon, 5 Dec 2022 at 06:24, David Mertz, Ph.D. wrote:
>
> On Sun, Dec 4, 2022, 2:08 PM Chris Angelico wrote:
>>
>> You're not the first to try to use globals() for this, but it means that the
>> context manager works ONLY at top-level.
>
>
> True. I know that. But if you're inside a function,
On Sun, Dec 4, 2022, 2:08 PM Chris Angelico wrote:
> You're not the first to try to use globals() for this, but it means that
> the context manager works ONLY at top-level.
True. I know that. But if you're inside a function, you already have scope
containment, so the issue feels like "so
On Mon, 5 Dec 2022 at 06:04, David Mertz, Ph.D. wrote:
>
> Like most commenters, I think the whole "create an anonymous function then
> call it" scoping thing is too complex and has too many edge cases to be a
> good idea.
>
> That said, I decided to play around with what I can do to serve the
Like most commenters, I think the whole "create an anonymous function then
call it" scoping thing is too complex and has too many edge cases to be a
good idea.
That said, I decided to play around with what I can do to serve the general
purpose within existing Python:
>>> @contextmanager
... def
On Mon, 5 Dec 2022 at 04:07, Rob Cliffe via Python-ideas
wrote:
>
>
>
> On 30/11/2022 20:27, Anony Mous wrote:
> > Danceswithmice wrote:
> >
> >
> >
> > The idea is that YOU write "local:", and the interpreter, without you
> > ever seeing it, promotes that into a hidden function with a hidden
> >
On 30/11/2022 20:27, Anony Mous wrote:
Danceswithmice wrote:
The idea is that YOU write "local:", and the interpreter, without you
ever seeing it, promotes that into a hidden function with a hidden
name and a hidden call.
---
p.f.moore wrote:
> That would make "return" in the local
On 2022-12-02 02:48, Anony Mous wrote:
Obviously if you were to say "extend library with X", and X was already
present (remember, these are immutable), such an attempt would fail.
Bang. Exception. The very first time you tried it. Therefore, you're
already directly on the path of "going to
Anony Mous writes:
> You want
> You want
> You want
You can't always get what you want
But if you try some time
You might find
You get what you need.
Batteries included![tm]
Jagger and Richards evidently knew a lot about language design. ;-)
> It works very well, does exactly what I
On Fri, Dec 02, 2022 at 03:48:36AM -0700, Anony Mous wrote:
> These objections -- such as they are -- are all applicable to every
> instance of "I wrote a function" or even "I named a variable" in any
> particular namespace: not just within imports, either. Anywhere. Global
> context. Sub
On Fri, 2 Dec 2022 at 21:49, Anony Mous wrote:
> Or... like these non-Python Ruby people that keep mysteriously polluting the
> argument - just tell the team "we're not going to do that." Again, problem
> solved. You do *not* have to cripple a language to resolve this in any
> particular
These objections -- such as they are -- are all applicable to every
instance of "I wrote a function" or even "I named a variable" in any
particular namespace: not just within imports, either. Anywhere. Global
context. Sub functions. etc.
Collisions, etc... not a big deal. Change a name. It'll
I entirely agree with all of Steven's points. I was going to reply with
similar comments, but his are precisely spot-on, and probably more detailed
than I would have provided.
In particular, the Avdi Grimm essay that Steven linked too is one of the
main references I would have provided as well.
On Thu, Dec 01, 2022 at 03:19:38PM -0700, Anony Mous wrote:
> I'd love to hear a justification -- any justification -- against what I'm
> talking about, because to date, I've never run into one. Many have tried,
> too. :)
What is the `str` interface? Perhaps not the best example, because
> This is very, very deliberately a design goal of Python.
I suspect we're likely not talking about this same "this." Or if we are,
I'd love to hear a justification -- any justification -- against what I'm
talking about, because to date, I've never run into one. Many have tried,
too. :)
I'm
This is very, very deliberately a design goal of Python.
Ruby is a largely similar language that deliberately made the decision you
advocate here. It's a good language, but also one in which monkey patching
by imported modules creates a huge amount of chaos.
Most large Ruby projects have adopted
>> 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: that strings are
created by string syntax. What did you
On 1/12/22 9:27 am, Anony Mous wrote:
The idea is that YOU write "local:", and the interpreter, without you
ever seeing it, promotes that into a hidden function with a hidden name
and a hidden call.
But if that's *all* it does, then this wouldn't happen:
I would expect them to return to, or
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
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:
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
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:
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
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):
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
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
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
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
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
> 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
34 matches
Mail list logo
