Re: [Python-Dev] PATCH submitted: Speed up + for string concatenation, now as fast as .join(x) idiom

2006-10-06 Thread Steve Holden
Gregory P. Smith wrote: I've never liked the .join([]) idiom for string concatenation; in my opinion it violates the principles Beautiful is better than ugly. and There should be one-- and preferably only one --obvious way to do it.. (And perhaps several others.) To that end I've submitted

Re: [Python-Dev] PATCH submitted: Speed up + for string concatenation, now as fast as .join(x) idiom

2006-10-06 Thread Fredrik Lundh
Steve Holden wrote: instance.method(*args) == type.method(instance, *args) You can nowadays spell this as str.join(, lst) - no need to import a whole module! except that str.join isn't polymorphic: str.join(u,, [1, 2, 3]) Traceback (most recent call last): File stdin, line 1, in

Re: [Python-Dev] PATCH submitted: Speed up + for string concatenation, now as fast as .join(x) idiom

2006-10-06 Thread skip
Greg have you run any generic benchmarks such as pystone to get a Greg better idea of what the net effect on typical python code is? MAL's pybench would probably be better for this presuming it does some addition with string operands. Skip ___

Re: [Python-Dev] PATCH submitted: Speed up + for string concatenation, now as fast as .join(x) idiom

2006-10-06 Thread Fredrik Lundh
[EMAIL PROTECTED] wrote: Greg have you run any generic benchmarks such as pystone to get a Greg better idea of what the net effect on typical python code is? MAL's pybench would probably be better for this presuming it does some addition with string operands. or stringbench. /F

Re: [Python-Dev] PATCH submitted: Speed up + for string concatenation, now as fast as .join(x) idiom

2006-10-06 Thread Ron Adam
Gregory P. Smith wrote: I've never liked the .join([]) idiom for string concatenation; in my opinion it violates the principles Beautiful is better than ugly. and There should be one-- and preferably only one --obvious way to do it.. (And perhaps several others.) To that end I've submitted

Re: [Python-Dev] PATCH submitted: Speed up + for string concatenation, now as fast as .join(x) idiom

2006-10-06 Thread Fredrik Lundh
Ron Adam wrote: I think what may be missing is a larger set of higher level string functions that will work with lists of strings directly. Then lists of strings can be thought of as a mutable string type by its use, and then working with substrings in lists and using ''.join() will not

[Python-Dev] 2.4.4: backport classobject.c HAVE_WEAKREFS?

2006-10-06 Thread A.M. Kuchling
I was looking at the logs for classobject.c and noticed this commit that adds Py_TPFLAGS_HAVE_WEAKREFS to the instance type. Should it be backported to 2.4? (It looks to me like it should, but I don't know anything about weakref implementation and want to get approval from someone who knows.)

Re: [Python-Dev] 2.4.4: backport classobject.c HAVE_WEAKREFS?

2006-10-06 Thread Raymond Hettinger
No need to backport. Py_TPFLAGS_DEFAULT implies Py_TPFLAGS_HAVE_WEAKREFS. The change was for clarity -- most things that have the weakref slots filled-in will also make the flag explicit -- that makes it easier on the brain when verifying code that checks the weakref flag. Raymond

Re: [Python-Dev] PATCH submitted: Speed up + for string concatenation, now as fast as .join(x) idiom

2006-10-06 Thread Josiah Carlson
Fredrik Lundh [EMAIL PROTECTED] wrote: Ron Adam wrote: I think what may be missing is a larger set of higher level string functions that will work with lists of strings directly. Then lists of strings can be thought of as a mutable string type by its use, and then working with

Re: [Python-Dev] 2.4.4: backport classobject.c HAVE_WEAKREFS?

2006-10-06 Thread A.M. Kuchling
On Fri, Oct 06, 2006 at 08:48:15AM -0700, Raymond Hettinger wrote: The change was for clarity -- most things that have the weakref slots filled-in will also make the flag explicit -- that makes it easier on the brain when verifying code that checks the weakref flag. OK; I won't backport this.

Re: [Python-Dev] PATCH submitted: Speed up + for string concatenation, now as fast as .join(x) idiom

2006-10-06 Thread Bob Ippolito
On 10/6/06, Fredrik Lundh [EMAIL PROTECTED] wrote: Ron Adam wrote: I think what may be missing is a larger set of higher level string functions that will work with lists of strings directly. Then lists of strings can be thought of as a mutable string type by its use, and then working with

Re: [Python-Dev] PATCH submitted: Speed up + for string concatenation, now as fast as .join(x) idiom

2006-10-06 Thread Ron Adam
Josiah Carlson wrote: Fredrik Lundh [EMAIL PROTECTED] wrote: Ron Adam wrote: I think what may be missing is a larger set of higher level string functions that will work with lists of strings directly. Then lists of strings can be thought of as a mutable string type by its use, and

Re: [Python-Dev] PATCH submitted: Speed up + for string concatenation, now as fast as .join(x) idiom

2006-10-06 Thread Nicko van Someren
On 6 Oct 2006, at 12:37, Ron Adam wrote: I've never liked the .join([]) idiom for string concatenation; in my opinion it violates the principles Beautiful is better than ugly. and There should be one-- and preferably only one --obvious way to do it.. ... Well I always like things to

[Python-Dev] Weekly Python Patch/Bug Summary

2006-10-06 Thread Kurt B. Kaiser
Patch / Bug Summary ___ Patches : 428 open ( +6) / 3417 closed ( +2) / 3845 total ( +8) Bugs: 939 open ( +6) / 6229 closed (+17) / 7168 total (+23) RFE : 240 open ( +3) / 239 closed ( +0) / 479 total ( +3) New / Reopened Patches __ Speed up

Re: [Python-Dev] PATCH submitted: Speed up + for string concatenation, now as fast as .join(x) idiom

2006-10-06 Thread Ron Adam
Nicko van Someren wrote: On 6 Oct 2006, at 12:37, Ron Adam wrote: I've never liked the .join([]) idiom for string concatenation; in my opinion it violates the principles Beautiful is better than ugly. and There should be one-- and preferably only one --obvious way to do it.. ... Well I