This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rhettinger
Recipients eric.smith, paul.moore, rhettinger, sreedevi.ha, steven.daprano, terry.reedy
Date 2020-09-25.08:31:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1601022669.0.0.613042559421.issue41774@roundup.psfhosted.org>
In-reply-to
Content
> I like the simple ad easy 'slice replacement = iterator' form
>  because it illustrates to me that we have done something 
> right with Python's design.

I understand that you like it and that it reflects the way you think the world should work, , but that doesn't warrant putting it in the FAQ.  We should steer users down a path of feeding unsizable inputs into tooling that needs a size to work well (the receiving code either has to implicitly build a list first before it can start or it will have to have periodic resizes). A straight list comprehension will suffice to answer the question cleanly.

FWIW, the same issue occurs with str.join().  It works better with a list comprehension than an iterator.  Given an iterator, it has to build an internal list first before it can start.  That is slower than starting with a list in the first place and makes the memory consumption implicit when it should be explicit (a generator would create the illusion that a list isn't being formed which is misleading).
History
Date User Action Args
2020-09-25 08:31:09rhettingersetrecipients: + rhettinger, terry.reedy, paul.moore, eric.smith, steven.daprano, sreedevi.ha
2020-09-25 08:31:09rhettingersetmessageid: <1601022669.0.0.613042559421.issue41774@roundup.psfhosted.org>
2020-09-25 08:31:08rhettingerlinkissue41774 messages
2020-09-25 08:31:08rhettingercreate