Re: [Python-Dev] Not-a-Number
On Fri, Apr 29, 2011 at 2:18 AM, Greg Ewing wrote: > Taking a step back from all this, why does Python allow > NaNs to arise from computations *at all*? History, I think. There's a c.l.p. message from Tim Peters somewhere saying something along the lines that he'd love to make (e.g.,) 1e300 * 1e300 raise an exception instead of producing an infinity, but dare not for fear of the resulting outcry from people who use the current behaviour. Apologies if I've misrepresented what he actually said---I'm failing to find the exact message at the moment. If it weren't for backwards compatibility, I'd love to see Python raise exceptions instead of producing IEEE special values: IOW, to act as though the divide-by-zero, overflow and invalid_operation FP signals all produce an exception. As a bonus, perhaps there could be a mode that allowed 'nonstop' arithmetic, under which infinities and nans were produced as per IEEE 754: with math.non_stop_arithmetic(): ... But this is python-ideas territory. Mark ___ 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] Not-a-Number
On Sat, 30 Apr 2011 08:02:33 +0100 Mark Dickinson wrote: > On Fri, Apr 29, 2011 at 2:18 AM, Greg Ewing > wrote: > > Taking a step back from all this, why does Python allow > > NaNs to arise from computations *at all*? > > History, I think. There's a c.l.p. message from Tim Peters somewhere > saying something along the lines that he'd love to make (e.g.,) 1e300 > * 1e300 raise an exception instead of producing an infinity, but dare > not for fear of the resulting outcry from people who use the current > behaviour. Apologies if I've misrepresented what he actually > said---I'm failing to find the exact message at the moment. > > If it weren't for backwards compatibility, I'd love to see Python > raise exceptions instead of producing IEEE special values: IOW, to > act as though the divide-by-zero, overflow and invalid_operation FP > signals all produce an exception. As a bonus, perhaps there could be > a mode that allowed 'nonstop' arithmetic, under which infinities and > nans were produced as per IEEE 754: > > with math.non_stop_arithmetic(): > ... > > But this is python-ideas territory. I would much prefer this idea than the idea of making NaNs non-orderable. It would break code, but at least it would break in less unexpected and annoying ways. Regards Antoine. ___ 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] cpython: PyGILState_Ensure(), PyGILState_Release(), PyGILState_GetThisThreadState() are
Le mercredi 27 avril 2011 à 20:18 -0400, Jim Jewett a écrit : > Would it be a problem to make them available a no-ops? > > On 4/26/11, victor.stinner wrote: > > http://hg.python.org/cpython/rev/75503c26a17f > > changeset: 69584:75503c26a17f > > user:Victor Stinner > > date:Tue Apr 26 23:34:58 2011 +0200 > > summary: > > PyGILState_Ensure(), PyGILState_Release(), PyGILState_GetThisThreadState() > > are > > not available if Python is compiled without threads. Oh, I realized that PyGILState_STATE may also be included only if Python is compiled with threads. -- PyGILState_Ensure() and PyGILState_Release() could be no-op yes, it would simplify the usage of these functions. For example: #ifdef WITH_THREAD PyGILState_STATE gil; #endif fprintf(stderr, "object : "); #ifdef WITH_THREAD gil = PyGILState_Ensure(); #endif (void)PyObject_Print(op, stderr, 0); #ifdef WITH_THREAD PyGILState_Release(gil); #endif -- Even without threads, a Python process has a PyThreadState structure, so PyGILState_GetThisThreadState() can be patched to work even if Python is compiled without threads. -- Would you like to work on such patch? Or at least open an issue? Victor ___ 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] Not-a-Number
[Greg Ewing] >> Taking a step back from all this, why does Python allow >> NaNs to arise from computations *at all*? [Mark Dickinson] > History, I think. There's a c.l.p. message from Tim Peters somewhere > saying something along the lines that he'd love to make (e.g.,) 1e300 > * 1e300 raise an exception instead of producing an infinity, but dare > not for fear of the resulting outcry from people who use the current > behaviour. Apologies if I've misrepresented what he actually > said---I'm failing to find the exact message at the moment. > > If it weren't for backwards compatibility, I'd love to see Python > raise exceptions instead of producing IEEE special values: IOW, to > act as though the divide-by-zero, overflow and invalid_operation FP > signals all produce an exception. Exactly. It's impossible to create a NaN from "normal" inputs without triggering div-by-0 or invalid_operation, and if overflow were also enabled it would likewise be impossible to create an infinity from normal inputs. So, 20 years ago, that's how I arranged Kendall Square Research's default numeric environment: enabled those three exception traps by default, and left the underflow and inexact exception traps disabled by default. It's not just "naive" users initially baffled by NaNs and infinities; most of KSR's customers were heavy duty number crunchers, and they didn't know what to make of them at first either. But experts do find them very useful (after climbing the 754 learning curve), so there was also a simple function call (from all the languages we supported - C, C++, FORTRAN and Pascal), to establish the 754 default all-traps-disabled mode: > As a bonus, perhaps there could be a mode that allowed 'nonstop' > arithmetic, under which infinities and nans were produced as per IEEE 754: > > with math.non_stop_arithmetic(): > ... > > But this is python-ideas territory. All of which is just moving toward the numeric environment 754 was aiming for from the start: complete user control over which exception traps are and aren't currently enabled. The only quibble I had with that vision was its baffle-99%-of-users requirement that they _all_ be disabled by default. As Kahan wrote, it's called "an exception" because no matter _what_ you do, someone will take exception to your policy ;-) That's why user control is crucial in a 754 environment. He wanted even more control than 754 recommends (in particular, he wanted the user to be able to specify _which_ value was returned when an exception triggered; e.g., in some apps it may well be more useful for overflow to produce a NaN than an infinity, or to return the largest normal value with the correct sign). Unfortunately, the hardware and academic types who created 754 had no grasp of how difficult it is to materialize their vision in software, and especially not of how very difficult it is to backstitch a pleasant wholly conforming environment into an existing language. As a result, I'm afraid the bulk of 754's features are stilled viewed as "a nuisance" by a vast majority of users :-( ___ 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] Issue Tracker
On Tue, Mar 29, 2011 at 4:37 AM, R. David Murray wrote: > > The hardest part is debugging the TAL when you make a mistake, but > even that isn't a whole lot worse than any other templating language. How much in % is it worse than Django templating language? -- anatoly t. ___ 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] Socket servers in the test suite
Hi, Le 29/04/2011 18:09, Vinay Sajip a écrit : [Georg] BTW, didn't we agree not to put "pragma" comments into the stdlib code? I'd be grateful for a link to the prior discussion - it must have passed me by originally, and I searched python-dev on gmane but couldn't find any threads about this. I remember only this: http://bugs.python.org/issue11572#msg131139 Regards ___ 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] sys.settrace: behavior doesn't match docs
This week I learned something new about trace functions (how to write a
C trace function that survives a sys.settrace(sys.gettrace())
round-trip), and while writing up what I learned, I was surprised to
discover that trace functions don't behave the way I thought, or the way
the docs say they behave.
The docs say:
The trace function is invoked (with /event/ set to 'call') whenever
a new local scope is entered; it should return a reference to a
local trace function to be used that scope, or None if the scope
shouldn't be traced.
The local trace function should return a reference to itself (or to
another function for further tracing in that scope), or None to turn
off tracing in that scope.
It's that last part that's wrong: returning None from the trace function
only has an effect on the first call in a new frame. Once the trace
function returns a function for a frame, returning None from subsequent
calls is ignored. A "local trace function" can't turn off tracing in
its scope.
To demonstrate:
import sys
UPTO_LINE = 1
def t(frame, event, arg):
num = frame.f_lineno
print("line %d" % num)
if num < UPTO_LINE:
return t
def try_it():
print("twelve")
print("thirteen")
print("fourteen")
print("fifteen")
UPTO_LINE = 1
sys.settrace(t)
try_it()
UPTO_LINE = 13
sys.settrace(t)
try_it()
Produces:
line 11
twelve
thirteen
fourteen
fifteen
line 11
line 12
twelve
line 13
thirteen
line 14
fourteen
line 15
fifteen
line 15
The first call to try_it() returns None immediately, preventing tracing
for the rest of the function. The second call returns None at line 13,
but the rest of the function is traced anyway. This behavior is the
same in all versions from 2.3 to 3.2, in fact, the 100 lines of code in
sysmodule.c responsible for Python tracing functions are completely
unchanged through those versions. (A deeper mystery that I haven't
looked into yet is why Python 3.x intersperses all of these lines with
"line 18" interjections.)
I'm writing this email because I'm not sure whether this is a behavior
bug or a doc bug. One of them is wrong, since they disagree. The
documented behavior makes sense, and is what people have all along
thought the trace function did. The actual behavior is a bit more
complicated to explain, but is what people have actually been
experiencing. FWIW, PyPy implements the documented behavior.
Should we fix the code or the docs? I'd be glad to supply a patch for
either.
--Ned.
___
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] sys.settrace: behavior doesn't match docs
I think you need to go back farther in time. :-) In Python 2.0 the
call_trace function in ceval.c has a completely different signature
(but the docs are the same). I haven't checked all history but
somewhere between 2.0 and 2.3, SET_LINENO-less tracing was added, and
that's where the implementation must have gone wrong. So I think we
should fix the code.
--Guido
On Sat, Apr 30, 2011 at 3:49 PM, Ned Batchelder wrote:
> This week I learned something new about trace functions (how to write a C
> trace function that survives a sys.settrace(sys.gettrace()) round-trip), and
> while writing up what I learned, I was surprised to discover that trace
> functions don't behave the way I thought, or the way the docs say they
> behave.
>
> The docs say:
>
> The trace function is invoked (with event set to 'call') whenever a new
> local scope is entered; it should return a reference to a local trace
> function to be used that scope, or None if the scope shouldn’t be traced.
>
> The local trace function should return a reference to itself (or to another
> function for further tracing in that scope), or None to turn off tracing in
> that scope.
>
> It's that last part that's wrong: returning None from the trace function
> only has an effect on the first call in a new frame. Once the trace
> function returns a function for a frame, returning None from subsequent
> calls is ignored. A "local trace function" can't turn off tracing in its
> scope.
>
> To demonstrate:
>
> import sys
>
> UPTO_LINE = 1
>
> def t(frame, event, arg):
> num = frame.f_lineno
> print("line %d" % num)
> if num < UPTO_LINE:
> return t
>
> def try_it():
> print("twelve")
> print("thirteen")
> print("fourteen")
> print("fifteen")
>
> UPTO_LINE = 1
> sys.settrace(t)
> try_it()
>
> UPTO_LINE = 13
> sys.settrace(t)
> try_it()
>
> Produces:
>
> line 11
> twelve
> thirteen
> fourteen
> fifteen
> line 11
> line 12
> twelve
> line 13
> thirteen
> line 14
> fourteen
> line 15
> fifteen
> line 15
>
> The first call to try_it() returns None immediately, preventing tracing for
> the rest of the function. The second call returns None at line 13, but the
> rest of the function is traced anyway. This behavior is the same in all
> versions from 2.3 to 3.2, in fact, the 100 lines of code in sysmodule.c
> responsible for Python tracing functions are completely unchanged through
> those versions. (A deeper mystery that I haven't looked into yet is why
> Python 3.x intersperses all of these lines with "line 18" interjections.)
>
> I'm writing this email because I'm not sure whether this is a behavior bug
> or a doc bug. One of them is wrong, since they disagree. The documented
> behavior makes sense, and is what people have all along thought the trace
> function did. The actual behavior is a bit more complicated to explain, but
> is what people have actually been experiencing. FWIW, PyPy implements the
> documented behavior.
>
> Should we fix the code or the docs? I'd be glad to supply a patch for
> either.
>
> --Ned.
>
>
> ___
> 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 (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
