On 22 Mar 2005 07:40:50 GMT, Antoon Pardon <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
