[Python-Dev] order of Misc/ACKS
The PS: at the top of Misc/ACKS says: PS: In the standard Python distribution, this file is encoded in UTF-8 and the list is in rough alphabetical order by last names. However, the last 3 names in the list don't appear to be part of that alphabetical order. Is this somehow intentional, or just a mistake? Eli ___ 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] order of Misc/ACKS
Hi, On 11/11/2011 10.39, Eli Bendersky wrote: The PS: at the top of Misc/ACKS says: PS: In the standard Python distribution, this file is encoded in UTF-8 and the list is in rough alphabetical order by last names. However, the last 3 names in the list don't appear to be part of that alphabetical order. Is this somehow intentional, or just a mistake? Only the last two are out of place, and should be fixed. The 'Å' in "Peter Åstrand" sorts after 'Z'. See http://mail.python.org/pipermail/python-dev/2010-August/102961.html for a discussion about the order of Misc/ACKS. Best Regards, Ezio Melotti Eli ___ 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] order of Misc/ACKS
Am 11.11.2011 10:56, schrieb Ezio Melotti: > Hi, > > On 11/11/2011 10.39, Eli Bendersky wrote: >> The PS: at the top of Misc/ACKS says: >> >> PS: In the standard Python distribution, this file is encoded in UTF-8 >> and the list is in rough alphabetical order by last names. >> >> However, the last 3 names in the list don't appear to be part of that >> alphabetical order. Is this somehow intentional, or just a mistake? > > Only the last two are out of place, and should be fixed. The 'Å' in > "Peter Åstrand" sorts after 'Z'. > See http://mail.python.org/pipermail/python-dev/2010-August/102961.html > for a discussion about the order of Misc/ACKS. The key point here is that it is *rough* alphabetic order. IMO, sorting accented characters along with their unaccented versions would be fine as well, and be more practical. In general, it's not possible to provide a "correct" alphabetic order. For example, in German, 'ö' sorts after 'o', whereas in Swedish, it sorts after 'z'. In fact, in German, we have two different ways of sorting the ö: one is to treat it is a letter after o, and the other is to treat it as equivalent to oe. 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
Re: [Python-Dev] unicode_internal codec and the PEP 393
Le 09/11/2011 23:45, "Martin v. Löwis" a écrit : After a quick search on Google codesearch (before it disappears!), I don't think that "encoding" a Unicode string to its internal PEP-393 representation would satisfy any program. It looks like wchar_t* is a better candidate. Ok. Making it Py_UNICODE, documenting that, and deprecating the encoding sounds fine to me as well. Done. Victor ___ 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] order of Misc/ACKS
> The key point here is that it is *rough* alphabetic order. IMO, sorting > accented characters along with their unaccented versions would be fine > as well, and be more practical. In general, it's not possible to provide > a "correct" alphabetic order. For example, in German, 'ö' sorts after > 'o', whereas in Swedish, it sorts after 'z'. In fact, in German, we have > two different ways of sorting the ö: one is to treat it is a letter > after o, and the other is to treat it as equivalent to oe. This is really interesting. I guess lexical ordering of alphabet letters is a locale thing, but Misc/ACKS isn't supposed to be any special locale. It makes me wonder whether it's possible to have a contradiction in the ordering, i.e. have a set of names that just can't be sorted in any order acceptable by everyone. We can then call it "the Misc/ACKS incompleteness theorem" ;-) Eli ___ 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 (2011-11-04 - 2011-11-11) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open3110 ( -8) closed 22056 (+50) total 25166 (+42) Open issues with patches: 1325 Issues opened (19) == #13340: list.index does not accept None as start or stop http://bugs.python.org/issue13340 reopened by rhettinger #13344: closed sockets don't raise EBADF anymore http://bugs.python.org/issue13344 opened by pitrou #13346: re.split() should behave like string.split() for maxsplit=0 an http://bugs.python.org/issue13346 opened by acg #13348: test_unicode_file fails: shutil.copy2 says "same file" http://bugs.python.org/issue13348 opened by flox #13349: Uninformal error message in index() and remove() functions http://bugs.python.org/issue13349 opened by petri.lehtinen #13354: tcpserver should document non-threaded long-living connections http://bugs.python.org/issue13354 opened by shevek #13355: random.triangular error when low = mode http://bugs.python.org/issue13355 opened by mark108 #13357: HTMLParser parses attributes incorrectly. http://bugs.python.org/issue13357 opened by Michael.Brooks #13358: HTMLParser incorrectly handles cdata elements. http://bugs.python.org/issue13358 opened by Michael.Brooks #13359: urllib2 doesn't escape spaces in http requests http://bugs.python.org/issue13359 opened by davide.rizzo #13368: Possible problem in documentation of module subprocess, method http://bugs.python.org/issue13368 opened by eli.bendersky #13369: timeout with exit code 0 while re-running failed tests http://bugs.python.org/issue13369 opened by flox #13370: test_ctypes fails on osx 10.7 http://bugs.python.org/issue13370 opened by ronaldoussoren #13371: Some Carbon extensions don't build on OSX 10.7 http://bugs.python.org/issue13371 opened by ronaldoussoren #13372: handle_close called twice in poll2 http://bugs.python.org/issue13372 opened by xdegaye #13374: Deprecate usage of the Windows ANSI API in the nt module http://bugs.python.org/issue13374 opened by haypo #13376: readline: pre_input_hook not getting called http://bugs.python.org/issue13376 opened by scates #13378: Change the variable "nsmap" from global to instance (xml.etree http://bugs.python.org/issue13378 opened by Nekmo #13380: ctypes: add an internal function for reseting the ctypes cache http://bugs.python.org/issue13380 opened by meador.inge Most recent 15 issues with no replies (15) == #13380: ctypes: add an internal function for reseting the ctypes cache http://bugs.python.org/issue13380 #13372: handle_close called twice in poll2 http://bugs.python.org/issue13372 #13369: timeout with exit code 0 while re-running failed tests http://bugs.python.org/issue13369 #13354: tcpserver should document non-threaded long-living connections http://bugs.python.org/issue13354 #13336: packaging.command.Command.copy_file doesn't implement preserve http://bugs.python.org/issue13336 #13330: Attempt full test coverage of LocaleTextCalendar.formatweekday http://bugs.python.org/issue13330 #13325: no address in the representation of asyncore dispatcher after http://bugs.python.org/issue13325 #13294: http.server - HEAD request when no resource is defined. http://bugs.python.org/issue13294 #13282: the table of contents in epub file is too long http://bugs.python.org/issue13282 #13277: tzinfo subclasses information http://bugs.python.org/issue13277 #13276: distutils bdist_wininst created installer does not run the pos http://bugs.python.org/issue13276 #13272: 2to3 fix_renames doesn't rename string.lowercase/uppercase/let http://bugs.python.org/issue13272 #13231: sys.settrace - document 'some other code blocks' for 'call' ev http://bugs.python.org/issue13231 #13217: Missing header dependencies in Makefile http://bugs.python.org/issue13217 #13213: generator.throw() behavior http://bugs.python.org/issue13213 Most recent 15 issues waiting for review (15) = #13380: ctypes: add an internal function for reseting the ctypes cache http://bugs.python.org/issue13380 #13378: Change the variable "nsmap" from global to instance (xml.etree http://bugs.python.org/issue13378 #13374: Deprecate usage of the Windows ANSI API in the nt module http://bugs.python.org/issue13374 #13372: handle_close called twice in poll2 http://bugs.python.org/issue13372 #13371: Some Carbon extensions don't build on OSX 10.7 http://bugs.python.org/issue13371 #13359: urllib2 doesn't escape spaces in http requests http://bugs.python.org/issue13359 #13338: Not all enumerations used in _Py_ANNOTATE_MEMORY_ORDER http://bugs.python.org/issue13338 #13330: Attempt full test coverage of LocaleTextCalendar.formatweekday http://bugs.python.org/issue13330 #13328: pdb shows code from wrong module http://bugs.python.org/is
[Python-Dev] documenting the Hg commit message hooks in the devguide
Hi, Our Hg repo has some useful hooks on commit messages that allow to specify which issue to notify for commits, and which issue to close. AFAIU, it's currently documented only in the code of the hook (http://hg.python.org/hooks/file/tip/hgroundup.py). I think adding a short description into the devguide would be a good idea, probably here: http://docs.python.org/devguide/committing.html#commit-messages-and-news-entries Any objections/alternative ideas? Eli ___ 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] documenting the Hg commit message hooks in the devguide
On Fri, Nov 11, 2011 at 11:24, Eli Bendersky wrote: > Hi, > > Our Hg repo has some useful hooks on commit messages that allow to > specify which issue to notify for commits, and which issue to close. > AFAIU, it's currently documented only in the code of the hook > (http://hg.python.org/hooks/file/tip/hgroundup.py). > > I think adding a short description into the devguide would be a good > idea, probably here: > > http://docs.python.org/devguide/committing.html#commit-messages-and-news-entries > > Any objections/alternative ideas? > +1 from me on documenting. ___ 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] documenting the Hg commit message hooks in the devguide
Am 11.11.2011 20:24, schrieb Eli Bendersky: > Hi, > > Our Hg repo has some useful hooks on commit messages that allow to > specify which issue to notify for commits, and which issue to close. > AFAIU, it's currently documented only in the code of the hook > (http://hg.python.org/hooks/file/tip/hgroundup.py). > > I think adding a short description into the devguide would be a good > idea, probably here: > http://docs.python.org/devguide/committing.html#commit-messages-and-news-entries > > Any objections/alternative ideas? No objections, it's a good idea. Georg ___ 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] order of Misc/ACKS
Eli Bendersky writes: > special locale. It makes me wonder whether it's possible to have a > contradiction in the ordering, i.e. have a set of names that just > can't be sorted in any order acceptable by everyone. Yes, it is. The examples were already given in this thread. The Han-using languages also have this problem, and Japanese is nondetermistic all by itself (there are kanji names which for historical reasons are pronounced in several different ways, and therefore cannot be placed in phonetic order without additional information). The sensible thing is to just sort in Unicode code point order, I think. ___ 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
