[Edu-sig] On case sensitivity

[David Scherer]

> 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
if t<0:
  T = -t
print 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
print position

At present, though, a typo in an lvalue is silently ignored:

position = 5
posiiton = position + 1  # silent failure
print position

> 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:
    try:
        _mod = __import__(_name)
    except ImportError:
        continue
    if not _defaultmod:
        _defaultmod = _mod
    _errors.append(_mod.error)

Fortunately, these symbols will not end up in the global namespace unless
the user takes extraordinary measures.  There are cases where they can, like
os.py:

elif 'nt' in names:
    from nt import *
    for i in ['_exit']:
        try:
            exec "from nt import " + i
        except ImportError:
            pass

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
undefined.

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!

Dave Scherer

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?