Thomas Wouters wrote: > > Now that everyone of importance is off to sunny California, how about we put > some of the patches that have been idling on the SF PM to the vote ? If > Barry objects we can always organize some gigs for him away from the > 'office' ;) I am +0 on voting. I don't like the silence on the checkins mailing list. > I'd personally like to hear some votes/opinions on the range literal patch, > but it seems to me there are others that only require some voting and second > opinions: Wasn't there a decision from the BDFL? > - arraymodule: adding count, extend, index, pop, remove > I believe there was some discussion about this before, don't know the > outcome. Guido said something like (hope I got it right): count, index and remove should be implemented in a faster way, but that would take a lot more code and not be worth it. who would use index, count and remove on arrays anyway? so better leave them out, pop is okay though. extend would be worth adding. Tim said something like (hope I got this one right, too): better to have count, index and remove at all than not to have them. I would use them. I interpret that as a -0 from Guido and a +1 from Tim, but - as always - YMMV. My opinion is that an array is only really useful if it supports as much of the list interface as possible. As I understand things arrays are lists where you trade the ability to store any element against some increase in speed. For the slow count, index and remove functions I have three proposals (in order of decreasing appeal to me): 1) just put em in, they are in any case not slower than the Python code you would use to emulate them. +1 2) put them in and add some warnings to the docs that say they are slow. +0 3) do it the fast way. that would be a lot of work and - as Guido pointed out - probably not worth it. I'd do it if it was neccessary though. -0 > - safe version of PyErr_Format > +0 on that, but what do I know. Don't know if it's actually safe ;) -0 on that, I'd rather use snprintf when available, sprintf when not. > - Optional pad character for rjust, ljust > Definately +1, but I have a nagging feeling there is a better way to do it: > Why wasn't this implemented before ? What are people using instead of > string.rjust(string, padchar) ? +1 in any case, but I think we should wait for the new version which supports padstrings, too. also I think there is still no docs/test cases. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de
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