[Python-Dev] deque alternative (original) (raw)

Christian Tismer tismer at stackless.com
Wed Dec 28 02:13:28 CET 2005

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/

More information about the Python-Dev mailing list