[Tim and Martin talking about leak tests when running regtest with -R]
I've disabled the LEAKY_TESTS exclusion in build.sh. This means if
any test reports leaks when regtest.py -R :: is run, mail will be sent
to python-checkins. The next run should kick off in a few hours (4
and 16 ET). We'll s
Tim Peters wrote:
> and filecmp contains a module-level _cache with a funky scheme for
> avoiding file comparisons if various os.stat() values haven't changed.
> But st_mtime on Windows doesn't necessarily change when a file is
> modified -- it has limited resolution (2 seconds on FAT32, and I'm
>
On 6/6/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 6/6/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > If you run ``import array; int(buffer(array.array('c')))`` the
> > interpreter will segfault. While investigating this I discovered that
> > buffer objects, for their tp_as_buffer->bf_ge
On 6/6/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> If you run ``import array; int(buffer(array.array('c')))`` the
> interpreter will segfault. While investigating this I discovered that
> buffer objects, for their tp_as_buffer->bf_getcharbuffer, return the
> result by calling the wrapped object
[Tim, gets different results across whole runs of
python_d ../Lib/test/regrtest.py -R 2:40: test_filecmp test_exceptions
]
I think I found the cause for test_filecmp giving different results
across runs, at least on Windows. It appears to be due to this test
line:
self.failUnless(d
Jim Jewett wrote:
> For pkgutil in particular, the change is that instead of writing to
> stderr (which can scroll off and get lost), it will write to the
> errorlog. In a truly default setup, that still ends up writing to
> stderr.
This might be better addressed by providing a centralised
way o
I just submitted http://python.org/sf/1501934 and assigned it to Neal so it doesn't get forgotten before 2.5 goes out ;) It seems Python 2.5 compiles the following code incorrectly:
>>> g = 1>>> def f1():... g += 1... >>> f1()>>> g2It looks like the compiler is not seeing augmented assignment a
I've finished my draft for the wsgiref documentation (including stuff I
swiped from AMK's draft; thanks AMK!), and am looking for comments before I
add it to the stdlib documentation.
Source: http://svn.eby-sarna.com/svnroot/wsgiref/docs
PDF:http://peak.telecommunity.com/wsgiref.pdf
HTML:
If you run ``import array; int(buffer(array.array('c')))`` the
interpreter will segfault. While investigating this I discovered that
buffer objects, for their tp_as_buffer->bf_getcharbuffer, return the
result by calling the wrapped object bf_getreadbuffer or
bf_getwritebuffer. This is wrong since
M.-A. Lemburg wrote:
> FWIW, these are my findings on the various timing strategies:
Correction (due to a bug in my pybench dev version):
> * Windows:
>
> time.time()
> - not usable; I get timings with an error interval of roughly 30%
>
> GetProcessTimes()
> - not usable; I get timi
Jim Jewett wrote:
> Jackilyn is adding logging to several stdlib modules for the Google
> Summer of Code (PEP 337), and asked me to review her first few
> changes.
A related question: Will your student try to resolve the issues on SF
referring to logging, or is that not part of the project? There
M.-A. Lemburg wrote:
> * Linux:
>
> time.clock()
> - not usable; I get timings with error interval of about 30%
> with differences in steps of 100ms
> resource.getrusage()
> - error interval of less than 10%; overall < 0.5%
> with differences in steps of 10ms
hmm. I cou
> Are you suggesting that the logging module should ship with a standard
> configuration that does something specific for py.* loggers? Or even
> one that has different handlers for different stdlib modules?
Sorry I'm a little late in to the discussion :-(
I can see people objecting to a "standa
Jim Jewett wrote:
> Martin v. Löwis replied:
>
>> ... column numbers shouldn't exceed 16-bits, and line #s
>> shouldn't exceed 31 bits.
>
> Why these particular numbers?
>
> As nearly as I can tell, 8 bits is already too many columns for human
> readability.
There isn't a practical 8-bit intege
Thomas Heller wrote:
> In Include/structmember.h, there is no T_... constant for Py_ssize_t
> member fields. Should there be one?
As Fredrik says: if you need it, feel free to add it.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
ht
FWIW, these are my findings on the various timing strategies:
* Windows:
time.time()
- not usable; I get timings with an error interval of roughly 30%
GetProcessTimes()
- not usable; I get timings with an error interval of up to 100%
with differences in steps of 15.626ms
tim
On Tue, Jun 06, 2006 at 10:36:06AM -0400, Jim Jewett wrote:
> Are you suggesting that the logging module should ship with a standard
> configuration that does something specific for py.* loggers? Or even
> one that has different handlers for different stdlib modules?
No, I meant some modules don'
At 10:13 AM 6/6/2006 -0400, Jim Jewett wrote:
>On 6/5/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>
>>I notice you've completely avoided the question of whether this should be
>>being done at all.
>
>>As far as I can tell, this PEP hasn't actually been discussed. Please
>>don't waste time changi
M.-A. Lemburg wrote:
> This example is a bit misleading, since chances are high that
> the benchmark will get a good priority bump by the scheduler.
which makes it run infinitely fast ? what planet are you buying your
hardware on ? ;-)
___
Python-D
Fredrik Lundh wrote:
> Martin v. Löwis wrote:
>
>>> since process time is *sampled*, not measured, process time isn't exactly
>>> in-
>>> vulnerable either.
>> I can't share that view. The scheduler knows *exactly* what thread is
>> running on the processor at any time, and that thread won't chan
Jim Jewett wrote:
> This does argue in favor of allowing the more intrusive additions to
> handlers and default configuration. It would be useful to have a
> handler that emitted only Apache log format records, and saved them
> (by default) to a rotating file rather than stderr.(And it *might*
>
On 6/6/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I notice in the PEP that BaseHTTPServer is on the list of candidate modules.
> Please don't mess with anything that logs in the common Apache log format.
> There are lots of tools out there that munch on that sort of output.
> Changing it wo
Fredrik Lundh wrote:
> M.-A. Lemburg wrote:
>
>> I just had an idea: if we could get each test to run
>> inside a single time slice assigned by the OS scheduler,
>> then we could benefit from the better resolution of the
>> hardware timers while still keeping the noise to a
>> minimum.
>>
>> I sup
Jim Jewett wrote:
> The existing logging that she is replacing is done through methods of
> the dispatcher class. The dispatcher class is only a portion of the
> whole module.
the dispatcher class is never used on its own; it's a base class for
user-defined communication classes.
asyncore user
>> As far as I can tell, this PEP hasn't actually been discussed.
>> Please don't waste time changing modules for which there is no
>> consensus that this *should* be done.
Jim> Under a specific PEP number, no. The concept of adding logging to
Jim> the stdlib, yes, periodical
On 6/6/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Jim Jewett wrote:
>
> > For pkgutil in particular, the change is that instead of writing to
> > stderr (which can scroll off and get lost), it will write to the
> > errorlog. In a truly default setup, that still ends up writing to
> > stderr.
>
>>py.asyncore.dispatcher.hits
>>py.asyncore.dispatcher.messages
> These handler names seem really specific, though. Why have
> 'dispatcher' in there?
The existing logging that she is replacing is done through methods of
the dispatcher class. The dispatcher class is only a portion of the
Jim Jewett wrote:
> For pkgutil in particular, the change is that instead of writing to
> stderr (which can scroll off and get lost), it will write to the
> errorlog. In a truly default setup, that still ends up writing to
> stderr.
umm. if pkgutil fails to open a pkg file, isn't it rather like
On 6/5/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> I notice you've completely avoided the question of whether this should be
> being done at all.
> As far as I can tell, this PEP hasn't actually been discussed. Please
> don't waste time changing modules for which there is no consensus that t
The Arlington sprint this past Saturday went well, though the number
of Python developers was small and people mostly worked on other
projects.
The CanDo group, the largest at the sprint with about 10 people, will
be having a three-day sprint July 28-30 (Fri-Sun) at the same
location. We should
(Neal Norwitz asked about changing some additional ints and longs to ssize_t)
Martin v. Löwis replied:
> ... column numbers shouldn't exceed 16-bits, and line #s
> shouldn't exceed 31 bits.
Why these particular numbers?
As nearly as I can tell, 8 bits is already too many columns for human
reada
Terry Reedy udel.edu> writes:
> tout court?? is not English or commonly used at least in America
It is French:
http://encarta.msn.com/dictionary_561508877/tout_court.html
I thought it was common in English too, but clearly I was mistaken.
> Ok, you mean generator function, which produces gene
Phillip J. Eby telecommunity.com> writes:
> I think the whole concept of inspecting for this is broken. *Any*
> function can return a generator-iterator. A generator function is just a
> function that happens to always return one.
> In other words, the confusion is in the idea of introspectin
Thomas Heller wrote:
> In Include/structmember.h, there is no T_... constant for Py_ssize_t
> member fields. Should there be one?
do you need one? if so, I see no reason why you cannot add it...
___
Python-Dev mailing list
Python-Dev@python.org
htt
On Mon, Jun 05, 2006 at 08:49:47PM -0400, Jim Jewett wrote:
> If no explicit changes are made locally,
>
>py.asyncore.dispatcher.hits
>py.asyncore.dispatcher.messages
These handler names seem really specific, though. Why have
'dispatcher' in there?
Part of Jackilyn's task should be to r
In Include/structmember.h, there is no T_... constant for Py_ssize_t
member fields. Should there be one?
Thomas
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/ma
36 matches
Mail list logo