I just read Guido's http://www.artima.com/weblogs/viewpost.jsp?thread=86641 "Adding Optional Static Typing to Python -- Part II"
and I it struck me that if you step back to a more distant perspective, you can see specific source syntax proposals as a special case of composing program information, and I wondered if the coupling inherent in editing a particular source to add information is always best. Certainly it makes for a handy single-file package of info, unlike C source and header files for example. Not to mention make files and the plethora of information they can direct the composition of. But, e.g., what is the best way to tell python that I intend to use its "sum" builtin to add a list of integers, so that it can figure out that it will be safe to generate machine code using 32-bit integers? Should I have to code a new version with static type declarations? What about stuff I've alrady written, that I'm pretty sure would work fine with floating point, but which has no type information? Should I have to edit that code, that may be in CVS, in order to tell python to generate more specialized code? Or would it be useful to have a specialization tool that I can tell what to do with what existing sources. IOW a pythonic make of some sort. What if specialization info for mylib/myutil.py were in currproj/myutil.pyspec and a pymake or pycc tool knew how to do the right thing? A .pyc file would contain the combined information and specialized code, and a smart inspection tool could show the combined source information in context by going to the relevant sources of myutil.py and myutil.pyspec etc. So the argument that all needs to be in the same file for easy reading is not absolute. Of course, it would be good if the combined presentation format were also a legal input format, for those who want a single specialization in a single file. A specialization tool could well raise exceptions saying a particular source module def foo... can't be specialized as you want, because e.g., it returns both strings and ints, and your interface info says foo(int, int) -> int. Anyway, I consider the Lego-like composability of python programming elements to be one of python's greatest attractions. I hope Guido can figure some way to let us snap in type info without filing existing knobs into new shapes. Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
