[Tim]
> OTOH, I do expect that once code relies on stability, we'll
> have about as much chance of taking that away as getting rid of
> list.append().
[Patrick K. O'Brien]
> There you go again! Your flip comment has got me thinking about the "one
> best idiom" for list appending.
It was a serious enough comment, judged against the universe of all comments
I make <wink>. I expect that if a hypothetical 3x-faster non-stable sort
algorithm got discovered for 2.6, we wouldn't be able to call it list.sort()
then. It's very hard to take any perceived goodness away, ever.
> So I'll ask the question. Is there a reason to want to get rid of
> list.append()?
I believe-- and sincerely hope --that I'm the only one who ever suggested
that.
> How does one decide between list.append() and augmented assignment (+=),
> such as:
>
> >>> l = []
> >>> l.append('something')
> >>> l.append('else')
> >>> l += ['to']
> >>> l += ['consider']
> >>> l
> ['something', 'else', 'to', 'consider']
> >>>
Clarity: l.append() is obvious; I'd never append a single item via +=.
More, I'd probably do
push = L.append
outside a loop and call push('something') inside the loop. "+=" as a
synonym for list.extend() is only interesting if you're writing polymorphic
code that wants to exploit the ability to define __iadd__. For sane people,
that's approximately never <wink>.
> And wasn't someone documenting current idioms in light of recent Python
> features? Did that ever get posted anywhere?
Rings a bell, but beats me.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4