Based on some ideas from Skip, I had tried transforming the likes of "x
in (1,2,3)" into "x in frozenset([1,2,3])". When applicable, it
substantially simplified the generated code and converted the O(n)
lookup into an O(1) step. There were substantial savings even if the
set contained only a sing
On Wed, 2005-02-16 at 22:53 -0800, Gregory P. Smith wrote:
> fyi - i've updated the python sha1/md5 openssl patch. it now replaces
> the entire sha and md5 modules with a generic hashes module that gives
> access to all of the hash algorithms supported by OpenSSL (including
> appropriate legacy in
[Gfeller Martin]
> what immediately comes to mind are Modules/cPickle.c and
> Modules/cStringIO.c, which (I believe) are heavily used by ZODB (which in turn
> is heavily used by the application).
I probably guessed right the first time : LFH doesn't help with
the lists directly, but helps indirec
Hi,
what immediately comes to mind are Modules/cPickle.c and Modules/cStringIO.c,
which (I believe) are heavily used by ZODB (which in turn is heavily used by
the application).
The lists also get fairly large, although not huge - up to typically 5
(complex) objects in the tests I've measu
Guido van Rossum wrote:
The Python test suite already has a way (the -u flag) to distinguish
between "regular" broad-coverage testing and deep coverage for
specific (or all) areas. Let's keep the really long-running tests out
of the regular test suite.
There used to be a farm of machines that did n
On Wed, 16 Feb 2005, Bob Ippolito wrote:
>
> On Feb 16, 2005, at 11:02, Phillip J. Eby wrote:
>
> >At 02:32 PM 2/11/05 -0800, Nick Rasmussen wrote:
> >>tommy said that this would be the best place to ask
> >>this question
> >>
> >>I'm trying to get functions wrapped via boost to show
> >>up
Tim Peters wrote:
Looks right to me -- cool! I never used struct's 'P' format because
it always appeared useless to me:But silly me! I'm sure Guido
put it there anticipating the need for calcsize('P') when making a
positive_id() function in Python.
Smells like more time machine activity to me
On Thu, Feb 17, 2005, Walter D?rwald wrote:
>
> Currently UserString.MutableString does not support negative indices:
>
> >>> import UserString
> >>> UserString.MutableString("foo")[-1] = "bar"
> Traceback (most recent call last):
> File "", line 1, in ?
> File "/home/Python-test/dist/src/Lib/
Currently UserString.MutableString does not support negative indices:
>>> import UserString
>>> UserString.MutableString("foo")[-1] = "bar"
Traceback (most recent call last):
File "", line 1, in ?
File "/home/Python-test/dist/src/Lib/UserString.py", line 149, in __setitem__
if index < 0 or
On 14-feb-05, at 10:23, Just van Rossum wrote:
[EMAIL PROTECTED] wrote:
\begin{datadesc}{PY_RESOURCE}
-The module was found as a Macintosh resource. This value can only be
-returned on a Macintosh.
+The module was found as a Mac OS 9 resource. This value can only be
+returned on a Mac OS 9 or ea
[removed pydotorg from people receiving this email]
Aahz wrote:
On Thu, Feb 17, 2005, Skip Montanaro wrote:
I am frantically trying to get ready to be out of town for a
week of vacation. Someone sent me some patches for datetime
and asked me to look at them. I begged off but referred him to
http:
Raymond Hettinger wrote:
> > but refactoring the contains code to use find_internal sounds like a good
> > first step. any takers?
>
> I'm up for it.
excellent!
just fyi, unless my benchmark is mistaken, the Unicode implementation has
the same problem:
str in -> 25.8 µsec per loop
unico
[Tim Peters]
>> # This is a puzzle: there's no way to know the natural width of
>> # addresses on this box (in particular, there's no necessary
>> # relation to sys.maxint).
[Armin Rigo]
> Isn't this natural width nowadays available as:
>
>256 ** struct.calcsize('P')
Hi Tim,
On Mon, Feb 14, 2005 at 10:41:35AM -0500, Tim Peters wrote:
> # This is a puzzle: there's no way to know the natural width of
> # addresses on this box (in particular, there's no necessary
> # relation to sys.maxint).
Isn't this natural width nowadays available as
On Thu, Feb 17, 2005, Skip Montanaro wrote:
>
> I am frantically trying to get ready to be out of town for a
> week of vacation. Someone sent me some patches for datetime
> and asked me to look at them. I begged off but referred him to
> http://www.python.org/dev/ and made mention of the five pat
[Raymond Hettinger]
>> For test_subprocess, consider adopting the technique used by
>> test_decimal. When -u decimal is not specified, a small random
>> selection of the resource intensive tests are run. That way, all of the
>> tests eventually get run even if no one is routinely using -u all.
[
"Raymond Hettinger" <[EMAIL PROTECTED]> writes:
>> Let's keep the really long-running tests out
>> of the regular test suite.
>
> For test_subprocess, consider adopting the technique used by
> test_decimal. When -u decimal is not specified, a small random
> selection of the resource intensive tes
Guido van Rossum wrote:
[...]
There used to be a farm of machines that did nothing but run the test
suite ("snake-farm"). This seems to have stopped (it was run by
volunteers at a Swedish university). Maybe we should revive such an
effort, and make sure it runs with -u all.
I've changed the job tha
I am frantically trying to get ready to be out of town for a week of
vacation. Someone sent me some patches for datetime and asked me to look at
them. I begged off but referred him to http://www.python.org/dev/ and made
mention of the five patch review idea. Can someone make sure that's
explain
> Let's keep the really long-running tests out
> of the regular test suite.
For test_subprocess, consider adopting the technique used by
test_decimal. When -u decimal is not specified, a small random
selection of the resource intensive tests are run. That way, all of the
tests eventually get run
On Thu, 17 Feb 2005, Guido van Rossum wrote:
> > I'd like to have your opinion on this bug. Personally, I'd prefer to keep
> > test_no_leaking as it is, but if you think otherwise...
> A suite of unit tests is a precious thing. We want to test as much as
> we can, and as thoroughly as possible; b
> I'd like to have your opinion on this bug. Personally, I'd prefer to keep
> test_no_leaking as it is, but if you think otherwise...
>
> One thing that actually can motivate that test_subprocess takes 20% of the
> overall time is that this test is a good generic Python stress test - this
> test m
Tim Peters <[EMAIL PROTECTED]> writes:
> [sorry for the near-duplicate msgs -- looks like gmail lied when it claimed
> the
> first msg was still in "draft" status]
>
>>> Did you add a test to ensure this remains fixed?
>
> [mwh]
>> Yup.
>
> Bless you. Did you attach a contributor agreement and
[sorry for the near-duplicate msgs -- looks like gmail lied when it claimed the
first msg was still in "draft" status]
>> Did you add a test to ensure this remains fixed?
[mwh]
> Yup.
Bless you. Did you attach a contributor agreement and mark the test
as being contributed under said contributo
On Friday 18 February 2005 01:19, Fredrik Lundh wrote:
>
> does anyone ever use the -u options when running tests?
I use "make testall" (which invokes with -uall) regularly, and turn
on specific options when they're testing something I'm working with.
--
Anthony Baxter <[EMAIL PROTECTED]>
I
[Fredrik Lundh]
> does anyone ever use the -u options when running tests?
Yes -- I routinely do -uall, under both release and debug builds, but
only on Windows. WinXP in particular seems to do a good job when
hyper-threading is available -- running the tests doesn't slow down
anything else I'm do
Tim Peters <[EMAIL PROTECTED]> writes:
> [Michael Hudson]
>> ...
>> Well, I fixed it on reading the bug report and before getting to
>> python-dev mail :) Sorry if this duplicated your work, but hey, it was
>> only a two line change...
>
> Na, the real work was tracking it down in the bowels of Zo
[Michael Hudson]
> ...
> Well, I fixed it on reading the bug report and before getting to
> python-dev mail :) Sorry if this duplicated your work, but hey, it was
> only a two line change...
Na, the real work was tracking it down in the bowels of Zope's C-coded
security machinery -- we'll let you
[Michael Hudson]
> ...
> Well, I fixed it on reading the bug report and before getting to
> python-dev mail :) Sorry if this duplicated your work, but hey, it was
> only a two line change...
Na, the real work was tracking it down in the bowels of Zope's C-coded
security machinery -- we'll let you
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> Nick Coghlan wrote:
>
>>> One thing that actually can motivate that test_subprocess takes 20% of the
>>> overall time is that this test is a good generic Python stress test - this
>>> test might catch some other startup race condition, for example.
>>
Nick Coghlan wrote:
>> One thing that actually can motivate that test_subprocess takes 20% of the
>> overall time is that this test is a good generic Python stress test - this
>> test might catch some other startup race condition, for example.
>
> test_decimal has a short version which tests basic
Peter Astrand wrote:
I'd like to have your opinion on this bug. Personally, I'd prefer to keep
test_no_leaking as it is, but if you think otherwise...
One thing that actually can motivate that test_subprocess takes 20% of the
overall time is that this test is a good generic Python stress test - thi
I'd like to have your opinion on this bug. Personally, I'd prefer to keep
test_no_leaking as it is, but if you think otherwise...
One thing that actually can motivate that test_subprocess takes 20% of the
overall time is that this test is a good generic Python stress test - this
test might catch
Tim Peters <[EMAIL PROTECTED]> writes:
> Rev 2.66 of funcobject.c made func.__name__ writable for the first
> time. That's great, but the patch also introduced what I'm pretty
> sure was an unintended incompatibility: after 2.66, func.__name__ was
> no longer *readable* in restricted execution m
"Gregory P. Smith" wrote:
> I don't quite like the module name 'hashes' that i chose for the
> generic interface (too close to the builtin hash() function). Other
> suggestions on a module name? 'digest' comes to mind.
hashtools, hashlib, and _hash are common names for helper modules like this.
35 matches
Mail list logo
