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