Re: [Python-Dev] Eliminating f_tstate
"Martin v. Löwis" <[EMAIL PROTECTED]> writes: > Bug #1579370 reports a crash when accessing the thread state of > a terminated thread, when releasing a generator object. > > In analysing the problem, I found that f_tstate doesn't have much > utility: it is used in very few places, and in these places, it > might be as good or better to use the *current* thread state > (rather than the frame's thread state); in some (most?) of these > places, the current thread should be identical to the frame's > thread, anyway. > > So I would like to propose that the f_tstate member is removed > from the frame object. > > For Python 2.5, for compatibility, it probably has to remain > where it is, and only PyTraceBack_Here should stop using it. > As a consequence, a generator .send() makes exceptions > occur in the current thread, not in the thread where the > generator was created. > > What do you think? Without having read the code in detail, I think what you say makes a great deal of sense. Cheers, mwh -- (FREE|OPEN) BSD: Shire horse. Solid, reliable, only occasionally prone to crushing you against a wall and then only because you've told it to without knowing. -- Jim's pedigree of operating systems, asr ___ 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] Floor division
On 1/21/07, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Tim]
> >> It's just a fact that different definitions of mod are most useful
> >> most often depending on data type. Python's is good for integers and
> >> often sucks for floats. The C99 and `decimal` definition(s) is/are
> >> good for floats and often suck(s) for integers. Trying to pretend
> >> that integers are a subset of floats can't always work ;-)
>
> [Guido]
> > That really sucks, especially since the whole point of making int
> > division return a float was to make the integers embedded in the
> > floats... I think the best solution would be to remove the definition
> > of % (and then also for divmod()) for floats altogether, deferring to
> > math.fmod() instead.
>
> In Python 2?
No way!
> I thought this was already (semi)settled for Py3K --
> back last May, on the Py3K list, in a near-repetition of the current
> thread:
>
> [Tim]
> I'd be happiest if P3K floats didn't support __mod__ or __divmod__ at
> all. Floating mod is so rare it doesn't need syntactic support, and
> the try-to-be-like-integer __mod__ and __divmod__ floats support now
> can deliver surprises to all users incautious enough to use them.
>
> [Guido]
> OK, this makes sense. I've added this to PEP 3100.
Oops, you're right. I'm suffering from memory loss. :-(
> > The ints aren't really embedded in Decimal, so we don't have to do
> > that there (but we could).
>
> Floor division is an odd beast for floats, and I don't know of a good
> use for it. As Raymond's original example in this thread showed, it's
> not always the case that
>
> math.floor(x/y) == x // y
>
> The rounding error in computing x/y can cause floor() to see an exact
> integer coming in even when the true value of x/y is a little smaller
> than that integer (of course it's also possible for x/y to overflow).
> This is independent of fp base (it's "just as true" for decimal floats
> as for binary floats).
>
> The `decimal` module also has two distinct flavors of "mod", neither
> of which match Python's integer-mod definition:
>
> >>> decimal.Decimal(7).__mod__(10)
> Decimal("7")
> >>> decimal.Decimal(7).remainder_near(10)
> Decimal("-3")
> >>> decimal.Decimal(-7).__mod__(10)
> Decimal("-7")
> >>> decimal.Decimal(-7).remainder_near(10)
> Decimal("3")
>
> But, again, I think floating mod is so rare it doesn't need syntactic
> support, and especially not when there's more than one implementation
> -- and `decimal` is a floating type (in Cowlishaw's REXX, this was the
> /only/ numeric type, so there was more pressure there to give it a
> succinct spelling).
So you are proposing that Decimal also rip out the % and // operators
and __divmod__? WFM, but I don't know what Decimal users say (I'm not
one).
> > The floats currently aren't embedded in complex, since f.real and
> > f.imag don't work for floats (and math.sqrt(-1.0) doesn't return 1.0j,
> > and many other anomalies). That was a conscious decision because
> > complex numbers are useless for most folks. But is it still the right
> > decision, given what we're trying to do with int and float?
>
> Sounds like a "purity" thing. The "pure form" of the original
> /intent/ was probably just that nobody should get a complex result
> from non-complex inputs (they should see an exception instead) unless
> they use a `cmath` function to prove they know what they're doing up
> front.
>
> I still think that has pragmatic value, since things like sqrt(-1) and
> asin(1.05) really are signs of logic errors for most programs.
OK, that's good.
> But under that view, there's nothing surprising about, e.g.,
> (math.pi).imag returning 0.0 -- or (3).imag returning 0.0 either.
> That sounds fine to me (if someone cares enough to implement it).
> Unclear what very_big_int.real should do (it can lose information to
> rounding if the int > 2**53, or even overflow -- maybe it should just
> return the int!).
For ints and floats, real could just return self, and imag could
return a 0 of the same type as self. I guess the conjugate() function
could also just return self (although I see that conjugate() for a
complex with a zero imaginary part returns something whose imaginary
part is -0; is that intentional? I'd rather not have to do that when
the input is an int or float, what do you think?)
--
--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
Re: [Python-Dev] Eliminating f_tstate
On 1/22/07, Michael Hudson <[EMAIL PROTECTED]> wrote: > "Martin v. Löwis" <[EMAIL PROTECTED]> writes: > > > Bug #1579370 reports a crash when accessing the thread state of > > a terminated thread, when releasing a generator object. > > > > In analysing the problem, I found that f_tstate doesn't have much > > utility: it is used in very few places, and in these places, it > > might be as good or better to use the *current* thread state > > (rather than the frame's thread state); in some (most?) of these > > places, the current thread should be identical to the frame's > > thread, anyway. > > > > So I would like to propose that the f_tstate member is removed > > from the frame object. > > > > For Python 2.5, for compatibility, it probably has to remain > > where it is, and only PyTraceBack_Here should stop using it. > > As a consequence, a generator .send() makes exceptions > > occur in the current thread, not in the thread where the > > generator was created. > > > > What do you think? > > Without having read the code in detail, I think what you say makes a > great deal of sense. > Ditto from me. -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
Re: [Python-Dev] Floor division
"Guido van Rossum" <[EMAIL PROTECTED]> wrote: > > That really sucks, especially since the whole point of making int > division return a float was to make the integers embedded in the > floats... I think the best solution would be to remove the definition > of % (and then also for divmod()) for floats altogether, deferring to > math.fmod() instead. Please, NO!!! At least not without changing the specification of the math module. The problem with it is that it is specified to be a mapping of the underlying C library, complete with its error handling. fmod isn't bad, as goes, BUT: God alone knows what happens with fmod(x,0.0), let alone fmod(x,-0.0). C99 says that it is implementation-defined whether a domain error occurs or the function returns zero, but domain errors are defined behaviour only in C90 (and not in C99!) It is properly defined only if Annex F is in effect (with all the consequences that implies). Note that I am not saying that syntactic support is needed, because Fortran gets along perfectly well with this as a function. All I am saying is that we want a defined function with decent error handling! Returning a NaN is fine on systems with proper NaN support, which is why C99 Annex F fmod is OK. > For ints and floats, real could just return self, and imag could > return a 0 of the same type as self. I guess the conjugate() function > could also just return self (although I see that conjugate() for a > complex with a zero imaginary part returns something whose imaginary > part is -0; is that intentional? I'd rather not have to do that when > the input is an int or float, what do you think?) I don't see the problem in doing that - WHEN implicit conversion to a smaller domain, losing information, raises an exception. The errors caused by needing a 'cast' (including Fortran INT, DBLE and (ugh) COMPLEX, here) causing not just conversion but information loss have caused major trouble for as long as I have been around. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ 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] buildbot failure in amd64 gentoo 2.5
Georg Brandl schrieb: > Do I miss something here, or is the buildbot hit by spammers now? It looks like it is. If that continues, we have to disable the web triggers. 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] Floor division
Guido van Rossum wrote: > The ints aren't really embedded in Decimal, so we don't have to do > that there (but we could). -0. If we can't achieve it without disturbing the rest of Python, I'll try as much as possible to keep what the Spec proposes. Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Eliminating f_tstate
"Martin v. Löwis" wrote: > For Python 2.5, for compatibility, it probably has to remain > where it is, and only PyTraceBack_Here should stop using it. > As a consequence, a generator .send() makes exceptions > occur in the current thread, not in the thread where the > generator was created. > > What do you think? That's the behaviour I would expect. There is nothing I can find in either the Python docs nor PEP 342 to suggest that interactions with generators happen on anything except the current thread. Anything else IMO is a bug, and should be a candidate for 2.5.1. Tim Delaney ___ 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] Floor division
[Guido]
> ...
> So you are proposing that Decimal also rip out the % and // operators
> and __divmod__? WFM, but I don't know what Decimal users say (I'm not
> one).
Yes: it's just as much a floating type as HW binary floats, and all
the same issues come up. For example, decimal floats are just as
prone to the floor division surprise Raymond started this thread with;
e.g.,
>>> a
Decimal("2.172839486617283948661728393E+29")
>>> b
Decimal("1234567890123456789012345678")
>>> a / b
Decimal("176.0")
>>> a/b == 176
True
>>> a // b
Decimal("175")
That is, floor division of `a` by `b` isn't necessarily the same as
the floor of `a` divided by `b` for decimal floats either, and for
exactly the same reason as when using binary floats: a/b can suffer a
rounding error due to finite precision, but floor division computes
the floor of the quotient "as if" infinite precision were available.
At least using `decimal` it's easy to /explain/ just by boosting the
precision:
>>> decimal.getcontext().prec *= 2
>>> a / b
Decimal("175.9773179587999814250798308")
This shows quite clearly why a/b rounded up to exactly 176 when
working with half this precision.
There's also that the decimal __mod__ implementation is like math.fmod
for binary floats, not like Python's int/long __mod__. Having just
one builtin meaning for numeric `%` as an infix operator is a good
thing, and the int/long meaning is both by far the most common use but
only "works" for types with exactly representable results (ints and
longs built in; rationals if someone adds them; ditto constructive
reals; ... -- but not floats).
> ...
> For ints and floats, real could just return self, and imag could
> return a 0 of the same type as self.
Cool! Works for me.
> I guess the conjugate() function could also just return self (although I see
> that conjugate() for a complex with a zero imaginary part returns
> something whose imaginary part is -0; is that intentional?
That's wrong, if true: it should return something with the opposite
sign on the imaginary part, whether or not that equals 0 (+0. and -0.
both "equal 0").
This is harder to check than it should be because it appears there's a
bug in the complex constructor (at least in Python 2.5): complex(1.,
0.0) and complex(1., -0.0) both appear to create a complex with a +0
imaginary part:
>>> def is_minus_0(x):
... import math
... return x == 0.0 and math.atan2(x, x) != 0
>>> is_minus_0(+0.0) # just showing that "it works"
False
>>> is_minus_0(-0.0) # ditto
True
>>> is_minus_0(complex(1, 0.0).imag)
False
>>> is_minus_0(complex(1, -0.0).imag) # should be True
False
OTOH, the complex constructor does respect the sign of the real part:
>>> is_minus_0(complex(0.0, 0.0).real)
False
>>> is_minus_0(complex(-0.0, 0.0).real)
True
complex_new() ends with:
cr.real -= ci.imag;
cr.imag += ci.real;
and I have no idea what that thinks it's doing. Surely this isn't intended?!:
>>> complex(complex(1.0, 2.0), complex(10.0, 20.0))
(-19+12j)
WTF? In any case, that's also what's destroying the sign of the
imaginary part in complex(1.0, -0.0).
Knowing that a -0 imaginary part can't be constructed in the obvious way:
>>> is_minus_0(complex(0, 0).conjugate().imag)
True
So conjugate() does flip the sign on a +0 imaginary part, and:
>>> is_minus_0(complex(0, 0).conjugate().conjugate().imag)
False
so it also flips the sign on a -0 imaginary part. That's all as it should be.
Hmm. You meant to ask something different, but I actually answered that too ;-)
> I'd rather not have to do that when the input is an int or float, what do you
> think?)
Returning `self` is fine with me for those, although, e.g., it does mean that
(3).conjugate().imag
and
(complex(3)).conjugate().imag
are distinguishable with enough pain. I don't care. I think of
integers and floats as "not having" an imaginary part more than as
having a 0 imaginary part (but happy to invent a 0 imaginary part if
someone asks for one).
___
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] Floor division
[Guido] >> That really sucks, especially since the whole point of making int >> division return a float was to make the integers embedded in the >> floats... I think the best solution would be to remove the definition >> of % (and then also for divmod()) for floats altogether, deferring to >> math.fmod() instead. [Nick Maclaren] > Please, NO!!! > > At least not without changing the specification of the math module. > The problem with it is that it is specified to be a mapping of the > underlying C library, complete with its error handling. > fmod isn't bad, as goes, BUT: > > God alone knows what happens with fmod(x,0.0), let alone fmod(x,-0.0). > C99 says that it is implementation-defined whether a domain error > occurs or the function returns zero, but domain errors are defined > behaviour only in C90 (and not in C99!) It is properly defined only > if Annex F is in effect (with all the consequences that implies). > > Note that I am not saying that syntactic support is needed, because > Fortran gets along perfectly well with this as a function. All I > am saying is that we want a defined function with decent error > handling! Returning a NaN is fine on systems with proper NaN support, > which is why C99 Annex F fmod is OK. math.fmod is 15 years old -- whether or not someone likes it has nothing to do with whether Python should stop trying to use the current integer-derived meaning of % for floats. On occasion we've added additional error checking around functions inherited from C. But adding code to return a NaN has never been done. If you want special error checking added to the math.fmod wrapper, it would be easiest to "sell" by far to request that it raise ZeroDivisionError (as integer mod does) for a modulus of 0, or ValueError (Python's historic mapping of libm EDOM, and what Python's fmod(1, 0) already does on some platforms). The `decimal` module raises InvalidOperation in this case, but that exception is specific to the `decimal` module for now. >> For ints and floats, real could just return self, and imag could >> return a 0 of the same type as self. I guess the conjugate() function >> could also just return self (although I see that conjugate() for a >> complex with a zero imaginary part returns something whose imaginary >> part is -0; is that intentional? I'd rather not have to do that when >> the input is an int or float, what do you think?) > I don't see the problem in doing that - WHEN implicit conversion > to a smaller domain, losing information, raises an exception. Take it as a pragmatic fact that it wouldn't. Besides, e.g., the conjugate of 10**5 is exactly 10**5 mathematically. Why raise an exception just because it can't be represented as a float? The exact result is easily supplied with a few lines of "obviously correct" implementation code (incref `self` and return it). ___ 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] Floor division
[Guido] >> The ints aren't really embedded in Decimal, so we don't have to do >> that there (but we could). [Facundo Batista] > -0. > > If we can't achieve it without disturbing the rest of Python, I'll try > as much as possible to keep what the Spec proposes. Which "Spec"? For example, floor division isn't mentioned at all in IBM's proposed decimal standard, or in PEP 327, or in the Python Library Reference section on `decimal`. It's an artifact of trying to extend Python's integer mod definition to floats, and for reasons explained in this thread (for the 27th time ;-)), that definition doesn't make good sense for floats. The IBM spec defines `remainder` and `remainder-near` for floats, and those do make good sense for floats. But they're /different/ definitions than Python uses for integer mod. Do note that this discussion is only about Python 3. Under the view that it was a (minor, but real) design error to /try/ extending Python's integer mod definition to floats, if __mod__, and __divmod__ and __floordiv__ go away for binary floats in P3K they should certainly go away for decimal floats in P3K too. And that's about syntax, not functionality: the IBM spec's "remainder" and "remainder-near" still need to be there, it's "just" that a user would have to get at "remainder" in a more long-winded way (analogous to that a P3K user would have to spell out "math.fmod" to get at a mod function for binary floats). ___ 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
