Larry Hastings <[EMAIL PROTECTED]> wrote:
[snip]
> The machine is dual-core, and was quiescent at the time. XP's scheduler
> is hopefully good enough to just leave the process running on one core.
It's not. Go into the task manager (accessable via Ctrl+Alt+Del by
default) and change the proces
I've uploaded a new patch to Sourceforge in response to feedback:
* I purged all // comments and fixed all > 80 characters added by my
patch, as per Neil Norwitz.
* I added a definition of max() for those who don't already have one,
as per [EMAIL PROTECTED]
It now compiles cleanly on Linux
s.
Cheers,
Kristján
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> On Behalf Of M.-A. Lemburg
> Sent: 9. október 2006 09:30
> To: Larry Hastings
> Cc: python-dev@python.org
> Subject: Re: [Python-Dev] PATCH submitted: Speed up + for
&
Larry Hastings wrote:
> Fredrik Lundh wrote:
>> [EMAIL PROTECTED] wrote:
>>
>>> MAL's pybench would probably be better for this presuming it does some
>>> addition with string operands.
>>>
>> or stringbench.
>>
>
> I ran 'em, and they are strangely consistent with pystone.
>
> With co
Fredrik Lundh wrote:
> [EMAIL PROTECTED] wrote:
>
>> MAL's pybench would probably be better for this presuming it does some
>> addition with string operands.
>>
> or stringbench.
>
I ran 'em, and they are strangely consistent with pystone.
With concat, stringbench is ever-so-slightly f
On 7 Oct 2006, at 09:17, Fredrik Lundh wrote:
> Nicko van Someren wrote:
>
>> If it speeds up pystone by 5.5% with such minimal down side
>> I'm hard pressed to see a reason not to use it.
>
> can you tell me where exactly "pystone" does string concatenations?
No, not without more in depth examin
Fredrik> Nicko van Someren wrote:
>> If it speeds up pystone by 5.5% with such minimal down side I'm hard
>> pressed to see a reason not to use it.
Fredrik> can you tell me where exactly "pystone" does string
Fredrik> concatenations?
I wondered about that as well. While I'm
Nicko van Someren wrote:
> If it speeds up pystone by 5.5% with such minimal down side
> I'm hard pressed to see a reason not to use it.
can you tell me where exactly "pystone" does string concatenations?
___
Python-Dev mailing list
Python-Dev@pyth
Nicko van Someren <[EMAIL PROTECTED]> wrote:
> It's not like having this patch is going to force anyone to change
> the way they write their code. As far as I can tell it simply offers
> better performance if you choose to express your code in some common
> ways. If it speeds up pystone by
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
>>
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
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 typ
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 wor
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 the
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
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
[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
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
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 "",
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
Gregory P. Smith wrote:
> have you run any generic benchmarks such as pystone to get a better
> idea of what the net effect on "typical" python code is?
I hadn't, but I'm happy to. On my machine (a fire-breathing Athlon 64
x2 4400+), best of three runs:
Python 2.5 release:
Pystone(1.1) time
On 5 Oct 2006, at 20:28, 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 p
"Gregory P. Smith" <[EMAIL PROTECTED]> 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 s
> 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 patch #1569040
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 patch #1569040
to S
25 matches
Mail list logo
