homepage

This issue tracker has been migrated to GitHub , and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: way to prevent accidental variable overriding
Type: enhancement Stage:
Components: Interpreter Core Versions: Python 3.2, Python 3.3, Python 3.4
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: Jimbofbx, benjamin.peterson, eric.snow
Priority: normal Keywords:

Created on 2011年12月29日 19:08 by Jimbofbx, last changed 2022年04月11日 14:57 by admin. This issue is now closed.

Messages (5)
msg150344 - (view) Author: James Hutchison (Jimbofbx) Date: 2011年12月29日 19:08
In python is currently there a way to elegantly throw an error if a variable is already in the current scope?
For example:
def longfunc(self, filename):
 FILE = open(filename);
 header = FILE.readline();
 ... bunch of code ...
 childfiles = self.children;
 for child in childfiles:
 FILE = open(child);
 header = FILE.readline();
 ... do something with header ...
 for line in FILE:
 ... etc ...
In this case, I'm accidentally overriding the old values of FILE and header, resulting in a bug. But I'm not going to catch this. I've had a couple of real life bugs due to this that were a lot more subtle and lived for months without anyone noticing the output data was slightly wrong.
This situation could be prevented if there was a way to say something along the lines of "new FILE = open(child)" or "new header = FILE.readline()" and have python throw an error to let me know that it already exists. This would also make code clearer because it allows the intended scope of a variable to become more apparent. Since "new var = something" is a syntax error, adding this functionality wouldn't break old code, as long as python would allow for 'new' (or whatever the keyword would end up being) to also be a variable name (like "new new = 1" or "new = 1")
msg150346 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2011年12月29日 20:09
Interesting thought, the syntax seems unnecessary. Adding new syntax to the language is something that happens rarely and only with a _lot_ of consideration.
As a slightly more verbose alternative, currently you can do this:
 def fail_if_defined(*args, namespace):
 for name in args:
 if name in namespace:
 raise AlreadyBoundError(name)
And in your code you would put the following where you cared about it:
 
 fail_if_defined("FILE", "header", namespace=locals())
You could even drop the namespace parameter (since it's sort of boilerplate):
 def fail_if_defined(*args):
 namespace = inspect.currentframe().f_back.f_locals
 for name in args:
 if name in namespace:
 raise AlreadyBoundError(name)
However, if you are going to the trouble of sticking those in place (or of selectively using a new syntax), you are likely paying attention to the the situation already, rendering either solution unnecessary.
Ultimately, this is something better addressed instead by keeping your functions small, by being a little more cautious in naming, and particularly by careful unit testing.
msg150347 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2011年12月29日 20:39
I think this more the domain of pylint/pyflakes.
msg150349 - (view) Author: James Hutchison (Jimbofbx) Date: 2011年12月29日 21:28
For starters, this would be most efficient implementation:
def unique(varname, value, scope):
 assert(not varname in scope);
 scope[varname] = value;
Usage:
unique('b', 1, locals());
print(b);
But you can't put that in a loop else it will false trigger. Ideally this wouldn't false trigger. This could be done by having python internally associate a line number with each explicit variable declaration.
Anyways, an external python function would be too slow for my use case. Likewise, since it would be something you could use a lot, it should be implemented in the underlying C code to give it minimal overhead.
Keeping functions small is very impractical at times. I shouldn't create 50 randomly named one use functions in my class as a safeguard against accidental overwriting when I have a legitimately complicated piece of code that can't be dissected without becoming unreadable. In many cases I might need 8 or 9 locals at a time in a single line in each loop section.
I don't see how this is the area of pylint/pyflakes at all. The idea is to make it so the human doesn't have to carefully inspect their code in order to decide if they made a mistake or not. Inspecting a long list of warnings is no better, and arguably I could pull up a bunch of python language design decisions and ask why they were made if pylint/pyflakes exists.
If such a change would have be implemented after much consideration and discussion, I don't see how closing my post helps accomplish that.
msg150351 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2011年12月29日 22:02
I suggest you mail python-ideas.
History
Date User Action Args
2022年04月11日 14:57:25adminsetgithub: 57887
2011年12月29日 22:02:02benjamin.petersonsetmessages: + msg150351
2011年12月29日 21:28:42Jimbofbxsetmessages: + msg150349
2011年12月29日 20:39:10benjamin.petersonsetstatus: open -> closed

nosy: + benjamin.peterson
messages: + msg150347

resolution: rejected
2011年12月29日 20:09:55eric.snowsetnosy: + eric.snow
messages: + msg150346
2011年12月29日 19:08:38Jimbofbxcreate

AltStyle によって変換されたページ (->オリジナル) /