[Python-Dev] Patches

[Peter Schneider-Kamp]

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