<p dir="ltr">Le 10 févr. 2015 06:48, "Greg Ewing" <<a href="mailto:greg.ewing@canterbury.ac.nz">greg.ewing@canterbury.ac.nz</a>> a écrit :<br>
> It could potentially be a little more efficient by<br>
> eliminating the construction of an intermediate list.</p>
<p dir="ltr">Is it the case in the implementation? If it has to create a temporary list/tuple, I will prefer to not use it.</p>
<p dir="ltr">After long years of development, I chose to limit myself to one instruction per line. It is for different reason:<br>
- I spend more time to read code than to write code, readability matters<br>
- it's easier to debug: most debugger work line by line, or at least it's a convinient way to use them. If you use instruction per instruction, usually you have to read assember/bytecode to get the current instruction<br>
- profilers computes statistics per line,not per instruction (it's also the case for tracemalloc)<br>
- tracebacks only give the line number, not the column<br>
- etc.</p>
<p dir="ltr">So I now prefer more verbise code even it is longer to write and may look less efficient.</p>
<p dir="ltr">> Same again, multiple ** avoids construction of an<br>
> itermediate dict.</p>
<p dir="ltr">Again, is it the case in the implementation. It may be possible to modify CPython to really avoid a temporary dict (at least for some kind of Python functions), but it would a large refactoring.</p>
<p dir="ltr">Usually, if an operation is not efficient, it's not implement, so users don't try to use it and may even try to write their code differently (to avoid the performance issue).</p>
<p dir="ltr">(But slow operations exist like list.remove.)</p>
<p dir="ltr">Victor</p>