[Python-Dev] Revive the types sig?

[Guido van Rossum]

> >>>>> "UO" == Uche Ogbuji <uche.ogbuji@fourthought.com> writes:
> 
>     UO> I know this isn't the types SIG and all, but since it has come
>     UO> up here, I'd like to (once again) express my violent
>     UO> disagreement with the efforts to add static typing to Python.
>     UO> After this, I won't pursue the thread further here.
> 
> Thank you Uche!  I couldn't agree more, and will also try to follow
> your example, at least until we see much more concrete proposals from
> the types-sig.  I just want to make a few comments for the record.

Barry, you were supposed to throw a brick at me with this content at
the meeting, on Eric's behalf.  Why didn't you?  I was waiting for
someone to explain why this was a big idea, but everybody kept their
face shut!  :-(

> First, it seemed to me that the greatest push for static type
> annotations at IPC9 was from the folks implementing Python on top of
> frameworks other than C.  I know from my own experiences that there is
> the allure of improved performance, e.g. JPython, given type hints
> available to the compiler.  While perhaps a laudable goal, this
> doesn't seem to be a stated top priority of Paul's.
> 
> Second, if type annotations are to be seriously considered for
> inclusion in Python, I think we as a community need considerable
> experience with a working implementation.  Yes, we need PEPs and specs
> and such, but we need something real and complete that we can play
> with, /without/ having to commit to its acceptance in mainstream
> Python.  Therefore, I think it'll be very important for type
> annotation proponents to figure out a way to allow people to see and
> play with an implementation in an experimental way.

+1

> This might mean an extensive set of patches, a la Stackless.  After
> seeing and talking to Neil and Andrew about PTL and Quixote, I think
> there might be another way.  It seems that their approach might serve
> as a framework for experimental Python syntaxes with minimal overhead.
> If I understand their work correctly, they have their own compiler
> which is built on Jeremy's tools, and which accepts a modified Python
> grammar, generating different but compatible bytecode sequences.
> E.g., their syntax has a "template" keyword approximately equivalent
> to "def" and they do something different with bare strings left on the
> stack.

I'm not sure this is viable.  I believe Jeremy's compiler package
actually doesn't have its own parser -- it uses the parser module
(which invokes Python's standard parse) and then transmogrifies the
parse tree into something more usable, but it doesn't change the
syntax!  Quixote can get away with this because their only change
is giving a different meaning to stand-alone string literals.  But for
type annotations this doesn't give enough freedom, I expect.

> The key trick is that it all hooks together with an import hook so
> normal Python code doesn't need to know anything about the mechanics
> of PTL compilation.  Given a homepage.ptl file, they just do an
> "import homepage" and this gets magically transformed into a .ptlc
> file and normal Python objects.

That would be nice, indeed.

> If I've got this correct, it seems like it would be a powerful tool
> for playing with alternative Python syntaxes.  Ideally, the same
> technique would allow the types-sig folks to create a working
> implementation that would require only the installation of an import
> hook.  This would let them build their systems with type annotation
> and prove to the skeptical among us of their overwhelming benefit.

+1

--Guido van Rossum (home page: http://www.python.org/~guido/)