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.
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 mode.
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 -
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
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.
test_decimal
[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 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 Zope's C-coded
[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
[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 contributor
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 mark the test
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
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
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
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 that
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 tests are run.
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 patch
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:
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
unicode in
[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
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
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
[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 wink: LFH doesn't help with
the lists directly, but helps
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
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 single
24 matches
Mail list logo
