Re: [Python-Dev] [Python-checkins] Python Regression Test Failures refleak (1)
[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 a hard time finding a believable answer for NTFS (which I'm >> using)). [Martin] > The time stamp itself has a precision of 100ns (it really is a > FILETIME). Right -- see "believable" above ;-) > I don't know whether there is any documentation that > explains how often it is updated; I doubt it has a higher resolution > than the system clock :-) Me too. >> Anyone bored enough to report what happens on Linux? > I had to run it 18 times to get > > test_exceptions > beginning 42 repetitions > 123456789012345678901234567890123456789012 > .. > test_exceptions leaked [203, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0] references > 1 test OK. Thank you! I'm sorry to hear you were so bored ;-) So here's a fun mystery for someone less sleepy than I am at this time: patch 1501987 (which I checked in) appears to have cured this, but neither I nor its author seem to know why. test_exceptions was picking a pickle protocol at random (WTF?!), and the patch makes it try all pickle protocols instead. Now that I typed that, I discovered I really don't care why it cured it, so it's all yours :-) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'fast locals' in Python 2.5
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 Jeremy to allow assignment to variables of enclosing scopes: [in 2.5] def f(): x = 5 def g(): x += 1 g() print x # 6 The next move is to say that this is an expected feature of the augmented assignment operators, from which it follows naturally that we need a pseudo-augmented assignment that doesn't actually read the old value: [in 2.6] def f(): x = 5 def g(): x := 6 g() print x# 6 Credits to Samuele's evil side for the ideas. His non-evil side doesn't agree, and neither does mine, of course :-) More seriously, a function with a variable that is only written to as the target of augmented assignments cannot possibly be something else than a newcomer's mistake: the augmented assignments will always raise UnboundLocalError. Maybe this should be a SyntaxWarning? A bientot, Armin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Benchmarks
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 looking for the expected run-time. The expected > run-time is a function of the speed of the CPU, the architechure > of same, what else is running simultaneously -- perhaps even > what music you choose to listen to that day. It is NOT a > constant for a given piece of code, and is NOT what you are > looking for. I was thinking of the expected value of the test for run-time (the statistical value). This would likely have a better repeatability than e.g. the average (see Andrew's analysis) or the minimum which can be affected by artifacts due to the method of measurement (see Fredrik's analysis). The downside is that you need quite a few data points to make a reasonable assumption on the value of the expected value. Another problem is that of sometimes running into the situation where you have a distribution of values which is in fact the overlap of two (or more) different distributions (see Andrew's graphics). In the end, the minimum is the best compromise, IMHO, since it is easy to get a good estimate fast. pybench stores all measured times in the test pickle, so it is possible to apply different statistical methods later on - even after the test was run. > What you really want to do in benchmarking is to *compare* the > performance of two (or more) different pieces of code. You do, > of course, care about the real-world performance. So if you > had two algorithms and one ran twice as fast when there were no > context switches and 10 times slower when there was background > activity on the machine, then you'd want prefer the algorithm > that supports context switches. But that's not a realistic > situation. What is far more common is that you run one test > while listening to the Grateful Dead and another test while > listening to Bach, and that (plus other random factors and the > phase of the moon) causes one test to run faster than the > other. I wonder which one of the two ;-) > Taking the minimum time clearly subtracts some noise, which is > a good thing when comparing performance for two or more pieces > of code. It fails to account for the distribution of times, so > if one piece of code occasionally gets lucky and takes far less > time then minimum time won't be a good choice... but it would > be tricky to design code that would be affected by the scheduler > in this fashion even if you were explicitly trying! Tried that and even though you can trick the scheduler into running your code without context switch, the time left to do benchmarks boils down to a milli-second - there's not a lot you can test in such a time interval. What's worse: the available timers don't have good enough resolution to make the timings useful. > Later he continues: >> Tim thinks that it's better to use short running tests and >> an accurate timer, accepting the added noise and counting >> on the user making sure that the noise level is at a >> minimum. >> >> Since I like to give users the option of choosing for >> themselves, I'm going to make the choice of timer an >> option. > > I'm generally a fan of giving programmers choices. However, > this is an area where we have demonstrated that even very > competent programmers often have misunderstandings (read this > thread for evidence!). So be very careful about giving such > a choice: the default behavior should be chosen by people > who think carefully about such things, and the documentation > on the option should give a good explanation of the tradeoffs > or at least a link to such an explanation. I'll use good defaults (see yesterdays posting), which essentially means: use Tim's approach... until we all have OSes with real-time APIs using hardware timers instead of jiffie counters. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 07 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] Python Regression Test Failuresrefleak (1)
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of "Martin v. Löwis" Sent: 7. júní 2006 05:54 To: Tim Peters Cc: Neal Norwitz; Python Dev Subject: Re: [Python-Dev] [Python-checkins] Python Regression Test Failuresrefleak (1) 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 > having a hard time finding a believable answer for NTFS (which I'm > using)). The time stamp itself has a precision of 100ns (it really is a FILETIME). I don't know whether there is any documentation that explains how often it is updated; I doubt it has a higher resolution than the system clock :-) > Anyone bored enough to report what happens on Linux? I had to run it 18 times to get test_exceptions beginning 42 repetitions 123456789012345678901234567890123456789012 .. test_exceptions leaked [203, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] references 1 test OK. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How to fix the buffer object's broken char buffersupport
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
Sent: 6. júní 2006 22:30
To: Python Dev
Subject: [Python-Dev] How to fix the buffer object's broken char buffersupport
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 it is essentially
redirecting the expected call to the wrong tp_as_buffer slot for the wrapped
object. Plus it doesn't have Py_TPFLAGS_HAVE_GETCHARBUFFER defined.
I see two options here. One is to remove the bf_getcharbuffer slot from the
buffer object. The other option is to fix it so that it only returns
bf_getcharbuffer and doesn't redirect improperly (this also brings up the issue
if Py_TPFLAGS_HAVE_GETCHARBUFFER should then also be defined for buffer
objects).
Since I don't use buffer objects I don't know if it is better to fix this or
just rip it out.
-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] wsgiref doc draft; reviews/patches wanted
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] wsgiref doc draft; reviews/patches wanted
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 good, and I think they'd be ready to go in. http://svn.eby-sarna.com/wsgiref/docs/ works for me. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Benchmarks
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 nice if you could have come to this conclusion before asking me not to make this change, which would otherwise have been checked in two weeks ago. Still, as long as we can all agree on this and move forward I suppose the intervening debate at least leaves us better-informed. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Love me, love my blog http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Benchmarks
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 ;-) >> > Perhaps so, but it would have been nice if you could have come to this > conclusion before asking me not to make this change, which would > otherwise have been checked in two weeks ago. I still believe that measuring process time is better than wall time and have tried hard to find suitable timers for implementing this. However, the tests using the various different timers have shown that this approach doesn't work out due to the problems with how process time is measured on the platforms in question (Linux and Windows). We should revisit this choice once suitable timers are available on those platforms. Note that even with the wall-time timers and using the minimum function as estimator you still get results which exhibit random noise. At least now we know that there's apparently no way to get it removed. > Still, as long as we can all agree on this and move forward I suppose > the intervening debate at least leaves us better-informed. Isn't that the whole point of such a discussion ? I'll check in pybench 2.0 once I've tested it enough. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 07 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] wsgiref doc draft; reviews/patches wanted
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: http://svn.eby-sarna.com/wsgiref/docs/ Kind of garbled up the svn: and http: URLs; the HTTP one is for ViewCVS. >The docs look good, and I think they'd be ready to go in. > >--amk >___ >Python-Dev mailing list >[email protected] >http://mail.python.org/mailman/listinfo/python-dev >Unsubscribe: >http://mail.python.org/mailman/options/python-dev/pje%40telecommunity.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How to fix the buffer object's broken char buffersupport
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 based on how I was
interpreting the docs. Hopefully that isn't wrong since I am basing
my patch on it. =)
But since I don't use buffers ever and Py3k is ditching buffers for
the bytes type, I am personally not going to worry about changing
their definition beyond clarifying the docs.
-Brett
> Kristján
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Cannon
> Sent: 6. júní 2006 22:30
> To: Python Dev
> Subject: [Python-Dev] How to fix the buffer object's broken char buffersupport
>
> 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 it
> is essentially redirecting the expected call to the wrong tp_as_buffer slot
> for the wrapped object. Plus it doesn't have Py_TPFLAGS_HAVE_GETCHARBUFFER
> defined.
>
> I see two options here. One is to remove the bf_getcharbuffer slot from the
> buffer object. The other option is to fix it so that it only returns
> bf_getcharbuffer and doesn't redirect improperly (this also brings up the
> issue if Py_TPFLAGS_HAVE_GETCHARBUFFER should then also be defined for buffer
> objects).
>
> Since I don't use buffer objects I don't know if it is better to fix this or
> just rip it out.
>
> -Brett
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Benchmarks
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 difference. > > Perhaps the sprint changed this ?! nope. but stringbench revealed the same thing, of course. the difference is most likely due to an inefficient implementation of locale-aware character lookups in Visual C (MSVC supports passing wide chars, but I don't think gcc bothers to do that; afaik, it's not part of the C standard). solving this is straightforward (let the locale module set a global flag if Python runs under a non-C locale, and use a built-in table as long as that flag isn't set), but I haven't gotten around to deal with that yet. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] Python Regression Test Failuresrefleak (1)
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 *originates* from the way NTFS stores time stamps. For FAT, the on-disk precision is worse, of course. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Benchmarks
Some more interesting results from comparing Python 2.4 (other) against the current SVN snapshot (this): Testnamesminimum run-timeaverage run-time thisother diffthisother diff --- BuiltinMethodLookup: 142ms 124ms +14.5% 151ms 134ms +13.1% ConcatUnicode:95ms 120ms -20.7% 104ms 131ms -20.5% CreateInstances: 102ms92ms +10.0% 107ms96ms +11.5% CreateUnicodeWithConcat:98ms 122ms -19.2% 103ms 129ms -20.1% DictWithFloatKeys: 128ms 149ms -14.1% 133ms 177ms -24.8% NestedForLoops: 141ms 126ms +11.8% 144ms 128ms +12.3% PythonFunctionCalls: 131ms 108ms +21.5% 133ms 109ms +21.3% SecondImport: 135ms 114ms +18.3% 140ms 117ms +20.0% SecondPackageImport: 136ms 122ms +11.2% 144ms 124ms +16.1% SecondSubmoduleImport: 166ms 146ms +13.5% 171ms 148ms +15.9% SimpleComplexArithmetic: 106ms 131ms -19.1% 112ms 133ms -16.2% StringPredicates: 109ms96ms +13.6% 114ms99ms +15.7% TryRaiseExcept: 119ms 137ms -13.3% 122ms 140ms -12.6% UnicodeMappings: 140ms 157ms -10.8% 141ms 160ms -11.4% UnicodePredicates: 111ms98ms +12.9% 115ms 100ms +15.3% UnicodeSlicing: 101ms 114ms -11.2% 108ms 116ms -6.7% It appears as if the import mechanism took a hit between the versions. The NFS sprint results are also visible. A little disturbing is the slow-down for Python function calls and the built-in method lookup. Did anything change in these parts of the interpreter ? This is the machine I used for running the pybench: Timer: time.time Machine Details: Platform ID: Linux-2.6.8-24.19-default-x86_64-with-SuSE-9.2-x86-64 Processor:x86_64 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 07 2006) >>> Python/Zope Consulting and Support ... >>> http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... >>> http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... >>> http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Benchmarks
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 thisother diffthisother diff --- BuiltinMethodLookup: 141ms 124ms +13.9% 148ms 134ms +10.8% ConcatUnicode:97ms 120ms -19.5% 104ms 131ms -20.6% CreateInstances: 102ms92ms +10.3% 104ms96ms +8.0% CreateUnicodeWithConcat:98ms 122ms -19.1% 103ms 129ms -20.6% DictWithFloatKeys: 128ms 149ms -14.4% 130ms 177ms -26.4% NestedForLoops: 140ms 126ms +11.1% 143ms 128ms +11.8% PythonFunctionCalls: 130ms 108ms +21.3% 132ms 109ms +20.9% SecondImport: 136ms 114ms +18.9% 138ms 117ms +18.2% SecondPackageImport: 141ms 122ms +15.4% 143ms 124ms +15.3% SecondSubmoduleImport: 166ms 146ms +13.3% 179ms 148ms +21.3% SimpleComplexArithmetic: 107ms 131ms -18.5% 121ms 133ms -9.2% StringPredicates: 109ms96ms +13.5% 117ms99ms +18.7% TryRaiseExcept: 115ms 137ms -16.2% 129ms 140ms -7.6% UnicodeMappings: 140ms 157ms -10.7% 142ms 160ms -11.3% UnicodePredicates: 111ms98ms +13.3% 115ms 100ms +15.6% UnicodeSlicing: 103ms 114ms -10.1% 108ms 116ms -6.7% > It appears as if the import mechanism took a hit between the > versions. > > The NFS sprint results are also visible. > > A little disturbing is the slow-down for Python function calls > and the built-in method lookup. Did anything change in these parts > of the interpreter ? > > > This is the machine I used for running the pybench: > Timer: time.time > Machine Details: >Platform ID: Linux-2.6.8-24.19-default-x86_64-with-SuSE-9.2-x86-64 >Processor:x86_64 > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 07 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Benchmarks
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 could be independently confirmed (the exception issue). try running some of your subtests under timeit, and see if you can repeat the results. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Is implicit underscore assignment buggy?
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 assignment is current or whether it represents an
earlier non-None result.
Here's an example from a co-worker's regular expression experiments:
>>> import re, string
>>> re.search('lmnop', string.letters)
<_sre.SRE_Match object at 0xb6f2c480>
>>> re.search('pycon', string.letters)
>>> if _ is not None:
... print _.group()
lmnop
Raymond
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is implicit underscore assignment buggy?
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 way of knowing > whether the underscore assignment is current or whether it represents an > earlier non-None result. why would a subsequent statement need to know that ? are you sure you didn't mean "user" instead of "subsequent statement" ? 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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is implicit underscore assignment buggy?
> 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 useful and intuitive if it always contained the immediately preceding result, even if it was None? In some cases (such as the regexp example), None is a valid and useful possible result of a computation and you may want to access that result with _. BTW, there is a trivial exception to the "most recently printed result" rule. >>> 13 13 >>> _ = None >>> _ # _ is no longer the most recently printed result Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is implicit underscore assignment buggy?
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 it is the > *right* behavior. Would the underscore assignment be more useful and > intuitive if it always contained the immediately preceding result, > even if it was None? In some cases (such as the regexp example), None > is a valid and useful possible result of a computation and you may > want to access that result with _. My take is that Fredrik is correct about the current behavior being most generally useful even if it is slightly less consistent, as well as being undesired in rare circumstances. Consider that your message is the only one I've seen in more than five years of monitoring python-dev and c.l.py. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "I saw `cout' being shifted "Hello world" times to the left and stopped right there." --Steve Gonedes ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is implicit underscore assignment buggy?
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 the *right* > behavior. Would the underscore assignment be more useful and intuitive > if it always contained the immediately preceding result, even if it was None? > In some cases (such as the regexp example), None is a valid and useful > possible result of a computation and you may want to access that result with > _. If you're using _ in an interactive environment, it's usually because you don't want to re-type the value of the expression. If the value is None, it isn't hard to type. > BTW, there is a trivial exception to the "most recently printed result" rule. > > >>> 13 > 13 > >>> _ = None > >>> _ # _ is no longer the most recently printed result If you want to assign to _, the results are your own fault. Jeremy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is implicit underscore assignment buggy?
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 course, there's a pattern to it. The question is whether it is >> the >> *right* behavior. Would the underscore assignment be more useful and >> intuitive if it always contained the immediately preceding result, >> even if it was None? In some cases (such as the regexp example), >> None >> is a valid and useful possible result of a computation and you may >> want to access that result with _. > > My take is that Fredrik is correct about the current behavior being > most > generally useful even if it is slightly less consistent, as well as > being > undesired in rare circumstances. Consider that your message is the > only > one I've seen in more than five years of monitoring python-dev and > c.l.py. I agree. I've definitely made use of the current behavior, e.g. for printing a different representation of _ before doing something else with it. -bob ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is implicit underscore assignment buggy?
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 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 assignment is current or whether it represents an
> earlier non-None result.
>
> Here's an example from a co-worker's regular expression experiments:
>
> >>> import re, string
> >>> re.search('lmnop', string.letters)
> <_sre.SRE_Match object at 0xb6f2c480>
> >>> re.search('pycon', string.letters)
> >>> if _ is not None:
> ... print _.group()
> lmnop
>
>
>
> Raymond
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Is "t#" argument format meant to be char buffer, or just read-only?
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.test_byteswap.Test)
--
Traceback (most recent call last):
File "/code/python/trunk/Lib/ctypes/test/test_byteswap.py", line
134, in test_endian_double
self.failUnlessEqual(bin(struct.pack("d", math.pi)), bin(s))
File "/code/python/trunk/Lib/ctypes/test/test_byteswap.py", line 7, in bin
return hexlify(buffer(s)).upper()
TypeError: requested buffer type not available
Turns out the test does the following::
binascii.hexlify(buffer(ctypes.c_double(math.pi)))
This is a problem because binascii.hexlify() uses "t#" as its argument
format string to PyArg_ParseTuple() and that fails now with a
TypeError since ctypes.c_double (which subclasses ctypes._SimpleCData
which defines the buffer interface) does not have a char buffer
defined.
Now this used to pass since buffer objects just used the read or write
buffer in place of the char buffer, regardless if the wrapped object
had a char buffer function defined.
But in checking out what "t#" did, I found a slight ambiguity in the
docs. The docs say "read-only character buffer" for the short
description, but "read-only buffer" for the longer description. Which
is it?
Plus, Thomas, you might want to change _SimpleCData if you want it to
truly suport char buffers.
-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Is implicit underscore assignment buggy?
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 assignment is current or whether it represents an
earlier non-None result.
Here's an example from a co-worker's regular expression experiments:
>>> import re, string
>>> re.search('lmnop', string.letters)
<_sre.SRE_Match object at 0xb6f2c480>
>>> re.search('pycon', string.letters)
>>> if _ is not None:
... print _.group()
lmnop
Raymond
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is implicit underscore assignment buggy?
"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 might be improved is the documentation of this, which I could not find in a few minutes of searching. As of current 2.4 docs, the Tutorial, Language, and Library manuals all have index pages for identifiers beginning with '_' but none contain '_' itself. (And none have entries for 'underscore'.) Language Reference 2.3.2 Reserved classes of identifiers lists all the other special identifier classes starting with '_' but not '_' itself. I think this would be a good place for an entry for '_' and its special meaning in interactive mode. Tutorial 2.1.2 Interactive Mode would be another place to mention the special use of '_'. If there is something I missed (that is not indexed), then I missed it. Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Symbol page for Language Reference Manual Index
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 syntactic units) used in Python code. I am willing to do perhaps half the work needed to produce such in time for the 2.5 release. In particular, I am willing to write a plain text file listing symbols (in ascii sort order) and section numbers, in an agreed-on format, if the idea is approved and someone else agrees to convert section numbers to page links and do the necessary latex/html formatting (with a Python script?). The main formatting decision is between the two formats already used for identifiers versus topics. For example, for the multiple meanings of '()' (which is one syntactic unit): () (calls) 5.3.4 () (expressions) 5.2.3 () (tuple literals) 5.2.3 with each line a link -- see '__dict__' for an example -- or () calls 5.3.4 expressions 5.2.3 tuple 5.2.3 with each subline a link -- see arithmetic for an example. [I just realized that some links need to be within-page rather than to the top of the page and that I can cut and paste additional info if I find the appropriate regular index entry, such as http://docs.python.org/ref/parenthesized.html#l2h-342 for 5.2.3. But I will work this sort of thing out with whoever formats.] Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
