
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.ewing@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-leave@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/KKMR7Z... Code of Conduct: http://python.org/psf/codeofconduct/