[Python-Dev] Eliminating f_tstate
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? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org 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
...
[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? 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.
> 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).
> 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.
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!).
___
Python-Dev mailing list
Python-Dev@python.org
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: > 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 ;-) 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. The ints aren't really embedded in Decimal, so we don't have to do that there (but we could). 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? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org 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
[Tim Peters]
>> ...
>> >>> decimal.Decimal(-1) % decimal.Decimal("1e100")
>> Decimal("-1")
[Armin Rigo]
> BTW - isn't that case in contradiction with the general Python rule that
> if b > 0, then a % b should return a number between 0 included and b
> excluded?
Sure.
> We try hard to do that for ints, longs and floats.
But fail in this case for floats:
>>> -1 % 1e100 < 1e100
False
Can't win. The infinite-precision result is the mathematical
F(1e100)-1, where F(1e100) is the binary float closest to 10**100, but
F(1e100)-1 isn't representable as a float -- it rounds back up to
F(1e100):
>>> -1 % 1e100 == 1e100
True
There simply is no /representable/ float value in [0, 10**100)
congruent to -1 modulo 10**100 (or modulo F(1e100)), so it's
impossible to return a non-surprising (to everyone) result in that
range. 0 and 1e100 are in some sense "the best" answers in that
range, both off by only 1 part in F(1e100), the smallest possible
error among representable floats in that range. -1/1e100 certainly
isn't 0, so
-1 // 1e100 == -1.0
is required. Picking -1 % 1e100 == 1e100 then follows, to try to preserve that
a = (a//b)*b + a%b
as closely as is possible.
Ints and longs never have problems here, because the exact % result is
always exactly representable.
That isn't true of floats (whether binary or decimal), but under a
different definition of "mod" the mathematically exact result is
always exactly representable: a%b takes the sign of `a` rather than
the sign of `b`. C's fmod (Python's math.fmod), and the proposed
standard for decimal arithmetic implemented by the `decimal` module,
use that meaning for "mod" instead.
>>> math.fmod(-1, 1e100)
-1.0
> The fact that it works differently with Decimal could be unexpected.
Yup. See "can't win" above :-(
Another good definition of "mod" for floats is to return the
representative of smallest absolute value; i.e., satisfy
abs(a%b) <= abs(b) / 2
The mathematically exact value for that is also exactly representable
(BTW, the proposed standard for decimal arithmetic calls this
"remainder-near", as opposed to "remainder").
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 ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] syntax misfeature (exception)
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote: > > At 01:17 PM 1/20/2007, Josiah Carlson wrote: > > >Neal Becker <[EMAIL PROTECTED]> wrote: > >[snip] > > > It's not a question, it's a critique. I believe this is a misfeature > > > since > > > it's so easy to make this mistake. > > > >And it is going away with Py3k. Making it go away for Python 2.6 would > >either allow for two syntaxes to do the same thing, or would require > >everyone to change their except clauses. Neither is very desireable > >(especially if writing code for 2.6 makes it not work for 2.5). > > With both, you can choose whether you'd rather your code be backward > compatible with 2.5, or forward-compatible with 3.0. So 2.6 has to > have both syntaxes. If it's already been decided; great! - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] syntax misfeature (exception)
At 01:17 PM 1/20/2007, Josiah Carlson wrote: >Neal Becker <[EMAIL PROTECTED]> wrote: >[snip] > > It's not a question, it's a critique. I believe this is a misfeature since > > it's so easy to make this mistake. > >And it is going away with Py3k. Making it go away for Python 2.6 would >either allow for two syntaxes to do the same thing, or would require >everyone to change their except clauses. Neither is very desireable >(especially if writing code for 2.6 makes it not work for 2.5). With both, you can choose whether you'd rather your code be backward compatible with 2.5, or forward-compatible with 3.0. So 2.6 has to have both syntaxes. > - Josiah > >___ >Python-Dev mailing list >Python-Dev@python.org >http://mail.python.org/mailman/listinfo/python-dev >Unsubscribe: >http://mail.python.org/mailman/options/python-dev/pje%40telecommunity.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
