Re: [Python-Dev] [Python-checkins] r64424 - inpython/trunk:Include/object.h Lib/test/test_sys.pyMisc/NEWSObjects/intobject.c Objects/longobject.cObjects/typeobject.cPython/bltinmodule.c
On Sun, Jun 29, 2008 at 3:12 AM, Alex Martelli <[EMAIL PROTECTED]> wrote: > On Sat, Jun 28, 2008 at 4:46 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >> Is everyone agreed on a tohex/fromhex pair using the C99 notation as >> recommended in 754R? > > Dunno about everyone, but I'm +1 on that. > > >> Are you thinking of math module functions or as a method and classmethod on >> floats? > > I'd prefer math modules functions. I'm halfway through implementing this as a pair of float methods. Are there compelling reasons to prefer math module functions over float methods, or vice versa? Personally, I'm leaning slightly towards float methods: for me, these conversions are important enough to belong in the core language. But I don't have strong feelings either way. Mark ___ 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] UCS2/UCS4 default
On 2008-07-03 21:59, Steve Holden wrote: M.-A. Lemburg wrote: On 2008-07-03 19:44, Terry Reedy wrote: The premise of this thread seems to be that the majority should suffer for the benefit of a few. That is not Python's philosophy. In reality, most Unixes ship with UCS4 builds of Python. Windows and Mac OS X ship with UCS2 builds. Still, anyone is free to build their own favorite version - that's freedom of choice, which is good. Programmers just need to be made aware of the differences in UCS2 and UCS4 builds and deal with it. Here's talk I've given many many times over the years which explains some of the details that a Python programmer needs to know when dealing with Unicode: http://www.egenix.com/files/python/PyConUK2007-Developing-Unicode-aware-applications-in-Python.pdf Perhaps I should add a section on UCS2 vs. UCS4 the next time around ;-) The indications are that would be helpful to many people (including myself). Ok, I'll add one for one of the next conferences. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 04 2008) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2008-07-07: EuroPython 2008, Vilnius, Lithuania 2 days to go Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ 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] [Python-checkins] r64424 - inpython/trunk:Include/object.h Lib/test/test_sys.pyMisc/NEWSObjects/intobject.c Objects/longobject.cObjects/typeobject.cPython/bltinmodule.c
Float methods are fine. On Fri, Jul 4, 2008 at 2:39 AM, Mark Dickinson <[EMAIL PROTECTED]> wrote: > On Sun, Jun 29, 2008 at 3:12 AM, Alex Martelli <[EMAIL PROTECTED]> wrote: >> On Sat, Jun 28, 2008 at 4:46 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >>> Is everyone agreed on a tohex/fromhex pair using the C99 notation as >>> recommended in 754R? >> >> Dunno about everyone, but I'm +1 on that. >> >> >>> Are you thinking of math module functions or as a method and classmethod on >>> floats? >> >> I'd prefer math modules functions. > > I'm halfway through implementing this as a pair of float methods. Are there > compelling reasons to prefer math module functions over float methods, or > vice versa? > > Personally, I'm leaning slightly towards float methods: for me, these > conversions are important enough to belong in the core language. But I > don't have strong feelings either way. > > Mark > ___ > 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/guido%40python.org > -- --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
[Python-Dev] ctypes assertion failure
This problem was raised on the comtypes-users list as it prevents comtypes from being imported on Python 2.6 at the moment. http://bugs.python.org/issue3258 I'll try to find the time to step through to code to work out what's going on, but it's inside the innards of ctypes which I've never looked into before. Could someone confirm at a glance whether this should be given a high priority, please? It results in an assertion error in debug mode, a SystemError in non-debug referring to a NULL return without an Exception set. Thanks TJG ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (06/27/08 - 07/04/08) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1941 open (+33) / 13165 closed (+34) / 15106 total (+67) Open issues with patches: 607 Average duration of open issues: 704 days. Median duration of open issues: 1570 days. Open Issues Breakdown open 1915 (+33) pending26 ( +0) Issues Created Or Reopened (71) ___ isinstance(anything, MetaclassThatDefinesInstancecheck) raises i 06/30/08 http://bugs.python.org/issue2325reopened jyasskin patch test_multiprocessing hangs on OS X 10.5.307/02/08 http://bugs.python.org/issue3088reopened jnoller patch test_multiprocessing causes test_ctypes to fail 07/02/08 http://bugs.python.org/issue3125reopened jnoller patch "Quick search" box renders too long on FireFox 3 06/27/08 http://bugs.python.org/issue3154reopened benjamin.peterson make text is broken 06/27/08 CLOSED http://bugs.python.org/issue3217created benjamin.peterson 2to3 Fix_imports optimization06/27/08 http://bugs.python.org/issue3218created nedds patch repeated keyword arguments 06/27/08 CLOSED http://bugs.python.org/issue3219created gangesmaster patch Improve Bytes and Byte Array Methods doc 06/27/08 CLOSED http://bugs.python.org/issue3220created tjreedy SystemError: Parent module 'foo' not loaded on import statement 06/27/08 http://bugs.python.org/issue3221created schmir inf*inf gives inf, but inf**2 gives overflow error 06/27/08 CLOSED http://bugs.python.org/issue3222created ms py3k warn on use of frame.f_exc* 06/27/08 http://bugs.python.org/issue3223created benjamin.peterson easy Small typo in 2.6 what's new 06/28/08 CLOSED http://bugs.python.org/issue3224created catlee backport python 3.0 language functionality to python 2.5 by addi 06/28/08 CLOSED http://bugs.python.org/issue3225created kaizhu can't install on OSX 10.406/28/08 http://bugs.python.org/issue3226created benjamin.peterson os.environ.clear has no effect on child processes06/28/08 CLOSED http://bugs.python.org/issue3227created joe.p.cool mailbox.mbox creates files with execute bit set 06/28/08 http://bugs.python.org/issue3228created pl Language reference, class definitions: missing text in "Programm 06/28/08 CLOSED http://bugs.python.org/issue3229created oefe dictobject.c: inappropriate use of PySet_GET_SIZE? 06/28/08 CLOSED http://bugs.python.org/issue3230created oefe re.compile fails with some bytes patterns06/28/08 http://bugs.python.org/issue3231created pitrou patch Wrong str->bytes conversion in Lib/encodings/i
Re: [Python-Dev] UCS2/UCS4 default
Martin v. Löwis v.loewis.de> writes: > > > Wrong term - code units and code points are equivalent in UTF-16 and > > UTF-32. What you're looking for is unicode scalar values. > > How so? Section 2.5, UTF-16 says > > "code points in the supplementary planes, in the range > U+1..U+10, are represented as pairs of 16-bit code units." > > So clearly, code points in Unicode range from U+..U+10, > independent of encoding form. > > In UTF-16, code units range from 0..65535. > > OTOH, "unicode scalar value" is nearly synonymous to "code point": > > D76 Unicode Scalar Value. Any Unicode code point except high-surrogate > and low-surrogate code points. > > So codepoint in Terry's message was the right term. > No Terry did definitely mean Unicode scalar values. He was describing the "pure" but impractical "len()" that would count a surrogate pair as "1", not 2, even in the 32-bit builds. For what it is worth: Code point: a number between 0 and 1114111. Scalar Value: a code point, except the surrogate code points. Code unit: The basic unit of the encoding. One code unit is always sufficient to encode some Unicode Scalar values. However, other Unicode scalar values may require multiple Code units. Note that a scalar value is a code point. A code point may or may not be a scalar value. Practical len() returns the number of code units of the internal storage format. Pure len() allegedly would return the number of Unicode scalar values (obviously a surrogate pair would be considered a single Unicode scalar value). Please keep in mind that encodings encode Unicode scalar values. Thus a utf-8 code unit sequence (or UTF-32 code unit) that would give a code point in the surrogate sections is technically in error. (Although python would do well to ignore this restriction as there may be valid reasons to have a utf-8 sequence that is not a valid encoded Unicode text sequence) ___ 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] UCS2/UCS4 default
>> The premise is the OP's idea that Python should switch to all UCS4 to
>> create a more pure ('ideal') situation or the idea that len(s) should
>> count codepoints (correct term?) for all builds as a matter of purity
>> even though on it would be time-costly on 16-bit builds as a matter
>> of practicality.
> No Terry did definitely mean Unicode scalar values.
True. However, using the word "code point" to refer to "Unicode scalar
values" is also correct. He (rather, the OP) wanted to count code
points (i.e. not count code units).
> Practical len() returns the number of code units of the internal storage
> format.
No, it returns the number of code units.
> Pure len() allegedly would return the number of Unicode scalar values
> (obviously
> a surrogate pair would be considered a single Unicode scalar value).
Perhaps-not-so-obviously-but-still-intendended, a pure len counting
surrogate pairs as one would *also* count code points.
> Please keep in mind that encodings encode Unicode scalar values.
A "coded character set" is "a character set in which each character is
assigned a numeric code point". So clearly, a character encoding form
encodeds code points.
> Thus a utf-8
> code unit sequence (or UTF-32 code unit) that would give a code point in the
> surrogate sections is technically in error.
Sure, but this has nothing to do with Terry's terminology use.
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
