Python design strategy (was Python evolution: Unease)

Discussion in 'Python' started by ajsiegel@optonline.net, Jan 4, 2005.

  1. Guest

    Viile writes -

    >Type declarations are a feature that might benefit IronPython and
    >Jython more than they would CPython.


    How much is this part of Guido's decisionmaking process?

    Guido is , IMO, very much a strategist, as well as a language designer.

    That's good, I think.

    However it seems to me he is much more comfortable discussing
    language design with the community. then he is in discussing
    strategy.

    That, I think, is a strategic decision.

    Understandable, in fact.

    Nonetheless, I have been uncomfortable with this strategy in the past.

    For my own reasons.

    But had no good basis to question the strategy, as strategy..

    With the language design issue now on the table, I think I can
    go further and question the strategy, as such.

    The question of *why* needs to be fully discussed with
    the community as part of this exercise, IMO.

    The "why" that does not give the BDFL's strategic
    thinking its due weight will not be a fully honest discussion.

    But what is the BDFL's strategic thinking. Will he stay vague?

    That it will help certain kinds of projects has been mentioned by Guido.

    Which specific projects now underway of which he is aware?

    Why is it important to accommodate those projects?

    What is Guido's motivation, at this level? Can we ask? Can he answer?
    In some specifics?

    To implictly direct the converstaion to the highly technical,.
    and implicitly assert community concensus should be reached
    strictly from a language design perspective on the merits, assures us
    more community damage then is necessary in sorting this one out.

    Because we won't be having the real conversation.

    IMO.

    Art
    , Jan 4, 2005
    #1
    1. Advertising

  2. wrote:
    > Viile writes -
    >
    >>Type declarations are a feature that might benefit IronPython and
    >>Jython more than they would CPython.

    >
    > How much is this part of Guido's decisionmaking process?


    One major reason to allow optional static typing is to aid specializing
    compilers. A language called "Self" had a type system even more
    dynamic than Python's, and it was capable of getting to quite
    reasonable speeds doing dynamic analysis and specialization. In
    fact, PyPy is quite likely to get great optimization from the
    declarations as well as IronPython and JPython.

    If for some reason you know the arguments to a function are all
    integers, you can create a translation of that function that
    only operates on integers, and you can often discover that
    operations not only on the arguments, but on partial results,
    can all be kept as integers. These operations can be translated
    into very simple operations that avoid method lookup, and can
    therefore run much faster. If, conceptually, some set of
    functions and methods always are called with specific types,
    those functions and methods can have very high-speed (relatively)
    implementations for fairly little cost in compiler complexity.
    Such specifications could be spread through the standard library
    (if only in the most obvious of places), and provide a _very_
    _substantial_ speed improvement for less investment than almost
    any of the other techniques around.

    Remember, at the core, all current CPUs operate on one or two
    data types: integers and floating point. Wherever they must
    distinguish types they must use conditional branches, the slowest
    operation on the fastest CPUs being produced today and in the
    relatively visible future. Even when the type specification
    is advice about the most common type path, rather than a strict
    guarantee of the type, code can be generated that does the test
    before choosing which path to choose, and have fast code on the
    type-specific path.

    --Scott David Daniels
    Scott David Daniels, Jan 4, 2005
    #2
    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. Iwan van der Kleyn

    Python evolution: Unease

    Iwan van der Kleyn, Jan 4, 2005, in forum: Python
    Replies:
    44
    Views:
    963
    Robert Kern
    Jan 7, 2005
  2. Roman Suzi

    RE: Python evolution: Unease

    Roman Suzi, Jan 4, 2005, in forum: Python
    Replies:
    52
    Views:
    1,033
    Robert Kern
    Jan 8, 2005
  3. Carlos Ribeiro

    Re: Python evolution: Unease

    Carlos Ribeiro, Jan 4, 2005, in forum: Python
    Replies:
    9
    Views:
    377
    David Fraser
    Jan 7, 2005
  4. Roman Suzi

    Concepts RE: Python evolution: Unease

    Roman Suzi, Jan 5, 2005, in forum: Python
    Replies:
    6
    Views:
    270
    Jeremy Bowers
    Jan 6, 2005
  5. Daniel Bowett

    Re: Python evolution: Unease

    Daniel Bowett, Jan 5, 2005, in forum: Python
    Replies:
    1
    Views:
    309
Loading...

Share This Page