[Python-Dev] Python 2.x and 3.x use survey, 2014 edition

[R. David Murray]

On Tue, 16 Dec 2014 10:48:07 -0800, Mark Roberts <wizzat at gmail.com> wrote:
> On Tue, Dec 16, 2014 at 2:45 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> >
> > Iterating accross a dictionary doesn't need compatibility shims. It's
> > dead simple in all Python versions:
> >
> > $ python2
> > Python 2.7.8 (default, Oct 20 2014, 15:05:19)
> > [GCC 4.9.1] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> d = {'a': 1}
> > >>> for k in d: print(k)
> > ...
> > a
> >
> > $ python3
> > Python 3.4.2 (default, Oct  8 2014, 13:08:17)
> > [GCC 4.9.1] on linux
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> d = {'a': 1}
> > >>> for k in d: print(k)
> > ...
> > a
> >
> > Besides, using iteritems() and friends is generally a premature
> > optimization, unless you know you'll have very large containers.
> > Creating a list is cheap.
> >
> 
> It seems to me that every time I hear this, the author is basically
> admitting that Python is a toy language not meant for "serious computing"
> (where serious is defined in extremely modest terms). The advice is also
> very contradictory to literally every talk on performant Python that I've
> seen at PyCon or PyData or ... well, anywhere. And really, doesn't it
> strike you as incredibly presumptuous to call the *DEFAULT BEHAVIOR* of
> Python 3 a "premature optimization"?

No.  A premature optimization is one that is made before doing any
performance analysis, so language features are irrelevant to that
labeling.  This doesn't mean you shouldn't use "better" idioms when they
are clear.  But if you are complicating your code because of performance
concerns *without measuring it* you are doing premature optimization, by
definition[*].

> Isn't the whole reason that the
> default behavior switch was made is because creating lists willy nilly all
> over the place really *ISN'T* cheap? This isn't the first time someone has

No.  In Python3 we made the iterator protocol more central to the
language.  Any performance benefit is actually a side effect of that
change.  One that was considered, yes, but in the context of the
*language* as a whole and not any individual program's performance
profile.  And "this doesn't make things worse for real world programs as
far as we can measure" is a more important criterion for this kind of
language change than "lets do this because we've measured and it makes
things better".

--David

[*] And yes, *we all do this*.  Sometimes doing it doesn't cost much.
Sometimes it does.