Re: [Python-Dev] trunk-math
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 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. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] trunk-math
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 feature gets > accepted. For the experimental branch it was much easier to write it in > Python. Sounds like a good plan to me - I was just pointing out that contextlib didn't really make sense as a long term home for the functionality. For what it's worth, I'm +1 on the improvements to math and cmath, but keep in mind that I'm not an active user of either module (I use Python for coordination tasks rather than number crunching). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] Error in PEP3118?
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 to miss the distinction between how the C compiler thinks the memory is arranged (just a simple list of values) and how the application interprets that memory (a 2-dimensional array). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] trunk-math
This sounds great! Thank you for your effort. Let me know if I can help (perhaps some testing?) ___ 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] Backporting PEP 3101 to 2.6
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 which means the user must
>>> be able to specifiy Unicode.)
I'm finally getting around to finishing this up. The approach I've
taken for int, long, and float, is that they take either unicode or str
format specifiers, and always return str results. The builtin format()
deals with converting str to unicode, if the format specifier was
originally unicode. This all works great. It allows me to easily
implement both ''.format and u''.format taking int, long, and float
parameters.
I'm now working on datetime. The __format__ method is really just a
wrapper around strftime. I was assuming (or rather hoping) that
strftime does the right thing with unicode and str (unicode in = unicode
out, str in = str out). But it turns out strftime doesn't accept unicode:
$ ./python
Python 2.6a0 (trunk:60845M, Feb 15 2008, 21:09:57)
[GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> datetime.date.today().strftime('%y')
'08'
>>> datetime.date.today().strftime(u'%y')
Traceback (most recent call last):
File "", line 1, in
TypeError: strftime() argument 1 must be str, not unicode
As part of this task, I'm really not up to the job of changing strftime
to support both str and unicode inputs. So I think I'll put all of the
__format__ code in place to support it if and when strftime supports
unicode. In the meantime, it won't be possible for u''.format to work
with datetime objects.
>>> 'year: {0:%y}'.format(datetime.date.today())
'year: 08'
>>> u'year: {0:%y}'.format(datetime.date.today())
Traceback (most recent call last):
File "", line 1, in
TypeError: strftime() argument 1 must be str, not unicode
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.
Maybe I'll extend strftime to unicode for the PyCon sprint.
Eric.
___
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] Py_CLEAR to avoid crashes
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 is
recursively called with the same object.
I recently submitted corrections for 3 problems found this way. Here
are two more examples of this method:
#
class Special:
def __del__(self):
print a.args
class MyException(BaseException):
def __init__(self):
global a
a = self
BaseException.__init__(self, Special(), 0)
BaseException.__init__(self, "other", 1)
MyException() # segfault
#
import sys
class Special2(str):
def __del__(self):
f.__init__("@temp", "w")
f = file(Special2("@temp"), "w")
f.__init__("@temp", "w") # segfault
#
Issue1020188 (which is still open btw) deals with member reset to
NULL; but any modification of the pointer is potentially concerned.
And the correction is always the same: use Py_CLEAR, or a similar
construction that detach the value from the structure before
defcref'ing it.
I think it would help a lot of code if we had a safe standard way to
set struct members from C. A macro like the following:
Py_SETREF(lvalue, newobj)
(whatever its name) would perform the assignment and expand to code
equivalent to:
PyObject* oldobj = lvalue;
Py_INCREF(newobj);
lvalue = newobj;
Py_DECREF(oldobj);
I am currently searching for all places that could benefit of this,
but I am not sure to find a test case for every potential crash.
Most of the time, it is very unlikely that "normal" python code can
fall in these traps (who calls f.__init__ in a __del__ method?), with
the exception of the one corrected by r60871.
Should we however intensively search and correct all of them?
Is there a clever way to prevent these problems globally, for example
by delaying finalizers "just a little"?
--
Amaury Forgeot d'Arc
___
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] Backporting PEP 3101 to 2.6
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 something like: def __format__(self, spec): encoding = None if isinstance(spec, unicode): encoding = 'utf-8' spec = spec.encode(encoding) result = strftime(spec, self) if encoding is not None: result = result.decode(encoding) return result Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] Py_CLEAR to avoid crashes
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 kind of
> Python object, and craft a __del__ method so that the same function is
> recursively called with the same object.
>
> I recently submitted corrections for 3 problems found this way. Here
> are two more examples of this method:
>
> #
> class Special:
> def __del__(self):
> print a.args
>
> class MyException(BaseException):
> def __init__(self):
> global a
> a = self
> BaseException.__init__(self, Special(), 0)
> BaseException.__init__(self, "other", 1)
>
> MyException() # segfault
> #
> import sys
> class Special2(str):
> def __del__(self):
> f.__init__("@temp", "w")
>
> f = file(Special2("@temp"), "w")
> f.__init__("@temp", "w") # segfault
> #
>
> Issue1020188 (which is still open btw) deals with member reset to
> NULL; but any modification of the pointer is potentially concerned.
>
> And the correction is always the same: use Py_CLEAR, or a similar
> construction that detach the value from the structure before
> defcref'ing it.
>
> I think it would help a lot of code if we had a safe standard way to
> set struct members from C. A macro like the following:
> Py_SETREF(lvalue, newobj)
> (whatever its name) would perform the assignment and expand to code
> equivalent to:
> PyObject* oldobj = lvalue;
> Py_INCREF(newobj);
> lvalue = newobj;
> Py_DECREF(oldobj);
>
> I am currently searching for all places that could benefit of this,
> but I am not sure to find a test case for every potential crash.
> Most of the time, it is very unlikely that "normal" python code can
> fall in these traps (who calls f.__init__ in a __del__ method?), with
> the exception of the one corrected by r60871.
>
Testing C code like this can be tough. Usually the crasher is used as
the test in hopes that any fix is general enough that if it fails that
same crasher will rear its ugly head again.
> Should we however intensively search and correct all of them?
I think it's fine to.
> Is there a clever way to prevent these problems globally, for example
> by delaying finalizers "just a little"?
Beats 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] Backporting PEP 3101 to 2.6
* 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 > if datetime.__format__ did something like: > >def __format__(self, spec): > encoding = None > if isinstance(spec, unicode): > encoding = 'utf-8' > spec = spec.encode(encoding) > result = strftime(spec, self) > if encoding is not None: > result = result.decode(encoding) > return result Note that hardcoding utf-8 is a bad guess here as strftime(3) emits locale strings, so decoding will easily fail. 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! nd -- > [...] weiß jemand zufällig, was der Tag DIV ausgeschrieben bedeutet? DIVerses. Benannt nach all dem unstrukturierten Zeug, was die Leute da so reinpacken und dann absolut positionieren ... -- Florian Hartig und Lars Kasper in dciwam ___ 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] Backporting PEP 3101 to 2.6
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 thinking. strftime already does some of this to support %[zZ]. But now that I look at time.strftime in py3k, it's converting the entire unicode string to a char string with PyUnicode_AsString, then converting back with PyUnicode_Decode. ___ 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] Py_CLEAR to avoid crashes
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 other words, what Amaury is doing already is the best solution I am aware of) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
