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 ;
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
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 repres
* 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
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__
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:
>> 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
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:
http://mail.python.org/mailman/options/py
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
per
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 t
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
11 matches
Mail list logo
