Python design strategy (was Python evolution: Unease)

[ajsiegel]

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

[Scott David Daniels]

aj******@optonl ine.net 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
Sc***********@A cm.Org