Many math books have an index or glossary of symbols connecting the symbols
used in the text with their meaning in that text. I have often found these
useful.
I believe that people learning and using Python would similarly benefit
from an index to the non-alphabetic symbols (and multi-symbol s
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> This is by design.
>
> The intent is that as long as you call something that returns no
> value, your last result is not thrown away. IOW _ is the last result
> that wasn't None.
>
> Please don't change this.
What m
When the result of an expression is None, the interactive interpreter
correctly suppresses the display of the result. However, it also
suppresses the underscore assignment. I'm not sure if that is correct
or desirable because a subsequent statement has no way of knowing
whether the underscore
I fixed the crasher for ``int(buffer(array.array('c')))`` by making
buffer objects operate properly. Problem is that by doing so I broke
the ctypes tests with a bunch of similar errors::
==
ERROR: test_endian_double (ctypes.test.
This is by design.
The intent is that as long as you call something that returns no
value, your last result is not thrown away. IOW _ is the last result
that wasn't None.
Please don't change this.
--Guido
On 6/7/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> When the result of an expression
On Jun 7, 2006, at 3:41 PM, Aahz wrote:
> On Wed, Jun 07, 2006, Raymond Hettinger wrote:
>> Fredrik:
>>>
>>> for users, it's actually quite simple to figure out what's in the _
>>> variable: it's the most recently *printed* result. if you cannot
>>> see
>>> it, it's not in there.
>>
>> Of cour
On 6/7/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > for users, it's actually quite simple to figure out what's in the _
> > variable: it's the most recently *printed* result. if you cannot see
> > it, it's not in there.
>
> Of course, there's a pattern to it. The question is whether it is
On Wed, Jun 07, 2006, Raymond Hettinger wrote:
>Fredrik:
>>
>> for users, it's actually quite simple to figure out what's in the _
>> variable: it's the most recently *printed* result. if you cannot see
>> it, it's not in there.
>
> Of course, there's a pattern to it. The question is whether i
> for users, it's actually quite simple to figure out what's in the _
> variable: it's the most recently *printed* result. if you cannot see
> it, it's not in there.
Of course, there's a pattern to it. The question is whether it is the *right*
behavior. Would the underscore assignment be more
Raymond Hettinger wrote:
> When the result of an expression is None, the interactive interpreter
> correctly suppresses the display of the result. However, it also
> suppresses the underscore assignment. I'm not sure if that is correct
> or desirable because a subsequent statement has no wa
When the result of an expression is None, the interactive interpreter
correctly suppresses the display of the result. However, it also
suppresses the underscore assignment. I'm not sure if that is correct
or desirable because a subsequent statement has no way of knowing
whether the undersc
M.-A. Lemburg wrote:
> Some more interesting results from comparing Python 2.4 (other) against
> the current SVN snapshot (this):
been there, done that, found the results lacking.
we spent a large part of the first NFS day to investigate all
reported slowdowns, and found that only one slowdown c
M.-A. Lemburg wrote:
> Some more interesting results from comparing Python 2.4 (other) against
> the current SVN snapshot (this):
Here's the list again, this time without wrapping (sigh):
Testnamesminimum run-timeaverage run-time
t
Some more interesting results from comparing Python 2.4 (other) against
the current SVN snapshot (this):
Testnamesminimum run-timeaverage run-time
thisother diffthisother
diff
-
Kristján V. Jónsson wrote:
> Right, it is a FILETIME in the API, but the resolution stored on disk
> is limited to what the disk format provides.
When I said "it really is a FILETIME", I meant precisely this: it is a
file time on disk, too, for NTFS. Basically, the Win32 notion of
FILETIME *origin
M.-A. Lemburg wrote:
> One interesting difference I found while testing on Windows
> vs. Linux is that the StringMappings test have quite a different
> run-time on both systems: around 2500ms on Windows vs. 590ms
> on Linux (on Python 2.4). UnicodeMappings doesn't show such
> a signficant differen
On 6/7/06, Kristján V. Jónsson <[EMAIL PROTECTED]> wrote:
> As a side note, It always seemed to me that the bf_getcharbuffer´s semantics
> were poorly defined. At least in the 2.3 documentation. Has that, and the
> need for it, changed recently?
>
I have tried to clean up the language a bit ba
At 08:38 AM 6/7/2006 -0400, A.M. Kuchling wrote:
>On Tue, Jun 06, 2006 at 06:49:45PM -0400, Phillip J. Eby wrote:
> > Source: http://svn.eby-sarna.com/svnroot/wsgiref/docs
>
>Minor correction: svn://svn.eby-sarna.com/svnroot/wsgiref/docs
>(at least, http didn't work for me).
Oops... I meant:
htt
Steve Holden wrote:
> M.-A. Lemburg wrote:
> [...]
>> Overall, time.clock() on Windows and time.time() on Linux appear
>> to give the best repeatability of tests, so I'll make those the
>> defaults in pybench 2.0.
>>
>> In short: Tim wins, I lose.
>>
>> Was a nice experiment, though ;-)
>>
> Perhap
M.-A. Lemburg wrote:
[...]
> Overall, time.clock() on Windows and time.time() on Linux appear
> to give the best repeatability of tests, so I'll make those the
> defaults in pybench 2.0.
>
> In short: Tim wins, I lose.
>
> Was a nice experiment, though ;-)
>
Perhaps so, but it would have been ni
On 6/7/06, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 06, 2006 at 06:49:45PM -0400, Phillip J. Eby wrote:
> > Source: http://svn.eby-sarna.com/svnroot/wsgiref/docs
>
> Minor correction: svn://svn.eby-sarna.com/svnroot/wsgiref/docs
> (at least, http didn't work for me).
>
> The docs look
On Tue, Jun 06, 2006 at 06:49:45PM -0400, Phillip J. Eby wrote:
> Source: http://svn.eby-sarna.com/svnroot/wsgiref/docs
Minor correction: svn://svn.eby-sarna.com/svnroot/wsgiref/docs
(at least, http didn't work for me).
The docs look good, and I think they'd be ready to go in.
--amk
As a side note, It always seemed to me that the bf_getcharbuffer´s semantics
were poorly defined. At least in the 2.3 documentation. Has that, and the
need for it, changed recently?
Kristján
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Cannon
Right, it is a FILETIME in the API, but the resolution stored on disk is
limited to what the disk format provides. FAT32 is particularly skinny.
I imagine that the value to store comes from GetSystemTimeAsFileTime which is
updated with the clock interrupt.
K
-Original Message-
From: [
Michael Chermside wrote:
> Marc-Andre Lemburg writes:
>> Using the minimum looks like the way to go for calibration.
>>
>> I wonder whether the same is true for the actual tests; since
>> you're looking for the expected run-time, the minimum may
>> not necessarily be the choice.
>
> No, you're not
Hi,
On Wed, Jun 07, 2006 at 02:07:48AM +0200, Thomas Wouters wrote:
> 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:
No, no, it's an underground move by Jerem
[Tim]
>> 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
>> having
27 matches
Mail list logo
