[Types-sig] Proposed Goals PEP

Jeremy Hylton jeremy@alum.mit.edu
Sun, 11 Mar 2001 21:25:57 -0500 (EST)


>>>>> "NK" == Krishnaswami, Neel <neelk@cswcasa.com> writes:

  >> 2. Better Documentation (major)
  >>
  >> Right now, it is basically impossible for programs like PyDoc or
  >> IDLE to detect the types of arguments to functions. This makes it
  >> difficult to give the user a clear summary of what a function
  >> expects or returns.

  NK> This isn't going to help unless you have parametrized types. The
  NK> most common case of type error in my code is when I pass in a
  NK> list or dictionary with bogus element types. This is because
  NK> usually a general list or dictionary of a particular shape is
  NK> being used as a custom "type." Errors with incorrectly handling
  NK> primitive types just doesn't seem to happen to me -- even the
  NK> string/sequence thing basically never bites me.

I agree that problems with container elements is a common problem.  In
the absence of a system with parameterized types, it appears that we
declare lots of "any"s and add a cast mechanism.  Yuck.

  >> 3. Optimization (minor)
  >>
  >> If a Python compiler knew that a function works on integers or
  >> strings then it could internally use bytecode or native code
  >> optimized for integers or strings.

  NK> This is a totally unrealistic expectation. Adding typechecking
  NK> is going to make typed Python code slower, not faster, for a
  NK> very long time.

I agree with you here, too.  I'd be interested to hear how much of a
slowdown in Python runtime speed is acceptable to support error
checking and/or documentation.

  NK> This should not be a 1.0 goal -at all-, except in the modest
  NK> sense that typed code shouldn't run too much more slowly than
  NK> ordinary Python code. If you want to improve performance, focus
  NK> on improving performance as a *separate* task -- stealing Scheme
  NK> interpreter implementation tricks can win a 2-5x speedup without
  NK> changing Python's semantics at all.

A 2-5x improvement sounds bigger than I would expect.  What Scheme
implementation techniques did you have in mind?

Jeremy