5 ms·

I honestly do not get the point of this page. None of the time differences in all the test cases are significant at all. Concerning yourself with this is prema

by ayrx 12y ago

I honestly do not get the point of this page. None of the time differences in all the test cases are significant at all. Concerning yourself with this is premature optimization of the highest level especially in a language like Python. One should definitely be more concerned about writing clearer and more idiomatic code.

romanlevin 12y ago
It's just a reference, it's not making a value judgement about the different ways to evaluate the truthiness of a list or something.
- deleted 12y ago
  [deleted]
vegabook 12y ago
I have to agree, though there is some information to be gleaned precisely because this guy has gone very far to show us that there is no point to try to get clever with alternative, non-idiomatic ways of doing things. Mind at ease to use the cleanest idioms. It reminds me a bit of some of my big data jobs. Sometimes you spend days and days torturing data to find interesting aspects, only to find nothing and end in "failure". Only it isn't failure because you've eliminated a bunch of dead-end avenues that you might otherwise have wondered about, freeing you to pursue more promising uses for your resources.
- jarcane 12y ago
  This is mainly what I took from it. The faster way here is almost always the most idiomatic way to do it in the examples, and the reasons why are usually pretty obvious. And while the individual differences are small, in a language already as slow as Python, starting from the faster, idiomatic code from the start is likely to save a lot of headache down the line.
nichochar 12y ago
If anything then he has proven exactly what you're saying, hence that it is OK to being explicit rather than try and be picky about these things, and that code readability can easily be a priority in python. There are also a few exceptions (the update() method on a dict and list comprehensions). As a junior python dev < me < senior python dev, this was very cool to read, also very quick to take in, kuddos on the presentation
simonh 12y ago
Someone popping up and trotting out the 'no premature optimization' argument every time an article is posted about optimization is getting very tiresome. Not all optimization is premature. Sometimes you find that you do need to optimize, and then having to wade through a morass of comments complaining about premature optimization to track down actual relevant content and comment is a pain in the arse.
- sweezyjeezy 12y ago
  But his first point still stands - none of these optimisations are very important.
beaumartinez 12y ago
Agreed, although it's interesting to see the disassemblies. Python is a language about readability and conciseness first, performance second. I would have liked to have seen `map` used in the list comp examples, as well as seeing the tests run on Python 3.

by ayrx 12y ago

romanlevin 12y ago

It's just a reference, it's not making a value judgement about the different ways to evaluate the truthiness of a list or something.

deleted 12y ago
[deleted]

vegabook 12y ago

I have to agree, though there is some information to be gleaned precisely because this guy has gone very far to show us that there is no point to try to get clever with alternative, non-idiomatic ways of doing things. Mind at ease to use the cleanest idioms. It reminds me a bit of some of my big data jobs. Sometimes you spend days and days torturing data to find interesting aspects, only to find nothing and end in "failure". Only it isn't failure because you've eliminated a bunch of dead-end avenues that you might otherwise have wondered about, freeing you to pursue more promising uses for your resources.

jarcane 12y ago
This is mainly what I took from it. The faster way here is almost always the most idiomatic way to do it in the examples, and the reasons why are usually pretty obvious. And while the individual differences are small, in a language already as slow as Python, starting from the faster, idiomatic code from the start is likely to save a lot of headache down the line.

nichochar 12y ago

If anything then he has proven exactly what you're saying, hence that it is OK to being explicit rather than try and be picky about these things, and that code readability can easily be a priority in python. There are also a few exceptions (the update() method on a dict and list comprehensions). As a junior python dev < me < senior python dev, this was very cool to read, also very quick to take in, kuddos on the presentation

simonh 12y ago

Someone popping up and trotting out the 'no premature optimization' argument every time an article is posted about optimization is getting very tiresome. Not all optimization is premature. Sometimes you find that you do need to optimize, and then having to wade through a morass of comments complaining about premature optimization to track down actual relevant content and comment is a pain in the arse.

sweezyjeezy 12y ago
But his first point still stands - none of these optimisations are very important.

beaumartinez 12y ago

Agreed, although it's interesting to see the disassemblies. Python is a language about readability and conciseness first, performance second. I would have liked to have seen `map` used in the list comp examples, as well as seeing the tests run on Python 3.