Mailman 3 August 2007 - Python-Dev

Re: [Python-Dev] Documentation switch imminent
by Christian Heimes Aug. 14, 2007

Aug. 14, 2007

Georg Brandl wrote: > Infos for people who will write docs in the new trees can be found in the > new "Documenting Python" document, at the moment still available from > http://pydoc.gbrandl.de:3000/documenting/, especially the "Differences" > section at http://pydoc.gbrandl.de:3000/documenting/fromlatex/ (which > is not complete, patches are welcome :) http://pydoc.gbrandl.de:3000/documenting/fromlatex/ doesn't work for me: Keyword Not Found The keyword documenting/fromlatex is not directly associated with a page. Christian

1 0

SimpleXMLRPCServer failure on G4 OS X
by Alan McIntyre Aug. 14, 2007

Aug. 14, 2007

Hi all, There are some new tests for xmlrpclib/SimpleXMLRPCServer that fail only on the G4 OS X buildbot. Unfortunately, the SimpleXMLRPCServer returns a vanilla 500 error for any local exceptions, so there's no obvious (to me) way to find out what's going wrong without having a G4 Mac on hand (which I don't). Can anybody recommend any way to look into this, or suggest any G4-specific issues I could check for? Thanks, Alan

1 0

Universal newlines support in Python 3.0
by Guido van Rossum Aug. 14, 2007

Aug. 14, 2007

Python 3.0 currently has limited universal newlines support: by default, \r\n is translated into \n for text files, but this can be controlled by the newline= keyword parameter. For details on how, see PEP 3116. The PEP prescribes that a lone \r must also be translated, though this hasn't been implemented yet (any volunteers?). However, the old universal newlines feature also set an attibute named 'newlines' on the file object to a tuple of up to three elements giving the actual line endings that were observed on the file so far (\r, \n, or \r\n). This feature is not in PEP 3116, and it is not implemented. I'm tempted to kill it. Does anyone have a use case for this? Has anyone even ever used this? -- --Guido van Rossum (home page: http://www.python.org/~guido/)

10 12

Python 3000: confused about str8, str, bytes
by Gerhard Häring Aug. 13, 2007

Aug. 13, 2007

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I maintain the sqlite module in the standard library, which makes heavy use of PyString_* C API. Now I've made it work under Python 3000 insofar as tests pass, but the new Python string semantics mean I have more work to do here and make some API choices. I've read in another thread that the future of str8 is not decided yet. To be honest I was confused when I saw it first, it's documented nowhere as far as I can see. Is that decided yet? Is str8 going away? What will happen with the Python C API? Will PyString_* become what PyUnicode_* is in Python 2.x? - -- Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGwMw6dIO4ozGCH14RAoyEAJ0eoqZ8gSqKh5/HIXxhbG5xpMedLgCgquQV Qv+CGyoD8eSXaoAKzn2WBSM= =w4HB -----END PGP SIGNATURE-----

2 1

Dropping support for Win9x
by "Martin v. Löwis" Aug. 13, 2007

Aug. 13, 2007

I'd like to remove support for Windows 9x (95, 98(SE), ME) soon from the Python trunk. This would primarily affect all wide-string APIs (which would be considered present unconditionally), as well as certain "new" Win32 functions; in this cleanup, I would also drop support for NT+ before Windows 2000 (i.e. NT 3.1, 3.5(1), 4.0). I'm not sure whether w9xpopen should be left in place; Tim suggested it should, however, I don't see why (something with alternative command line interpreters IIRC). The 2.5 installer already gives a warning on W9x that this will be the last release. If you object to this plan, please speak up. Regards, Martin

2 1

Summary of Tracker Issues
by Tracker Aug. 12, 2007

Aug. 12, 2007

ACTIVITY SUMMARY (08/05/07 - 08/12/07) 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. 1295 open ( +8) / 11130 closed ( +2) / 12425 total (+10) Average duration of open issues: 690 days. Median duration of open issues: 553 days. Open Issues Breakdown open 1295 ( +8) pending 0 ( +0) Issues Created Or Reopened (10) _______________________________ x 08/08/07 http://bugs.python.org/issue1000 created gbrandl MSVC++8 x86 tkinter build patch for trunk 08/05/07 http://bugs.python.org/issue1767787 created brotch test_asyncore fix 08/05/07 http://bugs.python.org/issue1767834 created hdiwan650 Badly formed XML using etree and utf-16 08/05/07 http://bugs.python.org/issue1767933 created bugok Byte code WITH_CLEANUP missing, MAKE_CLOSURE wrong 08/06/07 http://bugs.python.org/issue1768121 created lpd tutorial 08/06/07 CLOSED http://bugs.python.org/issue1768767 created mrbax Python - Operation time out problem 08/06/07 http://bugs.python.org/issue1768858 created mohammedsk Fix for failing test_scriptpackages in py3k-struni 08/07/07 CLOSED http://bugs.python.org/issue1768976 created arsatiki A paragraph about packages should be updated. 08/07/07 http://bugs.python.org/issue1769002 created noamr Fix for failing test_plistlib in py3k-struni 08/07/07 http://bugs.python.org/issue1769016 created brotch Issues Now Closed (7) _____________________ fix 1668596: copy datafiles properly when package_dir is ' ' 83 days http://bugs.python.org/issue1720897 loewis unicode(None,charset) raise TypeError 15 days http://bugs.python.org/issue1758804 sf-robot socket close fixed 6 days http://bugs.python.org/issue1763387 jyasskin urllib2-howto - correction 4 days http://bugs.python.org/issue1765839 gbrandl test_csv struni fixes + unicode support in _csv 3 days http://bugs.python.org/issue1767398 gvanrossum tutorial 0 days http://bugs.python.org/issue1768767 mrbax Fix for failing test_scriptpackages in py3k-struni 0 days http://bugs.python.org/issue1768976 nnorwitz

1 0

Exception pickling patch
by Georg Brandl Aug. 11, 2007

Aug. 11, 2007

Can somebody please review this patch: https://sourceforge.net/support/tracker.php?aid=1692335 It aims to fix the pickling of exceptions whose __init__ methods don't call Exception.__init__ at all, or with a different number of arguments. This should be fixed before 2.5.2. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

1 0

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser Aug. 11, 2007

Aug. 11, 2007

Patch / Bug Summary ___________________ Patches : 404 open ( +0) / 3855 closed ( +8) / 4259 total ( +8) Bugs : 1065 open ( +6) / 6790 closed ( +6) / 7855 total (+12) RFE : 263 open ( +0) / 295 closed ( +0) / 558 total ( +0) New / Reopened Patches ______________________ MSVC++8 x86 tkinter build patch for trunk (2007-08-05) http://python.org/sf/1767787 opened by brotchie test_asyncore fix (2007-08-05) CLOSED http://python.org/sf/1767834 opened by Hasan Diwan Fix for failing test_scriptpackages in py3k-struni (2007-08-07) CLOSED http://python.org/sf/1768976 opened by Antti Rasinen Fix for failing test_plistlib in py3k-struni (2007-08-07) CLOSED http://python.org/sf/1769016 opened by brotchie struni: test_xml_etree_c (2007-08-08) CLOSED http://python.org/sf/1769767 opened by Joe Gregorio Remove cStringIO usage (2007-08-08) CLOSED http://python.org/sf/1770008 reopened by tiran Remove cStringIO usage (2007-08-08) CLOSED http://python.org/sf/1770008 opened by Christian Heimes ctypes: c_char now uses bytes and not str (unicode) (2007-08-08) CLOSED http://python.org/sf/1770355 opened by STINNER Victor Misc improvements for the io module (2007-08-10) http://python.org/sf/1771364 opened by Christian Heimes Patches Closed ______________ test_asyncore fix (2007-08-05) http://python.org/sf/1767834 closed by gvanrossum test_csv struni fixes + unicode support in _csv (2007-08-03) http://python.org/sf/1767398 closed by gvanrossum urllib2-howto - correction (2007-08-02) http://python.org/sf/1765839 closed by gbrandl Fix for failing test_scriptpackages in py3k-struni (2007-08-06) http://python.org/sf/1768976 closed by nnorwitz Fix for failing test_plistlib in py3k-struni (2007-08-07) http://python.org/sf/1769016 closed by gvanrossum struni: test_xml_etree_c (2007-08-07) http://python.org/sf/1769767 closed by nnorwitz Remove cStringIO usage (2007-08-08) http://python.org/sf/1770008 closed by gvanrossum Remove cStringIO usage (2007-08-08) http://python.org/sf/1770008 closed by gvanrossum ctypes: c_char now uses bytes and not str (unicode) (2007-08-08) http://python.org/sf/1770355 closed by haypo New / Reopened Bugs ___________________ SocketServer.DatagramRequestHandler (2007-08-04) http://python.org/sf/1767511 opened by Alzheimer Badly formed XML using etree and utf-16 (2007-08-05) http://python.org/sf/1767933 opened by BugoK Byte code WITH_CLEANUP missing, MAKE_CLOSURE wrong (2007-08-05) http://python.org/sf/1768121 opened by L. Peter Deutsch tutorial (2007-08-06) CLOSED http://python.org/sf/1768767 opened by Michael R Bax Python - Operation time out problem (2007-08-06) http://python.org/sf/1768858 opened by MASK A paragraph about packages should be updated. (2007-08-07) CLOSED http://python.org/sf/1769002 opened by Noam Raphael decimal.Decimal("trash") produces informationless exception (2007-08-08) http://python.org/sf/1770009 opened by John Machin platform.mac_ver() returning incorrect patch version (2007-08-08) http://python.org/sf/1770190 opened by Gus Tabares Decimal.__int__ overflows for large values (2007-08-08) http://python.org/sf/1770416 opened by Jason G words able to decode but unable to encode in GB18030 (2007-08-09) http://python.org/sf/1770551 opened by Z-flagship Errors in site.py not reported properly (2007-08-09) http://python.org/sf/1771260 opened by Adam Olsen bsddb can't use unicode keys (2007-08-10) http://python.org/sf/1771381 opened by Erol Aktay another 'nothing to repeat' (2007-08-10) CLOSED http://python.org/sf/1771483 opened by viciousdog minor bug in turtle (2007-08-10) CLOSED http://python.org/sf/1771558 opened by Jeremy Sanders Bugs Closed ___________ String.capwords() does not capitalize first word (2007-08-03) http://python.org/sf/1767363 closed by gbrandl subprocess.Popen.wait fails sporadically with threads (2007-07-16) http://python.org/sf/1754642 closed by gbrandl subprocess raising "No Child Process" OSError (2007-07-14) http://python.org/sf/1753891 closed by gbrandl tutorial (2007-08-06) http://python.org/sf/1768767 deleted by mrbax A paragraph about packages should be updated. (2007-08-07) http://python.org/sf/1769002 closed by gbrandl cStringIO no longer accepts array.array objects (2007-06-03) http://python.org/sf/1730114 closed by gbrandl another 'nothing to repeat' (2007-08-10) http://python.org/sf/1771483 deleted by viciousdog minor bug in turtle (2007-08-10) http://python.org/sf/1771558 closed by gbrandl

1 0

Re: [Python-Dev] Regular expressions, Unicode etc.
by Nick Maclaren Aug. 11, 2007

Aug. 11, 2007

James Y Knight <foom(a)fuhm.net> wrote: > > > Firstly, things like backreferences are an absolute no-no. They > > are not regular, and REs with them in cannot be converted to DFAs. > > That could be 'solved' by a parser that kicked out such constructions, > > but it would get screams from many users. > > People keep saying things like this as if GNU grep and tcl's regular > expression matchers didn't exist. > See http://www.tcl.tk/man/tcl8.5/TclCmd/re_syntax.htm for example. PCRE also has a breadth-first engine, but it does not convert the NFA to a DFA (its author is a close colleague of mine). Those engines won't do the conversion, either, and I am prepared to bet that I could produce a pattern that would either run very slowly or expose the semantics differences in most of them. I did NOT say that there were not, alternative, approaches. What I said was correct - you cannot convert such extended expressions to DFAs. You can convert them to things that are sort of NFA/DFA hybrids, which might or might not be a good way to proceed. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1(a)cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

2 1

Re: [Python-Dev] Unicode database
by Nick Maclaren Aug. 10, 2007

Aug. 10, 2007

=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <martin(a)v.loewis.de> wrote: > > Sure. But (again): you don't need to have the mappings at all for > what you want to achieve. So there is no point in downloading them Sigh. No, I don't. But, if I want to be able to merge anything back into the main Python source, it is a VERY good idea to use the existing mechanisms and not invent new ones. The easiest thing would have been to hack re.py to create a Unicode table using unicodedata.py directly, and that would indeed be a rather cleaner solution in the long term. But it would have meant that there were now multiple different ways of generating the Unicode data for _sre.c, and that would have led to inconsistencies. As I pointed out, there is already a problem where upgrading the data needs a complete rebuild to get all of the Unicode data back in step; 'make all' in itself does not work. That is precisely the sort of problem that is caused by having duplicate update mechanisms. Now, IF I can work out how the _sre.c engine works enough to put atomic/possessive quantifiers in, this problem will return. My question would be how best to make a suitable proposal that, inter alia, includes changes that can't be made by the normal building mechanisms. And I still don't have a clue about that one. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1(a)cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

2 1