Mark Dickinson wrote:
* There's a per-thread state for division operator. In IEEE 754 mode
1./0. and 1.%0. return INF and 0./0. NAN. The contextlib has a new
context ieee754 and the math lib set_ieee754/get_ieee754 (XXX better
place for the functions?)
I would put the context manager in
Christian Heimes wrote:
Nick Coghlan wrote:
I would put the context manager in the math module as well. contextlib
is intended for generic context related tools (like nested() and
closing() that don't have a more topical home.
I'll reimplement the ieee754 context manager in C once the
Greg Ewing wrote:
It might help to add a note to the effect that this
example is meant to illustrate that the descriptor doesn't
have to exactly match the C description, as long as it
describes the same memory layout.
This sounds like a good idea to me. I doubt Thomas will be the last
person
This sounds great! Thank you for your effort. Let me know if I can help
(perhaps some testing?)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Eric Smith wrote:
Guido van Rossum wrote:
For data types whose output uses only ASCII, would it be acceptable if
they always returned an 8-bit string and left it up to the caller to
convert it to Unicode? This would apply to all numeric types. (The
date/time types have a strftime() style API
Hello,
I think I found a prolific vein of potential crashes throughout the
python interpreter.
The idea is inspired from the discussion Issue1020188 and is quite
simple: find a Py_DECREF(xxx-yyy), where xxx represents any kind of
Python object, and craft a __del__ method so that the same function
Eric Smith wrote:
The bad error message is a result of __format__ passing on unicode to
strftime.
There are, of course, various ugly ways to work around this involving
nested format calls.
I don't know if this fits your definition of ugly workaround, but what
if datetime.__format__ did
On Feb 16, 2008 3:12 PM, Amaury Forgeot d'Arc [EMAIL PROTECTED] wrote:
Hello,
I think I found a prolific vein of potential crashes throughout the
python interpreter.
The idea is inspired from the discussion Issue1020188 and is quite
simple: find a Py_DECREF(xxx-yyy), where xxx represents any
* Nick Coghlan wrote:
Eric Smith wrote:
The bad error message is a result of __format__ passing on unicode to
strftime.
There are, of course, various ugly ways to work around this involving
nested format calls.
I don't know if this fits your definition of ugly workaround, but what
André Malo wrote:
I guess, a clean and complete solution (besides re-implementing the whole
thing) would be to resolve each single format character with strftime,
decode according to the locale and re-assemble the result string piece by
piece. Doh!
That's along the lines of what I was
Brett Cannon wrote:
On Feb 16, 2008 3:12 PM, Amaury Forgeot d'Arc [EMAIL PROTECTED] wrote:
Is there a clever way to prevent these problems globally, for example
by delaying finalizers just a little?
Beats me.
Finalizers can be delayed 'just a little' with a macro called Py_CLEAR ;)
(in
11 matches
Mail list logo
