[Python-Dev] deque alternative

[Christian Tismer]

Dear Armin,

> You are mentioning confusingly many levels of PyPy for this argument.

This is true, I didn't want to care.

> This is not directly related to static analysis nor to the JIT.  The
> point is just that while a Python program runs, the implementation can
> decide to start using a deque-like structure instead of a zero-based
> array for a given user list.  This can be done in any implementation of
> Python; both in PyPy and in CPython it would be done by adding checks
> and cases in the code that implements list objects.

Correct. It is neither directly related to static analysis nor
to JIT, I just drew some line of analogy between how we decide whether
to implement a list or a straight array.

Mentioning many levels of PyPy might be confusing, but these levels
are more related to each other for me than you might expect, or you
might just not expect the kind of picture I think to have. I'm
of course not confused, but tend to put different levels into
relation.

PyPy has several levels to attack/approach certain problems. It
thinks to insulate them. Actually, it is less insulating but more
structuring, trying to attach valid levels of approaches to a problem.

This crystallizes as certain ways to implement some ideas in RPython,
while it comes up in a different flavor when JIT approaches for one
level up are discussed. But all these different approaches have one
similar mindset in common, which is always seeking for the best balance
between feasibility, simplicity, comprehensibility and elegance,
in conjunction with the confidence that we can do better if we do it
right. And there are similar patterns to be observed, at every level.

PyPy gives me the advantage that I can emit a more or less wild idea
and check if it is doable, makes sense, or leads to more problems
than it solves. I cannot discuss this on the Python list, because
this is always bearing lots of other considerations, where the
hardest ones are "can we implement it", "do people like it", and
"is it worth it", where the latter was the point why I brought
the issue up, at all, trying to ride on Guido's arguments.

> As much as I like this approach I fear that it will be rejected for
> CPython, as e.g. lazily concatenated string objects were, on grounds of
> code obfuscation and unpredictability of performance.  But it's PyPy's
> goal to experiment here :-)

No fears needed, I'm not putting my person into it, again.

Guido asked me to shut up, a while ago. I did!
If I'm showing up from time to time, this is not meant
to make him happy, just to remind him on contradictions to himself.

You know CPython and its community almost as good as I know, and that
I left it to some extent quite a while ago. One reason was the
ambiguous decision of what is considerable and what not. This is
too much of personality going into it for me. PyPy gives me the
chance to discuss things, try things, go wrong, correct myself, and
in case of disagreement, nobody would object to create a branch
for a new idea until it is approved or I'm healed. This is what
I'm missing in CPython, and why I'm feeling well being with PyPy.

Stackless is a good example. In PyPy, everybody can decide to go
for Stackless and set a compiler option. There is no question
asked, everybody agrees that it can be a good thing if you need it,
so use it or not. A new feature may be a good thing as well, so
let's see if it makes sense, and categorize it if it is of general
use, or a special case, which should be treated differently, maybe
even by a real branch. The big advantage that we have is that we are
not bound to a single, hand-written implementation which has to be
maintained by hand. We can try and let the code generator get
astray, automatically. We'll fix it and don't worry.

Don't worry, I'm not expecting anything positive from python-dev,
and the only thing that makes me still unhappy is unreflected
abuses of my changed topic, but that's a minor matter of taste :-))

all the best -- chris

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/