>>>>> "Fred" == Fred L Drake, Jr <fdrake@beopen.com> writes:
Fred> Sounds good to me! If lists and tuples are special cased,
Fred> it shouldn't even matter if the sequence API is too slow --
Fred> that's new functionality for [].extend(), and can be
Fred> optimized later if it needs to be.
This has been a typical implementation strategy for a long while now,
and I think successfully so. When I removed the distinction between
list and tuple unpacking to allow any sequence unpacking (and
incidently w/o special syntax), I did exactly this. Special case for
tuples and lists, and if it was neither then use the sequence API.
Jeremy's right that this can get hairy if your as anal as I am about
error checking and refcounting. In addition to PySequence_Length()
ability to lie, there are all sorts of errors that can happen, which
should abort the whole process and clean up any temporary objects.
Plus you've now got three very similar branches in the code, which
adds its own overhead.
So you should decide whether this situation will be used widely enough
to warrant the extra coding complexity for the performance win.
list.extend() is probably not used too often these days, but it should
be 'cause it's cool. So maybe it's worth it in this case.
On the other hand, this is a situation that comes up often, and if we
were to really audit the APIs, we'd probably find even more cases
where restrictions to concrete lists or tuples should be relaxed to
accept any sequence. Maybe there's a way we can factor this out in a
single function which handles this once and for all?
-Barry
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