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:
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
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...
/F
___
Python-Dev mailing list
Python-Dev@python.org
Phillip J. Eby pje at 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
Terry Reedy tjreedy at 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
(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
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
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 this
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
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.
umm. if
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, periodically.
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 users
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 suppose this could
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 would
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*
make
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 ? ;-)
/F
___
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 changing modules
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't
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
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 integer type in
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 could have
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 timings
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
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 as creating a
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 of
[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:
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
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
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
29 matches
Mail list logo
