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 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] 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 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] 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 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] trunk-math
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/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 stdin, line 1, in module
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 stdin, line 1, in module
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
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
[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 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] 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 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] 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 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] 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 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] 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 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] 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 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
