B
Bengt Richter
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
"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