missing? dictionary methods

Bengt Richter bokr at oz.net
Tue Mar 22 11:33:21 EST 2005


On 22 Mar 2005 07:40:50 GMT, Antoon Pardon <apardon at forel.vub.ac.be> wrote:
[...]
>I also was under the impression that a particular part of
>my program almost doubled in execution time once I replaced
>the naive dictionary assignment with these self implemented
>methods. A rather heavy burden IMO for something that would
>require almost no extra burden when implemented as a built-in.
>
I think I see a conflict of concerns between language design
and optimization. I call it "arms-length assembler programming"
when I see language features being proposed to achieve assembler-level
code improvements.

For example, what if subclassing could be optimized to have virtually
zero cost, with some kind of sticky-mro hint etc to the compiler/optimizer?
How many language features would be dismissed with "just do a sticky subclass?"

>But you are right that there doesn't seem to be much support
>for this. So I won't press the matter.
I think I would rather see efficient general composition mechanisms
such as subclassing, decoration, and metaclassing etc. for program elements,
if possible, than incremental aggregation of efficient elements into the built-in core.

Also, because optimization risks using more computation to optimize than the expression
being optimized, I suspect that some kind of evaluate-expression-once (at def-time or first
execution time) and optimize-particular-expression hints could pay off more in general
than particular useful methods. Maybe Pypy will be an easier place to experiment with
these kinds of things.

Regards,
Bengt Richter



More information about the Python-list mailing list