On Thu, Oct 24, 2019 at 7:53 AM Ethan Furman <ethan@stoneleaf.us> wrote:
>      for something in lots_of_items:
>          for another in more_items:
>              function(spam, eggs, "cyan,forest green,burnt umber".split(','))

If you have a tight loop that is a performance bottleneck (you did measure, right?), then you trade readability for performance.  This is not news.

> That's easy to fix, you say. Move the list outside the loop:
>      L = "cyan,forest green,burnt umber".split(','))
>      for something in lots_of_items:
>          for another in more_items:
>              function(spam, eggs, L)
> What's wrong with this picture?

Other than you're now using one list for all calls, and the function could by modifying that list?  You do know if the function modifies the list, right?  I give up, what is wrong with that picture?

Imagine that was his point -- the two codes are not equivalent if the list if modified by the function.

I'll confess that I didn't immediately see that -- but then again, I'm not writing the code and thinking about what it's actually supposed to do,

But of course we can come up with toy examples of where you *could* have to put a list of string literals inside a tight loop, but I'm having trouble imagining real-world cases. And I'm pretty sure that most folks think passing a list into a function and having it modified is "bad form" anyway. But where it does make sense for a function to modify a list, it's pretty unlikely that you would want to call it with the exact same initial list anyway -- if it's getting modified, presumably you want to preserve that modification, no?

This does bring up a point though: I often think that folks use lists be default, where they don't need it to be mutable, and very well might not want it to be mutable (see above -- there is no way for the caller to know if that list is modified without reading the source -- if you wanted to be sure, you could pass in tuple of string instead.

It's long standing practice to use a tuple when you *need* it to be immutable, and a list otherwise. but maybe we should have an easy way to make a tuple of strings as well?

Just sayin'

But again: my point (I think I started this sub-thread) was that performance is NOT a good reason to add this feature, and I'm still surprised that people are still bringing it up.


Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/B5SRQ4T3ULOTYYWF7B4FIYKNDYPB46PJ/
Code of Conduct: http://python.org/psf/codeofconduct/

Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython