This is a massively less ambitious idea, and doesn't solve the
original problem, but:
I'd like to see a scope for names that are "obviously ;-)" meant to be
short lived. At the moment that's the for loop "counters" and those created
by context managers:
for i in something:
# use i as usual
more_code
# now i is not defined
This would be a lot like comprehensions, and for the same reasons (though
less compelling)
And:
with something as a_name:
# use a_name here
more_code
# a_name is not defined.
This just plain makes "natural" sense to me -- a context manager creates,
well, a context. Various cleanup is done at the end of the block. The
variable was created specifically for that context. It's really pretty odd
that it hangs around after the context manager is done -- deleting that
name would seem a natural part of the cleanup a context manager does. This
one seems more compelling than the for loop example.
Consider probably the most commonly used context manager:
with open(a_path, 'w') as output_file:
output_file.write(some-stuff)
# whatever else
now we have a closed, useless, file object hanging around -- all keeping
that name around does is keep that file object from being freed.
The challenge, of course, is that this would be a backward
incompatible change. I don't think it would break much code (though a lot
more for for than with) but maybe it could be enabled with a __future__
import.
In any case, I would much rather have to opt-in to keep that variable
around than opt out with an extra let or something.
-CHB
On Sun, Nov 29, 2020 at 3:59 PM Greg Ewing <greg.ew...@canterbury.ac.nz>
wrote:
> On 29/11/20 11:02 pm, Paul Sokolovsky wrote:
> > It will be much more obvious if there's a general (standalone) "const",
>
> I don't think it will. There's nothing about the problem
> that points towards constness as a solution, so it doesn't
> matter how many other places in the language "const" appears.
>
> And even if you're told about it, you need two or three steps
> of reasoning to understand *why* it solves the problem.
>
> > that's why I'm saying we can't really consider "for const" without just
> > "const"
>
> I agree with that.
>
> > And it's "pretty obvious" to someone who considered various choices and
> > saw pieces falling into their places. Also might be pretty obvious for
> > someone who used other languages.
>
> I strongly suspect it's something that's obvious only in
> hindsight.
>
> --
> Greg
> _______________________________________________
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/KKMR7ZU5Z7KS6VMDVK7Y5X6RBQ2EA7WU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Christopher Barker, PhD
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/NJDCNPLFFQNE4Z57QGFJNG2PEVRIOA76/
Code of Conduct: http://python.org/psf/codeofconduct/
