<div dir="ltr">><span style="font-size:12.8px">All performance matters. All </span><span style="font-size:12.8px">memory consumption matters. Being wasteful over a purely aesthetic few </span><span style="font-size:12.8px">extra characters of code is silly.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Isn't the logical conclusion of this to write everything in a different language? :)</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 13, 2016 at 8:42 AM, Terry Wilson <span dir="ltr"><<a href="mailto:twilson@redhat.com" target="_blank">twilson@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Jun 10, 2015 at 4:41 AM, Robert Collins<br>
<<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>> wrote:<br>
> On 10 June 2015 at 21:30, Ihar Hrachyshka <<a href="mailto:ihrachys@redhat.com">ihrachys@redhat.com</a>> wrote:<br>
>> -----BEGIN PGP SIGNED MESSAGE-----<br>
>> Hash: SHA256<br>
>><br>
>> On 06/10/2015 02:15 AM, Robert Collins wrote:<br>
>>> I'm very glad folk are working on Python3 ports.<br>
>>><br>
>>> I'd like to call attention to one little wart in that process: I<br>
>>> get the feeling that folk are applying a massive regex to find<br>
>>> things like d.iteritems() and convert that to six.iteritems(d).<br>
>>><br>
>>> I'd very much prefer that such a regex approach move things to<br>
>>> d.items(), which is much easier to read.<br>
>>><br>
>>> Here's why. Firstly, very very very few of our dict iterations are<br>
>>> going to be performance sensitive in the way that iteritems()<br>
>>> matters. Secondly, no really - unless you're doing HUGE dicts, it<br>
>>> doesn't matter. Thirdly. Really, it doesn't.<br>
>>><br>
>><br>
>> Does it hurt though? ;)<br>
><br>
> Yes.<br>
><br>
> Its: harder to read. Its going to have to be removed eventually anyway<br>
> (when we stop supporting 2.7). Its marginally slower on 3.x (it has a<br>
> function and an iterator wrapping the actual thing). Its unidiomatic,<br>
> and we get lots of programmers that are new to Python; we should be<br>
> giving them as beautiful code as we can to help them learn.<br>
<br>
</span>If someone is so new they can't handle six.iteritems, they should stay<br>
away from Neutron code. It'll eat them.<br>
<span class=""><br>
>>> At 1 million items the overhead is 54ms[1]. If we're doing inner<br>
>>> loops on million item dictionaries anywhere in OpenStack today, we<br>
>>> have a problem. We might want to in e.g. the scheduler... if it<br>
>>> held in-memory state on a million hypervisors at once, because I<br>
>>> don't really to to imagine it pulling a million rows from a DB on<br>
>>> every action. But then, we'd be looking at a whole 54ms. I think we<br>
>>> could survive, if we did that (which we don't).<br>
>>><br>
>>> So - please, no six.iteritems().<br>
<br>
</span>Huge -1 from me. The "I like looking at d.items() more than I like<br>
looking at six.iteritems(d) so make everything (even slightly) less<br>
efficient" argument is insane to me. All performance matters. All<br>
memory consumption matters. Being wasteful over a purely aesthetic few<br>
extra characters of code is silly.<br>
<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div>