[Edu-sig] On case sensitivity
Fri, 4 Feb 2000 12:23:07 -0500
> Actually, I want to create an IDE that is sufficiently aware of the
> syntax that it can tell assignment from use in most cases.
What is the desired behavior in this case?
t = 5
T = -t
It seems that T should be corrected to t, but in that case there is little
need to distinguish assignment from use.
Separately, I think the following heuristic would be valuable (and does
require the distinction): Assignment to a variable which is never used
should generate a warning in the IDE. This helps with a vast class of
typographical errors which are not limited to case errors.
A single typo in use will usually generate an exception:
position = 5
position = posiiton + 1 # error
At present, though, a typo in an lvalue is silently ignored:
position = 5
posiiton = position + 1 # silent failure
> It would parse the module source code (caching results to make the
> time expenditure acceptable).
Reasonable, provided it can deal successfully with dynamic importing
(worst-case is acceptable, but see below).
> For extension modules it could simply
> import the module and report the names it defines. We may also create
> special interface description files in a dialect of Python to describe
> extensions; the work being done in the Python type-sig on optional
> static typing is relevant here.
Importing a module might have side effects. One thing I think is axiomatic
is that the IDE must not crash. Never ever ever, no matter what the user
program does. If a program loads itself or another broken program as a
module, the IDE must not go off trying to solve the halting problem.
> This is not very common (usually the from M import * is executed
> unconditionally) so it will rarely be a problem. The IDE could always
> compute a worst case outcome.
Even worst-case is hard when there are calls to __import__ like this
(somewhere obscure in \python\Lib):
for _name in _names:
_mod = __import__(_name)
if not _defaultmod:
_defaultmod = _mod
Fortunately, these symbols will not end up in the global namespace unless
the user takes extraordinary measures. There are cases where they can, like
elif 'nt' in names:
from nt import *
for i in ['_exit']:
exec "from nt import " + i
The standard libraries could be special-cased or altered; the real worry is
something like an extension module that does this sort of thing in C. I
doubt that's very common, but the IDE can never prove that an identifier is
It would be nice to say, "if the IDE can't figure out a module, it just
doesn't do case correction in that module's namespace." The presence of
from ... import * breaks this approach.
OTOH, it is probably not an entirely bad thing to encourage people to avoid
from ... import * for modules that define names dynamically!
p.s. I just read Gerrit's post, and the point about the
foo = Foo()
idiom is disturbing. What can the IDE do about that?