On Fri, 19 Nov 2004 20:29:45 +1000, Nick Coghlan <ncoghlan at iinet.net.au> wrote: > Carlos Ribeiro wrote: > > list.pop doesn't solve the case for when the data is stored in a > > tuple (which is immutable). > > For immutable objects, you *have* to make a copy, so I don't see any real > downside to just using: > > a, b, T = T[0], T[1], T[2:] (First of all, let me say that I am not at all against making list.pop accept slices. It's nice that it seems to be agreed that this is a worthy addition. And I don't intend to keep pushing for iunpack(); but I feel that is important to make a few clarifications.) If I want to do: a,b,X = T[0], T[1], T[2:] (?) The lesson here is that it can't be assumed for unpacking purposes that the programmer wanted to modify the original list. Of course, if he does want it, then list.pop just comes nice. (also, list.pop(slice) can be used to remove elements from anywhere on the list, which is a big plus) > While I think iunpack is kind of neat, I don't think it solves anything which is > currently a major problem, as it is really just a different way of spelling the > above slicing. The major portion (sans some index checking) of iunpack(T, 2) can > be written on one line: > > a, b, T = (T[i] for i in (range(2) + [slice(2, None)])) I would rather prefer not to have to use this idiom -- it's neither obvious nor convenient. Either list.pop or unpack would be cleaner for this purpose. > When the number of elements to be unpacked is known at compile time (as it has > to be to use tuple unpacking assignment), there seems little benefit in moving > things inside a generator instead of spelling them out as a tuple of slices. For more than a few arguments, it seems to be silly to require the user to write it as: a,b,c,d,e = t[0],t[1],t[2],t[3],t[4:] [lots of remarks about list.pop snipped] I'm not against list.pop; it's just that iunpack provides a different approach to the problem. It's fairly generic: it works for both mutable and immutable lists. The implementation provided is a proof of concept. The fact that it does not modify the original arguments *is* a design feature (althought not what the OP wanted for his particular case). After all, as shown in the example above, conventional tuple unpacking on assignment doesn't change the right-side arguments either. One posible improvement for iunpack() is to accept any iterable as an argument. On return, instead of a tuple to represent the remaining elements, it would return the generator itself. This would allow for code that consume the generator in "chunks" to be written rather simply: a,b,c,g = iunpack(3, g) In this case, to solve the OP problem, instead to have all the values to be processed stored into a list, he could rely on a generator to produce values on the fly. Depending on the scenario this would come handy (less memory consumption, more responsiveness). -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: carribeiro at gmail.com mail: carribeiro at yahoo.com
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