>>>>> "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.
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.
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.
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.
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.
Cheers,
-Barry
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4