On Thu, Oct 24, 2019 at 7:53 AM Ethan Furman <et...@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.
-CHB
> --
> ~Ethan~
> _______________________________________________
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/KO4HXFEMIMTJE3CIKL566BJ6SRPIAY3Q/
Code of Conduct: http://python.org/psf/codeofconduct/
