[Python-Dev] Python 2.x and 3.x use survey, 2014 edition (original) (raw)

R. David Murray rdmurray at bitdance.com
Tue Dec 16 20🔞20 CET 2014

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.

More information about the Python-Dev mailing list