type declarations, interfaces, etc as program information composition

Discussion in 'Python' started by Bengt Richter, Jan 5, 2005.

  1. 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
     
    Bengt Richter, Jan 5, 2005
    #1
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Code4u
    Replies:
    9
    Views:
    2,775
  2. Robin Cull
    Replies:
    5
    Views:
    417
    Andrew Dalke
    Jul 31, 2003
  3. Kevin Walzer

    Re: PIL (etc etc etc) on OS X

    Kevin Walzer, Aug 1, 2008, in forum: Python
    Replies:
    4
    Views:
    430
    Fredrik Lundh
    Aug 13, 2008
  4. paulo
    Replies:
    9
    Views:
    725
    James Kanze
    Mar 6, 2009
  5. Jeremy
    Replies:
    1
    Views:
    376
    John Saunders [MVP]
    Jul 18, 2007
Loading...

Share This Page