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

Reply via email to