From noreply@sourceforge.net Sun Jul 1 09:30:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Jul 2001 01:30:44 -0700 Subject: [Patches] [ python-Patches-437683 ] Improve h2py Message-ID: Patches item #437683, was opened at 2001-07-01 01:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=437683&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Improve h2py Initial Comment: This patch changes h2py in the following ways: - use re instead of regex - if multiple header files are processed simultaneously which include each other, the corresponding modules import each other. Specifically, if h2py is invoked with sys/types.h first, later header files won't contain the complete contents of TYPES.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=437683&group_id=5470 From noreply@sourceforge.net Sun Jul 1 17:24:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Jul 2001 09:24:11 -0700 Subject: [Patches] [ python-Patches-437733 ] Additional Argument to Python/C Function Message-ID: Patches item #437733, was opened at 2001-07-01 09:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=437733&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Additional Argument to Python/C Function Initial Comment: this patch makes it possible that a python/c function gets an aditional void* argument. this makes it easier to use python with c++. PS:i'm a bad despriptor,so please look at the diff file. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=437733&group_id=5470 From reklama@publicist.com Sun Jul 1 18:56:07 2001 From: reklama@publicist.com (E-mail Reklama) Date: Sun, 1 Jul 2001 21:56:07 +0400 Subject: [Patches] =?windows-1251?Q?E-mail_-_=F0=E5=EA=EB=E0=EC=E0?= Message-ID: <8544200170117567702@publicist.com> =C7=E4=F0=E0=E2=F1=F2=E2=F3=E9=F2=E5! =C2 =EF=E5=F0=E8=EE=E4 =EB=E5=F2=ED=E5=E3=EE =E7=E0=F2=E8=F8=FC=FF =ED=E0 = =F0=FB=ED=EA=E5 =E2=FB =EC=EE=E6=E5=F2=E5 =EA=EE=EB=EE=F1=F1=E0=EB=FC=ED=EE= =EE=E6=E8=E2=E8=F2=FC =F1=E2=EE=E8 =EF=F0=EE=E4=E0=E6=E8, =E2 =EE=F2=EB=E8= =F7=E8=E5 =EE=F2 =F1=E2=EE=E8=F5 =EA=EE=ED=EA=F3=F0=E5=ED=F2=EE=E2=2E =C4=EB= =FF =FD=F2=EE=E3=EE =E7=E0=EA=E0=E6=E8=F2=E5 =FD=EB=E5=EA=F2=F0=EE=ED=ED=F3= =FE =F0=E0=F1=F1=FB=EB=EA=F3 =C2=E0=F8=E5=E9 =F0=E5=EA=EB=E0=EC=ED=EE=E9 =E8= =ED=F4=EE=F0=EC=E0=F6=E8=E8 =EF=EE =F0=E0=E7=EB=E8=F7=ED=FB=EC =F1=EF=E8=F1= =EA=E0=EC =E0=E4=F0=E5=F1=EE=E2 (=EE=F2 30=F2=FB=F1=2E =E4=EE 1=EC=EB=ED=2E= , =EA=E0=EA =EF=EE =CC=EE=F1=EA=E2=E5, =F2=E0=EA =E8 =EF=EE =E2=F1=E5=E9 =D0= =EE=F1=F1=E8=E8 =E8 =D1=CD=C3)=2E =D1=EE=EE=F2=ED=EE=F8=E5=ED=E8=E5 =F1=F2= =EE=E8=EC=EE=F1=F2=FC/=EE=F2=E4=E0=F7=E0 =EF=F0=E8 =FD=F2=EE=EC =E1=F3=E4=E5= =F2 =F1=E0=EC=EE=E5 =ED=E8=E7=EA=EE=E5=2E =CC=FB =EF=F0=EE=F4=E5=F1=F1=E8=EE=ED=E0=EB=FC=ED=EE =E7=E0=ED=E8=EC=E0=E5= =EC=F1=FF =FD=EB=E5=EA=F2=F0=EE=ED=ED=FB=EC=E8 =F0=E0=F1=F1=FB=EB=EA=E0=EC= =E8 4 =E3=EE=E4=E0=2E =CD=E0=F8=E8 =EF=EE=F1=F2=EE=FF=ED=ED=FB=E5 =EA=EB=E8= =E5=ED=F2=FB - =EA=F0=F3=EF=ED=E5=E9=F8=E8=E5 =E8=E7=E2=E5=F1=F2=ED=FB=E5 = =EA=EE=EC=EF=E0=ED=E8=E8, =EA=EE=F2=EE=F0=FB=E5 =E4=E0=E2=ED=EE =EF=EE=ED=FF= =EB=E8, =F7=F2=EE =FD=F4=F4=E5=EA=F2=E8=E2=ED=EE=F1=F2=FC e-mail =F0=E0=F1= =F1=FB=EB=EE=EA =E8=E7-=E7=E0 =F8=E8=F0=EE=F2=FB =EE=F5=E2=E0=F2=E0 =E0=F3= =E4=E8=F2=EE=F0=E8=E8 =F1=EE=E8=E7=EC=E5=F0=E8=EC=E0 =EB=E8=F8=FC =F1 =F0=E5= =EA=EB=E0=EC=EE=E9 =ED=E0 =F6=E5=ED=F2=F0=E0=EB=FC=ED=EE=EC =F2=E5=EB=E5=E2= =E8=E4=E5=ED=E8=E8! =CA=EB=E8=E5=ED=F2=FB, =E7=E0=EA=E0=E7=E0=E2=F8=E8=E5 = =F0=E0=F1=F1=FB=EB=EA=F3 =EE=E4=E8=ED =F0=E0=E7, =EE=E1=F0=E0=F9=E0=FE=F2=F1= =FF =EA =ED=E0=EC =F1=ED=EE=E2=E0 =E8 =F1=ED=EE=E2=E0=2E =D1=E5=E9=F7=E0=F1= =EC=ED=EE=E3=E8=E5 =EF=F0=EE=E4=E0=FE=F2 =F1=EF=E8=F1=EA=E8 e-mail =E0=E4= =F0=E5=F1=EE=E2, =ED=EE =EF=F0=E0=EA=F2=E8=F7=E5=F1=EA=E8 =ED=E8=EA=F2=EE = =E8=E7 =E8=F5 =EF=EE=EA=F3=EF=E0=F2=E5=EB=E5=E9 (=EA=E0=EA, =EA=F1=F2=E0=F2= =E8, =E8 =F1=E0=EC=E8 =EF=F0=EE=E4=E0=E2=F6=FB) =ED=E5 =EC=EE=E6=E5=F2 =E2= =E4=E0=EB=FC=ED=E5=E9=F8=E5=EC =EF=F0=E0=E2=E8=EB=FC=ED=EE =E8=EC=E8 =E2=EE= =F1=EF=EE=EB=FC=E7=EE=E2=E0=F2=FC=F1=FF, =F2=E0=EA =EA=E0=EA =ED=E5 =E8=EC= =E5=E5=F2 =EE=EF=FB=F2=E0 =E8 =E4=EE=F1=F2=E0=F2=EE=F7=ED=FB=F5 =EC=EE=F9=ED= =EE=F1=F2=E5=E9 =E4=EB=FF =E4=E5=E9=F1=F2=E2=E8=F2=E5=EB=FC=ED=EE =EA=F0=F3= =EF=ED=EE=EC=E0=F1=F8=F2=E0=E1=ED=FB=F5 =F0=E0=F1=F1=FB=EB=EE=EA=2E =C2 =EB= =F3=F7=F8=E5=EC =F1=EB=F3=F7=E0=E5, =EE=ED=E8 =F3=F1=EF=E5=E2=E0=FE=F2 =F0= =E0=E7=EE=F1=EB=E0=F2=FC =F2=EE=EB=FC=EA=EE =ED=E5=E1=EE=EB=FC=F8=E8=E5 =EA= =EE=EB=E8=F7=E5=F1=F2=E2=E0 =EF=E8=F1=E5=EC, =EF=F0=E8 =FD=F2=EE=EC =EF=EE= =F0=F2=FF =F1=E5=E1=E5 =E8=EC=E8=E4=E6 =E8 =EF=F0=E8=EE=E1=F0=E5=F2=E0=FF = =EF=F0=EE=E1=EB=E5=EC=FB =F1=EE =F1=E2=EE=E8=EC=E8 =EF=F0=EE=E2=E0=E9=E4=E5= =F0=E0=EC=E8=2E =CC=FB =E7=ED=E0=E5=EC =E2=F1=E5 =EF=F0=EE e-mail =F0=E5=EA=EB=E0=EC=F3 =E8= =E8=EC=E5=E5=EC =E2=F1=E5 =E4=EB=FF =F2=EE=E3=EE, =F7=F2=EE=E1=FB =C7=C0=C2= =C0=CB=C8=D2=DC =C2=C0=D1 =C7=C0=CA=C0=C7=C0=CC=C8 =ED=E0 =E2=E0=F8=E8 =F3= =F1=EB=F3=E3=E8 =E8=EB=E8 =EF=F0=EE=E4=F3=EA=F6=E8=FE=2E =DD=F2=EE =E1=EE=EB= =FC=F8=EE=E9 =EF=E0=F0=EA =EF=F0=EE=E8=E7=E2=EE=E4=E8=F2=E5=EB=FC=ED=E5=E9= =F8=E8=F5 =EA=EE=EC=EF=FC=FE=F2=E5=F0=EE=E2 =E8 =E2=FB=F1=EE=EA=EE=F1=EA=EE= =F0=EE=F1=F2=ED=FB=E5 =EA=E0=ED=E0=EB=FB =E4=EE=F1=F2=F3=EF=E0 =E2 =C8=ED=F2= =E5=F0=ED=E5=F2 =E2 =EC=EE=F1=EA=EE=E2=F1=EA=E8=F5 =EE=F4=E8=F1=E0=F5, =F1= =EE=E1=F1=F2=E2=E5=ED=ED=FB=E5 =EF=EE=F7=F2=EE=E2=FB=E5 smtp-=F1=E5=F0=E2=E5= =F0=E0 =E7=E0 =F0=F3=E1=E5=E6=EE=EC, =E0 =F2=E0=EA=E6=E5 =F1=EE=E1=F1=F2=E2= =E5=ED=ED=FB=E5 =FD=EA=F1=EA=EB=FE=E7=E8=E2=ED=FB=E5 =ED=E0=F0=E0=E1=EE=F2= =EA=E8 =E8 =ED=EE=F3-=F5=E0=F3 =E2 =FD=F2=EE=E9 =EE=E1=EB=E0=F1=F2=E8=2E =CC=FB =F3=EC=E5=E5=EC =E4=E5=EB=E0=F2=FC =F0=E0=F1=F1=FB=EB=EA=E8 =F2=E0=EA= , =F7=F2=EE =FD=F2=EE =ED=E8=EA=E0=EA =ED=E5 =EF=EE=E2=F0=E5=E4=E8=F2 =E2=E0= =F8=E5=EC=F3 =E8=EC=E8=E4=E6=F3=2E =C5=F1=EB=E8 =E2=FB =E7=E0=E8=ED=F2=E5=F0=E5=F1=EE=E2=E0=ED=ED=FB =E2 =F0=E0= =F1=F1=FB=EB=EA=E0=F5 =E8 =F5=EE=F2=E8=F2=E5 =EF=EE=EB=F3=F7=E8=F2=FC =EE=F2= =ED=E0=F1 =E1=EE=EB=E5=E5 =EF=EE=EB=ED=F3=FE =E8=ED=F4=EE=F0=EC=E0=F6=E8=FE= , =EF=F0=E8=F8=EB=E8=F2=E5 =E7=E0=EF=F0=EE=F1 =E2 =EF=F0=EE=E8=E7=E2=EE=EB= =FC=ED=EE=E9 =F4=EE=F0=EC=E5 =E2 =F2=E5=EB=E5 =EF=E8=F1=FC=EC=E0, =ED=E0=E6= =E0=E2 =E2 =F1=E2=EE=E5=E9 =EF=EE=F7=F2=EE=E2=EE=E9 =EF=F0=EE=E3=F0=E0=EC=EC= =E5 "=CE=F2=E2=E5=F2=E8=F2=FC", =E8=EB=E8 =ED=E0 =F1=F1=FB=EB=EA=F3: rekla= ma@publicist=2Ecom=2E =CF=F0=E8 =FD=F2=EE=EC =E2 =EF=EE=EB=E5 "=D2=E5=EC=E0 =F1=EE=EE=E1=F9=E5=ED= =E8=FF" =EE=E1=FF=E7=E0=F2=E5=EB=FC=ED=EE =F3=EA=E0=E6=E8=F2=E5: "=F0=E0=F1= =F1=FB=EB=EA=E0"=2E From noreply@sourceforge.net Mon Jul 2 12:42:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Jul 2001 04:42:26 -0700 Subject: [Patches] [ python-Patches-436173 ] site.py shouldn't normcase() agressively Message-ID: Patches item #436173, was opened at 2001-06-25 12:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=436173&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: site.py shouldn't normcase() agressively Initial Comment: The site module should not be using the normcase() version of directory names as the final result in sys.path; this patch only uses the normcase() version for comparisons, but not sys.path contents. The intention is to allow Windows and MacOS users to see the paths as they would in their native filesystem tools. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-07-02 04:42 Message: Logged In: YES user_id=45365 It works fine on the Mac. I'll assign it back to Fred, because I don't know whether it also needs to be double-checked on Windows (or has that been done already?). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=436173&group_id=5470 From noreply@sourceforge.net Mon Jul 2 17:38:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Jul 2001 09:38:35 -0700 Subject: [Patches] [ python-Patches-436173 ] site.py shouldn't normcase() agressively Message-ID: Patches item #436173, was opened at 2001-06-25 12:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=436173&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: site.py shouldn't normcase() agressively Initial Comment: The site module should not be using the normcase() version of directory names as the final result in sys.path; this patch only uses the normcase() version for comparisons, but not sys.path contents. The intention is to allow Windows and MacOS users to see the paths as they would in their native filesystem tools. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-02 09:38 Message: Logged In: YES user_id=31435 Full speed ahead. Doubt it will hurt on Windows, but if it does it's more efficient to check in a fix myself afterwards than to test the patch first <0.7 wink>. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-07-02 04:42 Message: Logged In: YES user_id=45365 It works fine on the Mac. I'll assign it back to Fred, because I don't know whether it also needs to be double-checked on Windows (or has that been done already?). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=436173&group_id=5470 From noreply@sourceforge.net Mon Jul 2 17:53:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Jul 2001 09:53:01 -0700 Subject: [Patches] [ python-Patches-417084 ] sre: Speed up Unicode charsets Message-ID: Patches item #417084, was opened at 2001-04-18 08:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417084&group_id=5470 Category: core (C code) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Fredrik Lundh (effbot) Summary: sre: Speed up Unicode charsets Initial Comment: When matching large Unicode charsets (e.g. the one that defines an XML name, from xml.utils.characters), matching is quite slow, since a linear search over the ranges is performed. The patch compiles a unicode character class into a BIGCHARSET opcode, using a compression technique similar to the one that the expat parser uses (see comment in sre_parse). With the patch, runtime for import time,re,xml.utils.characters u = u"Hallo welt" e = xml.utils.characters.re_Name t = time.time() for i in xrange(1000000): e.match(u) print time.time()-t could be reduced to 45%. Even when doing full parsing using CVS xmlproc, a 4% speedup can still be observed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417084&group_id=5470 From noreply@sourceforge.net Mon Jul 2 17:56:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Jul 2001 09:56:41 -0700 Subject: [Patches] [ python-Patches-436173 ] site.py shouldn't normcase() agressively Message-ID: Patches item #436173, was opened at 2001-06-25 12:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=436173&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: site.py shouldn't normcase() agressively Initial Comment: The site module should not be using the normcase() version of directory names as the final result in sys.path; this patch only uses the normcase() version for comparisons, but not sys.path contents. The intention is to allow Windows and MacOS users to see the paths as they would in their native filesystem tools. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-02 09:56 Message: Logged In: YES user_id=3066 Checked in as Lib/site.py revisions 1.28 and 1.26.2.1. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-02 09:38 Message: Logged In: YES user_id=31435 Full speed ahead. Doubt it will hurt on Windows, but if it does it's more efficient to check in a fix myself afterwards than to test the patch first <0.7 wink>. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-07-02 04:42 Message: Logged In: YES user_id=45365 It works fine on the Mac. I'll assign it back to Fred, because I don't know whether it also needs to be double-checked on Windows (or has that been done already?). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=436173&group_id=5470 From noreply@sourceforge.net Mon Jul 2 20:43:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Jul 2001 12:43:31 -0700 Subject: [Patches] [ python-Patches-438013 ] Remove 2-byte Py_UCS2 assumptions Message-ID: Patches item #438013, was opened at 2001-07-02 12:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438013&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: M.-A. Lemburg (lemburg) Summary: Remove 2-byte Py_UCS2 assumptions Initial Comment: The patch changes PyUnicode_EncodeUTF16 and PyUnicode_DecodeUTF16 to work without assuming the existence of a (exactly) 2-byte type. There are no more references remaining in the code base to Py_UCS2, except for what looks to be a now- pointless complaint in unicodeobject.h. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438013&group_id=5470 From noreply@sourceforge.net Mon Jul 2 21:09:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Jul 2001 13:09:23 -0700 Subject: [Patches] [ python-Patches-438013 ] Remove 2-byte Py_UCS2 assumptions Message-ID: Patches item #438013, was opened at 2001-07-02 12:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438013&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: M.-A. Lemburg (lemburg) Summary: Remove 2-byte Py_UCS2 assumptions Initial Comment: The patch changes PyUnicode_EncodeUTF16 and PyUnicode_DecodeUTF16 to work without assuming the existence of a (exactly) 2-byte type. There are no more references remaining in the code base to Py_UCS2, except for what looks to be a now- pointless complaint in unicodeobject.h. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2001-07-02 13:09 Message: Logged In: YES user_id=38376 +1 from here. Py_UCS2 should either go away, or be redefined as "large enough to hold a UCS-2 code point" (maybe there's some codec that may want to use such a data type? in real life, "unsigned int" is probably a decent approximation...) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438013&group_id=5470 From noreply@sourceforge.net Mon Jul 2 21:12:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Jul 2001 13:12:47 -0700 Subject: [Patches] [ python-Patches-426880 ] Tkinter Listbox missing methods Message-ID: Patches item #426880, was opened at 2001-05-24 00:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426880&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fredrik Lundh (effbot) Summary: Tkinter Listbox missing methods Initial Comment: Both the itemconfigure and the itemcget methods are missing in the current Tkinter so here they are..... ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2001-07-02 13:12 Message: Logged In: YES user_id=38376 is it just me, or is the patch file missing? (shouldn't be that hard to create my own version of the patch, though... I'll keep this one open as a reminder) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426880&group_id=5470 From noreply@sourceforge.net Mon Jul 2 21:27:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Jul 2001 13:27:10 -0700 Subject: [Patches] [ python-Patches-438013 ] Remove 2-byte Py_UCS2 assumptions Message-ID: Patches item #438013, was opened at 2001-07-02 12:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438013&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: M.-A. Lemburg (lemburg) Summary: Remove 2-byte Py_UCS2 assumptions Initial Comment: The patch changes PyUnicode_EncodeUTF16 and PyUnicode_DecodeUTF16 to work without assuming the existence of a (exactly) 2-byte type. There are no more references remaining in the code base to Py_UCS2, except for what looks to be a now- pointless complaint in unicodeobject.h. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-02 13:27 Message: Logged In: YES user_id=31435 Isn't Py_UNICODE always big enough to hold a UCS-2 code point? If the latter is 16 bits (which I assume), C guarantees an unsigned short is big enough to hold it (and doesn't guarantee an int is bigger than that -- although Python would be pretty useless if an int weren't bigger!). ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-07-02 13:09 Message: Logged In: YES user_id=38376 +1 from here. Py_UCS2 should either go away, or be redefined as "large enough to hold a UCS-2 code point" (maybe there's some codec that may want to use such a data type? in real life, "unsigned int" is probably a decent approximation...) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438013&group_id=5470 From noreply@sourceforge.net Tue Jul 3 20:59:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 12:59:47 -0700 Subject: [Patches] [ python-Patches-438331 ] make ndiff.py into a library module Message-ID: Patches item #438331, was opened at 2001-07-03 12:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438331&group_id=5470 Category: demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Nobody/Anonymous (nobody) Summary: make ndiff.py into a library module Initial Comment: Here's a patch to make ndiff.py's functionality generally available to Python programs. It should move from Tools/scripts/ to Lib/. ndiff.py's functionality is very useful for making comparisons human-readable. I wanted to use it from my Python code (unittest's of generated XML), but unfortunately ndiff.py wasn't written that way. So I refactored out the lists-of-strings comparison code from fcompare() into lcompare(), and parameterized the formerly hard-coded IS_*_JUNK filters. I'd like to see it further converted to return a diff string, rather than only spew to stdout. It's easy enough to capture stdout, but klugey. I will do the mods if they have a good-to-certain chance of making it in. (Please let me know.) Also, give me the word and I will whip up some TeX docs if Tim doesn't have the time. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438331&group_id=5470 From noreply@sourceforge.net Wed Jul 4 04:17:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 20:17:25 -0700 Subject: [Patches] [ python-Patches-438424 ] Fix for missing turtle fuctionality Message-ID: Patches item #438424, was opened at 2001-07-03 20:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438424&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josh Cogliati (jjc) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for missing turtle fuctionality Initial Comment: Python's logolike module turtle.py did not display the turtle except when actually drawing lines. This patch changes the turtle.py module so that it displays the turtle at all times when tracing is on. This is similar to the the way that logo works. When tracing is off the turtle will not be displayed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438424&group_id=5470 From noreply@sourceforge.net Wed Jul 4 05:20:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 21:20:08 -0700 Subject: [Patches] [ python-Patches-407093 ] urllib2 correction of typos Message-ID: Patches item #407093, was opened at 2001-03-08 10:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407093&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Eduardo Fernandez Corrales (ejfc) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 correction of typos Initial Comment: Bug #406683 "typos in urllib2" includes a patch. I have modified it so that Basic HTTP Authentication works now. (At least with my Squid proxy) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 21:20 Message: Logged In: YES user_id=3066 The related bug has already been fixed and closed (by Moshe Zadka) using a different patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-16 01:16 Message: Logged In: YES user_id=21627 Where is the patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407093&group_id=5470 From noreply@sourceforge.net Wed Jul 4 05:23:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 21:23:01 -0700 Subject: [Patches] [ python-Patches-401394 ] lookdict optimizations Message-ID: Patches item #401394, was opened at 2000-09-01 14:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401394&group_id=5470 Category: core (C code) Group: None >Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Vladimir Marangozov (marangoz) Assigned to: Tim Peters (tim_one) Summary: lookdict optimizations Initial Comment: ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 21:23 Message: Logged In: YES user_id=3066 Tim marked this "Out of Date", but I'll be bolder and state that this is no longer relevant given the restructuring of the dict code that Tim has done. Closing the patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-05-18 12:03 Message: Logged In: YES user_id=6380 Assigning to Tim, who (by the fact that he is reviewing it :-) is more qualified to own this patch than Fred. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-05-18 12:01 Message: Logged In: YES user_id=31435 Marked Out of Date: I've fiddled the dict code quite a bit in the meantime. Changing the computation of the initial table index reduced the # of collisions, so the case this is aiming at is probably less frequent now. The guts of the loop have been reordered to check for dummy last in every case, so "inlining the first collision probe" probably doesn't buy anything anymore. Using a length check is probably still helpful: you're effectively creating a Py_EQ string richcmp here, but inlined. It will be less helpful once strings grow a tp_richcompare slot, because that will almost certainly do a Py_EQ length check too (e.g., Martin's pending patch does). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-02-19 13:19 Message: This patch optimizes what appears to be a small corner case (string keys in a string-only dict that have hash collisions), but the cause can indeed come up. I need to spend a little time instrumenting the code to determine how often this corner case occurs, and haven't had time to do that yet. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-02-09 16:11 Message: Is this patch still revelant? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-09-25 18:52 Message: It's postponed since I've not had time to run performance tests to measure the corner case it aims to improve. It turns out that generating the test data I need takes a long time (I need hash collisions of identifier-like strings). I just need to be able to let my generator run for a long time (it was generating more collisions than I'd expected, but I don't know how many off-hand). Another interesting metric would be to examine the .pyc files generated from the standard library and find out if there are any string hash collisions there -- if not, or if very few, it's not worth the added complexity. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2000-09-25 14:38 Message: Shouldn't this patch be either postponed or checked in? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-09-15 11:18 Message: Accepted. Assuming you've tested this, it looks fine to me. Can you time this a bit? There's one niggling issue: some people think that before you do memcmp() you should manually compare the first character. Others think that's unnecessary (since a good compiler can inline memcmp anyway). (It's also a bit scary if the size is zero.) So please ignore this but keep it in mind for timing experiments. :) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-09-14 13:51 Message: Guido, please review (since Vladimir's away). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-09-14 09:26 Message: Revised patch: Instead of defining a function to do the fast string comparison, use a macro, but let it use the documented string object API (PyString_GET_SIZE(), PyString_AS_STRING()) instead of breaking the encapsulation in the code. This avoids all function calls to do the string compare, except memcmp() (which good compilers can inline anyway). Vladimir, take a look at this; if you're happy, I'm happy, and you can check it in. Thanks! ---------------------------------------------------------------------- Comment By: Vladimir Marangozov (marangoz) Date: 2000-09-05 06:08 Message: Argh! These Web interfaces strike again - forgot to login. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2000-09-05 06:05 Message: Correct! But then, aren't the current "else" if(cmp == 0) clauses risky after PyObject_Compare()? An exception may be set in external code while making Object_Compare() to return 0! Perhaps not in Python source, but in buggy extensions. lookdict() will then overlook this "hit". Patch updated, without "else" clauses and with the 1st char check in string_compare_equal(). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-09-04 06:45 Message: Quick comments: we should *always* call PyErr_Occurred() after PyObject_Compare() (and PyErr_Clear() if PyErr_Occurred() returned true). PyErr_Compare() really doesn't expect a pending exception coming in and so *not* clearing the error might break the *next* PyErr_Compare() call. (This doesn't happen typically but PyObject_Compare() can execute arbitrary code, some of which might call PyErr_Occurred() without calling PyErr_Clear() first.) ---------------------------------------------------------------------- Comment By: Vladimir Marangozov (marangoz) Date: 2000-09-03 21:09 Message: Let's add a comment, although this has been raised on python-dev. This patch proposes a couple of ideas for optimizing & speeding dict lookups -- not all of them need to be applied though. - clear the eventual errors from Object_Compare only on need (this logic needs to be double-checked once again to see whether it really works) - defer variable initializations after the most common return cases - specialize string_compare() for lookdict_string. The test comparing the first char, before calling memcmp(), can be added too. - inline the first item probe in PyDict_GetItem. This saves a func call for the most common case (common to lookdict & lookdict_string). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401394&group_id=5470 From noreply@sourceforge.net Wed Jul 4 05:26:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 21:26:05 -0700 Subject: [Patches] [ python-Patches-438331 ] make ndiff.py into a library module Message-ID: Patches item #438331, was opened at 2001-07-03 12:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438331&group_id=5470 Category: demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) >Assigned to: Tim Peters (tim_one) Summary: make ndiff.py into a library module Initial Comment: Here's a patch to make ndiff.py's functionality generally available to Python programs. It should move from Tools/scripts/ to Lib/. ndiff.py's functionality is very useful for making comparisons human-readable. I wanted to use it from my Python code (unittest's of generated XML), but unfortunately ndiff.py wasn't written that way. So I refactored out the lists-of-strings comparison code from fcompare() into lcompare(), and parameterized the formerly hard-coded IS_*_JUNK filters. I'd like to see it further converted to return a diff string, rather than only spew to stdout. It's easy enough to capture stdout, but klugey. I will do the mods if they have a good-to-certain chance of making it in. (Please let me know.) Also, give me the word and I will whip up some TeX docs if Tim doesn't have the time. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 21:26 Message: Logged In: YES user_id=3066 Is this still relevant in light of ndiff being factored into the ndiff.py script and the difflib library module? difflib is already documented. Assigning to Tim since this is his baby. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438331&group_id=5470 From noreply@sourceforge.net Wed Jul 4 05:27:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 21:27:30 -0700 Subject: [Patches] [ python-Patches-403972 ] threaded profiler. Message-ID: Patches item #403972, was opened at 2001-02-23 07:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403972&group_id=5470 Category: demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Amila Fernando (amila) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: threaded profiler. Initial Comment: Basically a profiler that can handle threaded programs and generate profiling snapshots. It does however have some situations it cannot handle well . (see included README for details). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 21:27 Message: Logged In: YES user_id=3066 Assigned to me since I've been digging into the profiling support lately. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-05-09 09:11 Message: Logged In: YES user_id=31392 Perhaps you could share this on comp.lang.python and see if people can help you fix the situations it doesn't handle well. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403972&group_id=5470 From noreply@sourceforge.net Wed Jul 4 05:28:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 21:28:51 -0700 Subject: [Patches] [ python-Patches-418659 ] Fixes for UnixWare and ReliantUnix Message-ID: Patches item #418659, was opened at 2001-04-24 14:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418659&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Fixes for UnixWare and ReliantUnix Initial Comment: This patch fixes the build problems on UnixWare, by: a) backing out 1.215 of configure.in and 1.34 of Makefile.pre.in b) Adding a test to check whether the compiler supports -Kpthread, and using that instead of #defines and libraries for pthread support. This part is not only restricted to UnixWare, but should work on other SysV compilers as well (e.g. ReliantUnix, untested) With these patches, UnixWare still passes the test suite except for test_math. Compared to 2.1, this drops usage of a shared libpython2.1.so. Such a feature is highly problematic, and was implemented incorrectly in 2.1. It should be brought back only as a configure option, which should be off by default, and apply to all Unix systems that support shared libraries. These patches should be applied to both the mainline and the 2.1 maintenance branch. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 21:28 Message: Logged In: YES user_id=3066 Assigned to me since the Reliant Unix issue is assigned to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418659&group_id=5470 From noreply@sourceforge.net Wed Jul 4 05:30:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 21:30:48 -0700 Subject: [Patches] [ python-Patches-429611 ] doc build on win32 with MiKTeX et al. Message-ID: Patches item #429611, was opened at 2001-06-02 08:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429611&group_id=5470 Category: documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: doc build on win32 with MiKTeX et al. Initial Comment: With this patch, everything build fine on win32 but for the following problems: - html/api/labels.pl not generated -> html/api/*.html uncorrect - lib/modindex.html not generated -> html/modindex.html uncorrect Problems worked out: - fancyhdr.sty is not in the Miktex distribution ... - Makefile content made compatible with the Windows command line (now runs fine with VC++'s nmake, or cygnus's make --win32) - misc. problems regarding the path formats - miktex 2.0's pdflatex would block on a mismatching macro level in python.sty -> fixed Hints on installing latex2html: - I had to work out some fixes in the config.pl script (2,000 lines of perl...) - make sure the paths to the ghostscript and miktex installations have no spaces!!!!!! latex2html will silently screw up its configuration process - looking at perl scripts gave me a serious trauma ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 21:30 Message: Logged In: YES user_id=3066 Assigned to the doc-tsar for review. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429611&group_id=5470 From noreply@sourceforge.net Wed Jul 4 05:38:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 21:38:45 -0700 Subject: [Patches] [ python-Patches-435381 ] Distutils patches for OS/2+EMX support Message-ID: Patches item #435381, was opened at 2001-06-22 01:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=435381&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) >Assigned to: Greg Ward (gward) Summary: Distutils patches for OS/2+EMX support Initial Comment: The attached patch file is against the code released with Python 2.1. The changes are included in the binary installation package of the OS/2+EMX port of Python 2.1 I released on June 17, 2001. With these changes, I have successfully built and installed the Numeric 20.0.0 extention, and created a bdist_dumb distribution package of it. The installed extention tests successfully using the supplied test routines. Particular items of note:- - OS/2 limits DLLs to 8.3 filenames :-( :-( - ld is not used to link, instead gcc is used with the -Zomf option which invokes the LINK386 linker native to OS/2 - I haven't made any attempt to merge cloned code back into the parent code where it would make sense, which I think is in a few places. Feedback appreciated. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 21:38 Message: Logged In: YES user_id=3066 The third item in the list of issues at the end of the initial comment indicates that the patch isn't ready for inclusion. Assigning to Greg Ward for review. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=435381&group_id=5470 From noreply@sourceforge.net Wed Jul 4 05:46:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 21:46:19 -0700 Subject: [Patches] [ python-Patches-438424 ] Fix for missing turtle fuctionality Message-ID: Patches item #438424, was opened at 2001-07-03 20:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438424&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josh Cogliati (jjc) >Assigned to: Guido van Rossum (gvanrossum) Summary: Fix for missing turtle fuctionality Initial Comment: Python's logolike module turtle.py did not display the turtle except when actually drawing lines. This patch changes the turtle.py module so that it displays the turtle at all times when tracing is on. This is similar to the the way that logo works. When tracing is off the turtle will not be displayed. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 21:46 Message: Logged In: YES user_id=3066 Assigned to Guido, since he likely knows more about Logo than I do (I don't!), and this is his module to begin with. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438424&group_id=5470 From noreply@sourceforge.net Wed Jul 4 05:43:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 21:43:48 -0700 Subject: [Patches] [ python-Patches-436258 ] Some cleanup of the cPickle module Message-ID: Patches item #436258, was opened at 2001-06-25 20:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=436258&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Minsk (rminsk) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Some cleanup of the cPickle module Initial Comment: While getting rid of compiler warning messages for another non-gcc compiler I found some dead code in cPickle.c. The attached patch fixes some possible type casting problems and removed some dead code. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=436258&group_id=5470 From noreply@sourceforge.net Wed Jul 4 05:48:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 21:48:44 -0700 Subject: [Patches] [ python-Patches-437733 ] Additional Argument to Python/C Function Message-ID: Patches item #437733, was opened at 2001-07-01 09:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=437733&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Additional Argument to Python/C Function Initial Comment: this patch makes it possible that a python/c function gets an aditional void* argument. this makes it easier to use python with c++. PS:i'm a bad despriptor,so please look at the diff file. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 21:48 Message: Logged In: YES user_id=3066 The patch is easy enough to understand, but the motivation for this is not at all clear. Rejecting as code bloat. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=437733&group_id=5470 From noreply@sourceforge.net Wed Jul 4 06:20:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 22:20:16 -0700 Subject: [Patches] [ python-Patches-419459 ] urllib adds extra CRLF in posted data Message-ID: Patches item #419459, was opened at 2001-04-27 04:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419459&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Per Cederqvist (ceder) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: urllib adds extra CRLF in posted data Initial Comment: urllib.py and urllib2.py adds an extra trailing CRLF in data that is sent in a POST statement. That is in violation of RFC 2616 that says: > Certain buggy HTTP/1.0 client implementations > generate extra CRLF's after a POST request. To > restate what is explicitly forbidden by the > BNF, an HTTP/1.1 client MUST NOT preface or > follow a request with an extra CRLF. The enclosed patch removes the generation of the extra CRLF. The patch was generated against the current CVS revisions. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:20 Message: Logged In: YES user_id=3066 Checked in as Lib/urllib.py revisions 1.127 and 1.126.2.1, and Lib/urllib2.py revisions 1.15 and 1.13.2.1. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419459&group_id=5470 From noreply@sourceforge.net Wed Jul 4 06:22:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 22:22:20 -0700 Subject: [Patches] [ python-Patches-430181 ] Make httplib work with picky servers Message-ID: Patches item #430181, was opened at 2001-06-04 19:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=430181&group_id=5470 Category: library Group: 2.0.1 bugfix >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Leonard Samuelson (lenski) Assigned to: Nobody/Anonymous (nobody) Summary: Make httplib work with picky servers Initial Comment: Python2.0: httplib.py: httplib: HTTPconnection Header processing: (putheader, putrequest, and endheaders) methods transmit each HTTP header line using a separate socket send invocation. Before this change, My Linksys Etherfast Cable/DSL router (Linksys BEFSR41, firmware v 1.22, March 31 2000) rejected the request becuase the entire HTTP header block is not contained in a single TCP packet. Clearly, the router is engaging in a noncompliant optimization! This patch is not required to allow httplib to work with real servers, making it completely optional. The patch I am submitting with this note causes httplib to work with the router. It is intended mostly as a model; a developer with greater familiarity with the library might have a better approach. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:22 Message: Logged In: YES user_id=3066 Martin pegged it; rejecting. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-07 12:47 Message: Logged In: YES user_id=21627 I recommend to reject this patch. Not only is the router broken, but it appears that the operating system is broken also; I think it legally could, and probably should, combine small write requests to a TCP socket that occur shortly after each other into a single IP packet. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=430181&group_id=5470 From noreply@sourceforge.net Wed Jul 4 06:23:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 22:23:32 -0700 Subject: [Patches] [ python-Patches-423140 ] adds encode- and decodestring to quopri Message-ID: Patches item #423140, was opened at 2001-05-10 12:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423140&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 3 Submitted By: Aluo Nowu (etoffi) >Assigned to: Barry Warsaw (bwarsaw) Summary: adds encode- and decodestring to quopri Initial Comment: i added this to match base64.py ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:23 Message: Logged In: YES user_id=3066 Assigned to Barry since the new APIs in base64 are his invention. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423140&group_id=5470 From noreply@sourceforge.net Wed Jul 4 06:25:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 22:25:08 -0700 Subject: [Patches] [ python-Patches-429136 ] BROWSER fix for webbrowser.py Message-ID: Patches item #429136, was opened at 2001-05-31 13:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429136&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: BROWSER fix for webbrowser.py Initial Comment: webbrowser.py currently assumes the BROWSER environment variable was set by the user who will take care of registering that browser. In the case of Gnome+Mandrake 8.0 (at least), this is not the case. The attached patch attempts to register any browsers found in BROWSER that aren't in the _browser dict already. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:25 Message: Logged In: YES user_id=3066 Assigned to me, since the webbrowser module is largely my fault, and the initialization has become more complex than it needs to be anyway. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429136&group_id=5470 From noreply@sourceforge.net Wed Jul 4 06:29:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 22:29:58 -0700 Subject: [Patches] [ python-Patches-429614 ] pythonpath and optimize def. before init Message-ID: Patches item #429614, was opened at 2001-06-02 08:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429614&group_id=5470 Category: core (C code) Group: None >Status: Pending >Resolution: Postponed Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Nobody/Anonymous (nobody) Summary: pythonpath and optimize def. before init Initial Comment: A) Addition of four functions ===================== Py_{Set, Get}{PythonPath, OptimizeLevel}() with the same semantics as Py_{Set, Get}ProgramName() (Note: the C ANSI type 'char const*' is used to describe non-modifiable strings) These four functions are needed in the next JPE runtime (Python 2.1 patch included in the distribution); this allows setting the PYTHONPATH and optimize level from Java property values. B) Option '-P pythonpath' on the Python command line: ======================================== This option defines 'pythonpath' from the command line (and override the PYTHONPATH environment variable if necessary). Usefullness: Sometimes, one does not want to rely on the environment variables, or modify them. Sample application: Running build and test scripts in full control of the environment, and with different PYTHONPATH values. This option is needed by the build and test scripts of the next JPE source distribution (Python 2.1 patch included in the distribution. Frederic Giacometti fred@arakne.com ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:29 Message: Logged In: YES user_id=3066 Flagged this patch as postponed pending the availability of a suitable or at least a publically archived discussion that indicates this is a useful and non-controversial change. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-10 22:53 Message: Logged In: YES user_id=21627 You can find the PEP guidelines in PEP 1: http://python.sourceforge.net/peps/pep-0001.html ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-06-08 14:37 Message: Logged In: YES user_id=93657 1) PEP: I am not in python-dev. What is the procedure for opening the PEP? 2) Override: I though about the question. My response was: If you wnat concatenation, use: python -P "something:$PYTHONPATH" or python -P "$PYTHONPATH:something" That's for all the better... 3) I renamed Py_{Set,Get}OptimizeFlag to Py_{Set,Get}OtimizeLevel after I wrote the documentation. Glad you caught the typo :)), sorry :(( I changed 'Flag' to 'Level' because 'Flag' normally designates a binary variable (2 states) whereas what we are doing is actually defining a debuging level (3 levels as of now, but who knows that some more levels might be addes). 'OptimizeLevel' is more accurate and less ambiguous than 'OptimizeFlag'. Frederic Giacometti ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-07 12:58 Message: Logged In: YES user_id=21627 I think a PEP describing the exact rationale and nature of the change is required here. For example, why is it good that -P overrides PYTHONPATH, instead of combining both somehow? Also, the documentation talks about Py_GetOptimizeLevel, whereas the header declares Py_GetOptimizeFlag. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429614&group_id=5470 From noreply@sourceforge.net Wed Jul 4 06:31:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 22:31:00 -0700 Subject: [Patches] [ python-Patches-423139 ] webbrowser.py fix for konqueror Message-ID: Patches item #423139, was opened at 2001-05-10 12:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423139&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joseph VanAndel (vanandel) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: webbrowser.py fix for konqueror Initial Comment: The 2.1 version of webbrowser.py uses kfmclient, and opens a new Konqueror window for each 'open' call. This patched version of webbrowser.py uses the KDE command line utility 'dcop' to either open a URL in an existing Konqueror window, or to open a new window. pydoc is much more useful with this version of webbrowser.py ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:31 Message: Logged In: YES user_id=3066 Assigned to me since webbrowser.py is my fault. ;-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423139&group_id=5470 From noreply@sourceforge.net Wed Jul 4 06:33:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 22:33:20 -0700 Subject: [Patches] [ python-Patches-424554 ] pythonrun.c: bag the _Py_AskYesNo call Message-ID: Patches item #424554, was opened at 2001-05-16 08:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424554&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Guido van Rossum (gvanrossum) Summary: pythonrun.c: bag the _Py_AskYesNo call Initial Comment: Currently, on Unix-like systems if Py_TRACE_REFS is defined, the Python interpreter asks at the end of the run if remaining references should be dumped. If you are trying to debug Python or its interaction with other packages that use it this can cause problems. Case in point, the configure script for the PyGtk2 package runs the python interpreter to check that its version number is >= 2.0. If you need Py_DEBUG enabled to build a version of PyGtk2 with that stuff turned on, you need it to not ask about printing references. I think the better solution is just to have the reference dumping dependent on the presence of the PYTHONDUMPREFS environment variable, which is currently only used under Windows. A patch to fix this problem is attached. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:33 Message: Logged In: YES user_id=3066 Another approach would be to use command line parameters. I'm not sure that either approach is necessarily better than the other. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424554&group_id=5470 From noreply@sourceforge.net Wed Jul 4 06:37:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 22:37:08 -0700 Subject: [Patches] [ python-Patches-424856 ] Better way to read files from ZipFiles Message-ID: Patches item #424856, was opened at 2001-05-17 07:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424856&group_id=5470 Category: library Group: None >Status: Pending >Resolution: Postponed Priority: 5 Submitted By: Itamar Shtull-Trauring (itamar) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Better way to read files from ZipFiles Initial Comment: RIght now, reading a file from a ZipFile loads the whole file into memory and returns it as a string. This makes the module useless for large files. My patch allows you to get a file-like object for each entry in the zip, so you can do: f = z.readfile("largfile") print f.read(500) Instead of the current method: s = z.read("largefile") print s[:500] Much nicer if "largefile" is a 10MB file... I added a function ZipFile.readfile, two classes for the file-like objects (uncompressed and deflated), and reimplemented ZipFile.read to use ZipFile.readfile. I also added a small test to test_zipfile.py, although some more extensive testing would be better, as usual. I will be using this code in a project, which'll provide additional testing. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:37 Message: Logged In: YES user_id=3066 The test definately needs to be better, and documentation is also required. Postponing the patch pending an update. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424856&group_id=5470 From noreply@sourceforge.net Wed Jul 4 06:41:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 22:41:28 -0700 Subject: [Patches] [ python-Patches-431422 ] "print" not emitting POP_TOP Message-ID: Patches item #431422, was opened at 2001-06-08 08:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=431422&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Shane Hathaway (hathawsh) >Assigned to: Jeremy Hylton (jhylton) >Summary: "print" not emitting POP_TOP Initial Comment: The Python-based compiler module (in Tools) has a bug in the visitPrint() method of pycodegen.CodeGenerator. It does not emit a trailing POP_TOP instruction, which AFAICT it should emit only when outputting to a stream and there is a trailing comma (indicating no newline). I've attached the patch applied to Zope's RestrictedPython module; if there is anything incorrect about it please tell me right away. Otherwise please apply the patch to Tools/compiler/pycodgen.py. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:41 Message: Logged In: YES user_id=3066 Assigned to Jeremy since the compiler package is his. ---------------------------------------------------------------------- Comment By: Shane Hathaway (hathawsh) Date: 2001-06-22 11:41 Message: Logged In: YES user_id=16701 Oops, it turns out the patch is incorrect! POP_TOP should only be added to the *last* print node. Here are the revised visitPrint() and visitPrintnl() methods. This is what is being used in Zope now. def visitPrint(self, node, newline=0): self.set_lineno(node) if node.dest: self.visit(node.dest) for child in node.nodes: if node.dest: self.emit('DUP_TOP') self.visit(child) if node.dest: self.emit('ROT_TWO') self.emit('PRINT_ITEM_TO') else: self.emit('PRINT_ITEM') if node.dest and not newline: self.emit('POP_TOP') def visitPrintnl(self, node): self.visitPrint(node, 1) if node.dest: self.emit('PRINT_NEWLINE_TO') else: self.emit('PRINT_NEWLINE') ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=431422&group_id=5470 From noreply@sourceforge.net Wed Jul 4 06:53:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 22:53:19 -0700 Subject: [Patches] [ python-Patches-428320 ] rich comparisons as operator.__lt__ etc. Message-ID: Patches item #428320, was opened at 2001-05-29 07:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428320&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: rich comparisons as operator.__lt__ etc. Initial Comment: Rich Comparisons (PEP 207) introduce new special names in classes (__lt__, __le__, __eq__, etc.). They should be available in the 'operator' module just like the other special names (__add__ and the like). This patch introduce 12 new names in 'operator': lt, le, eq, ne, gt, ge, __lt__, __le__, __eq__, __ne__, __gt__, __ge__. The first 6 are provided for uniformity with the rest of the module but I am not sure whether it is a good idea to clutter a namespace with names only two letters long; for example, could names like 'eq' accidentally break existing programs using from operator import * ? ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:53 Message: Logged In: YES user_id=3066 I'd prefer to see the names that don't have underscores be lessthan, lessthanequal, equal, notequal, greaterthan, greaterthanequal. Not sure what others think. I doubt the issue is "from operator import *" -- no one should be doing that anyway. Also, the documentation fragment uses "informations" (note the 's') instead of "information". ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2001-05-29 08:01 Message: Logged In: YES user_id=4771 Sorry, I forgot to login when I posted the patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428320&group_id=5470 From noreply@sourceforge.net Wed Jul 4 11:01:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Jul 2001 03:01:47 -0700 Subject: [Patches] [ python-Patches-424554 ] pythonrun.c: bag the _Py_AskYesNo call Message-ID: Patches item #424554, was opened at 2001-05-16 08:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424554&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Guido van Rossum (gvanrossum) Summary: pythonrun.c: bag the _Py_AskYesNo call Initial Comment: Currently, on Unix-like systems if Py_TRACE_REFS is defined, the Python interpreter asks at the end of the run if remaining references should be dumped. If you are trying to debug Python or its interaction with other packages that use it this can cause problems. Case in point, the configure script for the PyGtk2 package runs the python interpreter to check that its version number is >= 2.0. If you need Py_DEBUG enabled to build a version of PyGtk2 with that stuff turned on, you need it to not ask about printing references. I think the better solution is just to have the reference dumping dependent on the presence of the PYTHONDUMPREFS environment variable, which is currently only used under Windows. A patch to fix this problem is attached. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2001-07-04 03:01 Message: Logged In: YES user_id=44345 In the example I noted (a configure script running python) it would be difficult to get at the command line without messing around with the configure script or the autoconf macros. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:33 Message: Logged In: YES user_id=3066 Another approach would be to use command line parameters. I'm not sure that either approach is necessarily better than the other. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424554&group_id=5470 From noreply@sourceforge.net Thu Jul 5 03:27:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Jul 2001 19:27:59 -0700 Subject: [Patches] [ python-Patches-438331 ] make ndiff.py into a library module Message-ID: Patches item #438331, was opened at 2001-07-03 12:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438331&group_id=5470 Category: demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Tim Peters (tim_one) Summary: make ndiff.py into a library module Initial Comment: Here's a patch to make ndiff.py's functionality generally available to Python programs. It should move from Tools/scripts/ to Lib/. ndiff.py's functionality is very useful for making comparisons human-readable. I wanted to use it from my Python code (unittest's of generated XML), but unfortunately ndiff.py wasn't written that way. So I refactored out the lists-of-strings comparison code from fcompare() into lcompare(), and parameterized the formerly hard-coded IS_*_JUNK filters. I'd like to see it further converted to return a diff string, rather than only spew to stdout. It's easy enough to capture stdout, but klugey. I will do the mods if they have a good-to-certain chance of making it in. (Please let me know.) Also, give me the word and I will whip up some TeX docs if Tim doesn't have the time. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-04 19:27 Message: Logged In: YES user_id=31435 Fred, I think I understand what David's after. ndiff has a great deal of logic for comparing "files" as sequences of lines which are in turn sequences of characters, on top of what difflib.py provides (in fact, only the easiest part was factored out). Whether that should go into the std library is a legit question, though. I'll ask Guido about it; if he's at all inclined to say "yes", I bet it would only be because he trusts me to maintain it for the rest of my life <0.7 wink>. I've wanted this at times too; e.g., doctest would love to do a clearer job of showing "expected" vs "but got" outcomes than just listing both in full without any correlation. David, if you want to do this you should supply a proper "file-like object" comparison class instead. You appear to be aiming more at minimal changes here than at clean library design. I'd rather see a clean new class added to difflib.py, the use of which could reduce ndiff.py to a one-pager (or so). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 21:26 Message: Logged In: YES user_id=3066 Is this still relevant in light of ndiff being factored into the ndiff.py script and the difflib library module? difflib is already documented. Assigning to Tim since this is his baby. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438331&group_id=5470 From noreply@sourceforge.net Thu Jul 5 04:49:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Jul 2001 20:49:38 -0700 Subject: [Patches] [ python-Patches-438331 ] make ndiff.py into a library module Message-ID: Patches item #438331, was opened at 2001-07-03 12:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438331&group_id=5470 Category: demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Tim Peters (tim_one) Summary: make ndiff.py into a library module Initial Comment: Here's a patch to make ndiff.py's functionality generally available to Python programs. It should move from Tools/scripts/ to Lib/. ndiff.py's functionality is very useful for making comparisons human-readable. I wanted to use it from my Python code (unittest's of generated XML), but unfortunately ndiff.py wasn't written that way. So I refactored out the lists-of-strings comparison code from fcompare() into lcompare(), and parameterized the formerly hard-coded IS_*_JUNK filters. I'd like to see it further converted to return a diff string, rather than only spew to stdout. It's easy enough to capture stdout, but klugey. I will do the mods if they have a good-to-certain chance of making it in. (Please let me know.) Also, give me the word and I will whip up some TeX docs if Tim doesn't have the time. ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2001-07-04 20:49 Message: Logged In: YES user_id=7733 Tim: Your doctest example is spot-on. That's exactly what I'm using ndiff for, within unit tests. I will work on a clean class to add to difflib.py, implementing the ndiff functionality. PEP required? (No, I'm not going for a record.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-04 19:27 Message: Logged In: YES user_id=31435 Fred, I think I understand what David's after. ndiff has a great deal of logic for comparing "files" as sequences of lines which are in turn sequences of characters, on top of what difflib.py provides (in fact, only the easiest part was factored out). Whether that should go into the std library is a legit question, though. I'll ask Guido about it; if he's at all inclined to say "yes", I bet it would only be because he trusts me to maintain it for the rest of my life <0.7 wink>. I've wanted this at times too; e.g., doctest would love to do a clearer job of showing "expected" vs "but got" outcomes than just listing both in full without any correlation. David, if you want to do this you should supply a proper "file-like object" comparison class instead. You appear to be aiming more at minimal changes here than at clean library design. I'd rather see a clean new class added to difflib.py, the use of which could reduce ndiff.py to a one-pager (or so). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 21:26 Message: Logged In: YES user_id=3066 Is this still relevant in light of ndiff being factored into the ndiff.py script and the difflib library module? difflib is already documented. Assigning to Tim since this is his baby. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438331&group_id=5470 From noreply@sourceforge.net Thu Jul 5 16:13:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Jul 2001 08:13:36 -0700 Subject: [Patches] [ python-Patches-438790 ] additional mappings for mimetypes.py Message-ID: Patches item #438790, was opened at 2001-07-05 08:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438790&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: additional mappings for mimetypes.py Initial Comment: added some additional mapping for mimetypes.py. Andreas ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438790&group_id=5470 From biz@6x6.net Thu Jul 5 16:05:44 2001 From: biz@6x6.net (biz@6x6.net) Date: 05 Jul 2001 16:05:44 +0100 Subject: [Patches] ATTENTION! Well-Paid Job in the Internet! Message-ID: ATTENTION! The Well-Paid Job in the Internet!
We wish You a pleasant and successful day!
 
Make money without leaving Your computer!


If You show some interest and patience and understand as IT works, You can earn up to $100,000 and more!!! During the following 120 days - it depends only on You. DOES IT SEEMS TO BE IMPOSSIBLE?? Read this document to be sure there is no catch or deceit. If You are completely lazy - we beg Your pardon for the assumption!!!, then this is not for You!!! You'd better do something like surfing either clicking on banners or not doing anything at all.

!!! If the offer hasn't interested You, we bring our apologies and it is not necessary to get angry - "Spam" has its expenses, just as radio and TV, but do not forget, that the first billionaire of the USA, Dale Carnegie said:

"I'll better earn 1% as a result of the efforts of 100 men, than 100% as a result of my own efforts."


RISE ON THE WAY TO THE FINANCIAL INDEPENDENCE AND FREEDOM!!!
Welcome to the 6X6!
 
It is difficult to believe but nevertheless it is like that! People get richer and richer! Some of them can't recover from the shock which had come together with a heap of crust banknotes even some months later. While the others deliberate and doubt, people that believed in Business System 6X6 bathe now in money!...
 
In view of prompt rates of development of the Internet and electronic commerce the number of users of the "World Wide Web" grows with the great speed. There are more than 15,000 new people who join the Internet daily...
 

Copyright © 2001 6x6 MLM Corporation. All rights reserved.
Ladies and Gentlemen!
 
 


PLEASE READ THOUGHTFULLY AND ATTENTIVELY, TRYING NOT TO DISTRACT YOUR ATTENTION WITH EXTERNAL NOISES AND IRRITANTS, AND YOU'LL UNDERSTAND WHAT WILL MAKE YOU RATHER RICH AND FREE PEOPLE!!!
 

 


It is difficult to believe but nevertheless it is like that! People get richer and richer! Some of them can't recover from the shock which had come together with a heap of crust banknotes even some months later. While the others deliberate and doubt, people that believed in Business System 6X6 bathe now in money! In a literal sense! Have You ever seen how the heap of the $5 bills under which the adult person entirelly finds room looks like?! It is 100 thousand dollars!!! Can You imagine how the heap of $1,000,000 which is earned by each third participant of the superprogram 6X6 looks like?! And what is the feeling when You, not getting troubled with work, start to receive envelopes with six dollars already on the second week and further the profit is much more! And eventually some months later You don't know how to get rid of the money! You even get a bit scary of this avalanches of the money!!!
 

ALL THAT IT WILL NECESSARY TO DO - TO SEND THE ADVERTISING LETTERS VIA E-MAIL AND FROM TIME TO TIME TO CHECK YOUR MAILBOX OR TO GO TO THE BANK! YOU SHOULDN'T EVEN STRAIN THE BRAIN - THE SUPER COMPUTER BUSINESS SYSTEM 6X6 WILL MAKE EVERYTHING ITSELF!!!

SINCE THE MOMENT YOU ENTER THIS BUSINESS YOUR PROFIT SNOWBALLS AND BY THE END OF 4TH MONTH YOU'LL GET AS MINIMUM $100,000. BUT IF YOU DON'T STOP THE RESULTS WILL BE ASTRONOMICAL - $1,000,000 FOR 1 YEAR!!!!


"What is the secret of such dizzy success?" - You ask. This is because there is a new formula in the business system which provides all participants with 100%-s' success due to the account of such special factors which the human brain is simply not capable of grasping. Therefore this excellent program works! And it works brilliantly! This is a prodigy-system in which success is madly infectious! Hurry up to achieve the success too!!!
 

TRY YOURSELF!!!
 
&nbps;


Have You ever wondered why the majority of people achieve nothing in life but only complain? This is because they are ready on a little in their life. They have a ready definitions on everything, but these definitions are formulated not by them and taken from the others. To have Your own opinion is a luxury and rarity. Those who are not afraid to try and work more than doubts very quickly appears at the top of the World! Yes, it is difficult to believe that it is possible to get rich so quickly, difficult to overcome the doubts and find Yourself suddenly fantastically rich. But believe if You will do it, it becomes Your blessing and Your dizzy success! You will not argue that You are worthy of big success and big richness, will You? And so it is vitally necessary for You to do this step to find the financial independence which will bring You co-operation with superprogram 6X6! Your time has come!
 

"Pair words about the system..." - an interview with Igor Tichtchenkov, the founder of the business system
 
 


- In view of prompt rates of development of the Internet and electronic commerce the number of users of the "World Wide Web" grows with the great speed. There are more than 15,000 new people who join the Internet daily. With the growth of number of the Internet's users the number of different types of business programs also grows. Every day their popularity increases too and it is natural because the electronic commerce is the business of the 21st century. But business system 6X6 surpasses all others on some orders - it is possible to judge it by looking at the success it brings to all its participants. What is its advantage above the other business programs of similar type? Why does 6X6 bring success to all its participants - not only for its founder and the people who stand near him?

- Yes, You are absolutely right about the prompt development of electronic commerce and the occurrence of many business systems similar to 6X6.

Before the development of the program 6X6 I had closely studied all systems existing at concurrently and understood the way they had appeared. Probably everyone remembers those bonds which were so popular in 90-s. And so with the development of the Internet someone who knows nothing about computer technologies and of the principles of the "World Wide Web" simply transferred this program with bonds to the network. Yes, the idea is ingenious especially for those times - without the Internet You will hardly find 5 clients, in the network there are millions of users and it is possible to send thousands of advertising letters and find a lot of clients. But this system had setbacks: absence of the description of how to send a bulk mailing of advertising letters, where to take thousands of e-mail addresses etc. The most important deficiency was that this system was designed for extremely honest people. In the advertising letter there was a form similar to our business-table according to which the person who entered that business system had to buy its commodity units (each at the different participant). When he bought them he had to put his postal address for payment opposite to the first commodity unit and shift all other addresses one level below. If nobody supervised him he could change the table somehow. For example if he opened some P.O. boxes with various names at different post offices of the city and put the requisitions of these so-called "dead souls" to the table instead of the previous participants and the process stopped that way. Thus the system worked only at 100% at the first level, 1% -at the second, 0,1% - at the third and 0% at the fourth. Actually the profit came only from the first level, i.e. from direct sales. If You sent about 3,000 advertising letters per day You earned about $300 - $400 per month. But the idea of such kind of business systems - was to bring a maximum of the profit due to the last two levels, i.e. You send a party of letters, for example 10,000, receive 30 orders for the first level commodity unit and further the system works for You for several years. But many people earn these $300 - $400 per month sending 3,000 letters per day, having opened some P.O. boxes and put their requisitions everywhere where only it was possible. The commodity units also didn't contain useful information, excepting the names in the advertising letter. Therefore when You worked with such system You deceived the clients.

Probably, there is no sense to describe all other similar kinds of business systems because they are the copies of previous in literal sense. All they appeared that way - the essence was copied and secondary factors such as the names of commodity units, ways of payment, the contents of the advertising letter etc. were changed. It is possible to tell one about all of them: they are "created" (if it is possible to apply this word to pure plagiarism) by amateurs, that are distant from business in general (what is electronic commerce - they simply don't know!) as well as from computer technologies. But the idea to create such business systems is genious. Especially at our time – a time of the cutting edge Internet development and electronic commerce. Excluding the deficiencies of this system it is invaluable! Can You imagine what will the Internet look like in five years!

Even though the task was very difficult I developed such a business system.

The absence of the description of how to send a bulk mailing of advertising letters, where to take thousands of e-mail addresses and other technical details, I compensated with a specially developed software for automation of this process, that allowed one to send 5,000 to 20,000 advertising letters per day having spent only 30-40 minutes of the time, and with the very detailed description of work with this software, written in language which is comprehensible for users of any level and a plenty of advices and recommendations. I managed to do two things at once: to considerably increase productivity of the business system and to make the commondity units not only useful - required for the every participant of the business system, because they contain this special software and the description of work with it.

I stopped the dishonesty of participants by an obligatory registration at the main office of 6X6 MLM Corporation.

Because the system does not break I have added 2 additional levels and now the system has 6 levels (and the commodity unit of every level costs $6 - therefore and the name "6X6").

I made a more flexible system of the payment for the orders. Now the commodity units can be paid both by the "traditional" first class mail and can be transferred on the bank account. But I forbade to specify P.O. boxes as the address for payment for avoidance of a deceit and that the business system don't lose its attractiveness. Proceeding from the same reasons I forbade WebMoney.

I concluded the contract with iWin Loto Ltd. So with registration in our main office You are automatically included in a lottery and Your chances to win are directly proportional to the amount of sold Chapter#1.
 

The responses of our partners
 
 


My name is Jerry Proctor. Two years ago, the corporation I worked at for the past fifteen years down-sized and my position was eliminated. After unproductive job interviews, I decided to open my own business. Over the past year, I incurred many unforeseen financial problems. I owed my family, friends and creditors over $35,000. The economy was taking a toll on my business and I just couldn't seem to make ends meet. I had to refinance and borrow against my home to support my family and struggling business. AT THAT MOMENT something significant happened in my life and I am writing to share the experience in hopes that this will change Your life FOREVER FINANCIALLY!!! In mid December, I received this program via e-mail. Six month's prior to receiving this program I had been sending away for information on various business opportunities. All of the programs I received, in my opinion, were not cost effective. They were either too difficult for me to comprehend or the initial investment was too much for me to risk to see if they would work or not. One claimed that I would make a million dollars in one year ...it didn't tell me I'd have to write a book to make it! But like I was saying, in December of 1997 I received this program. I didn't send for it, or ask for it, they just got my name off a mailing list. THANK GOODNESS FOR THAT!!! After reading it several times, to make sure I was reading it correctly, I couldn't believe my eyes. Here was a MONEY MAKING PHENOMENON. I could invest as much as I wanted to start, without putting me further into debt. After I got a pencil and paper and figured it out, I would at least get my money back. But like most of You I was still a little skeptical and a little worried about the legal aspects of it all. So I checked it out with the U.S. Post Office (1-800-725-2161 24-hrs) and they confirmed that it is indeed legal! After determining the program was LEGAL and NOT A CHAIN LETTER, I decided "WHY NOT." Initially I sent out 30,000 e-mails. It cost me about $15 for my time on-line. The great thing about e-mail is that I don't need any money for printing to send out the program, and because all of my orders are fulfilled via e-mail, the only expense is my time. I am telling You like it is, I hope it doesn't turn You off, but I promised myself that I would not "rip-off" anyone, no matter how much money it cost me. In less than two weeks, I was starting to receive orders for CHAPTER#1. By January 13, I had received 36 orders for CHAPTER#1. Your goal is to "RECEIVE at least 30 ORDERS FOR CHAPTER#1" My first step in making $100,000 in 120 days was done. By January 30, I had received 246 orders for CHAPTER#2. Your goal is to "RECEIVE AT LEAST 150 ORDERS FOR CHAPTER#2. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU DO. ONCE YOU HAVE 150 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $100,000 GOAL." Well, I had 246 orders for CHAPTER#2, 96 more than I needed. So I sat back and relaxed. By March 30, of my e-mailing of 30,000, I received $118,000 with more coming in every day. I paid off ALL my debts and bought a much needed new car. Please take time to read this program, IT WILL CHANGE YOUR LIFE FOREVER!!! Remember, it won't work if You don't try it. This program does work, but You must follow it EXACTLY! In order for this program to work, You must meet Your goal of 30+ orders for CHAPTER#1, and 150+ orders for CHAPTER#2 and You will make $100,000 or more in 120 days. I AM LIVING PROOF THAT IT WORKS!!! If You choose not to participate in this program, I am sorry. It really is a great opportunity with little cost or risk to You. If You choose to participate, follow the program and You will be on Your way to financial security. If You are a fellow business owner and are if financial trouble like I was, or You want to start Your own business, consider this a sign. I DID!

Sincerely, Jerry Proctor.

 


This program really works. I live outside the US, in Europe and at first I had doubts, I wasn't sure if it would work and so I didn't take it very seriously. But after a while I figured "Why not?". After all, I can't loose much. I sended the requests for the Chapters (I did everything just like I had to because I wanted to do everything right, so if it wouldn't work it wouldn't be my fault, but the program's) and waited. After a while the Chapters arrived by e-mail and I read them several times, they gave me precise information on how to let the program work and after I knew it all, I started my work. I started searching e-mail addresses everywhere (sites, magazines,...) and made long lists (I really enjoyed this because it was like a new hobby and I had nothing to loose). like crazy I started sending e-mail to people all over the world. I kept doing this and checked the mail every day. After two weeks orders started to arrive. I remember the moment when I went to the mailbox and I found the first order for Chapter#1. I just stood there for a moment and I said to myself: "this works, this thing f..... works!!!" I was so happy that I started sending even more e-mails. The next day, nothing in the mail, I thought "maybe this is it" and I was a bit dissapointed but the next day I received 3 orders for Chapter#1. I sended the Chapters to those people so they could start making money too (for them and for me). Two weeks later I was sitting almost 30 minutes a day before my computer sending Chapters to people that had ordered them. In these two weeks I received 39 orders for Chapter#1. Profit so far: about 240 dollars. After that orders came faster and faster, every week I got hundreds of orders and the dollars kept coming. In total I received 124'000 dollars. can You believe this??? Last week I bought a new motorcycle and I owe it all to this program. if You're reading this letter right now and You're not sure whether to participate or not I can only say one thing: TRY IT, You won't regret. This is Your chance, take it now or You will be sorry for the rest of Your live.

H.J. Moines, France.

 


The main reason for this letter is to convince You that this system is honest, lawful, extremely profitable, and is a way to get a large amount of money in a short time. I was approached several times before I checked this out. I joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received $136,470 in the first 14 weeks, with money still coming in.

Charles Morris, Esq.

 


Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back. Boy, was I surprised when I found my medium-size mailbox crammed with orders! For awhile, it got so overloaded that I had to start picking up my mail at the window. I'll make more money this year than any 10 years of my life before. The nice thing about this deal is that it doesn't matter where people live. There simply isn't a better investment with a faster return.

Paige Willis, Des Moines, IA.

 


I had received this program before. I deleted it, but later I wondered if I shouldn't have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed another program, ...11 months passed then it came... I didn't delete this one! I made more than $141,000 on the first try!!

Violet Wilson, Johnstown, PA.

 


This is my third time to participate in this plan. We have quit our jobs, and will soon buy a home on the beach and live off the interest on our money. The only way on earth that this plan will work for You is if You do it. For Your sake, and for Your family's sake don't pass up this golden opportunity. Good luck and happy spending!

Kerry Ford, Centerport, NY.

We wait for Your responses. Send them to the main office.
What is the 6X6?
 
 


So, let’s start earning heaps of money without leaving the house! "This is my chance!", - You exclaim having realized that is not necessary to go anywhere and to persuade somebody - only send advertising letters and receive profits! "And what is necessary to do for this purpose?" - the question is inevitable. Earning a heap of money - from $100,000 up to $1,000,000 - for the beginning You must be registered at the main office of the 6X6 MLM Corporation and receive a personal registration number. Having entered in 6X6, You become the distributor of the Chapters - detailed descriptions of work with business system 6X6 and optimization the computer. Clients of Your business become the people that will be interested in these Chapters. And the Chapters should interest them! People will be interested in business itself and all this is a guaranty that people certainly shall respond to Your letter. What is this letter? This is the advertising letter which You'll receive from the main office of the 6X6 MLM Corporation after the registration (it differs from the letter which You are reading now by the presence of Your registration number in the business table). You simply send it to a lot of people. How to find the endless amount of e-mails, how automatically send the advertising letter to them and many other things You will find out in the Chapters. If You are worried where to find so many e-mail addresses don’t bother. There are more than 15,000 new people connecting to the Internet daily!!! It'll be enough for everybody!!! After You send the application for registration, a letter will be sent to You, containing:

1) Your registration number,

2) The advertising letter with Your registration number in the business table. In the future You'll send this letter to thousands of recipients,

3) Postal addresses or bank accounts of other participants of the business system. It is necessary for You to order the Chapters from them, each Chapter from different participant (excepting the Master) according to the deciphered business table, that You had an opportunity to sell them to the customers.

Together with it You will also receive other instructions. Well the thing You'll have to do now is to catch the essence of the algorithm below. So, You have all Chapters and You have to send the letter which contains the foreword to these surprising Chapters as the advertisement. Having read it, the person who has received the letter from You will certainly want to enter to the business system 6X6 and read all Chapters. But even if suddenly he will not want to read the Chapters he'll certainly become interested in a unique opportunity to earn millions practically without any expenses, both on money and on time! I agree, it is just impossible to refuse it! Approximately in 2 weeks from the date of Your first mailing You will receive orders for the first Chapter and a payment for it ($6 for each Chapter) from 30 persons or even more. Thus, Your first income will be $180 or more. This is only the beginning! At registration You will be automatically included in a lottery from iWin Lotto - one of the most popular companies engaged in lotto-business in the World, the main prize is $5,000,000 (it is also played 5 prizes on $1,000,000, 100 prizes on $100,000 and more than 5,000 branded T-shirts from 6X6 MLM Corp., draws are carried out every month) – as much orders You get on Chapter#1, as much chances to win the main prize. Do You see?!!! All that is required of You is to send more advertising letters. All Your work will be to go to the bank from time to time or check Your mailbox for cash, and at home, in silence to count up everytime increasing profit! The guarantor of Your dizzy success and reliable ally becomes the most grandiose in the world computer superprogram 6X6!!!
 

THE CHAPTERS
 
 


The Chapters are the most detailed description of the business system 6X6, they are advices about the way to optimize the work with the system and adjust the computer for it. Having read them You will understand how to improve a connection with the Internet, how to find 5,000 to 20,000 e-mail addresses per day, to sort them, to send 5,000 to 20,000 advertising letters per day, how to increase productivity of the computer on 50% and many others interesting things, not applying special efforts.

The Chapters are written in language that is clear for the users of any levels, therefore for working with the business system 6X6 You don't need to be a programmer or even have computer experience. Moreover, if You have begun to work with the computer just yesterday and don't know anything about it, You should read attentively the Chapters and work some time with the business system 6X6. Thus You will soon become an advanced user who knows everything about Windows and the Internet. In addition You also get the special software with each Chapter that is necessary for work and certain amount of e-mail addresses.

The list of the Chapters:

Chapter#1 “Introduction to business system 6Õ6. Optimization of the Internet connection. How to use the Internet much more effectively.”

+20,000 e-mails
+software for automatic reconnecting to the Internet and its complete description.

Chapter#2 “How to find 5,000 to 20,000 e-mails per day, working about 30-40 minutes.”

+10,000 e-mails
+software for automatic inclusion/deenergizing of the program for e-mails searching at connection/break of connection with the Internet described in the previous Chapter.

Chapter#3 “How to sort e-mails.”

+10,000 e-mails
+software for automatic e-mails searching described in the previous Chapter.

Chapter#4 “How to send 5,000 to 20,000 thousand advertising letters per day, working the same 30-40 minutes.”

+10,000 e-mails
+software for fast e-mails sorting described in the previous Chapter.

Chapter#5 “The most effective algorithm of the work with the business system 6X6.”

+80,000 e-mails (!)
+software for automatic sending a huge amount of the advertising letters with attachments described in the previous Chapter.

Chapter#6 “Optimize Your computer, raise its productivity on 50%.”

+100,000 e-mails (!)
+the server part of the software for automatic sending a huge amount of the advertising letters with attachments.

THE RULES OF THE PARTICIPATION IN THE BUSINESS SYSTEM 6X6
 
 


The terms:

The master – Igor Tichtchenkov, the founder of the business system;

referrer – the participant of 6X6 from that You have received this advertising letter and should order the Chapter;

client – the owner of e-mail address where You send the advertising letter;

referral – the participant of 6X6 who has ordered from You the Chapter.

How does the business system 6X6 work
 
 


The following system was developed to earn not only from the direct sales (i.e. when You sell the Chapter#1 to Your referrals) but also from the sales of the referrals (i.e. when Your referrals bring to You buyers on Chapter#2 - Chapter#6). There is a following table (so-called the business table) in the advertising letter:

Chapter#1...............referrer nr.1
Chapter#2...............referrer nr.2
Chapter#3...............referrer nr.3
Chapter#4...............referrer nr.4
Chapter#5...............referrer nr.5
Chapter#6...............referrer nr.6

Opposite to each Chapter there is the essential elements of different participants, i.e. You will buy the Chapter#1 from referrer nr.1, Chapter#2 from referrer nr.2, Chapter#3 from referrer nr.3, Chapter#4 from referrer nr.4, Chapter#5 from referrer nr.5, Chapter#6 from referrer nr.6. When You will be registered You'll receive the advertising letter with the business table changed as follows:

Chapter#1...............You
Chapter#2...............referrer nr.1
Chapter#3...............referrer nr.2
Chapter#4...............referrer nr.3
Chapter#5...............referrer nr.4
Chapter#6...............referrer nr.5

Then You begin to send the advertising letter with such business table. I.e. Your referrals will buy the Chapter#1 from You, Chapter#2 from referrer nr.1, Chapter#3 from referrer nr.2, Chapter#4 from referrer nr.3, Chapter#5 from referrer nr.4, Chapter#6 from referrer nr.5. Your referrals nr.1 (they who will buy Chapter#1 from You) will get similarly transformed business table:

Chapter#1...............referral nr.1
Chapter#2...............You
Chapter#3...............referrer nr.1
Chapter#4...............referrer nr.2
Chapter#5...............referrer nr.3
Chapter#6...............referrer nr.4

Then they begin to send the advertising letter with such business table. I.e. their referrals nr.1 (Your referrals nr.2) will buy the Chapter#1 from them (from Your referrals nr.1), Chapter#2 from You, Chapter#3 from referrer nr.1, Chapter#4 from referrer nr.2, Chapter#5 from referrer nr.3, Chapter#6 from referrer nr.4. And etc...

Thus Your referrals involve the clients to the Chapter#1 for themselves and also involve the clients to the other Chapters for You. That means that a direct task of each participant of business system 6X6 - to get as more as possible orders for Chapter#1.

Let's just count up how much money You will earn if each participant involves 10 referrals nr.1:

You......................10 X $6 = $60
Your referrals nr.1...10 X 10 X $6 = $600
Your referrals nr.2...10 X 10 X 10 X $6 = $6,000
Your referrals nr.3...10 X 10 X 10 X 10 X $6 = $60,000
Your referrals nr.4...10 X 10 X 10 X 10 X 10 X $6 = $600,000
Your referrals nr.5...10 X 10 X 10 X 10 X 10 X 10 X $6 = $6,000,0000

Total You will earn $6,666,660!

The figure is not small and therefore You may have doubts. - Try to figure Yourself and You'll get the same result!

Protection against the fraud
 
 


The following protection was developed to exclude breaking of the system.

In the advertising letter there is such business table:

Chapter#1...............reg. nr. of the 1st referrer
Chapter#2...............reg. nr. of the 2nd referrer
Chapter#3...............reg. nr. of the 3rd referrer
Chapter#4...............reg. nr. of the 4th referrer
Chapter#5...............reg. nr. of the 5th referrer
Chapter#6...............reg. nr. of the 6th referrer

The client who has received this advertising letter knows only registration numbers of the referrers from that he must buy the Chapters. He can't buy all their Chapters directly because he doesn't know their requisitions.

Further he registers at the main office of 6X6 MLM Corporation and gets:

1) His registration number;

2) Addresses and bank accounts of all referrers at that he must buy the Chapters;

3) The advertising letter with the changed business table likes that:

Chapter#1...............His reg. nr.
Chapter#2...............reg. nr. of the 1st referrer
Chapter#3...............reg. nr. of the 2nd referrer
Chapter#4...............reg. nr. of the 3rd referrer
Chapter#5...............reg. nr. of the 4th referrer
Chapter#6...............reg. nr. of the 5th referrer

buys all of the Chapters and begins to send this letter.

Due to this protection he can't stop the process and leave their own referrers without their profit. The process can be stopped only if their requisitions will not be in the business table. It is possible only if he will replace requisitions of all five referrers with his requisitios. But he can't do that because for this purpose it will come to register 6 times, whereas it is possible to register only once.
 

ARE YOU READY TO START WITH THE BUSINESS SYSTEM 6X6! LET'S START!
 
 


Attention! There is an enormous amount of referrals who enter the business system 6X6 and that's why from the 1st of September 2000 the registration costs $5.

WHAT YOU NEED TO DO:

a) Register at the main office of 6X6 MLM Corporation:

1) Write on a sheet of paper:

1) Your name;
2) Your postal address for payment;
3) Your bank account for payment (optional);
4) Your e-mail - write legibly and use it only for communication with the main office;
5) The business table which is below;
6) The date.

2) Put $5 in this sheet of paper and send by the first class mail to the 6x6 MLM Corporation's main office:

Igor Tichtchenkov, Laanemere 20-96, 13913 Tallinn, Estonia.

3) Within one week You'll receive (via e-mail You have written in the registration form) the letter containing:

1) Your registration number;
2) Addresses of the referrers from that You should buy the Chapters;
3) The advertising letter with Your registration number for mailing;
4) The instructions that is necessary for beginning.

b) Buy all of the Chapters according to the business table:

Chapter Nr.
Referrer's reg. nr.
Chapter#1
6x6-000002-z-115
Chapter#2
6x6-000000-z-001
Chapter#3
Master 6x6
Chapter#4
Master 6x6
Chapter#5
Master 6x6
Chapter#6
Master 6x6

THE NOTE! If several or even all registration numbers are "Master 6X6" - there isn't any mistake. When You join You'll be at the begining of the system and undoubtedly earn the enormous amount of money! Your chances to the success are maximal!

As soon as You do this, start sending the advertising letters (more detailed information about the way to do it You will find at the Chapters). In general You should involve about 30 referrals - i.e. to sell 30 Chapters #1. But the more referrals You involve the more Your profit will be!

Try to send 3,000 or more advertising letters per day - it is very easy to do with the special software which You'll get together with the Chapters. If You can send more - do it! Remember as many advertising letters You send the more orders You will get!

The entire process lasts approximately for 4 months. If You precisely follow all the rules, You undoubtedly will be the owner of several hundreds thousand dollars! We know that it will be like that and we congratulate You!!!

And now let's start!

We wish You Great Success!!!

 
 

Copyright © 2001 6x6 MLM Corporation. All rights reserved.
Æåëàåì Âàì ïðèÿòíîãî è óñïåøíîãî äíÿ!
 
Ýòî çàðàáîòîê áåç îòðûâà îò ìîíèòîðà!


Åñëè Âû ïðîÿâèòå íåêîòîðûé èíòåðåñ è òåðïåíèå, à ãëàâíîå, ðàçáåðåòåñü, êàê ÝÒÎ ðàáîòàåò, Âû ìîæåòå õîðîøî çàðàáîòàòü â òå÷åíèå ñëåäóþùèõ 120 äíåé - äî $100.000 è áîëåå!!!, ýòî çàâèñèò òîëüêî îò Âàñ. ÊÀÆÅÒÑß ÍÅÂÎÇÌÎÆÍÛÌ?? Ïðî÷èòàéòå äàííûé äîêóìåíò è Âû óáåäèòåñü, ÷òî â ýòîì íåò íèêàêîé êàâåðçû èëè îáìàíà. Åñëè Âû ïîëíûé ëåíòÿé - ïðîñèì ïðîùåíèå çà ïðåäëîæåíèå!!!,- òî ýòî íå äëÿ Âàñ!!! Ëó÷øå çàíèìàéòåñü ñåðôèíãîì èëè êëèêàéòå ïî áàííåðàì èëè æå íå çàíèìàéòåñü íè÷åì.

!!!Åñëè ïðåäëîæåíèå Âàñ íè÷åì íå çàèíòåðåñîâàëî, ïðèíîñèì ñâîè èçâèíåíèÿ è íå íàäî ñåðäèòüñÿ. "Ñïàì" èìååò ñâîè èçäåðæêè, òàê æå êàê ðàäèî è TV, íî íå çàáûâàéòå, ÷òî ñêàçàë ïåðâûé ìèëëèàðäåð ÑØÀ Äåéë Êàðíåãè:

"ß ëó÷øå áóäó çàðàáàòûâàòü 1% â ðåçóëüòàòå óñèëèé 100 ÷åëîâåê, ÷åì 100% â ðåçóëüòàòå ñâîèõ ñîáñòâåííûõ óñèëèé."


ÂÑÒÀÍÜÒÅ ÍÀ ÏÓÒÜ Ê ÔÈÍÀÍÑÎÂÎÉ ÍÅÇÀÂÈÑÈÌÎÑÒÈ È ÑÂÎÁÎÄÅ!!!
Äîáðî ïîæàëîâàòü â 6X6!
 
 ýòî òðóäíî ïîâåðèòü, íî, òåì íå ìåíåå, ýòî ñâåðøèâøèéñÿ ôàêò! Ëþäè áîãàòåþò íà ãëàçàõ! Íåêîòîðûå äàæå ìåñÿöû ñïóñòÿ íå ìîãóò îïðàâèòüñÿ îò øîêà, ïðèøåäøåãî âìåñòå ñ êó÷åé õðóñòÿùèõ áàíêíîò! Ïîêà îñòàëüíûå ðàçäóìûâàþò è ñîìíåâàþòñÿ, ïîâåðèâøèå â ÷óäî Áèçíåñ Ñèñòåìû 6Õ6 êóïàþòñÿ â äåíüãàõ!...
 
×èñëî ïîëüçîâàòåëåé "âñåìèðíîé ïàóòèíû" ðàñòåò ñ ìîëíèåíîñíîé áûñòðîòîé. Óæå ñåé÷àñ òîëüêî â Ðîññèè ê ñåòè Èíòåðíåò åæåäíåâíî ïîäêëþ÷àþòñÿ áîëåå 2000 ÷åëîâåê, íà Çàïàäå è â ÑØÀ ýòà öèôðà â íåñêîëüêî ðàç áîëüøå...
 

Copyright © 2001 6x6 MLM Corporation. All rights reserved.
ÄÀÌÛ È ÃÎÑÏÎÄÀ!
 
 


ÏÐÎ×ÒÈÒÅ ÝÒÎ ÂÄÓÌ×ÈÂÎ, ÂÍÈÌÀÒÅËÜÍÎ, ÍÅ ÎÒÂËÅÊÀßÑÜ ÍÀ ÂÍÅØÍÈÅ ØÓÌÛ È ÐÀÇÄÐÀÆÈÒÅËÈ, È ÂÛ ÏÎÉÌÅÒÅ, ×ÒÎ ÑÄÅËÀÅÒ ÂÀÑ ÏÎ-ÍÀÑÒÎßÙÅÌÓ ÁÎÃÀÒÛÌÈ È ÑÂÎÁÎÄÍÛÌÈ ËÞÄÜÌÈ!!!
 

 


 ýòî òðóäíî ïîâåðèòü, íî, òåì íå ìåíåå, ýòî ñâåðøèâøèéñÿ ôàêò! Ëþäè áîãàòåþò íà ãëàçàõ! Íåêîòîðûå äàæå ìåñÿöû ñïóñòÿ íå ìîãóò îïðàâèòüñÿ îò øîêà, ïðèøåäøåãî âìåñòå ñ êó÷åé õðóñòÿùèõ áàíêíîò! Ïîêà îñòàëüíûå ðàçäóìûâàþò è ñîìíåâàþòñÿ, ïîâåðèâøèå â ÷óäî Áèçíåñ Ñèñòåìû 6Õ6 êóïàþòñÿ â äåíüãàõ!  áóêâàëüíîì ñìûñëå ñëîâà! Âû êîãäà-íèáóäü âèäåëè, êàê âûãëÿäèò âîðîõ ñîòåííûõ êóïþð, ïîä êîòîðûì öåëèêîì óìåùàåòñÿ âçðîñëûé ÷åëîâåê?! Ýòî 100 òûñÿ÷ äîëëàðîâ! Ìîæåòå ñåáå ïðåäñòàâèòü, êàê áû âûãëÿäåëà êó÷à èç ìèëëèîíà äîëëàðîâ, êîòîðûå çàðàáàòûâàåò êàæäûé òðåòèé ó÷àñòíèê ñóïåðïðîãðàììû 6Õ6? À êàêîâî îùóùåíèå, êîãäà òû, îñîáî íå óòðóæäàÿ ñåáÿ ðàáîòîé, óæå íà âòîðîé íåäåëå íà÷èíàåøü ïîëó÷àòü êîíâåðòû ñ øåñòüþ äîëëàðàìè, è ÷åì äàëüøå, òåì áîëüøå! À, â êîíöå êîíöîâ, íà 3-ì, íà 4-ì ìåñÿöå òû óæå íå çíàåøü, êóäà îò íèõ äåâàòüñÿ! Äàæå äóõ çàõâàòûâàåò îò ýòîé ëàâèíû äåíåã!
 

ÂÑÅ, ×ÒÎ ÂÀÌ ÍÓÆÍÎ ÁÓÄÅÒ ÄÅËÀÒÜ, ÝÒÎ ÐÀÑÑÛËÀÒÜ ÃÎÒÎÂÛÅ ÏÈÑÜÌÀ ÏÎ E-MAIL È ÂÐÅÌß ÎÒ ÂÐÅÌÅÍÈ ÕÎÄÈÒÜ ÍÀ ÏÎ×ÒÓ ÈËÈ Â ÁÀÍÊ ÇÀ ÄÅÍÜÃÀÌÈ! ÂÀÌ ÄÀÆÅ ÍÅ ÍÀÄÎ ÍÀÏÐßÃÀÒÜ ÑÂÎÉ ÌÎÇà – ÇÀ ÂÀÑ ÂÑÅ ÑÄÅËÀÅÒ ÊÎÌÏÜÞÒÅÐÍÀß ÑÓÏÅÐ ÁÈÇÍÅÑ ÑÈÑÒÅÌÀ 6Õ6!

Ñ ÌÎÌÅÍÒÀ ÂÀØÅÃÎ ÂÑÒÓÏËÅÍÈß Â ÁÈÇÍÅÑ ÏÐÈÁÛËÜ ÍÀÐÀÑÒÀÅÒ, ÊÀÊ ÑÍÅÆÍÛÉ ÊÎÌ, È Ê ÊÎÍÖÓ 4-ÃÎ ÌÅÑßÖÀ ÂÛ ÏÎËÓ×ÈÒÅ ÊÀÊ ÌÈÍÈÌÓÌ 100.000 ÄÎËËÀÐÎÂ. À ÅÑËÈ ÂÛ ÍÅ ÎÑÒÀÍÎÂÈÒÅÑÜ ÍÀ ÄÎÑÒÈÃÍÓÒÎÌ, ÒÎ ÐÅÇÓËÜÒÀÒÎÌ ÁÓÄÓÒ ÀÑÒÐÎÍÎÌÈ×ÅÑÊÈÅ 1.000.000 ÄÎËËÀÐΠÇÀ ÃÎÄ!


“ ×ÅÌ ÑÅÊÐÅÒ ÒÀÊÎÃÎ ÃÎËÎÂÎÊÐÓÆÈÒÅËÜÍÎÃÎ ÓÑÏÅÕÀ?”, – ÑÏÐÎÑÈÒÅ ÂÛ. ÄÅËÎ Â ÒÎÌ, ×ÒÎ Â ÏÐÎÃÐÀÌÌÅ 6Õ6 ÇÀËÎÆÅÍÀ ÍÎÂÀß ÔÎÐÌÓËÀ, ÊÎÒÎÐÀß ÎÁÅÑÏÅ×ÈÂÀÅÒ 100%-ÍÛÉ ÓÑÏÅÕ ÂÑÅÌ Ó×ÀÑÒÍÈÊÀÌ ÁÈÇÍÅÑÀ ÇÀ Ñ×ÅÒ Ó×ÅÒÀ ÒÀÊÈÕ ÓÒÎÍ×ÅÍÍÛÕ ÔÀÊÒÎÐÎÂ, ÊÎÒÎÐÛÅ ×ÅËÎÂÅ×ÅÑÊÈÉ ÌÎÇà ÏÐÎÑÒÎ ÍÅ ÑÏÎÑÎÁÅÍ ÎÕÂÀÒÈÒÜ. ÏÎÝÒÎÌÓ ÏÐÎÃÐÀÌÌÀ ÐÀÁÎÒÀÅÒ! È ÐÀÁÎÒÀÅÒ ÁËÅÑÒßÙÅ! ÝÒÎ – ×ÓÄÎ-ÑÈÑÒÅÌÀ,  ÊÎÒÎÐÎÉ ÓÑÏÅÕ ÁÅÇÓÌÍÎ ÇÀÐÀÇÅÍ! ÑÏÅØÈÒÅ ÇÀÐÀÇÈÒÜÑß È ÂÛ!
 

ÂÍÈÌÀÍÈÅ!!!
 
 


 ËÀÁÎÐÀÒÎÐÈÈ ÑÎÖÈÎËÎÃÈ×ÅÑÊÈÕ ÈÑÑËÅÄÎÂÀÍÈÉ Â ÑØÀ ÁÛË ÏÐÎÂÅÄÅÍ ÝÊÑÏÅÐÈÌÅÍÒ: ÏÐÎÃÐÀÌÌÀ 6Õ6 ÁÛËÀ ÇÀÏÓÙÅÍÀ 16 ÐÀÇ Â ÑÀÌÛÕ ÐÀÇËÈ×ÍÛÕ ÓÑËÎÂÈßÕ È Ñ ÑÀÌÛÌÈ ÐÀÇÍÛÌÈ ËÞÄÜÌÈ Â ÊÀ×ÅÑÒÂÅ Ó×ÀÑÒÍÈÊΠÁÈÇÍÅÑÀ, È ÂÑÅ 16 ÐÀÇ ÎÍÀ ÏÐÈÍÎÑÈËÀ ÎÄÈÍÀÊÎÂÛÉ ÓÑÏÅÕ, È ÍÅ ÁÛËÎ ÍÈ ÎÄÍÎÃÎ ×ÅËÎÂÅÊÀ, ÊÎÒÎÐÛÉ ÁÛ ×ÓÂÑÒÂÎÂÀË ÑÅÁß ÎÁÄÅËÅÍÍÛÌ È ÎÁÈÆÅÍÍÛÌ. ÒÀÊÆÅ ÑÏÅÖÈÀËÈÑÒÛ ÏÐÎÈÇÂÅËÈ ÍÀÓ×ÍÛÉ ÀÍÀËÈÇ ÔÅÍÎÌÅÍÀ 6Õ6 È ÓÑÒÀÍÎÂÈËÈ, ×ÒÎ, ÍÅÑÌÎÒÐß ÍÀ ÂÍÅØÍÅÅ ÑÕÎÄÑÒÂÎ, ÏÎ ÑÂÎÅÉ ÌÈÊÐÎÑÒÐÓÊÒÓÐÅ ÎÍÀ  ÊÎÐÍÅ ÎÒËÈ×ÀÅÒÑß ÎÒ ÑÅÒÅÂÎÃÎ ÌÀÐÊÅÒÈÍÃÀ È ÏÐÈÂÎÄÈÒ Ê ÍÅÑÐÀÂÍÈÌÎ ÁÎËÅÅ ÂÛÑÎÊÈÌ, À ÑÀÌÎÅ ÃËÀÂÍÎÅ – ÄÅÌÎÊÐÀÒÈ×ÍÛÌ ÐÅÇÓËÜÒÀÒÀÌ, Ò.Ê. ÂÑÅ Ó×ÀÑÒÍÈÊÈ ÝÒÎÃÎ ÁÈÇÍÅÑÀ ÈÌÅÞÒ ÄÎÕÎÄ. ÑÐÅÄÈ ÀÌÅÐÈÊÀÍÑÊÈÕ ÁÈÇÍÅÑÌÅÍΠÝÒÀ ÑÓÏÅÐÏÐÎÃÐÀÌÌÀ ÏÐÎÈÇÂÅËÀ ÍÀÑÒÎßÙÈÉ ÔÓÐÎÐ: ÎÍÈ ÏÐÎÇÂÀËÈ ÅÅ “DIAMOND STREAM”, ×ÒÎ ÏÅÐÅÂÎÄÈÒÑß ÊÀÊ “ÀËÌÀÇÍÛÉ ÏÎÒÎÊ”. “ÏÎÒÎÊ” – ÏÎÒÎÌÓ ×ÒÎ ÄÅÍÜÃÈ ÒÅÊÓÒ ÐÅÊÎÉ, À “ÀËÌÀÇÍÛÉ” – ÏÎÒÎÌÓ ×ÒÎ ÝÒÎÒ ÓÑÏÅÕ ÒÀÊÎÉ ÆÅ ÏÐÎ×ÍÛÉ È ÍÅÇÛÁËÅÌÛÉ, ÊÀÊ ÀËÌÀÇ!” – ÎÒÂÅÒÈË ÎÄÈÍ ÈÇ ÁÈÇÍÅÑÌÅÍΠÍÀ ÂÎÏÐÎÑ ÊÎÐÐÅÑÏÎÍÄÅÍÒÀ “NEW-YORK TIMES”.
 

&nbps;


Âû íèêîãäà íå çàäóìûâàëèñü, ïî÷åìó áîëüøèíñòâî ëþäåé íè÷åãî íå äîñòèãàþò â æèçíè, à òîëüêî ñåòóþò? Äà ïîòîìó ÷òî îíè ìàëî íà ÷òî â æèçíè ðåøàþòñÿ. Íà âñå ó íèõ åñòü ãîòîâûå îïðåäåëåíèÿ, ïðè÷åì ñôîðìóëèðîâàííûå íå èìè ñàìèìè, à óñëûøàííûå îò äðóãèõ. Íî èìåòü ñâîå ïðîâåðåííîå ìíåíèå – ýòî áîëüøàÿ ðîñêîøü è ðåäêîñòü. Òå æå, êòî íå áîèòñÿ ïðîáîâàòü è æèâåò áîëüøå äåéñòâèÿìè, ÷åì ñîìíåíèÿìè, î÷åíü áûñòðî îêàçûâàþòñÿ íà âåðøèíå ìèðà! Äà, òðóäíî ïîâåðèòü, ÷òî ìîæíî òàê áûñòðî ðàçáîãàòåòü, òðóäíî ïðåîäîëåòü ñâîè ñîìíåíèÿ, òðóäíî ïðåäñòàâèòü ñåáÿ âäðóã ñêàçî÷íî áîãàòûì. Íî ïîâåðüòå, åñëè Âû ýòî ñäåëàåòå, ýòî ñòàíåò âàøèì áëàãîì è âàøèì ãîëîâîêðóæèòåëüíûì óñïåõîì! Âû âåäü íå áóäåòå ñïîðèòü ñ òåì, ÷òî Âû äîñòîéíû áîëüøîãî óñïåõà è áîëüøîãî áîãàòñòâà? È ïîýòîìó Âàì æèçíåííî íåîáõîäèìî ñäåëàòü ýòîò øàã íà âñòðå÷ó ê ôèíàíñîâîé íåçàâèñèìîñòè, ê êîòîðîé ïðèâåäåò Âàñ ñîòðóäíè÷åñòâî ñ ñóïåðïðîãðàììîé 6Õ6! Ïîòîìó ÷òî âàøå âðåìÿ íàñòàëî!
 

"Ïàðà ñëîâ î ñèñòåìå..." - èíòåðâüþ ñ îñíîâàòåëåì áèçíåñ ñèñòåìû 6Õ6, Òèùåíêîâûì È.À.
 
 


- Ââèäó ñòðåìèòåëüíûõ òåìïîâ ðàçâèòèÿ ñåòè Èíòåðíåò è ýëåêòðîííîé êîììåðöèè ÷èñëî ïîëüçîâàòåëåé "âñåìèðíîé ïàóòèíû" ðàñòåò ñ ìîëíèåíîñíîé áûñòðîòîé. Óæå ñåé÷àñ òîëüêî â Ðîññèè ê ñåòè Èíòåðíåò åæåäíåâíî ïîäêëþ÷àþòñÿ áîëåå 2000 ÷åëîâåê, íà Çàïàäå è â ÑØÀ ýòà öèôðà â íåñêîëüêî ðàç áîëüøå. Ñ ðîñòîì ÷èñëà ïîëüçîâàòåëåé Èíòåðíåò ðàñòåò è êîëè÷åñòâî ðàçëè÷íîãî òèïà áèçíåñ ïðîãðàìì. Ñ êàæäûì äíåì îíè ïîëüçóþòñÿ âñå áîëüøåé ïîïóëÿðíîñòüþ è ýòî åñòåñòâåííî, âåäü ýëåêòðîííàÿ êîììåðöèÿ - áèçíåñ 21 âåêà. Íî áèçíåñ ñèñòåìà 6Õ6 ïðåâîñõîäèò âñå îñòàëüíûå íà íåñêîëüêî ïîðÿäêîâ - îá ýòîì ìîæíî ñóäèòü ãëÿäÿ íà òî êàêîé óñïåõ îíà ïðèíîñèò âñåì åå êîìïàíüîíàì. È âñå æå â ÷åì åå ïðåèìóùåñòâî íàä äðóãèìè áèçíåñ ïðîãðàììàìè àíàëîãè÷íîãî òèïà, ïî÷åìó îíà ïðèíîñèò óñïåõ âñåì åå ó÷àñòíèêàì, à íå òîëüêî åå îñíîâàòåëþ è òåì êòî "ñòîèò ó èñòîêîâ"?

- Äà, Âû ñîâåðøåííî ïðàâû íàñ÷åò ñòðåìèòåëüíîãî ðàçâèòèÿ ýëåêòðîííîé êîììåðöèè è ïîÿâëåíèÿ áîëüøîãî êîëè÷åñòâà áèçíåñ ñèñòåì àíàëîãè÷íûõ 6Õ6.

Ïðåæäå ÷åì ðàçðàáîòàòü ïðîãðàììó 6Õ6 ÿ âíèìàòåëüíî èçó÷èë âñå ñóùåñòâóþùèå íà äàííûé ìîìåíò ñèñòåìû è ïîíÿë êàê îíè ïîÿâèëèñü. Íàâåðíîå âñå ïîìíÿò òå îáëèãàöèè, êîòîðûå áûëè òàê ïîïóëÿðíû ó íàñ â 90-å ãîäû. Òàê âîò ñ ðàçâèòèåì Èíòåðíåò êòî-òî äàëåêèé îò êîìïüþòåðíûõ òåõíîëîãèé è çíàíèé ïðèíöèïà ðàáîòû "âñåìèðíîé ïàóòèíû" ïðîñòî ïåðåíåñ ýòó ïðîãðàììó ñ îáëèãàöèÿìè â ñåòü. Äà, èäåÿ ãåíèàëüíà, îñîáåííî äëÿ òåõ âðåìåí - òàê Âû âðÿä ëè íàéäåòå è 5 êëèåíòîâ, â ñåòè æå ìîæíî ðàññûëàòü òûñÿ÷è ðåêëàìíûõ ïèñåì. Íî ýòà ñèñòåìà èìåëà ìíîæåñòâî íåäîñòàòêîâ: íåäîêóìåíòèðîâàííîñòü òîãî, êàê ðàññûëàòü áîëüøîå êîëè÷åñòâî ðåêëàìû, ãäå áðàòü òûñÿ÷è àäðåñîâ ýëåêòðîííîé ïî÷òû è ò.ä. Ñàìûì ãëàâíûì íåäîñòàòêîì áûëî òî, ÷òî ýòà ïðîãðàììà áûëà ðàññ÷èòàíà íà ñëèøêîì ÷åñòíûõ ëþäåé.  ðåêëàìíîì ïèñüìå ñîäåðæàëàñü ôîðìà, àíàëîãè÷íàÿ íàøåé áèçíåñ-òàáëèöå, ñîãëàñíî êîòîðîé âñòóïàâøèå â ñèñòåìó äîëæíû áûëè ïîêóïàòü òîâàðíûå åäèíèöû ñèñòåìû (êàæäóþ ó ðàçíîãî ó÷àñòíèêà). Êóïèâ èõ îíè äîëæíû áûëè ñòàâèòü ñâîè ðåêâèçèòû íàïðîòèâ ïåðâîé òîâàðíîé åäèíèöû, à âñåõ îñòàëüíûõ ñäâèãàòü íà îäèí óðîâåíü íèæå. Òàê êàê èõ íèêòî íå êîíòðîëèðîâàë â èõ âîëå áûëî èçìåíÿòü òàáëèöó êàê óãîäíî. Îíè îòêðûâàëè íåñêîëüêî àáîíåíòíûõ ÿùèêîâ íà ðàçëè÷íûå èìåíà â ðàçíûõ ïî÷òîâûõ îòäåëåíèÿõ ãîðîäà è ñòàâèëè ðåêâèçèòû ýòèõ ò.í. "ìåðòâûõ äóø" â òàáëèöó âìåñòî ïðåäûäóùèõ ó÷àñòíèêîâ, ò.å. ñèñòåìà îáðûâàëàñü. Èç-çà ýòîãî îíà ðàáîòàëà òîëüêî íà 100% íà ïåðâîì óðîâíå, 1% - íà âòîðîì, 0,1% - íà òðåòüåì è 0% - íà ÷åòâåðòîì. Ïðàêòè÷åñêè çàðàáîòîê øåë òîëüêî ñ ïåðâîãî óðîâíÿ, ò.å. ñ ïðÿìûõ ïðîäàæ, ÷òî ïðè ðàññûëêå 3.000 ðåêëàìíûõ ïèñåì â äåíü ñîñòàâëÿëî îêîëî $300 - $400 â ìåñÿö. Íî ñóòü áèçíåñ ñèñòåì òàêîãî òèïà - ïðèíîñèòü ìàêñèìóì ïðèáûëè çà ñ÷åò 2-õ ïîñëåäíèõ óðîâíåé. Ò.å. Âû ðàññûëàåòå ïàðòèþ ïèñåì ñ ðåêëàìîé, íàïðèìåð, 10.000 øò., ïîëó÷àåòå 30 çàêàçîâ íà òîâàðíóþ åäèíèöó ïåðâîãî óðîâíÿ è äàëüøå â òå÷åíèå íåñêîëüêèõ ëåò ñèñòåìà ðàáîòàåò íà Âàñ. Íî ìíîãèõ óñòðàèâàëè ýòè $300 - $400 â ìåñÿö, è îíè ðàññûëàëè ïî 3.000 ïèñåì â äåíü, îòêðûâ íåñêîëüêî àáîíåíòíûõ ÿùèêîâ è ïîñòàâèâ ñâîè ðåêâèçèòû âåçäå, ãäå òîëüêî ìîæíî. Òàê êàê òîâàðíûå åäèíèöû ïî ñâîåé ñóòè íè÷åãî íå ñîäåðæàëè, êðîìå íàçâàíèÿ â ðåêëàìíîì ïèñüìå, òî ïîëó÷àëîñü, ÷òî ðàáîòàÿ ñ òàêîé ñèñòåìîé Âû, êî âñåìó ïðî÷åìó, åùå è îáìàíûâàëè ñâîèõ êëèåíòîâ.

Íàâåðíîå, íåò ñìûñëà îïèñûâàòü âñå îñòàëüíûå àíàëîãè÷íîãî òèïà áèçíåñ ñèñòåìû - ò.ê. îíè â áóêâàëüíîì ñìûñëå ÿâëÿþòñÿ êîïèÿìè ïðåäûäóùåé. Äà, èìåííî òàê îíè è ïîÿâèëèñü - êîïèðîâàëàñü ñóòü è èçìåíÿëèñü âòîðîñòåïåííûå ôàêòîðû, òàêèå êàê, íàçâàíèÿ òîâàðíûõ åäèíèö, ñïîñîáû îïëàòû, ñîäåðæàíèå ðåêëàìíîãî ïèñüìà è ò.ä. Î íèõ âñåõ ìîæíî ñêàçàòü îäíî: âñå îíè "ñîçäàíû" (åñëè ìîæíî ïðèìåíèòü ýòî ñëîâî ê ÷èñòîé âîäû ïëàãèàòó) íåïðîôåññèîíàëàìè, ëþäüìè äàëåêèìè êàê îò áèçíåñà âîîáùå (÷òî òàêîå ýëåêòðîííàÿ êîììåðöèÿ - îíè è ïîíÿòèÿ íå èìåþò!), òàê è îò êîìïüþòåðíûõ òåõíîëîãèé è ñåòè Èíòåðíåò. Íî ñàìà èäåÿ ñîçäàòü òàêîãî ðîäà áèçíåñ ñèñòåìó - ãåíèàëüíà. Îñîáåííî â íàøå âðåìÿ - âðåìÿ áóðíîãî ðàçâèòèÿ ñåòè Èíòåðíåò è ýëåêòðîííîé êîììåðöèè. È åñëè èñêëþ÷èòü íåäîñòàòêè, òî òàêîé ñèñòåìå öåíû íåò! Âû òîëüêî ïðåäñòàâüòå ñåáå ÷åì áóäåò Èíòåðíåò õîòÿ áû ëåò ÷åðåç ïÿòü!

È ïóñòü çàäà÷à áûëà íåëåãêîé, âñå æå ìíå óäàëîñü ðàçðàáîòàòü èìåííî òàêóþ áèçíåñ ñèñòåìó.

Íåäîêóìåíòèðîâàííîñòü òîãî ãäå è êàê íàõîäèòü àäðåñà ýëåêòðîííîé ïî÷òû, êàê íà íèõ ðàññûëàòü îãðîìíîå êîëè÷åñòâî ðåêëàìíûõ ïèñåì è ïðî÷èå òåõíè÷åñêèå äåòàëè ÿ êîìïåíñèðîâàë ñïåöèàëüíî ðàçðàáîòàííûìè ïðîãðàììàìè äëÿ àâòîìàòèçàöèè ýòîãî ïðîöåññà, ïîçâîëèâøèìè ðàññûëàòü 5-20 òûñÿ÷ ðåêëàìíûõ ïèñåì â äåíü, çàòðàòèâ âñåãî 30-40 ìèíóò ñîáñòâåííîãî âðåìåíè, íàèïîäðîáíåéøèì îïèñàíèåì ðàáîòû ñ íèìè, íàïèñàííûì ÿçûêîì ïîíÿòíûì äëÿ ïîëüçîâàòåëÿ ëþáîãî óðîâíÿ è áîëüøèì êîëè÷åñòâîì ñîâåòîâ è ðåêîìåíäàöèé. ×åì ïî ñóòè óáèë ñðàçó äâóõ çàéöåâ: çíà÷èòåëüíî ïîâûñèë ïðîèçâîäèòåëüíîñòü áèçíåñ ñèñòåìû è ñäåëàë òîâàðíûå åäèíèöû íå òî ÷òî ïîëåçíûìè - ïðîñòî íåîáõîäèìûìè äëÿ ó÷àñòíèêà áèçíåñ ñèñòåìû (âïðî÷åì, êàê è äëÿ ëþáîãî çàíèìàþùåãîñÿ ðåêëàìîé â ñåòè Èíòåðíåò), ò.ê. èìåííî îíè ñîäåðæàò ñïåöèàëüíûå ïðîãðàììû è îïèñàíèå ðàáîòû ñ íèìè.

Íå÷åñòíîñòü ó÷àñòíèêîâ ïðåñåê îáÿçàòåëüíîé ðåãèñòðàöèåé â ãëàâíîé êîíòîðå 6X6 MLM Corporation (ïîäðîáíåå â ðàçäåëå "Çàùèòà îò îáìàíà").

Ò.ê. ñèñòåìà íå îáðûâàåòñÿ, äîáàâèë åùå 2 óðîâíÿ, ò.å. âñåãî â ñèñòåìå 6 óðîâíåé (ïî $6 çà òîâàðíóþ åäèíèöó êàæäîãî óðîâíÿ - îòñþäà è íàçâàíèå "6X6").

Ñäåëàë áîëåå ãèáêîé ñèñòåìó îïëàòû çàêàçîâ. Òåïåðü òîâàðíûå åäèíèöû ìîæíî îïëà÷èâàòü êàê "òðàäèöèîííûì" çàêàçíûì àâèàïèñüìîì, òàê è ïåðåâîäîì íà áàíêîâñêèé ñ÷åò. Íî çàïðåòèë óêàçûâàòü â êà÷åñòâå àäðåñà äëÿ îïëàòû àáîíåíòíûå ÿùèêè - âî-ïåðâûõ, äëÿ èçáåæàíèÿ îáìàíà, âî-âòîðûõ, ÷òîáû áèçíåñ ñèñòåìà íå òåðÿëà ñâîåé ïðèâëåêàòåëüíîñòè. Èñõîäÿ èç òàêèõ æå ñîîáðàæåíèé, çàïðåòèë ñèñòåìó îïëàòû WebMoney.

Çàêëþ÷èë äîãîâîð ñ iWin Loto Ltd. Òàê ÷òî ïðè ðåãèñòðàöèè â íàøåé ãëàâíîé êîíòîðå Âû àâòîìàòè÷åñêè âêëþ÷àåòåñü â ëîòåðåþ, ïðè÷åì Âàøè øàíñû âûèãðàòü ïðÿìî ïðîïîðöèîíàëüíû êîëè÷åñòâó ïðîäàííûõ Chapter#1.
 

Îòçûâû íàøèõ êîìïàíüîíîâ
 
 


Âñåì ïðèâåò! Ñïåøó ïîäåëèòüñÿ ñ Âàìè âïå÷àòëåíèåì îò ïðîãðàììû 6Õ6, ÷òîáû Âû, íå äàé Áîã, íå ïðîøëè ìèìî. Ïèñüìî ïðèøëî íà e-mail ìîåìó ìóæó. Îí ðåøèë ïîâåñåëèòü ìåíÿ è ïîçâàë ïî÷èòàòü, “êàêóþ ëàïøó ñåé÷àñ íà óøè âåøàþò”. ß íå îñîáî âíèêëà â ñèñòåìó, äà îñîáî è íå ñòàðàëàñü ÷òî-òî ïîíÿòü, ïîòîìó ÷òî íå âåðèëà â òàêîãî ðîäà ñïîñîáû çàðàáîòêà, ò.å. íå çàõîòåëà çàðàáîòàòü 100.000 äîëëàðîâ. Íî, ê ìîåìó ñ÷àñòüþ, ýòà öèôðà âñå êðóòèëàñü â ìîåì ìîçãó è íå äàâàëà ñïàòü. È âñå-òàêè, â êîíöå êîíöîâ, ÿ ðåøèëà îòâàæíî áðîñèòüñÿ íà ïèñüìî. Ê ñ÷àñòüþ, ìóæ åãî åùå íå ñòåð. Ê ñâîåìó óäèâëåíèþ, ÷èòàÿ 2-é ðàç, ÿ âñå ïîíèìàëà. À ñàìîå ãëàâíîå, ÷òî ÿ óÿñíèëà, ýòî òî, ÷òî íàïðÿãàòüñÿ-òî ïî÷òè íå íàäî! È âðåìåíè è äåíåæåê ñâîèõ òîæå ïî÷òè òðàòèòü íå íàäî. Ê òîìó æå ìåíÿ, êàê è Âàñ, ïðèâëåêëî òî, ÷òî âñå äåëàåò êîìïüòåð è ÷òî íå íóæíî íè÷åìó ó÷èòüñÿ, ò.ê. àëãîðèòì ðàáîòû ïîäðîáíî îïèñàí â Chapter`àõ!  îáùåì, ðåøèëà ÿ, áûëà – íå áûëà. Ïîïðîáóþ! Çà äâå íåäåëè ÿ ðàçîñëàëà îêîëî 30.000 ïèñåì è ðåøèëà, ÷òî ñ ìåíÿ õâàòèò. ×åðåç íåñêîëüêî äíåé ñòàëè ïðèõîäèòü çàêàçû – ïðèøåë 31 çàêàç íà 1-óþ ÷àñòü è $186 äî êîíöà ìåñÿöà. “Íó, - äóìàþ, - ïîøëî äåëî”.  òå÷åíèå ñëåäóþùèõ äâóõ ìåñÿöåâ ïðèõîäèëè åùå çàêàçû íà 1 ÷àñòü è ïðèøëî îêîëî 5.000 çàêàçîâ íà 2,3,4 è 5 ÷àñòè è $30.000! ÎÃÎ! Ìåñÿö ñïóñòÿ ó ìåíÿ áûëî óæå áîëåå $110.000! Íó, à ïîòîì ñòàëî ñîâñåì êëàññíî – ê íûíåøíåìó ìîìåíòó äåíüãè ïðîäîëæàþò ïðèáûâàòü, à ó ìåíÿ îäíà ïðîáëåìà – êóäà áû èõ äåòü?! ß äóìàþ, ôàíòàçèÿ ó Âàñ ðàáîòàåò, è Âû ìîæåòå ñåáå ïðåäñòàâèòü, ñêîëüêî óäîâîëüñòâèé ìîæíî äîñòàâëÿòü ñåáå, èìåÿ òàêèå äåíüãè!

Âàëåíòèíà, ã. Ìîñêâà.

 


Çäðàâñòâóéòå, óâàæàåìûå ãîñïîäà è äàìû! Íå òàê äàâíî – ïîëãîäà íàçàä ÿ, òàê æå êàê è Âû, ñèäåë è ÷èòàë ïèñüìî, ïðèøåäøåå íà ìîé e-mail. È, êàê áîëüøèíñòâî èç Âàñ, ÿ òåðçàëñÿ ñîìíåíèÿìè. Õîòÿ, åñëè ïîñìîòðåòü òðåçâî – íåïîíÿòíî ïî÷åìó. Âèäíî, òàê ïðèâûê ÷åëîâåê, âñåãî áîÿòüñÿ è ñòðàøèòüñÿ. Äà, âåëèêè áûëè ãëàçà ó ìîåãî ñòðàõà, íî ÿ ðåøèë ïîïðîáîâàòü. Âåäü â ñàìîì óæàñíîì ñëó÷àå ÿ íè÷åãî íå ïîòåðÿþ, êðîìå íåñêîëüêèõ ÷àñîâ âðåìåíè, êîòîðîå è òàê ó ìåíÿ òðàòèòüñÿ áåññìûñëåííî, à òîëüêî óçíàþ ïîáîëüøå î ðàáîòå êîìïüþòåðà è åãî îïòèìèçàöèè. Ê òîìó æå ÿ ïîäóìàë, ÷òî õîòü îäíîãî ÷åëîâåêà ÿ òî÷íî íàéäó, ÷òîáû âåðíóòü ñâîè $6 çà ïåðâóþ ÷àñòü. Íå áóäó óòîìëÿòü Âàñ ïîäðîáíîñòÿìè. ß ïðîñòî ÷åòêî è äîñêîíàëüíî âûïîëíÿë âñå ïðàâèëà áèçíåñ ñèñòåìû 6Õ6. È â òå÷åíèå 4-õ ìåñÿöåâ ÿ çàðàáîòàë 120.000 äîëëàðîâ! È ýòî â ìîè 25 ëåò! Òåïåðü ÿ áóäó êîëëåêöèîíèðîâàòü ïðîèçâåäåíèÿ èñêóññòâà! Îá ýòîì âñåãäà ÿ ìå÷òàë. Íó à ñåé÷àñ ÿ åäó, íå ñìåéòåñü, íà Ìàëüîðêó â ñâàäåáíîå ïóòåøåñòâèå ñ ëþáèìîé, êîòîðàÿ íå óñòîÿëà ïåðåä ìîèì áîãàòñòâîì. Òåïåðü – âñÿ æèçíü âïåðåäè! Êðàñèâàÿ è ñ÷àñòëèâàÿ, â áîãàòñòâå è ðîñêîøè ñ 6Õ6!!!

Àëåêñàíäð, ã. Ñàíêò-Ïåòåðáóðã.

 


 ïåðâûé ðàç ÿ êîíêðåòíî ñòîðìîçèë, óäàëèâ ïèñüìî î ïðîãðàììå 6Õ6. ß åùå ïîñìåÿëñÿ íàä òåì, ÷òî êòî-òî âäðóã ñòàíåò ìíå ñëàòü äåíüãè. È êàê æå ÿ ïðîêëèíàë ñâîþ íåäîâåð÷èâîñòü, êîãäà ïîçâîíèë áðàò èç Íîâîðîññèéñêà è ðàññêàçàë ìíå êàê ðàç îá ýòîì áèçíåñå è î òîì, êàêàÿ ýòî êëàññíàÿ øòóêà! Êàêîé ÿ äóðàê! Âåäü ÿ æå ñàì ìå÷òàë ñòàòü áîãàòûì, êàê æå åùå ÿ ìîãó áûñòðî ðàçáîãàòåòü, åñëè íå ñ ïîìîùüþ âîò òàêîãî áèçíåñà? È êîãäà ÷åðåç ìåñÿö ïèñüìî ñíîâà íàøëî ìåíÿ, ÿ óæå áûë óìíåå. Òóò æå âçÿëñÿ çà äåëî è ðàçîñëàë îêîëî 70 òûñÿ÷ ïèñåì ïî ýëåêòðîííîé ïî÷òå. Îòêëèê áûë ïî÷òè ìãíîâåííûì (åñòü åùå óìíûå ëþäè íà ñâåòå!). À îò Chapter`îâ ñ îïèñàíèåì ÿ âîîáùå îáàëäåë, îñîáåííî îò ïîñëåäíåãî! Ìàëî òîãî ÷òî ÿ ñðàçó ïîíÿë êàê ðàáîòàòü ñ ñèñòåìîé, òåïåðü – ìîé Celeron 300 ðàáîòàåò áûñòðåå, ÷åì Celeron 466 ìîåãî äðóãà! Ýòî óäèâèòåëüíî – òðàòèøü íå áîëüøå ïîëó÷àñà â äåíü íà ðàáîòó ñ 6Õ6 è ïîëó÷àåøü òàêèå äåíüãè!!! Êîðî÷å, äàëüøå âñå ïîøëî êàê ïî ìàñëó. Åæåäíåâíî ïî÷òàëüîí ïðèíîñèë ïî 10 - 15 êîíâåðòîâ, â êàæäîì èç êîòîðûõ ïî $6! Yes-s! Ýòà øòóêà çàðàáîòàëà!!! À ÿ åùå íå âåðèë! Âîò, áëèí, ïåíü! Ïðàâ áûë áðàòåëëà! À ÷òî íà÷àëîñü ïîòîì! Êîãäà ÿ ñòàë ïðîäàâàòü 2 ÷àñòü, êàæäûé äåíü ìíå ïðèíîñèëè ïî 20-30 êîíâåðòîâ ñ êóïþðàìè. Íó, à êîãäà ÿ çàíÿëñÿ 3, 4, 5 è 6 ÷àñòÿìè, ÿ ïðîñòî íå çíàë êóäà îò íèõ äåâàòüñÿ! Íà ïðîøëîé íåäåëå ÿ êóïèë ñåáå íîâûé “Lincoln Navigator”. Êëàññíûé äæèï! Âñåãäà ìå÷òàë î òàêîì!  êàêîì áû äóðíîì íàñòðîåíèè ÿ íè ïðîñíóëñÿ óòðîì, ñòîèò ìíå âñïîìíèòü î ìîåì ñâåðêàþùåì íà ñîëíöå äæèïå, ÿ íà÷èíàþ ÷óâñòâîâàòü ñåáÿ ñàìûì ñ÷àñòëèâûì ÷åëîâåêîì íà Ñâåòå! È âñå – áëàãîäàðÿ ñóïåðïðîãðàììå 6Õ6!!! Ïèøó ýòî ñ íàäåæäîé, ÷òî ìîé óðîê íåâåðèÿ ïîéäåò Âàì íà ïîëüçó, è âû íå ñòàíåòå, êàê ÿ â ïåðâûé ðàç, óäàëÿòü èç ñâîåãî êîìïüþòåðà ýòî ïèñüìî, êîòîðîå èìååò ïðèÿòíîå ñâîéñòâî ïðåâðàùàòüñÿ â íåîãðàíè÷åííîå êîëè÷åñòâî äåíåã! Óäà÷è Âàì!

Èãîðü, ã. Âîëãîãðàä.

 


ß ñðàçó ñåðäöåì îùóòèëà, ÷òî ýòî ìîé øàíñ! Íàêîíåö-òî èñïîëíèòñÿ çàâåòíàÿ ìå÷òà ìîåãî äåòñòâà – ñúåçäèòü â Àìåðèêó! ß ñ óäîâîëüñòâèåì ïðèíÿëàñü ó÷àñòâîâàòü â ïðîãðàììå 6Õ6. Íî ïî íà÷àëó ñîìíåâàëàñü, óäàñòüñÿ ëè ìíå íàéòè òàê ìíîãî àäðåñîâ e-mail. Îäíàêî, êîãäà ïðèøëè Chapter`û ñ îïèñàíèåì, òî âìåñòå ñ íèìè ïðèøëî îáúÿñíåíèå, êàê ëåãêî, áåç âñÿêèõ ïðîáëåì ìîæíî íàéòè ñêîëüêî óãîäíî àäðåñîâ ýëåêòðîííîé ïî÷òû. Çà ìåñÿö ÿ ðàçîñëàëà áîëåå 150.000 ïèñåì, è ýôôåêò íå çàñòàâèë ñåáÿ äîëãî æäàòü – ÿ ïîëó÷èëà 68 çàêàçîâ íà ïåðâóþ ãëàâó!  êîíöå êîíöîâ, ÿ çàðàáîòàëà 170 òûñÿ÷ äîëëàðîâ!!! Òåïåðü ÿ, ïîæàëóé, ïåðåáåðóñü â Àìåðèêó íà ñîâñåì. Ñáûëàñü ìîÿ ãîëóáàÿ ìå÷òà! Ñïàñèáî, äîðîãàÿ 6Õ6! À åùå ñïàñèáî çà óäèâèòåëüíîå îïèñàíèå ðàáîòû ñ ñèñòåìîé. Æåëàþ âñåì Âàì ñòàòü òàêèìè æå ñ÷àñòëèâûìè, êàê è ÿ, áëàãîäàðÿ ñóïåðïðîãðàììå 6Õ6!

Ìàðèíà, ã. Ðèãà.

Æäåì Âàøèõ îòçûâîâ. Ïðèñûëàéòå èõ íà àäðåñ ãëàâíîé êîíòîðû.
×ÒÎ ÆÅ ÒÀÊÎÅ 6Õ6?
 
 


Èòàê, çàðàáàòûâàòü êó÷è äåíåã, íå âûõîäÿ èç äîìà! “Âîò ýòî øàíñ!”, – âîñêëèêíèòå Âû, îñîçíàâ, ÷òî íèêóäà íå íóæíî õîäèòü, íèêîãî íå íóæíî óãîâàðèâàòü, à òîëüêî çíàé ñåáå – ïîñûëàé e-mail`û è ïîëó÷àé ïðèáûëü! “À ÷òî æå äëÿ ýòîãî íóæíî äåëàòü?” – íåèçáåæåí âîïðîñ. Äëÿ òîãî, ÷òîá çàðàáîòàòü êó÷ó äåíåã, à èìåííî – 100.000 äîëëàðîâ è áîëåå, äëÿ íà÷àëà Âàì íóæíî áóäåò çàðåãèñòðèðîâàòüñÿ â ãëàâíîé êîíòîðå 6Õ6 MLM Corporation è ïîëó÷èòü ñâîé ëè÷íûé ðåãèñòðàöèîííûé íîìåð. Âñòóïèâ â 6Õ6, Âû ñòàíîâèòåñü ðàñïðîñòðàíèòåëåì ïî Èíòåðíåòó Chapter`îâ (ãëàâ) ñ íàèïîäðîáíåéøèì îïèñàíèåì ðàáîòû ñ áèçíåñ ñèñòåìîé 6Õ6 è îïòèìèçàöèè êîìïüþòåðà (ïîäðîáíåå î íèõ â ñëåäóþùåì ðàçäåëå). Êëèåíòàìè Âàøåãî áèçíåñà ñòàíîâÿòñÿ ëþäè, êîòîðûõ ýòè ãëàâû çàèíòåðåñóþò. À ãëàâû ïðîñòî íå ìîãóò íå çàèíòåðåñîâàòü - îíè ñîäåðæàò óíèêàëüíóþ èíôîðìàöèþ, ïðîñòî íåîáõîäèìóþ äëÿ ëþáîãî, êòî õî÷åò äîáèòüñÿ óñïåõà â ñåòåâîì ìàðêåòèíãå! Êðîìå òîãî, ëþäåé çàèíòåðåñóåò ñàì áèçíåñ, è âñå ýòî ÿâëÿåòñÿ ãàðàíòèåé òîãî, ÷òî ëþäè íåïðåìåííî áóäóò îòêëèêàòüñÿ íà Âàøå ïèñüìî. ×òî ýòî çà ïèñüìî? Ýòî – òî ñàìîå ïèñüìî, êîòîðîå Âû ïîëó÷èòå ïîñëå ðåãèñòðàöèè â ãëàâíîé êîíòîðå 6Õ6 MLM Corporation (îòëè÷àåòñÿ îò ïèñüìà, êîòîðîå Âû ñåé÷àñ ÷èòàåòå, ïðèñóòñòâèåì Âàøåãî ðåãèñòðàöèîííîãî íîìåðà â áèçíåñ-òàáëèöå). Âû ïðîñòî îòïðàâëÿåòå åãî êàê ìîæíî áîëüøåìó êîëè÷åñòâó ëþäåé. Ïîäðîáíåå î òîì, êàê íàéòè áåñêîíå÷íîå êîëè÷åñòâî e-mail`îâ, àâòîìàòè÷åñêè ðàçîñëàòü íà íèõ ðåêëàìíîå ïèñüìî è ìíîãîå äðóãîå Âû óçíàåòå íåïîñðåäñòâåííî â ñàìèõ ãëàâàõ. Åñëè Âû äóìàåòå: “Îòêóäà âîçüìåòñÿ òàê ìíîãî àäðåñîâ?”, òî ýòî íå ñòîèò òîãî, ÷òîáû áåñïîêîèòüñÿ. Åæåäíåâíî òîëüêî â Ðîññèè ê Èíòåðíåòó ïîäêëþ÷àþòñÿ ìèíèìóì 2000 íîâûõ ïîëüçîâàòåëåé!!! Íà âñåõ õâàòèò! Ïîñëå òîãî êàê Âû îòïðàâèòå çàÿâêó íà ðåãèñòðàöèþ, Âàì ïðèéäåò ïèñüìî, ñîäåðæàùåå:

1) Âàø ðåãèñòðàöèîííûé íîìåð,

2) Ðåêëàìíîå ïèñüìî ñ Âàøèì ðåãèñòðàöèîííûì íîìåðîì â áèçíåñ-òàáëèöå, êîòîðîå Âû áóäåòå ðàññûëàòü,

3) Ðåêâèçèòû îñòàëüíûõ ó÷àñòíèêîâ áèçíåñ ñèñòåìû 6Õ6, ó êîòîðûõ Âàì íåîáõîäèìî çàêàçàòü Chapter`û, êàæäûé ó ðàçíîãî (èñêëþ÷åíèå ñîñòàâëÿåò òîëüêî ìàñòåð) â ñîîòâåòñòâèè ñ ðàñøèôðîâàííîé áèçíåñ-òàáëèöåé, ÷òîáû Âû ñàìè èìåëè âîçìîæíîñòü ïðîäàâàòü èõ ñâîèì çàêàç÷èêàì.

Âìåñòå ñ ýòèì Âû ïîëó÷èòå òàêæå è äàëüíåéøèå óêàçàíèÿ ïðîãðàììû 6Õ6. Íó à òî, ÷òî Âàì íóæíî áóäåò ñäåëàòü ñðàçó ñåé÷àñ, îïèñàíî íèæå â âèäå ÷åòêîãî àëãîðèòìà, ïîýòîìó ïîêà ïðîñòî óëîâèòå ñóòü. Èòàê, Âû îáëàäàåòå âñåìè ãëàâàìè è ðàññûëàåòå ïèñüìî, â êîòîðîì â êà÷åñòâå ðåêëàìû ñîäåðæèòñÿ ïðåäèñëîâèå ê ýòèì óäèâèòåëüíûì ãëàâàì. Ïðî÷èòàâ åãî, ÷åëîâåê, ïîëó÷èâøèé îò Âàñ ïèñüìî, íåïðåìåííî çàõî÷åò âñòóïèòü â áèçíåñ ñèñòåìó 6Õ6 è ïðî÷èòàòü âñå ãëàâû. Íî äàæå åñëè âäðóã îí íå çàõî÷åò ÷èòàòü Chapter`û, îí íàâåðíÿêà çàèíòåðåñóåòñÿ óíèêàëüíîé âîçìîæíîñòüþ çàðàáîòàòü ìèëëèîíû ïðàêòè÷åñêè áåç âñÿêèõ çàòðàò, êàê ïî äåíüãàì, òàê è ïî âðåìåíè! Ñîãëàñèòåñü, îò ýòîãî ïðîñòî íåâîçìîæíî îòêàçàòüñÿ! Ïðèìåðíî ÷åðåç 2 íåäåëè ñî äíÿ íà÷àëà ðàññûëêè Âû ïîëó÷èòå çàêàçû íà ïåðâóþ ãëàâó è ïëàòó çà íåå (â ðàçìåðå 6 äîëëàðîâ ÑØÀ) îò 30-òè ÷åëîâåê è áîëåå. Òàêèì îáðàçîì, Âàø ïåðâûé äîõîä ñîñòàâèò ìèíèìóì – $180. È ýòî – òîëüêî íà÷àëî! Ïðè ðåãèñòðàöèè Âû áóäåòå àâòîìàòè÷åñêè âêëþ÷åíû â ëîòåðåþ îò iWin Loto - îäíîé èç ñàìûõ ïîïóëÿðíûõ íà Çàïàäå è â ÑØÀ êîìïàíèé çàíèìàþùèõñÿ ëîòî-áèçíåñîì, ãëàâíûé ïðèç êîòîðîé - $5.000.000 (òàêæå ðàçûãðûâàåòñÿ 5 ïðèçîâ ïî $1.000.000, 100 ïðèçîâ ïî $100.000 è áîëåå 5 òûñÿ÷ ôèðìåííûõ ôóòáîëîê îò 6Õ6 MLM Corporation, ðîçûãðûøè ïðîâîäÿòñÿ êàæäûé ìåñÿö) – ÷åì áîëüøå Âû ïîëó÷èòå çàêàçîâ íà Chapter#1, òåì áîëüøå øàíñîâ âûèãðàòü ãëàâíûé ïðèç. Âû âèäèòå?!!! Âñå, ÷òî îò Âàñ òðåáóåòñÿ, ýòî ðàçîñëàòü ïîáîëüøå ðåêëàìíûõ ïèñåì. Âñÿ Âàøà ðàáîòà áóäåò çàêëþ÷àòüñÿ òîëüêî â òîì, ÷òîáû âðåìÿ îò âðåìåíè ïðîâåðÿòü ñâîé ïî÷òîâûé ÿùèê èëè õîäèòü â áàíê çà íàëè÷íûìè è äîìà, â òèøèíå ïîäñ÷èòûâàòü âñå íàðàñòàþùóþ ïðèáûëü! Ãàðàíòîì Âàøåãî ãîëîâîêðóæèòåëüíîãî óñïåõà è íàäåæíûì ñîþçíèêîì ñòàíîâèòñÿ ñàìàÿ ãðàíäèîçíàÿ â ìèðå êîìïüþòåðíàÿ ñóïåðïðîãðàììà 6Õ6!!!
 

CHAPTER`Û
 
 


Chapter`û (èëè ãëàâû) – ýòî ïîäðîáíåéøåå îïèñàíèå áèçíåñ ñèñòåìû 6Õ6, ñîâåòû î òîì êàê îïòèìàëüíî ðàáîòàòü ñ ñèñòåìîé è íàñòðîèòü äëÿ ýòîãî ñâîé êîìïüþòåð. Ïðî÷èòàâ èõ Âû ïîéìåòå êàê íå ïðèëàãàÿ îñîáûõ óñèëèé óëó÷øèòü ñâÿçü ñ Èíòåðíåò, íàõîäèòü ïî 5-20 òûñ. e-mail`îâ â äåíü, îáðàáàòûâàòü èõ, ðàññûëàòü ïî 5-20 ðåêëàìíûõ ïèñåì â äåíü, ïîâûñèòü ïðîèçâîäèòåëüíîñòü ñâîåãî êîìïüþòåðà íà 50% è ìíîãîå äðóãîå.

Chapter`û íàïèñàíû ÿçûêîì ïîíÿòíûì äëÿ ïîëüçîâàòåëÿ ëþáîãî óðîâíÿ, ïîýòîìó äëÿ ðàáîòû ñ áèçíåñ ñèñòåìîé 6Õ6 Âàì íå íóæíî áûòü ïðîãðàììèñòîì èëè èìåòü îïûò ðàáîòû ñ êîìïüþòåðîì. Áîëåå òîãî, åñëè Âû òîëüêî â÷åðà ñåëè çà êîìïüþòåð è âîîáùå íå çíàåòå íè÷åãî î ðàáîòå ñ íèì, òî ïðî÷èòàâ âíèìàòåëüíî ãëàâû è ïîðàáîòàâ íåêîòîðîå âðåìÿ ñ áèçíåñ ñèñòåìîé 6Õ6 Âû âñêîðå ñòàíåòå ïðîäâèíóòûì ïîëüçîâàòåëåì, çíàþùèì âñå îá îïåðàöèîííîé ñèñòåìå Windows è Èíòåðíåòå. Êðîìå òîãî ê êàæäîé ãëàâå ïðèëàãàåòñÿ ïðîãðàììà äëÿ ðàáîòû ñ ñèñòåìîé 6Õ6 è íåêîòîðîå êîëè÷åñòâî e-mail`îâ.

Ñïèñîê Chapter`îâ:

Chapter#1 “Ââåäåíèå â áèçíåñ ñèñòåìó 6Õ6. Îïòèìèçàöèÿ èíòåðíåò ñîåäèíåíèÿ. Ðàöèîíàëüíîå èñïîëüçîâàíèå èíòåðíåò âðåìåíè.”

+20.000 e-mail àäðåñîâ
+ïðîãðàììà äëÿ ïîääåðæêè ñòàáèëüíîãî ñîåäèíåíèÿ ñ Èíòåðíåò, àâòîìàòè÷åñêîãî âîññòàíîâëåíèÿ ñâÿçè ïðè åå îáðûâàõ, äîçâîíå/ðàçðûâå ñâÿçè â çàäàííîå âðåìÿ è çàïóñêå äîïîëíèòåëüíûõ ïðîãðàì ïðè íà÷àëå ñîåäèíåíèÿ è ðàçðûâàõ ñâÿçè/ïåðåçâîíàõ, è ïîëíîå îïèñàíèå ðàáîòû ñ ïðîãðàììîé.

Chapter#2 “Êàê íàõîäèòü 5-20 òûñÿ÷ e-mail àäðåñîâ â äåíü, ñèäÿ çà êîìïüþòåðîì 30-40 ìèíóò.”

+10.000 e-mail àäðåñîâ
+ïðîãðàììà äëÿ àâòîìàòè÷åñêîãî âêëþ÷åíèÿ/âûêëþ÷åíèÿ ïðîãðàììû äëÿ ïîèñêà e-mail`îâ ïðè ñîåäèíåíèè/ðàçðûâå ñâÿçè ñ Èíòåðíåò, ïîäðîáíî îïèñàííàÿ â ïðåäûäóùåé ãëàâå.

Chapter#3 “Êàê îáðàáàòûâàòü íàéäåííûå e-mail àäðåñà.”

+10.000 e-mail àäðåñîâ
+ïðîãðàììà äëÿ àâòîìàòè÷åñêîãî ïîèñêà e-mail àäðåñîâ, ïîäðîáíî îïèñàííàÿ â ïðåäûäóùåé ãëàâå.

Chapter#4 “Êàê ðàññûëàòü ïî 5-20 òûñÿ÷ ðåêëàìíûõ ïèñåì â äåíü, ñèäÿ çà êîìïüþòåðîì âñå òå æå 30-40 ìèíóò.”

+10.000 e-mail àäðåñîâ
+ïðîãðàììà äëÿ áûñòðîé îáðàáîòêè e-mail àäðåñîâ, ïîäðîáíî îïèñàííàÿ â ïðåäûäóùåé ãëàâå.

Chapter#5 “Àëãîðèòì ðàáîòû, èëè êàê íàèáîëåå ýôôåêòèâíî èñïîëüçîâàòü áèçíåñ ñèñòåìó 6Õ6.”

+80.000 e-mail àäðåñîâ (!)
+ïðîãðàììà äëÿ àâòîìàòè÷åñêîé ðàññûëêè îãðîìíîãî êîëè÷åñòâà ðåêëàìíûõ ïèñåì ñ âëîæåíèÿìè, ïîäðîáíî îïèñàííàÿ â ïðåäûäóùåé ãëàâå.

Chapter#6 “Îïòèìèçèðóåì Âàø êîìïüþòåð, ïîâûøàåì åãî ïðîèçâîäèòåëüíîñòü íà 50%, èëè êàê çàñòàâèòü Pentium 166 ðàáîòàòü êàê Pentium II-300.”

+100.000 e-mail àäðåñîâ (!)
+Ñåðâåðíàÿ ÷àñòü ïðîãðàììû äëÿ àâòîìàòè÷åñêîé ðàññûëêè îãðîìíîãî êîëè÷åñòâà ðåêëàìíûõ ïèñåì ñ âëîæåíèÿìè, ïîäðîáíî îïèñàííàÿ â 4-îé ãëàâå.

ÏÐÀÂÈËÀ Ó×ÀÑÒÈß Â ÏÐÎÃÐÀÌÌÅ 6Õ6
 
 


Òåðìèíû:

Ìàñòåð – Òèùåíêîâ Èãîðü Àëåêñàíäðîâè÷, îñíîâàòåëü áèçíåñ ñèñòåìû;

ðåôåðåð – ó÷àñòíèê 6Õ6, îò êîòîðîãî Âû ïîëó÷èëè ýòî ïèñüìî è ó êîòîðîãî Âû äîëæíû çàêàçàòü Chapter;

êëèåíò – õîçÿèí e-mail, íà êîòîðûé Âû îòïðàâëÿåòå ïèñüìî;

ðåôåðàë – ó÷àñòíèê 6Õ6, êîòîðûé çàêàçàë ó Âàñ Chapter.

Êàê ðàáîòàåò áèçíåñ ñèñòåìà 6Õ6
 
 


Äëÿ òîãî, ÷òîáû çàðàáàòûâàòü íå òîëüêî ñ ïðÿìûõ ïðîäàæ (ò.å. êîãäà Âû ñàìè ïðîäàåòå Chapter#1 ñâîè ðåôåðàëàì), íî è ñ ïðîäàæ ñâîèõ ðåôåðàëîâ (ò.å. êîãäà Âàøè ðåôåðàëû ïðèâîäÿò Âàì ïîêóïàòåëåé íà Chapter#2 - Chapter#6) áûëà ðàçðàáîòàíà ñëåäóþùàÿ ñèñòåìà – â ðåêëàìíîì ïèñüìå ñîäåðæèòñÿ òàêàÿ òàáëèöà (ò.í. áèçíåñ-òàáëèöà):

Chapter#1...............ðåôåðåð ¹1
Chapter#2...............ðåôåðåð ¹2
Chapter#3...............ðåôåðåð ¹3
Chapter#4...............ðåôåðåð ¹4
Chapter#5...............ðåôåðåð ¹5
Chapter#6...............ðåôåðåð ¹6

Íàïðîòèâ êàæäîãî Chapter`à ñòîÿò ðåêâèçèòû ðàçíûõ ëþäåé, ò.å. Âû áóäåòå ïîêóïàòü Chapter#1 ó ðåôåðåðà ¹1, Chapter#2 ó ðåôåðåðà ¹2, Chapter#3 ó ðåôåðåðà ¹3, Chapter#4 ó ðåôåðåðà ¹4, Chapter#5 ó ðåôåðåðà ¹5, Chapter#6 ó ðåôåðåðà ¹6. Çàðåãèñòðèðîâàâøèñü Âû ïîëó÷èòå ðåêëàìíîå ïèñüìî ñ áèçíåñ-òàáëèöåé, èçìåíåííîé ñëåäóþùèì îáðàçîì:

Chapter#1...............Âû
Chapter#2...............ðåôåðåð ¹1
Chapter#3...............ðåôåðåð ¹2
Chapter#4...............ðåôåðåð ¹3
Chapter#5...............ðåôåðåð ¹4
Chapter#6...............ðåôåðåð ¹5

È íà÷íåòå ðàññûëàòü ðåêëàìíîå ïèñüìî ñ òàêîé áèçíåñ-òàáëèöåé. Ò.å. Âàøè ðåôåðàëû áóäóò ïîêóïàòü ó Âàñ Chapter#1, ó ðåôåðåðà ¹1 – Chapter#2, ó ðåôåðåðà ¹2 – Chapter#3, ó ðåôåðåðà ¹3 – Chapter#4, ó ðåôåðåðà ¹4 – Chapter#5, ó ðåôåðåðà ¹5 – Chapter#6. Âàøè ðåôåðàëû ¹1 (òå, êòî êóïÿò ó Âàñ Chapter#1) ïðè ðåãèñòðàöèè ïîëó÷àò ðåêëàìíîå ïèñüìî ñ àíàëîãè÷íî ïðåîáðàçîâàííîé áèçíåñ-òàáëèöåé:

Chapter#1...............ðåôåðàë ¹1
Chapter#2...............Âû
Chapter#3...............ðåôåðåð ¹1
Chapter#4...............ðåôåðåð ¹2
Chapter#5...............ðåôåðåð ¹3
Chapter#6...............ðåôåðåð ¹4

È íà÷íóò ðàññûëàòü ðåêëàìíîå ïèñüìî ñ òàêîé áèçíåñ-òàáëèöåé. Ò.å. èõ ðåôåðàëû ¹1 (Âàøè ðåôåðàëû ¹2) áóäóò ïîêóïàòü Chapter#1 ó íèõ (Âàøèõ ðåôåðàëîâ ¹1), Chapter#2 – ó Âàñ, Chapter#3 – ó ðåôåðåðà ¹1, Chapter#4 – ó ðåôåðåðà ¹2, Chapter#5 – ó ðåôåðåðà ¹3, Chapter#6 – ó ðåôåðåðà ¹4. È ò.ä...

Ò.å. òàêèì âîò îáðàçîì Âàøè ðåôåðàëû, ïðèâëåêàÿ ñåáå êëèåíòîâ íà Chapter#1 áóäóò îäíîâðåìåííî ïðèâëåêàòü Âàì êëèåíòîâ íà Chapter#2 - Chapter#6. Îòñþäà ñëåäóåò, ÷òî ïðÿìîé çàäà÷åé êàæäîãî ó÷àñòíèêà áèçíåñ ñèñòåìû 6Õ6 ÿâëÿåòñÿ ïðèâëå÷åíèå ïîêóïàòåëåé íà Chapter#1 – ðåôåðàëîâ ¹1.

Òåïåðü äàâàéòå ïðîñòî ïðèêèíåì, ñêîëüêî äåíåã Âû çàðàáîòàåòå åñëè êàæäûé ó÷àñòíèê ïðèâëå÷åò ïî 10 ðåôåðàëîâ ¹1:

Âû...........................10 Õ $6 = $60
Âàøè ðåôåðàëû ¹1...10 X 10 X $6 = $600
Âàøè ðåôåðàëû ¹2...10 X 10 X 10 X $6 = $6.000
Âàøè ðåôåðàëû ¹3...10 X 10 X 10 X 10 X $6 = $60.000
Âàøè ðåôåðàëû ¹4...10 X 10 X 10 X 10 X 10 X $6 = $600.000
Âàøè ðåôåðàëû ¹5...10 X 10 X 10 X 10 X 10 X 10 X $6 = $6.000.0000

Ò.å. âñåãî Âû çàðàáîòàåòå $6.666.660!

Öèôðà íå ìàëàÿ è âîçìîæíî ïîýòîìó ó Âàñ âîçíèêíóò ñîìíåíèÿ. - Âíèêíèòå â ðàññ÷åòû è â ñóòü ðàáîòû ñèñòåìû, ïðîñ÷èòàéòå âñå ñàìè è Âû ïîëó÷èòå òîò æå ðåçóëüòàò!

Çàùèòà îò îáìàíà
 
 


Äëÿ òîãî, ÷òîáû èñêëþ÷èòü îáðûâàåìîñòü ñèñòåìû áûëà ðàçðàáîòàíà ñëåäóþùàÿ çàùèòà:

 ðåêëàìíîå ïèñüìî ïîìåùàåòñÿ òàêàÿ áèçíåñ-òàáëèöà:

Chapter#1...............ðåãèñòð. íîìåð ðåôåðåðà ¹1
Chapter#2...............ðåãèñòð. íîìåð ðåôåðåðà ¹2
Chapter#3...............ðåãèñòð. íîìåð ðåôåðåðà ¹3
Chapter#4...............ðåãèñòð. íîìåð ðåôåðåðà ¹4
Chapter#5...............ðåãèñòð. íîìåð ðåôåðåðà ¹5
Chapter#6...............ðåãèñòð. íîìåð ðåôåðåðà ¹6

Ò.å. êëèåíò ê êîòîðîìó ïðèøëî ýòî ðåêëàìíîå ïèñüìî çíàåò òîëüêî ðåãèñòðàöèîííûå íîìåðà ðåôåðåðîâ ó êîòîðûõ îí äîëæåí êóïèòü Chapter`û. Êóïèòü âñå Chapter`û ó íèõ íàïðÿìóþ â äàííûé ìîìåíò îí íå ìîæåò òàê êàê íå çíàåò èõ ðåêâèçèòîâ.

Äàëåå îí ðåãèñòðèðóåòñÿ â ãëàâíîé êîíòîðå 6Õ6 MLM Corporation è ïîëó÷àåò:

1) Câîé ðåãèñòðàöèîííûé íîìåð.

2) Àäðåñà âñåõ ðåôåðåðîâ, ó êîòîðûõ äîëæåí êóïèòü Chapter#1 - Chapter#6.

3) Ðåêëàìíîå ïèñüìî äëÿ ðàññûëêè ñ èçìåíåííîé áèçíåñ-òàáëèöåé ñëåäóþùåãî âèäà:

Chapter#1...............ðåãèñòð. íîìåð äàííîãî êëèåíòà
Chapter#2...............ðåãèñòð. íîìåð ðåôåðåðà ¹1
Chapter#3...............ðåãèñòð. íîìåð ðåôåðåðà ¹2
Chapter#4...............ðåãèñòð. íîìåð ðåôåðåðà ¹3
Chapter#5...............ðåãèñòð. íîìåð ðåôåðåðà ¹4
Chapter#6...............ðåãèñòð. íîìåð ðåôåðåðà ¹5

ïîêóïàåò âñå Chapter`û è íà÷èíàåò ðàññûëêó.

Áëàãîäàðÿ ýòîé çàùèòå, îí ïðîñòî íå ìîæåò îáîðâàòü öåïü è îñòàâèòü ñâîèõ ðåôåðåðîâ áåç ïðè÷èòàþùåéñÿ èì ïðèáûëè. Âåäü öåïü ìîæåò îáîðâàòüñÿ òîëüêî òîãäà, êîãäà èõ ðåêâèçèòîâ íå áóäåò â áèçíåñ-òàáëèöå. ×òî âîçìîæíî, òîëüêî åñëè îí çàìåíèò ðåêâèçèòû âñåõ ïÿòè ðåôåðåðîâ ñâîèìè ðåêâèçèòàìè. ×åãî îí ñäåëàòü ïðîñòî íå ìîæåò, ò.ê. äëÿ ýòîãî åìó ïðèäåòñÿ çàðåãèñòðèðîâàòüñÿ åùå ïÿòü ðàç, òîãäà êàê ðåãèñòðèðîâàòüñÿ ìîæíî òîëüêî îäèí ðàç.
 

ÂÛ ÃÎÒÎÂÛ ÍÀ×ÀÒÜ ÁÈÇÍÅÑ Ñ 6Õ6?!
ÈÒÀÊ, ÏÐÈÑÒÓÏÀÅÌ!
 
 


Âíèìàíèå! Â ñâÿçè ñ îãðîìíûì ïðèòîêîì ðåôåðàëîâ ñ 1/IX-2000 ðåãèñòðàöèÿ ñòàëà ïëàòíîé è ñòîèò 5 äîëëàðîâ ÑØÀ.

×ÒÎ ÂÀÌ ÍÅÎÁÕÎÄÈÌÎ ÑÄÅËÀÒÜ:

à) Çàðåãèñòðèðóéòåñü â ãëàâíîé êîíòîðå 6Õ6 MLM Corporation:

1) Íàïèøèòå íà ëèñòå áóìàãè (àíãëèéñêèìè áóêâàìè):

1) Âàøè Ô.È.Î.,
2) Ïî÷òîâûé àäðåñ äëÿ îïëàòû,
3) Áàíêîâñêèå ðåêâèçèòû äëÿ îïëàòû (íåîáÿçàòåëüíî),
4) Âàø e-mail - ïèøèòå ðàçáîð÷èâî è â äàëüíåéøåì èñïîëüçóéòå åãî òîëüêî äëÿ ñâÿçè ñ ãëàâíîé êîíòîðîé 6Õ6,
5) Íàõîäÿùóþñÿ íèæå áèçíåñ-òàáëèöó â ðåãèñòðàöèîííî-íîìåðíîì âèäå,
6) Äàòó îòïðàâëåíèÿ ïèñüìà.

2) Âëîæèòå â íåãî $5 è îòïðàâüòå ïî ïî÷òå çàêàçíûì àâèàïèñüìîì íà àäðåñ ãëàâíîé êîíòîðû 6x6 MLM Corporation:

Igor Tichtchenkov, Laanemere 20-96, 13913 Tallinn, Estonia.

3)  òå÷åíèå íåäåëè Âàì ïðèéäåò (íà e-mail, êîòîðûé Âû óêàçàëè â ðåãèñòðàöèîííîé ôîðìå) ïèñüìî, ñîäåðæàùåå:

1) Âàø ðåãèñòðàöèîííûé íîìåð.
2) Àäðåñà âñåõ ðåôåðåðîâ, ó êîòîðûõ Âû äîëæíû êóïèòü Chapter`û.
3) Ðåêëàìíîå ïèñüìî ñ èçìåíåííîé áèçíåñ-òàáëèöåé, ñîäåðæàùåé Âàø ðåãèñòðàöèîííûé íîìåð, êîòîðîå Âû áóäåòå ðàññûëàòü.
4) Íåîáõîäèìûå äëÿ íà÷àëà ðàáîòû èíñòðóêöèè.

á) Ñðàçó êóïèòå Chapter`û â ñîîòâåòñòâèè ñ áèçíåñ-òàáëèöåé:

Ãëàâà ¹
Ðåã. ¹ Ðåôåðåðà
Chapter#1
6x6-000002-z-115
Chapter#2
6x6-000000-z-001
Chapter#3
Master 6x6
Chapter#4
Master 6x6
Chapter#5
Master 6x6
Chapter#6
Master 6x6

ÏÐÈÌÅ×ÀÍÈÅ! Åñëè â áèçíåñ-òàáëèöå íåñêîëüêî èëè äàæå âñå ðåãèòðàöèîííûå íîìåðà - Master 6x6, òî íèêàêîé îøèáêè â ýòîì íåò, ïðîñòî Âàì ïîâåçëî ò.ê. ïðèñîåäèíèâøèñü Âû áóäåòå â ñàìîì íà÷àëå áèçíåñ ñèñòåìû - ò.å. Âàøè øàíñû íà óñïåõ ìàêñèìàëüíû.

Êàê òîëüêî Âû ýòî ñäåëàåòå ñðàçó íà÷èíàéòå ðàññûëêó. Ïîäðîáíåå îá ýòîì Âû óçíàåòå íåïîñðåäñòâåííî èç Chapter`îâ. Âñåãî Âàì æåëàòåëüíî ïðèâëå÷ü îêîëî 30 ðåôåðàëîâ ¹1 - ò.å. ïðîäàòü 30 Chapter#1. Õîòÿ ÷åì áîëüøå Âû èõ ïðèâëå÷åòå, òåì áîëüøå ïðèáûëè ïîëó÷èòå.

Ïîñòàðàéòåñü ðàññûëàòü íå ìåíåå 3.000 ðåêëàìíûõ ïèñåì â äåíü (ñî ñïåöèàëüíûìè ïðîãðàììàìè, êîòîðûå Âû ïîëó÷èòå âìåñòå ñ Chapter`àìè, íå ñîñòàâèò òðóäà ðàññûëàòü è ïî 20.000 ïèñåì â äåíü). Åñëè ìîæåòå áîëüøå, ðàññûëàéòå áîëüøå (ïîäðîáíåå â Chapter#5).

Î äàëüíåéøèõ øàãàõ Âû óçíàåòå â Chapter`àõ. Âåñü ïðîöåññ ðàñòÿãèâàåòñÿ ïðèìåðíî íà 4 ìåñÿöà ñî äíÿ íà÷àëà áèçíåñà. Åñëè Âû áóäåòå ÷åòêî ñëåäîâàòü âñåì ïðàâèëàì, òî âíå âñÿêèõ ñîìíåíèé áóäåòå îáëàäàòåëåì íåñêîëüêèõ ñîòåí òûñÿ÷ äîëëàðîâ! Ìû çíàåì, ÷òî ýòî áóäåò èìåííî òàê, è íàì îñòàåòñÿ òîëüêî ïîçäðàâèòü Âàñ!

À òåïåðü çà äåëî!

Æåëàåì Âàì îãðîìíûõ óñïåõîâ!!!

 
 

Copyright © 2001 6x6 MLM Corporation. All rights reserved.
From noreply@sourceforge.net Sat Jul 7 23:32:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Jul 2001 15:32:11 -0700 Subject: [Patches] [ python-Patches-439364 ] GC for frames and generators Message-ID: Patches item #439364, was opened at 2001-07-07 15:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439364&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Tim Peters (tim_one) Summary: GC for frames and generators Initial Comment: For me, test_generators leaks, with or without this patch. The number of objects tracked by the GC does not increase but memory usage does. There must be other objects creating cycles that are not tracked by the GC. I haven't profiled the effect this change. I have another patch in the works that should minimize the performance hit. Please examine frame_traverse and frame_clear closely. I'm not 100% sure that I am chasing all the references necessary to find cycles or that I am dropping enough to break them. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439364&group_id=5470 From noreply@sourceforge.net Mon Jul 9 05:40:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Jul 2001 21:40:01 -0700 Subject: [Patches] [ python-Patches-439364 ] GC for frames and generators Message-ID: Patches item #439364, was opened at 2001-07-07 15:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439364&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Tim Peters (tim_one) Summary: GC for frames and generators Initial Comment: For me, test_generators leaks, with or without this patch. The number of objects tracked by the GC does not increase but memory usage does. There must be other objects creating cycles that are not tracked by the GC. I haven't profiled the effect this change. I have another patch in the works that should minimize the performance hit. Please examine frame_traverse and frame_clear closely. I'm not 100% sure that I am chasing all the references necessary to find cycles or that I am dropping enough to break them. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-08 21:40 Message: Logged In: YES user_id=31435 Thanks, Neil! I've been too overwhelmed with merging descr- branch code to look at this until now. Clarification, please: when you say "test_generators leaks, with or without this patch", what exactly do you mean by "leak"? It does not leak for me before the patch (haven't yet tried it with the patch), and this is what I mean-- exactly -- by "does not leak": I change a stock CVS build by changing "if 0:" to "if 1:" in test_generators.py's test_main, then let it run and run and run. Now on Win98SE, the heap space *does* grow very slowly and steadily, until it reaches about 3600Kb. Sometimes a little more, sometimes a little less, depending on what else I'm doing at the time. It takes about 5 minutes of CPU time on a 866MHz box to reach that. But then it *stays* at this point forever after (well, after another 10 minutes of CPU time it hasn't budged -- Win98SE probably can't run forever ). This is presumably because Win98SE malloc is lazy about coalescing free()'d memory until it nears a 4Mb boundary (at which point it starts rearranging VM address space-- because 4Mb is all the address space the system allocates to the initial heap --and it's very reluctant to do that). So if you're seeing a very slow "leak" (are you?), you *may* just be seeing a platform malloc reluctant to defragment free()'d memory. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439364&group_id=5470 From noreply@sourceforge.net Mon Jul 9 15:11:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Jul 2001 07:11:45 -0700 Subject: [Patches] [ python-Patches-439364 ] GC for frames and generators Message-ID: Patches item #439364, was opened at 2001-07-07 15:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439364&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Tim Peters (tim_one) Summary: GC for frames and generators Initial Comment: For me, test_generators leaks, with or without this patch. The number of objects tracked by the GC does not increase but memory usage does. There must be other objects creating cycles that are not tracked by the GC. I haven't profiled the effect this change. I have another patch in the works that should minimize the performance hit. Please examine frame_traverse and frame_clear closely. I'm not 100% sure that I am chasing all the references necessary to find cycles or that I am dropping enough to break them. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-07-09 07:11 Message: Logged In: YES user_id=35752 Your right, it doesn't leak before the patch. The process size goes up slowly be eventually stops increasing. After the patch the size continues going up slowly. :-( I'll try to find what is still leaking. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-08 21:40 Message: Logged In: YES user_id=31435 Thanks, Neil! I've been too overwhelmed with merging descr- branch code to look at this until now. Clarification, please: when you say "test_generators leaks, with or without this patch", what exactly do you mean by "leak"? It does not leak for me before the patch (haven't yet tried it with the patch), and this is what I mean-- exactly -- by "does not leak": I change a stock CVS build by changing "if 0:" to "if 1:" in test_generators.py's test_main, then let it run and run and run. Now on Win98SE, the heap space *does* grow very slowly and steadily, until it reaches about 3600Kb. Sometimes a little more, sometimes a little less, depending on what else I'm doing at the time. It takes about 5 minutes of CPU time on a 866MHz box to reach that. But then it *stays* at this point forever after (well, after another 10 minutes of CPU time it hasn't budged -- Win98SE probably can't run forever ). This is presumably because Win98SE malloc is lazy about coalescing free()'d memory until it nears a 4Mb boundary (at which point it starts rearranging VM address space-- because 4Mb is all the address space the system allocates to the initial heap --and it's very reluctant to do that). So if you're seeing a very slow "leak" (are you?), you *may* just be seeing a platform malloc reluctant to defragment free()'d memory. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439364&group_id=5470 From mosrassil@yahoo.com Mon Jul 9 15:50:02 2001 From: mosrassil@yahoo.com (mosrassil@yahoo.com) Date: Ïí, 9 èþë 2001 20:11:47 Subject: [Patches] Ðàññûëêà ïî 100.000 Ìîñêîâñêèõ å-ìàéëîâ Message-ID: Ðàññûëêà Âàøåé ðåêëàìû ïî 100.000 Ìîñêîâñêèõ å-ìàéëîâ. Ýôôåêòèâíî. Ïðîôåññèîíàëüíûé ïîäõîä. Öåíà: 100 äîëë. From noreply@sourceforge.net Mon Jul 9 21:48:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Jul 2001 13:48:21 -0700 Subject: [Patches] [ python-Patches-439364 ] GC for frames and generators Message-ID: Patches item #439364, was opened at 2001-07-07 15:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439364&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Tim Peters (tim_one) Summary: GC for frames and generators Initial Comment: For me, test_generators leaks, with or without this patch. The number of objects tracked by the GC does not increase but memory usage does. There must be other objects creating cycles that are not tracked by the GC. I haven't profiled the effect this change. I have another patch in the works that should minimize the performance hit. Please examine frame_traverse and frame_clear closely. I'm not 100% sure that I am chasing all the references necessary to find cycles or that I am dropping enough to break them. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-09 13:48 Message: Logged In: YES user_id=31435 + Performance hit is about a 2.5% slowdown. More than I hoped, but less than I feared . + The leak after the patch is solely due to fun_tests. Comment out the other lines in the __test__ dict, and on my box it leaks about half a megabyte per second then -- very dramatic, and impossible to ascribe to anything but a leak. + I don't know what causes the leak. Offhand my first guess would be unchased pointers inside traceback objects. Indeed, the first thing I'd *try* is adding tracebackobject to GC too just to see whether that made the leak go away (much easier than thinking about it <0.9 wink>). ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-07-09 07:11 Message: Logged In: YES user_id=35752 Your right, it doesn't leak before the patch. The process size goes up slowly be eventually stops increasing. After the patch the size continues going up slowly. :-( I'll try to find what is still leaking. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-08 21:40 Message: Logged In: YES user_id=31435 Thanks, Neil! I've been too overwhelmed with merging descr- branch code to look at this until now. Clarification, please: when you say "test_generators leaks, with or without this patch", what exactly do you mean by "leak"? It does not leak for me before the patch (haven't yet tried it with the patch), and this is what I mean-- exactly -- by "does not leak": I change a stock CVS build by changing "if 0:" to "if 1:" in test_generators.py's test_main, then let it run and run and run. Now on Win98SE, the heap space *does* grow very slowly and steadily, until it reaches about 3600Kb. Sometimes a little more, sometimes a little less, depending on what else I'm doing at the time. It takes about 5 minutes of CPU time on a 866MHz box to reach that. But then it *stays* at this point forever after (well, after another 10 minutes of CPU time it hasn't budged -- Win98SE probably can't run forever ). This is presumably because Win98SE malloc is lazy about coalescing free()'d memory until it nears a 4Mb boundary (at which point it starts rearranging VM address space-- because 4Mb is all the address space the system allocates to the initial heap --and it's very reluctant to do that). So if you're seeing a very slow "leak" (are you?), you *may* just be seeing a platform malloc reluctant to defragment free()'d memory. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439364&group_id=5470 From noreply@sourceforge.net Mon Jul 9 22:08:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Jul 2001 14:08:22 -0700 Subject: [Patches] [ python-Patches-439364 ] GC for frames and generators Message-ID: Patches item #439364, was opened at 2001-07-07 15:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439364&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Tim Peters (tim_one) Summary: GC for frames and generators Initial Comment: For me, test_generators leaks, with or without this patch. The number of objects tracked by the GC does not increase but memory usage does. There must be other objects creating cycles that are not tracked by the GC. I haven't profiled the effect this change. I have another patch in the works that should minimize the performance hit. Please examine frame_traverse and frame_clear closely. I'm not 100% sure that I am chasing all the references necessary to find cycles or that I am dropping enough to break them. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-09 14:08 Message: Logged In: YES user_id=31435 The attached fibleak.py is a self-contained massive leaker. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-09 13:48 Message: Logged In: YES user_id=31435 + Performance hit is about a 2.5% slowdown. More than I hoped, but less than I feared . + The leak after the patch is solely due to fun_tests. Comment out the other lines in the __test__ dict, and on my box it leaks about half a megabyte per second then -- very dramatic, and impossible to ascribe to anything but a leak. + I don't know what causes the leak. Offhand my first guess would be unchased pointers inside traceback objects. Indeed, the first thing I'd *try* is adding tracebackobject to GC too just to see whether that made the leak go away (much easier than thinking about it <0.9 wink>). ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-07-09 07:11 Message: Logged In: YES user_id=35752 Your right, it doesn't leak before the patch. The process size goes up slowly be eventually stops increasing. After the patch the size continues going up slowly. :-( I'll try to find what is still leaking. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-08 21:40 Message: Logged In: YES user_id=31435 Thanks, Neil! I've been too overwhelmed with merging descr- branch code to look at this until now. Clarification, please: when you say "test_generators leaks, with or without this patch", what exactly do you mean by "leak"? It does not leak for me before the patch (haven't yet tried it with the patch), and this is what I mean-- exactly -- by "does not leak": I change a stock CVS build by changing "if 0:" to "if 1:" in test_generators.py's test_main, then let it run and run and run. Now on Win98SE, the heap space *does* grow very slowly and steadily, until it reaches about 3600Kb. Sometimes a little more, sometimes a little less, depending on what else I'm doing at the time. It takes about 5 minutes of CPU time on a 866MHz box to reach that. But then it *stays* at this point forever after (well, after another 10 minutes of CPU time it hasn't budged -- Win98SE probably can't run forever ). This is presumably because Win98SE malloc is lazy about coalescing free()'d memory until it nears a 4Mb boundary (at which point it starts rearranging VM address space-- because 4Mb is all the address space the system allocates to the initial heap --and it's very reluctant to do that). So if you're seeing a very slow "leak" (are you?), you *may* just be seeing a platform malloc reluctant to defragment free()'d memory. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439364&group_id=5470 From noreply@sourceforge.net Mon Jul 9 22:12:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Jul 2001 14:12:03 -0700 Subject: [Patches] [ python-Patches-439848 ] Generic AIX C++ Module Support Message-ID: Patches item #439848, was opened at 2001-07-09 14:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439848&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Generic AIX C++ Module Support Initial Comment: The current support for C++ modules on AIX is out of date and incompatible with more recent compiler versions. Depending on which compiler is being used, the "load.h" include could be in any of at least three places, which may or may not be in the include path. Since only a single prototype is required, it is identical in all versions, and isn't likely to change, the simplest way to deal with the issue is to simply include the one prototype in the configuration and the dynload module. Also, the symbol is always going to live in /usr/lib/libC.a, so a simple -lC is sufficient to pull it in. I've tested it with C Set++ 3.1.4 on AIX 4.2.1 and VACPP 5.0 on AIX 4.3.3 (the two extremes, more or less) and it works fine. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439848&group_id=5470 From noreply@sourceforge.net Mon Jul 9 22:18:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Jul 2001 14:18:28 -0700 Subject: [Patches] [ python-Patches-439848 ] Generic AIX C++ Module Support Message-ID: Patches item #439848, was opened at 2001-07-09 14:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439848&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Generic AIX C++ Module Support Initial Comment: The current support for C++ modules on AIX is out of date and incompatible with more recent compiler versions. Depending on which compiler is being used, the "load.h" include could be in any of at least three places, which may or may not be in the include path. Since only a single prototype is required, it is identical in all versions, and isn't likely to change, the simplest way to deal with the issue is to simply include the one prototype in the configuration and the dynload module. Also, the symbol is always going to live in /usr/lib/libC.a, so a simple -lC is sufficient to pull it in. I've tested it with C Set++ 3.1.4 on AIX 4.2.1 and VACPP 5.0 on AIX 4.3.3 (the two extremes, more or less) and it works fine. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-09 14:18 Message: Logged In: NO One more thing. This supports xlC-compiled modules; g++ modules are another issue entirely. We have something that works for both xlC and g++ based on the AIX loader from Apache, but g++ requires its own set of fixes for things to work properly, so the xlC-only fix seems more practical until the AIX g++ problems are ironed out. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439848&group_id=5470 From noreply@sourceforge.net Mon Jul 9 22:21:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Jul 2001 14:21:58 -0700 Subject: [Patches] [ python-Patches-439848 ] Generic AIX C++ Module Support Message-ID: Patches item #439848, was opened at 2001-07-09 14:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439848&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Generic AIX C++ Module Support Initial Comment: The current support for C++ modules on AIX is out of date and incompatible with more recent compiler versions. Depending on which compiler is being used, the "load.h" include could be in any of at least three places, which may or may not be in the include path. Since only a single prototype is required, it is identical in all versions, and isn't likely to change, the simplest way to deal with the issue is to simply include the one prototype in the configuration and the dynload module. Also, the symbol is always going to live in /usr/lib/libC.a, so a simple -lC is sufficient to pull it in. I've tested it with C Set++ 3.1.4 on AIX 4.2.1 and VACPP 5.0 on AIX 4.3.3 (the two extremes, more or less) and it works fine. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-09 14:21 Message: Logged In: NO It seems the patch didn't attach. It is pretty straightforward, though, so I'll paste it here: Index: dist/src/configure.in =================================================================== RCS file: /cvsroot/python/python/dist/src/configure.in,v retrieving revision 1.223 diff -c -r1.223 configure.in *** dist/src/configure.in 2001/06/27 20:22:04 1.223 --- dist/src/configure.in 2001/07/09 20:58:17 *************** *** 874,884 **** # checks for system dependent C++ extensions support case "$ac_sys_system" in AIX*) AC_MSG_CHECKING(for genuine AIX C++ extensions support) ! AC_TRY_LINK([#include "/usr/lpp/xlC/include/load.h"], [loadAndInit("", 0, "")], [AC_DEFINE(AIX_GENUINE_CPLUSPLUS) AC_MSG_RESULT(yes)], ! [AC_MSG_RESULT(no)]);; *) ;; esac --- 874,887 ---- # checks for system dependent C++ extensions support case "$ac_sys_system" in AIX*) AC_MSG_CHECKING(for genuine AIX C++ extensions support) ! LIBS_SAVE=$LIBS ! LIBS="$LIBS -lC" ! AC_TRY_LINK([int (*loadAndInit(char *name, int flags, char *path))();], [loadAndInit("", 0, "")], [AC_DEFINE(AIX_GENUINE_CPLUSPLUS) AC_MSG_RESULT(yes)], ! [LIBS=$LIBS_SAVE ! AC_MSG_RESULT(no)]);; *) ;; esac Index: dist/src/Python/dynload_aix.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/dynload_aix.c,v retrieving revision 2.10 diff -c -r2.10 dynload_aix.c *** dist/src/Python/dynload_aix.c 2000/09/04 00:54:56 2.10 --- dist/src/Python/dynload_aix.c 2001/07/09 20:58:17 *************** *** 12,18 **** #ifdef AIX_GENUINE_CPLUSPLUS ! #include "/usr/lpp/xlC/include/load.h" #define aix_load loadAndInit #else #define aix_load load --- 12,18 ---- #ifdef AIX_GENUINE_CPLUSPLUS ! int (*loadAndInit(char *name, int flags, char *path))(); #define aix_load loadAndInit #else #define aix_load load ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-09 14:18 Message: Logged In: NO One more thing. This supports xlC-compiled modules; g++ modules are another issue entirely. We have something that works for both xlC and g++ based on the AIX loader from Apache, but g++ requires its own set of fixes for things to work properly, so the xlC-only fix seems more practical until the AIX g++ problems are ironed out. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439848&group_id=5470 From noreply@sourceforge.net Tue Jul 10 05:34:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Jul 2001 21:34:43 -0700 Subject: [Patches] [ python-Patches-439364 ] GC for frames and generators Message-ID: Patches item #439364, was opened at 2001-07-07 15:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439364&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Neil Schemenauer (nascheme) Summary: GC for frames and generators Initial Comment: For me, test_generators leaks, with or without this patch. The number of objects tracked by the GC does not increase but memory usage does. There must be other objects creating cycles that are not tracked by the GC. I haven't profiled the effect this change. I have another patch in the works that should minimize the performance hit. Please examine frame_traverse and frame_clear closely. I'm not 100% sure that I am chasing all the references necessary to find cycles or that I am dropping enough to break them. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-09 21:34 Message: Logged In: YES user_id=31435 I expect what's going on here is the obvious thing: clearing the LazyList dict stops the leak, but the dict only holds two things: a vanilla list of integers, and a bound method object. Since a list of ints can't cause a cycle, it must be the latter; and, indeed, a quick glance at methodobject.c shows GC doesn't chase PyCFunction_Type (yet). The bound method object in this case wraps the .next() method of a generator-iterator object, and there's a cycle: the LazyList fib maps fib.fetch to the fibgen() generator-iterator's .next method, from which we can get to the fibgen g-i, which in turn contains (indirect) references back to fib thanks to passing iter(fib) to the sum() and head() generators. Looks like breaking this by magic requires adding both seqiterobjects and PyCFunctionObjects to GC. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-09 14:08 Message: Logged In: YES user_id=31435 The attached fibleak.py is a self-contained massive leaker. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-09 13:48 Message: Logged In: YES user_id=31435 + Performance hit is about a 2.5% slowdown. More than I hoped, but less than I feared . + The leak after the patch is solely due to fun_tests. Comment out the other lines in the __test__ dict, and on my box it leaks about half a megabyte per second then -- very dramatic, and impossible to ascribe to anything but a leak. + I don't know what causes the leak. Offhand my first guess would be unchased pointers inside traceback objects. Indeed, the first thing I'd *try* is adding tracebackobject to GC too just to see whether that made the leak go away (much easier than thinking about it <0.9 wink>). ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-07-09 07:11 Message: Logged In: YES user_id=35752 Your right, it doesn't leak before the patch. The process size goes up slowly be eventually stops increasing. After the patch the size continues going up slowly. :-( I'll try to find what is still leaking. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-08 21:40 Message: Logged In: YES user_id=31435 Thanks, Neil! I've been too overwhelmed with merging descr- branch code to look at this until now. Clarification, please: when you say "test_generators leaks, with or without this patch", what exactly do you mean by "leak"? It does not leak for me before the patch (haven't yet tried it with the patch), and this is what I mean-- exactly -- by "does not leak": I change a stock CVS build by changing "if 0:" to "if 1:" in test_generators.py's test_main, then let it run and run and run. Now on Win98SE, the heap space *does* grow very slowly and steadily, until it reaches about 3600Kb. Sometimes a little more, sometimes a little less, depending on what else I'm doing at the time. It takes about 5 minutes of CPU time on a 866MHz box to reach that. But then it *stays* at this point forever after (well, after another 10 minutes of CPU time it hasn't budged -- Win98SE probably can't run forever ). This is presumably because Win98SE malloc is lazy about coalescing free()'d memory until it nears a 4Mb boundary (at which point it starts rearranging VM address space-- because 4Mb is all the address space the system allocates to the initial heap --and it's very reluctant to do that). So if you're seeing a very slow "leak" (are you?), you *may* just be seeing a platform malloc reluctant to defragment free()'d memory. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439364&group_id=5470 From noreply@sourceforge.net Tue Jul 10 10:35:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 02:35:19 -0700 Subject: [Patches] [ python-Patches-439995 ] fix for #439990: return value of nice Message-ID: Patches item #439995, was opened at 2001-07-10 02:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439995&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: fix for #439990: return value of nice Initial Comment: This patch fixes the problem reported in SF bug #439990: Linux' 'nice()' systemcall does not return the new priority. This could optionally be fixed by adding a configure check and a few defines for this behaviour, but that would either be messy #defines or a lot of code duplication, and I'm not sure if it's worth it. The patch assumes getpriority() is available verywhere nice() is available. I think that is a safe assumption, given that getpriority() has been available since BSD4.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439995&group_id=5470 From noreply@sourceforge.net Tue Jul 10 10:45:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 02:45:05 -0700 Subject: [Patches] [ python-Patches-439995 ] fix for #439990: return value of nice Message-ID: Patches item #439995, was opened at 2001-07-10 02:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439995&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: fix for #439990: return value of nice Initial Comment: This patch fixes the problem reported in SF bug #439990: Linux' 'nice()' systemcall does not return the new priority. This could optionally be fixed by adding a configure check and a few defines for this behaviour, but that would either be messy #defines or a lot of code duplication, and I'm not sure if it's worth it. The patch assumes getpriority() is available verywhere nice() is available. I think that is a safe assumption, given that getpriority() has been available since BSD4.2. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-07-10 02:45 Message: Logged In: YES user_id=34209 Alright, really submitted the patch this time :) (I thought the 'check to upload' button was *finally* auto-checked by SF, but it just looked that way in Mozilla :) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439995&group_id=5470 From noreply@sourceforge.net Tue Jul 10 13:01:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 05:01:40 -0700 Subject: [Patches] [ python-Patches-405228 ] split Telnet class into TelnetBase Message-ID: Patches item #405228, was opened at 2001-03-01 11:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405228&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Rejected Priority: 2 Submitted By: Luke Kenneth Casson Leighton (lkcl) Assigned to: Guido van Rossum (gvanrossum) Summary: split Telnet class into TelnetBase Initial Comment: I've been asked to make telnet, ssh, bash and rpcclient (http://www.samba-tng.org), http requests and possibly much more all look seamlessly like telnet. That means splitting telnetlib.py's Telnet class down into a base class. I need the write, read_until, expect and friends, but did not want to do a total rewrite / total pain-in-the-neck cut/paste job on telnetlib.py just to fulfil the requirements. I have noticed that someone wrote an scp class, already before: it's available on parnassus. it wraps scp in popen. with this TelnetBase class, doing the same thing will be trivial _and_ you get the exact same look and functionality as if it was a Telnet() instance. well, it makes _me_ happy enough to submit this patch. copyright is hereby assigned to Guido van Rossum. authorship must remain as-is. have fun, luke ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 05:01 Message: Logged In: YES user_id=6380 Closing this now; I don't think this is going to happen. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 18:23 Message: Logged In: YES user_id=6380 This version of the patch looks like it needs a lot of work. Sent comments directly to author. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-01 18:47 Message: Logged In: YES user_id=6380 I'll try to do this after b1 is released. ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-03-01 11:32 Message: Logged In: YES user_id=80200 good grief. what the hell is wrong with sourceforge??? you can't upload files! grrr. diff -u will be sent to patches@python.org. grrr ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405228&group_id=5470 From noreply@sourceforge.net Tue Jul 10 13:29:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 05:29:11 -0700 Subject: [Patches] [ python-Patches-432401 ] unicode encoding error callbacks Message-ID: Patches item #432401, was opened at 2001-06-12 06:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=432401&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: unicode encoding error callbacks Initial Comment: This patch adds unicode error handling callbacks to the encode functionality. With this patch it's possible to not only pass 'strict', 'ignore' or 'replace' as the errors argument to encode, but also a callable function, that will be called with the encoding name, the original unicode object and the position of the unencodable character. The callback must return a replacement unicode object that will be encoded instead of the original character. For example replacing unencodable characters with XML character references can be done in the following way. u"aäoöuüß".encode( "ascii", lambda enc, uni, pos: u"&#x%x;" % ord(uni[pos]) ) ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-10 05:29 Message: Logged In: YES user_id=38388 Ok, here we go... > > > raise an exception). U+FFFD characters in the > replacement > > > string will be replaced with a character that the > encoder > > > chooses ('?' in all cases). > > > > Nice. > > But the special casing of U+FFFD makes the interface > somewhat > less clean than it could be. It was only done to be 100% > backwards compatible. With the original "replace" > error > handling the codec chose the replacement character. But as > far as I can tell none of the codecs uses anything other > than '?', True. > so I guess we could change the replace handler > to always return u'?'. This would make the implementation a > little bit simpler, but the explanation of the callback > feature *a lot* simpler. Go for it. > And if you still want to handle > an unencodable U+FFFD, you can write a special callback for > that, e.g. > > def FFFDreplace(enc, uni, pos): > if uni[pos] == "\ufffd": > return u"?" > else: > raise UnicodeError(...) > > > ...docs... > > > > Could you add these docs to the Misc/unicode.txt file ? I > > will eventually take that file and turn it into a PEP > which > > will then serve as general documentation for these things. > > I could, but first we should work out how the decoding > callback API will work. Ok. BTW, Barry Warsaw already did the work of converting the unicode.txt to PEP 100, so the docs should eventually go there. > > > BTW, I guess PyUnicode_EncodeUnicodeEscape could be > > > reimplemented as PyUnicode_EncodeASCII with a \uxxxx > > > replacement callback. > > > > Hmm, wouldn't that result in a slowdown ? If so, I'd > rather > > leave the special encoder in place, since it is being > used a > > lot in Python and probably some applications too. > > It would be a slowdown. But callbacks open many > possiblities. True, but in this case I believe that we should stick with the native implementation for "unicode-escape". Having a standard callback error handler which does the \uXXXX replacement would be nice to have though, since this would also be usable with lots of other codecs (e.g. all the code page ones). > For example: > > Why can't I print u"gürk"? > > is probably one of the most frequently asked questions in > comp.lang.python. For printing Unicode stuff, print could be > extended the use an error handling callback for Unicode > strings (or objects where __str__ or tp_str returns a > Unicode object) instead of using str() which always returns > an 8bit string and uses strict encoding. There might even > be a > sys.setprintencodehandler()/sys.getprintencodehandler() There already is a print callback in Python (forgot the name of the hook though), so this should be possible by providing the encoding logic in the hook. > > > I have not touched PyUnicode_TranslateCharmap yet, > > > should this function also support error callbacks? Why > > > would one want the insert None into the mapping to > call > > > the callback? > > > > 1. Yes. > > 2. The user may want to e.g. restrict usage of certain > > character ranges. In this case the codec would be used to > > verify the input and an exception would indeed be useful > > (e.g. say you want to restrict input to Hangul + ASCII). > > OK, do we want TranslateCharmap to work exactly like > encoding, > i.e. in case of an error should the returned replacement > string again be mapped through the translation mapping or > should it be copied to the output directly? The former would > be more in line with encoding, but IMHO the latter would > be much more useful. It's better to take the second approach (copy the callback output directly to the output string) to avoid endless recursion and other pitfalls. I suppose this will also simplify the implementation somewhat. > BTW, when I implement it I can implement patch #403100 > ("Multicharacter replacements in > PyUnicode_TranslateCharmap") > along the way. I've seen it; will comment on it later. > Should the old TranslateCharmap map to the new > TranslateCharmapEx > and inherit the "multicharacter replacement" feature, > or > should I leave it as it is? If possible, please also add the multichar replacement to the old API. I think it is very useful and since the old APIs work on raw buffers it would be a benefit to have the functionality in the old implementation too. [Decoding error callbacks] > > > A remaining problem is how to implement decoding error > > > callbacks. In Python 2.1 encoding and decoding errors > are > > > handled in the same way with a string value. But with > > > callbacks it doesn't make sense to use the same > callback > > > for encoding and decoding (like > codecs.StreamReaderWriter > > > and codecs.StreamRecoder do). Decoding callbacks have > a > > > different API. Which arguments should be passed to the > > > decoding callback, and what is the decoding callback > > > supposed to do? > > > > I'd suggest adding another set of PyCodec_UnicodeDecode... > () > > APIs for this. We'd then have to augment the base classes > of > > the StreamCodecs to provide two attributes for .errors > with > > a fallback solution for the string case (i.s. "strict" > can > > still be used for both directions). > > Sounds good. Now what is the decoding callback supposed to > do? > I guess it will be called in the same way as the encoding > callback, i.e. with encoding name, original string and > position of the error. It might returns a Unicode string > (i.e. an object of the decoding target type), that will be > emitted from the codec instead of the one offending byte. Or > it might return a tuple with replacement Unicode object and > a resynchronisation offset, i.e. returning (u"?", 1) > means > emit a '?' and skip the offending character. But to make > the offset really useful the callback has to know something > about the encoding, perhaps the codec should be allowed to > pass an additional state object to the callback? > > Maybe the same should be added to the encoding callbacks to? > Maybe the encoding callback should be able to tell the > encoder if the replacement returned should be reencoded > (in which case it's a Unicode object), or directly emitted > (in which case it's an 8bit string)? I like the idea of having an optional state object (basically this should be a codec-defined arbitrary Python object) which then allow the callback to apply additional tricks. The object should be documented to be modifyable in place (simplifies the interface). About the return value: I'd suggest to always use the same tuple interface, e.g. callback(encoding, input_data, input_position, state) -> (output_to_be_appended, new_input_position) (I think it's better to use absolute values for the position rather than offsets.) Perhaps the encoding callbacks should use the same interface... what do you think ? > > > One additional note: It is vital that errors is an > > > assignable attribute of the StreamWriter. > > > > It is already ! > > I know, but IMHO it should be documented that an assignable > errors attribute must be supported as part of the official > codec API. > > Misc/unicode.txt is not clear on that: > """ > It is not required by the Unicode implementation to use > these base classes, only the interfaces must match; this > allows writing Codecs as extension types. > """ Good point. I'll add that to the PEP 100. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-22 13:51 Message: Logged In: YES user_id=38388 Sorry to keep you waiting, Walter. I will look into this again next week -- this week was way too busy... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-13 10:00 Message: Logged In: YES user_id=38388 On your comment about the non-Unicode codecs: let's keep this separated from the current patch. Don't have much time today. I'll comment on the other things tomorrow. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-13 08:49 Message: Logged In: YES user_id=89016 Guido van Rossum wrote in python-dev: > True, the "codec" pattern can be used for other > encodings than Unicode. But it seems to me that the > entire codecs architecture is rather strongly geared > towards en/decoding Unicode, and it's not clear > how well other codecs fit in this pattern (e.g. I > noticed that all the non-Unicode codecs ignore the > error handling parameter or assert that > it is set to 'strict'). I noticed that too. asserting that errors=='strict' would mean that the encoder is not able to deal in any other way with unencodable stuff than by raising an error. But that is not the problem here, because for zlib, base64, quopri, hex and uu encoding there can be no unencodable characters. The encoders can simply ignore the errors parameter. Should I remove the asserts from those codecs and change the docstrings accordingly, or will this be done separately? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-13 06:57 Message: Logged In: YES user_id=89016 > > [...] > > raise an exception). U+FFFD characters in the replacement > > string will be replaced with a character that the encoder > > chooses ('?' in all cases). > > Nice. But the special casing of U+FFFD makes the interface somewhat less clean than it could be. It was only done to be 100% backwards compatible. With the original "replace" error handling the codec chose the replacement character. But as far as I can tell none of the codecs uses anything other than '?', so I guess we could change the replace handler to always return u'?'. This would make the implementation a little bit simpler, but the explanation of the callback feature *a lot* simpler. And if you still want to handle an unencodable U+FFFD, you can write a special callback for that, e.g. def FFFDreplace(enc, uni, pos): if uni[pos] == "\ufffd": return u"?" else: raise UnicodeError(...) > > The implementation of the loop through the string is done > > in the following way. A stack with two strings is kept > > and the loop always encodes a character from the string > > at the stacktop. If an error is encountered and the stack > > has only one entry (during encoding of the original string) > > the callback is called and the unicode object returned is > > pushed on the stack, so the encoding continues with the > > replacement string. If the stack has two entries when an > > error is encountered, the replacement string itself has > > an unencodable character and a normal exception raised. > > When the encoder has reached the end of it's current string > > there are two possibilities: when the stack contains two > > entries, this was the replacement string, so the replacement > > string will be poppep from the stack and encoding continues > > with the next character from the original string. If the > > stack had only one entry, encoding is finished. > > Very elegant solution ! I'll put it as a comment in the source. > > (I hope that's enough explanation of the API and > implementation) > > Could you add these docs to the Misc/unicode.txt file ? I > will eventually take that file and turn it into a PEP which > will then serve as general documentation for these things. I could, but first we should work out how the decoding callback API will work. > > I have renamed the static ...121 function to all lowercase > > names. > > Ok. > > > BTW, I guess PyUnicode_EncodeUnicodeEscape could be > > reimplemented as PyUnicode_EncodeASCII with a \uxxxx > > replacement callback. > > Hmm, wouldn't that result in a slowdown ? If so, I'd rather > leave the special encoder in place, since it is being used a > lot in Python and probably some applications too. It would be a slowdown. But callbacks open many possiblities. For example: Why can't I print u"gürk"? is probably one of the most frequently asked questions in comp.lang.python. For printing Unicode stuff, print could be extended the use an error handling callback for Unicode strings (or objects where __str__ or tp_str returns a Unicode object) instead of using str() which always returns an 8bit string and uses strict encoding. There might even be a sys.setprintencodehandler()/sys.getprintencodehandler() > [...] > I think it would be worthwhile to rename the callbacks to > include "Unicode" somewhere, e.g. > PyCodec_UnicodeReplaceEncodeErrors(). It's a long name, but > then it points out the application field of the callback > rather well. Same for the callbacks exposed through the > _codecsmodule. OK, done (and PyCodec_XMLCharRefReplaceUnicodeEncodeErrors really is a long name ;)) > > I have not touched PyUnicode_TranslateCharmap yet, > > should this function also support error callbacks? Why > > would one want the insert None into the mapping to call > > the callback? > > 1. Yes. > 2. The user may want to e.g. restrict usage of certain > character ranges. In this case the codec would be used to > verify the input and an exception would indeed be useful > (e.g. say you want to restrict input to Hangul + ASCII). OK, do we want TranslateCharmap to work exactly like encoding, i.e. in case of an error should the returned replacement string again be mapped through the translation mapping or should it be copied to the output directly? The former would be more in line with encoding, but IMHO the latter would be much more useful. BTW, when I implement it I can implement patch #403100 ("Multicharacter replacements in PyUnicode_TranslateCharmap") along the way. Should the old TranslateCharmap map to the new TranslateCharmapEx and inherit the "multicharacter replacement" feature, or should I leave it as it is? > > A remaining problem is how to implement decoding error > > callbacks. In Python 2.1 encoding and decoding errors are > > handled in the same way with a string value. But with > > callbacks it doesn't make sense to use the same callback > > for encoding and decoding (like codecs.StreamReaderWriter > > and codecs.StreamRecoder do). Decoding callbacks have a > > different API. Which arguments should be passed to the > > decoding callback, and what is the decoding callback > > supposed to do? > > I'd suggest adding another set of PyCodec_UnicodeDecode... () > APIs for this. We'd then have to augment the base classes of > the StreamCodecs to provide two attributes for .errors with > a fallback solution for the string case (i.s. "strict" can > still be used for both directions). Sounds good. Now what is the decoding callback supposed to do? I guess it will be called in the same way as the encoding callback, i.e. with encoding name, original string and position of the error. It might returns a Unicode string (i.e. an object of the decoding target type), that will be emitted from the codec instead of the one offending byte. Or it might return a tuple with replacement Unicode object and a resynchronisation offset, i.e. returning (u"?", 1) means emit a '?' and skip the offending character. But to make the offset really useful the callback has to know something about the encoding, perhaps the codec should be allowed to pass an additional state object to the callback? Maybe the same should be added to the encoding callbacks to? Maybe the encoding callback should be able to tell the encoder if the replacement returned should be reencoded (in which case it's a Unicode object), or directly emitted (in which case it's an 8bit string)? > > One additional note: It is vital that errors is an > > assignable attribute of the StreamWriter. > > It is already ! I know, but IMHO it should be documented that an assignable errors attribute must be supported as part of the official codec API. Misc/unicode.txt is not clear on that: """ It is not required by the Unicode implementation to use these base classes, only the interfaces must match; this allows writing Codecs as extension types. """ ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-13 01:05 Message: Logged In: YES user_id=38388 > How the callbacks work: > > A PyObject * named errors is passed in. This may by NULL, > Py_None, 'strict', u'strict', 'ignore', u'ignore', > 'replace', u'replace' or a callable object. > PyCodec_EncodeHandlerForObject maps all of these objects to > one of the three builtin error callbacks > PyCodec_RaiseEncodeErrors (raises an exception), > PyCodec_IgnoreEncodeErrors (returns an empty replacement > string, in effect ignoring the error), > PyCodec_ReplaceEncodeErrors (returns U+FFFD, the Unicode > replacement character to signify to the encoder that it > should choose a suitable replacement character) or directly > returns errors if it is a callable object. When an > unencodable character is encounterd the error handling > callback will be called with the encoding name, the original > unicode object and the error position and must return a > unicode object that will be encoded instead of the offending > character (or the callback may of course raise an > exception). U+FFFD characters in the replacement string will > be replaced with a character that the encoder chooses ('?' > in all cases). Nice. > The implementation of the loop through the string is done in > the following way. A stack with two strings is kept and the > loop always encodes a character from the string at the > stacktop. If an error is encountered and the stack has only > one entry (during encoding of the original string) the > callback is called and the unicode object returned is pushed > on the stack, so the encoding continues with the replacement > string. If the stack has two entries when an error is > encountered, the replacement string itself has an > unencodable character and a normal exception raised. When > the encoder has reached the end of it's current string there > are two possibilities: when the stack contains two entries, > this was the replacement string, so the replacement string > will be poppep from the stack and encoding continues with > the next character from the original string. If the stack > had only one entry, encoding is finished. Very elegant solution ! > (I hope that's enough explanation of the API and implementation) Could you add these docs to the Misc/unicode.txt file ? I will eventually take that file and turn it into a PEP which will then serve as general documentation for these things. > I have renamed the static ...121 function to all lowercase > names. Ok. > BTW, I guess PyUnicode_EncodeUnicodeEscape could be > reimplemented as PyUnicode_EncodeASCII with a \uxxxx > replacement callback. Hmm, wouldn't that result in a slowdown ? If so, I'd rather leave the special encoder in place, since it is being used a lot in Python and probably some applications too. > PyCodec_RaiseEncodeErrors, PyCodec_IgnoreEncodeErrors, > PyCodec_ReplaceEncodeErrors are globally visible because > they have to be available in _codecsmodule.c to wrap them as > Python function objects, but they can't be implemented in > _codecsmodule, because they need to be available to the > encoders in unicodeobject.c (through > PyCodec_EncodeHandlerForObject), but importing the codecs > module might result in an endless recursion, because > importing a module requires unpickling of the bytecode, > which might require decoding utf8, which ... (but this will > only happen, if we implement the same mechanism for the > decoding API) I think that codecs.c is the right place for these APIs. _codecsmodule.c is only meant as Python access wrapper for the internal codecs and nothing more. One thing I noted about the callbacks: they assume that they will always get Unicode objects as input. This is certainly not true in the general case (it is for the codecs you touch in the patch). I think it would be worthwhile to rename the callbacks to include "Unicode" somewhere, e.g. PyCodec_UnicodeReplaceEncodeErrors(). It's a long name, but then it points out the application field of the callback rather well. Same for the callbacks exposed through the _codecsmodule. > I have not touched PyUnicode_TranslateCharmap yet, > should this function also support error callbacks? Why would > one want the insert None into the mapping to call the callback? 1. Yes. 2. The user may want to e.g. restrict usage of certain character ranges. In this case the codec would be used to verify the input and an exception would indeed be useful (e.g. say you want to restrict input to Hangul + ASCII). > A remaining problem is how to implement decoding error > callbacks. In Python 2.1 encoding and decoding errors are > handled in the same way with a string value. But with > callbacks it doesn't make sense to use the same callback for > encoding and decoding (like codecs.StreamReaderWriter and > codecs.StreamRecoder do). Decoding callbacks have a > different API. Which arguments should be passed to the > decoding callback, and what is the decoding callback > supposed to do? I'd suggest adding another set of PyCodec_UnicodeDecode...() APIs for this. We'd then have to augment the base classes of the StreamCodecs to provide two attributes for .errors with a fallback solution for the string case (i.s. "strict" can still be used for both directions). > One additional note: It is vital that errors is an > assignable attribute of the StreamWriter. It is already ! > Consider the XML example: For writing an XML DOM tree one > StreamWriter object is used. When a text node is written, > the error handling has to be set to > codecs.xmlreplace_encode_errors, but inside a comment or > processing instruction replacing unencodable characters with > charrefs is not possible, so here codecs.raise_encode_errors > should be used (or better a custom error handler that raises > an error that says "sorry, you can't have unencodable > characters inside a comment") Sure. > BTW, should we continue the discussion in the i18n SIG > mailing list? An email program is much more comfortable than > a HTML textarea! ;) I'd rather keep the discussions on this patch here -- forking it off to the i18n sig will make it very hard to follow up on it. (This HTML area is indeed damn small ;-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 12:18 Message: Logged In: YES user_id=89016 One additional note: It is vital that errors is an assignable attribute of the StreamWriter. Consider the XML example: For writing an XML DOM tree one StreamWriter object is used. When a text node is written, the error handling has to be set to codecs.xmlreplace_encode_errors, but inside a comment or processing instruction replacing unencodable characters with charrefs is not possible, so here codecs.raise_encode_errors should be used (or better a custom error handler that raises an error that says "sorry, you can't have unencodable characters inside a comment") BTW, should we continue the discussion in the i18n SIG mailing list? An email program is much more comfortable than a HTML textarea! ;) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 11:59 Message: Logged In: YES user_id=89016 How the callbacks work: A PyObject * named errors is passed in. This may by NULL, Py_None, 'strict', u'strict', 'ignore', u'ignore', 'replace', u'replace' or a callable object. PyCodec_EncodeHandlerForObject maps all of these objects to one of the three builtin error callbacks PyCodec_RaiseEncodeErrors (raises an exception), PyCodec_IgnoreEncodeErrors (returns an empty replacement string, in effect ignoring the error), PyCodec_ReplaceEncodeErrors (returns U+FFFD, the Unicode replacement character to signify to the encoder that it should choose a suitable replacement character) or directly returns errors if it is a callable object. When an unencodable character is encounterd the error handling callback will be called with the encoding name, the original unicode object and the error position and must return a unicode object that will be encoded instead of the offending character (or the callback may of course raise an exception). U+FFFD characters in the replacement string will be replaced with a character that the encoder chooses ('?' in all cases). The implementation of the loop through the string is done in the following way. A stack with two strings is kept and the loop always encodes a character from the string at the stacktop. If an error is encountered and the stack has only one entry (during encoding of the original string) the callback is called and the unicode object returned is pushed on the stack, so the encoding continues with the replacement string. If the stack has two entries when an error is encountered, the replacement string itself has an unencodable character and a normal exception raised. When the encoder has reached the end of it's current string there are two possibilities: when the stack contains two entries, this was the replacement string, so the replacement string will be poppep from the stack and encoding continues with the next character from the original string. If the stack had only one entry, encoding is finished. (I hope that's enough explanation of the API and implementation) I have renamed the static ...121 function to all lowercase names. BTW, I guess PyUnicode_EncodeUnicodeEscape could be reimplemented as PyUnicode_EncodeASCII with a \uxxxx replacement callback. PyCodec_RaiseEncodeErrors, PyCodec_IgnoreEncodeErrors, PyCodec_ReplaceEncodeErrors are globally visible because they have to be available in _codecsmodule.c to wrap them as Python function objects, but they can't be implemented in _codecsmodule, because they need to be available to the encoders in unicodeobject.c (through PyCodec_EncodeHandlerForObject), but importing the codecs module might result in an endless recursion, because importing a module requires unpickling of the bytecode, which might require decoding utf8, which ... (but this will only happen, if we implement the same mechanism for the decoding API) I have not touched PyUnicode_TranslateCharmap yet, should this function also support error callbacks? Why would one want the insert None into the mapping to call the callback? A remaining problem is how to implement decoding error callbacks. In Python 2.1 encoding and decoding errors are handled in the same way with a string value. But with callbacks it doesn't make sense to use the same callback for encoding and decoding (like codecs.StreamReaderWriter and codecs.StreamRecoder do). Decoding callbacks have a different API. Which arguments should be passed to the decoding callback, and what is the decoding callback supposed to do? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-12 11:00 Message: Logged In: YES user_id=38388 About the Py_UNICODE*data, int size APIs: Ok, point taken. In general, I think we ought to keep the callback feature as open as possible, so passing in pointers and sizes would not be very useful. BTW, could you summarize how the callback works in a few lines ? About _Encode121: I'd name this _EncodeUCS1 since that's what it is ;-) About the new functions: I was referring to the new static functions which you gave PyUnicode_... names. If these are not supposed to turn into non-static functions, I'd rather have them use lower case names (since that's how the Python internals work too -- most of the times). ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 09:56 Message: Logged In: YES user_id=89016 > One thing which I don't like about your API change is that > you removed the Py_UNICODE*data, int size style arguments > -- > this makes it impossible to use the new APIs on non-Python > data or data which is not available as Unicode object. Another problem is, that the callback requires a Python object, so in the PyObject *version, the refcount is incref'd and the object is passed to the callback. The Py_UNICODE*/int version would have to create a new Unicode object from the data. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 09:32 Message: Logged In: YES user_id=89016 > * please don't place more than one C statement on one line > like in: > """ > + unicode = unicode2; unicodepos = > unicode2pos; > + unicode2 = NULL; unicode2pos = 0; > """ OK, done! > * Comments should start with a capital letter and be > prepended > to the section they apply to Fixed! > * There should be spaces between arguments in compares > (a == b) not (a==b) Fixed! > * Where does the name "...Encode121" originate ? encode one-to-one, it implements both ASCII and latin-1 encoding. > * module internal APIs should use lower case names (you > converted some of these to PyUnicode_...() -- this is > normally reserved for APIs which are either marked as > potential candidates for the public API or are very > prominent in the code) Which ones? I introduced a new function for every old one, that had a "const char *errors" argument, and a few new ones in codecs.h, of those PyCodec_EncodeHandlerForObject is vital, because it is used to map for old string arguments to the new function objects. PyCodec_RaiseEncodeErrors can be used in the encoder implementation to raise an encode error, but it could be made static in unicodeobject.h so only those encoders implemented there have access to it. > One thing which I don't like about your API change is that > you removed the Py_UNICODE*data, int size style arguments > -- > this makes it impossible to use the new APIs on non-Python > data or data which is not available as Unicode object. I look through the code and found no situation where the Py_UNICODE*/int version is really used and having two (PyObject *)s (the original and the replacement string), instead of UNICODE*/int and PyObject * made the implementation a little easier, but I can fix that. > Please separate the errors.c patch from this patch -- it > seems totally unrelated to Unicode. PyCodec_RaiseEncodeErrors uses this the have a \Uxxxx with four hex digits. I removed it. I'll upload a revised patch as soon as it's done. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-12 07:29 Message: Logged In: YES user_id=38388 Thanks for the patch -- it looks very impressive !. I'll give it a try later this week. Some first cosmetic tidbits: * please don't place more than one C statement on one line like in: """ + unicode = unicode2; unicodepos = unicode2pos; + unicode2 = NULL; unicode2pos = 0; """ * Comments should start with a capital letter and be prepended to the section they apply to * There should be spaces between arguments in compares (a == b) not (a==b) * Where does the name "...Encode121" originate ? * module internal APIs should use lower case names (you converted some of these to PyUnicode_...() -- this is normally reserved for APIs which are either marked as potential candidates for the public API or are very prominent in the code) One thing which I don't like about your API change is that you removed the Py_UNICODE*data, int size style arguments -- this makes it impossible to use the new APIs on non-Python data or data which is not available as Unicode object. Please separate the errors.c patch from this patch -- it seems totally unrelated to Unicode. Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=432401&group_id=5470 From noreply@sourceforge.net Tue Jul 10 14:53:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 06:53:45 -0700 Subject: [Patches] [ python-Patches-429442 ] Cygwin sys.platform/get_platform() patch Message-ID: Patches item #429442, was opened at 2001-06-01 13:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429442&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Greg Ward (gward) Summary: Cygwin sys.platform/get_platform() patch Initial Comment: This patch corrects sys.platform and distutils.util.get_platform() problems caused by the cruft contained in Cygwin's uname -s. Please see the following for the gory details: http://www.cygwin.com/ml/cygwin-apps/2001-05/msg00106.html Note that the above also solicited input from the community in an attempt to prevent any potential heartache. Since no one responded it would appear that either the changes are acceptable or that no one really cares... :,) ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2001-07-10 06:53 Message: Logged In: YES user_id=86216 Any status? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-06-07 13:00 Message: Logged In: YES user_id=31435 Assigned to GregW. Greg, note that since Cygwin is really a Unix derivative, your primary concern is probably just that this doesn't break other Unixoid systems. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429442&group_id=5470 From noreply@sourceforge.net Tue Jul 10 14:54:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 06:54:54 -0700 Subject: [Patches] [ python-Patches-432457 ] Readline 4.2 Patch Message-ID: Patches item #432457, was opened at 2001-06-12 09:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=432457&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: Readline 4.2 Patch Initial Comment: This patch enables the Python readline module to build cleanly against readline 4.2. Specifically, it configures Python to use either completion_matches() or rl_completion_matches() as appropriate. This is necessary due to the deprecation of completion_matches() (and the other functions defined in compat.c) in readline 4.2. In this case, deprecated means no longer declared in readline.h but still defined in the readline library (e.g. libreadline.so). Although this patch is currently only necessary for Cygwin, it eventually will be needed by the other platforms when completion_matches() is finally removed from readline (e.g., 4.3). I tested this patch under the following environments: Linux with readline 2.2.1 Linux with readline 4.2 Cygwin with readline 4.1 Cygwin with readline 4.2 and it functioned as expected. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2001-07-10 06:54 Message: Logged In: YES user_id=86216 Any status? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=432457&group_id=5470 From noreply@sourceforge.net Tue Jul 10 17:45:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 09:45:13 -0700 Subject: [Patches] [ python-Patches-432457 ] Readline 4.2 Patch Message-ID: Patches item #432457, was opened at 2001-06-12 09:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=432457&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: Readline 4.2 Patch Initial Comment: This patch enables the Python readline module to build cleanly against readline 4.2. Specifically, it configures Python to use either completion_matches() or rl_completion_matches() as appropriate. This is necessary due to the deprecation of completion_matches() (and the other functions defined in compat.c) in readline 4.2. In this case, deprecated means no longer declared in readline.h but still defined in the readline library (e.g. libreadline.so). Although this patch is currently only necessary for Cygwin, it eventually will be needed by the other platforms when completion_matches() is finally removed from readline (e.g., 4.3). I tested this patch under the following environments: Linux with readline 2.2.1 Linux with readline 4.2 Cygwin with readline 4.1 Cygwin with readline 4.2 and it functioned as expected. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 09:45 Message: Logged In: YES user_id=6380 Thanks! This is exactly what I knew was needed. I've checked this in now, complete with changes to configure and config.h.in. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-07-10 06:54 Message: Logged In: YES user_id=86216 Any status? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=432457&group_id=5470 From noreply@sourceforge.net Tue Jul 10 18:44:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 10:44:41 -0700 Subject: [Patches] [ python-Patches-440144 ] Tests and minor bugfix for uu module Message-ID: Patches item #440144, was opened at 2001-07-10 10:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440144&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Tests and minor bugfix for uu module Initial Comment: Inspired by a Post by Tim to c.l.py this morning, I've decided to try my hand at writing real test cases for some of the modules formerly tested only by test_sundry.py. This is my first attempt: a set of tests for the uu.py module. In the process of writing the tests, I found a minor bug in uu: its tests for a missing 'end' line would never trigger. Files included are: a patch for uu.py and test_sundry.py, a new test_uu.py file, and an output file for test_uu. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440144&group_id=5470 From noreply@sourceforge.net Tue Jul 10 19:12:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 11:12:27 -0700 Subject: [Patches] [ python-Patches-440153 ] sgmllib docstrings added Message-ID: Patches item #440153, was opened at 2001-07-10 11:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440153&group_id=5470 Category: documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Evelyn Mitchell (efm) Assigned to: Nobody/Anonymous (nobody) Summary: sgmllib docstrings added Initial Comment: Diff is 2.1 released against CVS 1.32 Docstrings added to all methods. The text of the docstrings is from the existing # comments, which have been left intact. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440153&group_id=5470 From noreply@sourceforge.net Tue Jul 10 20:29:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 12:29:49 -0700 Subject: [Patches] [ python-Patches-440170 ] Tests for fileinput module Message-ID: Patches item #440170, was opened at 2001-07-10 12:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440170&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Tests for fileinput module Initial Comment: Inspired by a Post by Tim to c.l.py this morning, I've decided to try my hand at writing real test cases for some of the modules formerly tested only by test_sundry.py. This is my second attempt: a set of tests for the fileinput.py module. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440170&group_id=5470 From noreply@sourceforge.net Wed Jul 11 04:45:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 20:45:46 -0700 Subject: [Patches] [ python-Patches-439364 ] GC for frames and generators Message-ID: Patches item #439364, was opened at 2001-07-07 15:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439364&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Neil Schemenauer (nascheme) Summary: GC for frames and generators Initial Comment: For me, test_generators leaks, with or without this patch. The number of objects tracked by the GC does not increase but memory usage does. There must be other objects creating cycles that are not tracked by the GC. I haven't profiled the effect this change. I have another patch in the works that should minimize the performance hit. Please examine frame_traverse and frame_clear closely. I'm not 100% sure that I am chasing all the references necessary to find cycles or that I am dropping enough to break them. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-10 20:45 Message: Logged In: YES user_id=31435 The newly attached bmoleak.py shows a similar leak without any generators, involving seqiterobjects alone. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-09 21:34 Message: Logged In: YES user_id=31435 I expect what's going on here is the obvious thing: clearing the LazyList dict stops the leak, but the dict only holds two things: a vanilla list of integers, and a bound method object. Since a list of ints can't cause a cycle, it must be the latter; and, indeed, a quick glance at methodobject.c shows GC doesn't chase PyCFunction_Type (yet). The bound method object in this case wraps the .next() method of a generator-iterator object, and there's a cycle: the LazyList fib maps fib.fetch to the fibgen() generator-iterator's .next method, from which we can get to the fibgen g-i, which in turn contains (indirect) references back to fib thanks to passing iter(fib) to the sum() and head() generators. Looks like breaking this by magic requires adding both seqiterobjects and PyCFunctionObjects to GC. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-09 14:08 Message: Logged In: YES user_id=31435 The attached fibleak.py is a self-contained massive leaker. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-09 13:48 Message: Logged In: YES user_id=31435 + Performance hit is about a 2.5% slowdown. More than I hoped, but less than I feared . + The leak after the patch is solely due to fun_tests. Comment out the other lines in the __test__ dict, and on my box it leaks about half a megabyte per second then -- very dramatic, and impossible to ascribe to anything but a leak. + I don't know what causes the leak. Offhand my first guess would be unchased pointers inside traceback objects. Indeed, the first thing I'd *try* is adding tracebackobject to GC too just to see whether that made the leak go away (much easier than thinking about it <0.9 wink>). ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-07-09 07:11 Message: Logged In: YES user_id=35752 Your right, it doesn't leak before the patch. The process size goes up slowly be eventually stops increasing. After the patch the size continues going up slowly. :-( I'll try to find what is still leaking. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-08 21:40 Message: Logged In: YES user_id=31435 Thanks, Neil! I've been too overwhelmed with merging descr- branch code to look at this until now. Clarification, please: when you say "test_generators leaks, with or without this patch", what exactly do you mean by "leak"? It does not leak for me before the patch (haven't yet tried it with the patch), and this is what I mean-- exactly -- by "does not leak": I change a stock CVS build by changing "if 0:" to "if 1:" in test_generators.py's test_main, then let it run and run and run. Now on Win98SE, the heap space *does* grow very slowly and steadily, until it reaches about 3600Kb. Sometimes a little more, sometimes a little less, depending on what else I'm doing at the time. It takes about 5 minutes of CPU time on a 866MHz box to reach that. But then it *stays* at this point forever after (well, after another 10 minutes of CPU time it hasn't budged -- Win98SE probably can't run forever ). This is presumably because Win98SE malloc is lazy about coalescing free()'d memory until it nears a 4Mb boundary (at which point it starts rearranging VM address space-- because 4Mb is all the address space the system allocates to the initial heap --and it's very reluctant to do that). So if you're seeing a very slow "leak" (are you?), you *may* just be seeing a platform malloc reluctant to defragment free()'d memory. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439364&group_id=5470 From noreply@sourceforge.net Wed Jul 11 04:51:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 20:51:31 -0700 Subject: [Patches] [ python-Patches-438331 ] make ndiff.py into a library module Message-ID: Patches item #438331, was opened at 2001-07-03 12:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438331&group_id=5470 Category: demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Tim Peters (tim_one) Summary: make ndiff.py into a library module Initial Comment: Here's a patch to make ndiff.py's functionality generally available to Python programs. It should move from Tools/scripts/ to Lib/. ndiff.py's functionality is very useful for making comparisons human-readable. I wanted to use it from my Python code (unittest's of generated XML), but unfortunately ndiff.py wasn't written that way. So I refactored out the lists-of-strings comparison code from fcompare() into lcompare(), and parameterized the formerly hard-coded IS_*_JUNK filters. I'd like to see it further converted to return a diff string, rather than only spew to stdout. It's easy enough to capture stdout, but klugey. I will do the mods if they have a good-to-certain chance of making it in. (Please let me know.) Also, give me the word and I will whip up some TeX docs if Tim doesn't have the time. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-10 20:51 Message: Logged In: YES user_id=31435 David, Guido has given his blessing to this. Refactoring released functionality is too minor to require a PEP, so long as ndiff "still works" in the end -- all that changes is (I hope) that difflib grews a new capability. Just don't forget the docstrings . ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2001-07-04 20:49 Message: Logged In: YES user_id=7733 Tim: Your doctest example is spot-on. That's exactly what I'm using ndiff for, within unit tests. I will work on a clean class to add to difflib.py, implementing the ndiff functionality. PEP required? (No, I'm not going for a record.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-04 19:27 Message: Logged In: YES user_id=31435 Fred, I think I understand what David's after. ndiff has a great deal of logic for comparing "files" as sequences of lines which are in turn sequences of characters, on top of what difflib.py provides (in fact, only the easiest part was factored out). Whether that should go into the std library is a legit question, though. I'll ask Guido about it; if he's at all inclined to say "yes", I bet it would only be because he trusts me to maintain it for the rest of my life <0.7 wink>. I've wanted this at times too; e.g., doctest would love to do a clearer job of showing "expected" vs "but got" outcomes than just listing both in full without any correlation. David, if you want to do this you should supply a proper "file-like object" comparison class instead. You appear to be aiming more at minimal changes here than at clean library design. I'd rather see a clean new class added to difflib.py, the use of which could reduce ndiff.py to a one-pager (or so). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 21:26 Message: Logged In: YES user_id=3066 Is this still relevant in light of ndiff being factored into the ndiff.py script and the difflib library module? difflib is already documented. Assigning to Tim since this is his baby. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438331&group_id=5470 From noreply@sourceforge.net Wed Jul 11 05:09:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 21:09:49 -0700 Subject: [Patches] [ python-Patches-440144 ] Tests and minor bugfix for uu module Message-ID: Patches item #440144, was opened at 2001-07-10 10:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440144&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) >Assigned to: Tim Peters (tim_one) Summary: Tests and minor bugfix for uu module Initial Comment: Inspired by a Post by Tim to c.l.py this morning, I've decided to try my hand at writing real test cases for some of the modules formerly tested only by test_sundry.py. This is my first attempt: a set of tests for the uu.py module. In the process of writing the tests, I found a minor bug in uu: its tests for a missing 'end' line would never trigger. Files included are: a patch for uu.py and test_sundry.py, a new test_uu.py file, and an output file for test_uu. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-10 21:09 Message: Logged In: YES user_id=31435 Thank you, Nick! Since we hope to convert the entire test suite to a mix of doctest and unittest eventually, and those don't use "expected output" files, I'd like you to change this test to stop needing an expected-output file. You can do this easily, by importing "verbose" from test_support too, and putting the existing instances of e.g. print '1. encode file->file' under the protection of if verbose: Then the new test_uu isn't needed at all. The bug you found in uu.py is gross! Thanks for that too. I applied that part of the patch to the source tree, as Lib/uu.py, new revision: 1.17 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440144&group_id=5470 From noreply@sourceforge.net Wed Jul 11 05:14:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 21:14:30 -0700 Subject: [Patches] [ python-Patches-440170 ] Tests for fileinput module Message-ID: Patches item #440170, was opened at 2001-07-10 12:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440170&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) >Assigned to: Tim Peters (tim_one) Summary: Tests for fileinput module Initial Comment: Inspired by a Post by Tim to c.l.py this morning, I've decided to try my hand at writing real test cases for some of the modules formerly tested only by test_sundry.py. This is my second attempt: a set of tests for the fileinput.py module. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-10 21:14 Message: Logged In: YES user_id=31435 As with the uu test, please change this too not to need an expected-output file (make the print stmts conditional, under "if test_support.verbose:"). Note that Guido's style guide requires a single space after commas (in argument lists and tuples specifically). So e.g. def runTests(t1, t2, t3, t4, bs=0, round=0): not def runTests(t1,t2,t3,t4,bs=0,round=0): ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440170&group_id=5470 From noreply@sourceforge.net Wed Jul 11 06:07:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 22:07:09 -0700 Subject: [Patches] [ python-Patches-440144 ] Tests and minor bugfix for uu module Message-ID: Patches item #440144, was opened at 2001-07-10 10:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440144&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Tim Peters (tim_one) Summary: Tests and minor bugfix for uu module Initial Comment: Inspired by a Post by Tim to c.l.py this morning, I've decided to try my hand at writing real test cases for some of the modules formerly tested only by test_sundry.py. This is my first attempt: a set of tests for the uu.py module. In the process of writing the tests, I found a minor bug in uu: its tests for a missing 'end' line would never trigger. Files included are: a patch for uu.py and test_sundry.py, a new test_uu.py file, and an output file for test_uu. ---------------------------------------------------------------------- >Comment By: Nick Mathewson (nickm) Date: 2001-07-10 22:07 Message: Logged In: YES user_id=499 I've added a new version of test_uu.py that seems to do the right thing. (I haven't figured out how to make Sourceforge replace the old ones, if such is possible.) As you said, test_uu is now unneeded. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-10 21:09 Message: Logged In: YES user_id=31435 Thank you, Nick! Since we hope to convert the entire test suite to a mix of doctest and unittest eventually, and those don't use "expected output" files, I'd like you to change this test to stop needing an expected-output file. You can do this easily, by importing "verbose" from test_support too, and putting the existing instances of e.g. print '1. encode file->file' under the protection of if verbose: Then the new test_uu isn't needed at all. The bug you found in uu.py is gross! Thanks for that too. I applied that part of the patch to the source tree, as Lib/uu.py, new revision: 1.17 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440144&group_id=5470 From noreply@sourceforge.net Wed Jul 11 06:09:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 22:09:01 -0700 Subject: [Patches] [ python-Patches-440170 ] Tests for fileinput module Message-ID: Patches item #440170, was opened at 2001-07-10 12:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440170&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Tim Peters (tim_one) Summary: Tests for fileinput module Initial Comment: Inspired by a Post by Tim to c.l.py this morning, I've decided to try my hand at writing real test cases for some of the modules formerly tested only by test_sundry.py. This is my second attempt: a set of tests for the fileinput.py module. ---------------------------------------------------------------------- >Comment By: Nick Mathewson (nickm) Date: 2001-07-10 22:09 Message: Logged In: YES user_id=499 I've updated the tests for fileinput.py to do the right thing, and obey Guido's style guidelines. I don't know whether Sourceforge will let me replace the old ones, though. :/ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-10 21:14 Message: Logged In: YES user_id=31435 As with the uu test, please change this too not to need an expected-output file (make the print stmts conditional, under "if test_support.verbose:"). Note that Guido's style guide requires a single space after commas (in argument lists and tuples specifically). So e.g. def runTests(t1, t2, t3, t4, bs=0, round=0): not def runTests(t1,t2,t3,t4,bs=0,round=0): ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440170&group_id=5470 From noreply@sourceforge.net Wed Jul 11 06:12:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 22:12:52 -0700 Subject: [Patches] [ python-Patches-440290 ] Tests for test_fpformat.py Message-ID: Patches item #440290, was opened at 2001-07-10 22:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440290&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Tests for test_fpformat.py Initial Comment: Another installment in the series of "Tests for the Testless". This time, we tackle the fpformat.py module, which does almost-but-not-exactly the same thing as certain options to the % operator. This test shows an inconsistencies in the behavior between fix and sci; and between fpformat and %. I'm not sure of the original authors' intent, so I'm just testing for the original behavior. This may not be best. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440290&group_id=5470 From noreply@sourceforge.net Wed Jul 11 06:15:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 22:15:05 -0700 Subject: [Patches] [ python-Patches-440291 ] Test cases for commands.py Message-ID: Patches item #440291, was opened at 2001-07-10 22:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440291&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Test cases for commands.py Initial Comment: Test cases for the commands.py module. These are only tested to work on SunOS and Linux, though they should work on any posix system. (This module needs an overhaul!) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440291&group_id=5470 From noreply@sourceforge.net Wed Jul 11 06:21:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 22:21:09 -0700 Subject: [Patches] [ python-Patches-440292 ] Test cases for pyclbr.py Message-ID: Patches item #440292, was opened at 2001-07-10 22:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440292&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Test cases for pyclbr.py Initial Comment: These test cases exercise the pyclbr module. They work by comparing the output of pyclbr to the results of module introspection for some of the largest modules in the Python distribution. They also skirt several limitations of pyclbr not mentioned in the BUGS section of pyclbr.py. For example, pyclbr.py does really bad in the presence of the string [ '"""' ]. (This keeps it from handling pydoc.py.) While writing these test cases, I also found a minor bug in pyclbr.py that would prevent it from finding functions (but not classes) declared in other modules. I'm also including a patch for this bug. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440292&group_id=5470 From noreply@sourceforge.net Wed Jul 11 06:22:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 22:22:52 -0700 Subject: [Patches] [ python-Patches-440292 ] Test cases for pyclbr.py Message-ID: Patches item #440292, was opened at 2001-07-10 22:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440292&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Test cases for pyclbr.py Initial Comment: These test cases exercise the pyclbr module. They work by comparing the output of pyclbr to the results of module introspection for some of the largest modules in the Python distribution. They also skirt several limitations of pyclbr not mentioned in the BUGS section of pyclbr.py. For example, pyclbr.py does really bad in the presence of the string [ '"""' ]. (This keeps it from handling pydoc.py.) While writing these test cases, I also found a minor bug in pyclbr.py that would prevent it from finding functions (but not classes) declared in other modules. I'm also including a patch for this bug. ---------------------------------------------------------------------- >Comment By: Nick Mathewson (nickm) Date: 2001-07-10 22:22 Message: Logged In: YES user_id=499 (More information on the bug: whereas pyclbr.py can notice imports of the format: "from module import class", it wasn't able to handle "from module import fn". Now it can.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440292&group_id=5470 From noreply@sourceforge.net Wed Jul 11 14:35:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 06:35:56 -0700 Subject: [Patches] [ python-Patches-440407 ] Remote execution patch Message-ID: Patches item #440407, was opened at 2001-07-11 06:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440407&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: Remote execution patch Initial Comment: This is the code I have for the remote execution patch. (Remote execution must be enabled with an explicit command line argument -r.) Caveats: - undocumented - slow - security issue: the subprocess should not be the server but the client, to prevent a hacker from gaining access This should apply cleanly against IDLE as currently checked into the Python CVS tree. I don't want to check this in yet because of the security issue, and I don't have time to work on it. I hope the idlefork project will pick this up though and address the issues above. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440407&group_id=5470 From noreply@sourceforge.net Wed Jul 11 14:37:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 06:37:09 -0700 Subject: [Patches] [ python-Patches-440407 ] Remote execution patch for IDLE Message-ID: Patches item #440407, was opened at 2001-07-11 06:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440407&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) >Summary: Remote execution patch for IDLE Initial Comment: This is the code I have for the remote execution patch. (Remote execution must be enabled with an explicit command line argument -r.) Caveats: - undocumented - slow - security issue: the subprocess should not be the server but the client, to prevent a hacker from gaining access This should apply cleanly against IDLE as currently checked into the Python CVS tree. I don't want to check this in yet because of the security issue, and I don't have time to work on it. I hope the idlefork project will pick this up though and address the issues above. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440407&group_id=5470 From noreply@sourceforge.net Wed Jul 11 14:38:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 06:38:11 -0700 Subject: [Patches] [ python-Patches-440407 ] Remote execution patch for IDLE Message-ID: Patches item #440407, was opened at 2001-07-11 06:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440407&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: Remote execution patch for IDLE Initial Comment: This is the code I have for the remote execution patch. (Remote execution must be enabled with an explicit command line argument -r.) Caveats: - undocumented - slow - security issue: the subprocess should not be the server but the client, to prevent a hacker from gaining access This should apply cleanly against IDLE as currently checked into the Python CVS tree. I don't want to check this in yet because of the security issue, and I don't have time to work on it. I hope the idlefork project will pick this up though and address the issues above. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 06:38 Message: Logged In: YES user_id=6380 Uploading the patch again. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440407&group_id=5470 From noreply@sourceforge.net Wed Jul 11 16:01:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 08:01:16 -0700 Subject: [Patches] [ python-Patches-439995 ] fix for #439990: return value of nice Message-ID: Patches item #439995, was opened at 2001-07-10 02:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439995&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Thomas Wouters (twouters) >Assigned to: Thomas Wouters (twouters) Summary: fix for #439990: return value of nice Initial Comment: This patch fixes the problem reported in SF bug #439990: Linux' 'nice()' systemcall does not return the new priority. This could optionally be fixed by adding a configure check and a few defines for this behaviour, but that would either be messy #defines or a lot of code duplication, and I'm not sure if it's worth it. The patch assumes getpriority() is available verywhere nice() is available. I think that is a safe assumption, given that getpriority() has been available since BSD4.2. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-07-11 08:01 Message: Logged In: YES user_id=34209 Checked in a slightly modified version that checks for the availability of getpriority() before using it. Also checked into the 2.1.1 tree: configure.in revisions 1.226 and 1.215.2.3, configure 1.218 and 1.207.2.3, config.h.in 2.99 and 2.91.2.3, posixmodule.c 2.191 and 2.187.2.2. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-10 02:45 Message: Logged In: YES user_id=34209 Alright, really submitted the patch this time :) (I thought the 'check to upload' button was *finally* auto-checked by SF, but it just looked that way in Mozilla :) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439995&group_id=5470 From noreply@sourceforge.net Wed Jul 11 20:27:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 12:27:51 -0700 Subject: [Patches] [ python-Patches-440487 ] int to the negative power -> float Message-ID: Patches item #440487, was opened at 2001-07-11 12:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440487&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: int to the negative power -> float Initial Comment: Currently, int to the negative int power raises an exception. This was one of the two problems that the VPython users complained about. (The other was that integer division returns a truncated integer, but that's another story. :-) I propose to implement this in Python 2.2. Anybody have a problem with this? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440487&group_id=5470 From noreply@sourceforge.net Wed Jul 11 20:46:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 12:46:59 -0700 Subject: [Patches] [ python-Patches-440487 ] int to the negative power -> float Message-ID: Patches item #440487, was opened at 2001-07-11 12:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440487&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: int to the negative power -> float Initial Comment: Currently, int to the negative int power raises an exception. This was one of the two problems that the VPython users complained about. (The other was that integer division returns a truncated integer, but that's another story. :-) I propose to implement this in Python 2.2. Anybody have a problem with this? ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-11 12:46 Message: Logged In: YES user_id=31435 No objection so far as it goes, but surely long_pow() should also attempt the same kind of thing then. Should add some test cases and docs too (yes, I'm going to hold you to the same stds as contributors ). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440487&group_id=5470 From noreply@sourceforge.net Wed Jul 11 20:52:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 12:52:04 -0700 Subject: [Patches] [ python-Patches-440487 ] int to the negative power -> float Message-ID: Patches item #440487, was opened at 2001-07-11 12:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440487&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) >Assigned to: Tim Peters (tim_one) Summary: int to the negative power -> float Initial Comment: Currently, int to the negative int power raises an exception. This was one of the two problems that the VPython users complained about. (The other was that integer division returns a truncated integer, but that's another story. :-) I propose to implement this in Python 2.2. Anybody have a problem with this? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 12:52 Message: Logged In: YES user_id=6380 Tough luck. :-) There may be something else wrong with the patch: it probably shouldn't fall back to float when z is not None. After all, pow(x, y, z) should compute x**y % z, and I'm sure that someone using this would be quite surprised to get a floating point number back if they accidentally let y become negative! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 12:46 Message: Logged In: YES user_id=31435 No objection so far as it goes, but surely long_pow() should also attempt the same kind of thing then. Should add some test cases and docs too (yes, I'm going to hold you to the same stds as contributors ). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440487&group_id=5470 From noreply@sourceforge.net Wed Jul 11 20:59:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 12:59:20 -0700 Subject: [Patches] [ python-Patches-440487 ] int to the negative power -> float Message-ID: Patches item #440487, was opened at 2001-07-11 12:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440487&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Tim Peters (tim_one) Summary: int to the negative power -> float Initial Comment: Currently, int to the negative int power raises an exception. This was one of the two problems that the VPython users complained about. (The other was that integer division returns a truncated integer, but that's another story. :-) I propose to implement this in Python 2.2. Anybody have a problem with this? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 12:59 Message: Logged In: YES user_id=6380 New patch that only falls back to float when 3rd arg is None. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 12:52 Message: Logged In: YES user_id=6380 Tough luck. :-) There may be something else wrong with the patch: it probably shouldn't fall back to float when z is not None. After all, pow(x, y, z) should compute x**y % z, and I'm sure that someone using this would be quite surprised to get a floating point number back if they accidentally let y become negative! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 12:46 Message: Logged In: YES user_id=31435 No objection so far as it goes, but surely long_pow() should also attempt the same kind of thing then. Should add some test cases and docs too (yes, I'm going to hold you to the same stds as contributors ). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440487&group_id=5470 From noreply@sourceforge.net Wed Jul 11 21:04:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 13:04:59 -0700 Subject: [Patches] [ python-Patches-440487 ] int to the negative power -> float Message-ID: Patches item #440487, was opened at 2001-07-11 12:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440487&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Tim Peters (tim_one) Summary: int to the negative power -> float Initial Comment: Currently, int to the negative int power raises an exception. This was one of the two problems that the VPython users complained about. (The other was that integer division returns a truncated integer, but that's another story. :-) I propose to implement this in Python 2.2. Anybody have a problem with this? ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-11 13:04 Message: Logged In: YES user_id=31435 Tough luck for you, you mean . I considered z != None and didn't care. They're going to be just as surprised by i**j returning a float if j accidentally becomes negative. When making a formerly exceptional case "mean something", potential surprise is unavoidable, and if in the new world 2 ** -3 % 1 returns 0.125 is will be just as surprising if pow(2, -3, 1) does not return 0.125. The new rules should be consistent with *themselves* more than with oddball cases across releases. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 12:59 Message: Logged In: YES user_id=6380 New patch that only falls back to float when 3rd arg is None. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 12:52 Message: Logged In: YES user_id=6380 Tough luck. :-) There may be something else wrong with the patch: it probably shouldn't fall back to float when z is not None. After all, pow(x, y, z) should compute x**y % z, and I'm sure that someone using this would be quite surprised to get a floating point number back if they accidentally let y become negative! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 12:46 Message: Logged In: YES user_id=31435 No objection so far as it goes, but surely long_pow() should also attempt the same kind of thing then. Should add some test cases and docs too (yes, I'm going to hold you to the same stds as contributors ). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440487&group_id=5470 From noreply@sourceforge.net Wed Jul 11 21:23:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 13:23:58 -0700 Subject: [Patches] [ python-Patches-440487 ] int to the negative power -> float Message-ID: Patches item #440487, was opened at 2001-07-11 12:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440487&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Tim Peters (tim_one) Summary: int to the negative power -> float Initial Comment: Currently, int to the negative int power raises an exception. This was one of the two problems that the VPython users complained about. (The other was that integer division returns a truncated integer, but that's another story. :-) I propose to implement this in Python 2.2. Anybody have a problem with this? ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-11 13:23 Message: Logged In: YES user_id=31435 I liked the first patch better. *Looks* like under the new patch pow(2, -3, 1) will raise a ValueError but 2 ** -3 % 1 will return 0.125. That's close to inexplicable. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 13:04 Message: Logged In: YES user_id=31435 Tough luck for you, you mean . I considered z != None and didn't care. They're going to be just as surprised by i**j returning a float if j accidentally becomes negative. When making a formerly exceptional case "mean something", potential surprise is unavoidable, and if in the new world 2 ** -3 % 1 returns 0.125 is will be just as surprising if pow(2, -3, 1) does not return 0.125. The new rules should be consistent with *themselves* more than with oddball cases across releases. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 12:59 Message: Logged In: YES user_id=6380 New patch that only falls back to float when 3rd arg is None. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 12:52 Message: Logged In: YES user_id=6380 Tough luck. :-) There may be something else wrong with the patch: it probably shouldn't fall back to float when z is not None. After all, pow(x, y, z) should compute x**y % z, and I'm sure that someone using this would be quite surprised to get a floating point number back if they accidentally let y become negative! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 12:46 Message: Logged In: YES user_id=31435 No objection so far as it goes, but surely long_pow() should also attempt the same kind of thing then. Should add some test cases and docs too (yes, I'm going to hold you to the same stds as contributors ). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440487&group_id=5470 From noreply@sourceforge.net Wed Jul 11 21:31:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 13:31:56 -0700 Subject: [Patches] [ python-Patches-439364 ] GC for frames and generators Message-ID: Patches item #439364, was opened at 2001-07-07 15:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439364&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Neil Schemenauer (nascheme) Summary: GC for frames and generators Initial Comment: For me, test_generators leaks, with or without this patch. The number of objects tracked by the GC does not increase but memory usage does. There must be other objects creating cycles that are not tracked by the GC. I haven't profiled the effect this change. I have another patch in the works that should minimize the performance hit. Please examine frame_traverse and frame_clear closely. I'm not 100% sure that I am chasing all the references necessary to find cycles or that I am dropping enough to break them. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-07-11 13:31 Message: Logged In: YES user_id=35752 I believe this patch does the trick. The performance hit is larger than I would like however. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-10 20:45 Message: Logged In: YES user_id=31435 The newly attached bmoleak.py shows a similar leak without any generators, involving seqiterobjects alone. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-09 21:34 Message: Logged In: YES user_id=31435 I expect what's going on here is the obvious thing: clearing the LazyList dict stops the leak, but the dict only holds two things: a vanilla list of integers, and a bound method object. Since a list of ints can't cause a cycle, it must be the latter; and, indeed, a quick glance at methodobject.c shows GC doesn't chase PyCFunction_Type (yet). The bound method object in this case wraps the .next() method of a generator-iterator object, and there's a cycle: the LazyList fib maps fib.fetch to the fibgen() generator-iterator's .next method, from which we can get to the fibgen g-i, which in turn contains (indirect) references back to fib thanks to passing iter(fib) to the sum() and head() generators. Looks like breaking this by magic requires adding both seqiterobjects and PyCFunctionObjects to GC. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-09 14:08 Message: Logged In: YES user_id=31435 The attached fibleak.py is a self-contained massive leaker. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-09 13:48 Message: Logged In: YES user_id=31435 + Performance hit is about a 2.5% slowdown. More than I hoped, but less than I feared . + The leak after the patch is solely due to fun_tests. Comment out the other lines in the __test__ dict, and on my box it leaks about half a megabyte per second then -- very dramatic, and impossible to ascribe to anything but a leak. + I don't know what causes the leak. Offhand my first guess would be unchased pointers inside traceback objects. Indeed, the first thing I'd *try* is adding tracebackobject to GC too just to see whether that made the leak go away (much easier than thinking about it <0.9 wink>). ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-07-09 07:11 Message: Logged In: YES user_id=35752 Your right, it doesn't leak before the patch. The process size goes up slowly be eventually stops increasing. After the patch the size continues going up slowly. :-( I'll try to find what is still leaking. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-08 21:40 Message: Logged In: YES user_id=31435 Thanks, Neil! I've been too overwhelmed with merging descr- branch code to look at this until now. Clarification, please: when you say "test_generators leaks, with or without this patch", what exactly do you mean by "leak"? It does not leak for me before the patch (haven't yet tried it with the patch), and this is what I mean-- exactly -- by "does not leak": I change a stock CVS build by changing "if 0:" to "if 1:" in test_generators.py's test_main, then let it run and run and run. Now on Win98SE, the heap space *does* grow very slowly and steadily, until it reaches about 3600Kb. Sometimes a little more, sometimes a little less, depending on what else I'm doing at the time. It takes about 5 minutes of CPU time on a 866MHz box to reach that. But then it *stays* at this point forever after (well, after another 10 minutes of CPU time it hasn't budged -- Win98SE probably can't run forever ). This is presumably because Win98SE malloc is lazy about coalescing free()'d memory until it nears a 4Mb boundary (at which point it starts rearranging VM address space-- because 4Mb is all the address space the system allocates to the initial heap --and it's very reluctant to do that). So if you're seeing a very slow "leak" (are you?), you *may* just be seeing a platform malloc reluctant to defragment free()'d memory. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439364&group_id=5470 From noreply@sourceforge.net Wed Jul 11 21:33:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 13:33:10 -0700 Subject: [Patches] [ python-Patches-439364 ] GC for frames and generators Message-ID: Patches item #439364, was opened at 2001-07-07 15:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439364&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Tim Peters (tim_one) Summary: GC for frames and generators Initial Comment: For me, test_generators leaks, with or without this patch. The number of objects tracked by the GC does not increase but memory usage does. There must be other objects creating cycles that are not tracked by the GC. I haven't profiled the effect this change. I have another patch in the works that should minimize the performance hit. Please examine frame_traverse and frame_clear closely. I'm not 100% sure that I am chasing all the references necessary to find cycles or that I am dropping enough to break them. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-07-11 13:31 Message: Logged In: YES user_id=35752 I believe this patch does the trick. The performance hit is larger than I would like however. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-10 20:45 Message: Logged In: YES user_id=31435 The newly attached bmoleak.py shows a similar leak without any generators, involving seqiterobjects alone. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-09 21:34 Message: Logged In: YES user_id=31435 I expect what's going on here is the obvious thing: clearing the LazyList dict stops the leak, but the dict only holds two things: a vanilla list of integers, and a bound method object. Since a list of ints can't cause a cycle, it must be the latter; and, indeed, a quick glance at methodobject.c shows GC doesn't chase PyCFunction_Type (yet). The bound method object in this case wraps the .next() method of a generator-iterator object, and there's a cycle: the LazyList fib maps fib.fetch to the fibgen() generator-iterator's .next method, from which we can get to the fibgen g-i, which in turn contains (indirect) references back to fib thanks to passing iter(fib) to the sum() and head() generators. Looks like breaking this by magic requires adding both seqiterobjects and PyCFunctionObjects to GC. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-09 14:08 Message: Logged In: YES user_id=31435 The attached fibleak.py is a self-contained massive leaker. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-09 13:48 Message: Logged In: YES user_id=31435 + Performance hit is about a 2.5% slowdown. More than I hoped, but less than I feared . + The leak after the patch is solely due to fun_tests. Comment out the other lines in the __test__ dict, and on my box it leaks about half a megabyte per second then -- very dramatic, and impossible to ascribe to anything but a leak. + I don't know what causes the leak. Offhand my first guess would be unchased pointers inside traceback objects. Indeed, the first thing I'd *try* is adding tracebackobject to GC too just to see whether that made the leak go away (much easier than thinking about it <0.9 wink>). ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-07-09 07:11 Message: Logged In: YES user_id=35752 Your right, it doesn't leak before the patch. The process size goes up slowly be eventually stops increasing. After the patch the size continues going up slowly. :-( I'll try to find what is still leaking. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-08 21:40 Message: Logged In: YES user_id=31435 Thanks, Neil! I've been too overwhelmed with merging descr- branch code to look at this until now. Clarification, please: when you say "test_generators leaks, with or without this patch", what exactly do you mean by "leak"? It does not leak for me before the patch (haven't yet tried it with the patch), and this is what I mean-- exactly -- by "does not leak": I change a stock CVS build by changing "if 0:" to "if 1:" in test_generators.py's test_main, then let it run and run and run. Now on Win98SE, the heap space *does* grow very slowly and steadily, until it reaches about 3600Kb. Sometimes a little more, sometimes a little less, depending on what else I'm doing at the time. It takes about 5 minutes of CPU time on a 866MHz box to reach that. But then it *stays* at this point forever after (well, after another 10 minutes of CPU time it hasn't budged -- Win98SE probably can't run forever ). This is presumably because Win98SE malloc is lazy about coalescing free()'d memory until it nears a 4Mb boundary (at which point it starts rearranging VM address space-- because 4Mb is all the address space the system allocates to the initial heap --and it's very reluctant to do that). So if you're seeing a very slow "leak" (are you?), you *may* just be seeing a platform malloc reluctant to defragment free()'d memory. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439364&group_id=5470 From noreply@sourceforge.net Wed Jul 11 22:45:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 14:45:39 -0700 Subject: [Patches] [ python-Patches-440144 ] Tests and minor bugfix for uu module Message-ID: Patches item #440144, was opened at 2001-07-10 10:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440144&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Tim Peters (tim_one) Summary: Tests and minor bugfix for uu module Initial Comment: Inspired by a Post by Tim to c.l.py this morning, I've decided to try my hand at writing real test cases for some of the modules formerly tested only by test_sundry.py. This is my first attempt: a set of tests for the uu.py module. In the process of writing the tests, I found a minor bug in uu: its tests for a missing 'end' line would never trigger. Files included are: a patch for uu.py and test_sundry.py, a new test_uu.py file, and an output file for test_uu. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-11 14:45 Message: Logged In: YES user_id=31435 This took a bit of work to run on Windows. The "pass a bare file name" interface is deprecated, in part because it's impossible to get this to work correctly x-platform unless the caller opens file objects with the correct text- vs-binary mode distinctions. We also have a (possibly undocumented?) convention that all temp files have names based on test_support.TESTFN, and that we don't muck with other directories. After making those changes, I gratefully checked it in. Thanks again! Lib/test/test_sundry.py, new revision: 1.5 Lib/test/test_uu.py, initial revision: 1.1 ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-07-10 22:07 Message: Logged In: YES user_id=499 I've added a new version of test_uu.py that seems to do the right thing. (I haven't figured out how to make Sourceforge replace the old ones, if such is possible.) As you said, test_uu is now unneeded. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-10 21:09 Message: Logged In: YES user_id=31435 Thank you, Nick! Since we hope to convert the entire test suite to a mix of doctest and unittest eventually, and those don't use "expected output" files, I'd like you to change this test to stop needing an expected-output file. You can do this easily, by importing "verbose" from test_support too, and putting the existing instances of e.g. print '1. encode file->file' under the protection of if verbose: Then the new test_uu isn't needed at all. The bug you found in uu.py is gross! Thanks for that too. I applied that part of the patch to the source tree, as Lib/uu.py, new revision: 1.17 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440144&group_id=5470 From noreply@sourceforge.net Wed Jul 11 22:46:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 14:46:32 -0700 Subject: [Patches] [ python-Patches-440487 ] int to the negative power -> float Message-ID: Patches item #440487, was opened at 2001-07-11 12:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440487&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) >Assigned to: Guido van Rossum (gvanrossum) Summary: int to the negative power -> float Initial Comment: Currently, int to the negative int power raises an exception. This was one of the two problems that the VPython users complained about. (The other was that integer division returns a truncated integer, but that's another story. :-) I propose to implement this in Python 2.2. Anybody have a problem with this? ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-11 14:46 Message: Logged In: YES user_id=31435 Back to Guido. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 13:23 Message: Logged In: YES user_id=31435 I liked the first patch better. *Looks* like under the new patch pow(2, -3, 1) will raise a ValueError but 2 ** -3 % 1 will return 0.125. That's close to inexplicable. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 13:04 Message: Logged In: YES user_id=31435 Tough luck for you, you mean . I considered z != None and didn't care. They're going to be just as surprised by i**j returning a float if j accidentally becomes negative. When making a formerly exceptional case "mean something", potential surprise is unavoidable, and if in the new world 2 ** -3 % 1 returns 0.125 is will be just as surprising if pow(2, -3, 1) does not return 0.125. The new rules should be consistent with *themselves* more than with oddball cases across releases. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 12:59 Message: Logged In: YES user_id=6380 New patch that only falls back to float when 3rd arg is None. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 12:52 Message: Logged In: YES user_id=6380 Tough luck. :-) There may be something else wrong with the patch: it probably shouldn't fall back to float when z is not None. After all, pow(x, y, z) should compute x**y % z, and I'm sure that someone using this would be quite surprised to get a floating point number back if they accidentally let y become negative! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 12:46 Message: Logged In: YES user_id=31435 No objection so far as it goes, but surely long_pow() should also attempt the same kind of thing then. Should add some test cases and docs too (yes, I'm going to hold you to the same stds as contributors ). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440487&group_id=5470 From noreply@sourceforge.net Wed Jul 11 23:15:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 15:15:23 -0700 Subject: [Patches] [ python-Patches-440170 ] Tests for fileinput module Message-ID: Patches item #440170, was opened at 2001-07-10 12:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440170&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Tim Peters (tim_one) Summary: Tests for fileinput module Initial Comment: Inspired by a Post by Tim to c.l.py this morning, I've decided to try my hand at writing real test cases for some of the modules formerly tested only by test_sundry.py. This is my second attempt: a set of tests for the fileinput.py module. ---------------------------------------------------------------------- >Comment By: Nick Mathewson (nickm) Date: 2001-07-11 15:15 Message: Logged In: YES user_id=499 Tim says that tempfile is bad in unit tests, and TESTFN is good. I've uploaded a new version of test_fileinput.py that uses TESTFN. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-07-10 22:09 Message: Logged In: YES user_id=499 I've updated the tests for fileinput.py to do the right thing, and obey Guido's style guidelines. I don't know whether Sourceforge will let me replace the old ones, though. :/ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-10 21:14 Message: Logged In: YES user_id=31435 As with the uu test, please change this too not to need an expected-output file (make the print stmts conditional, under "if test_support.verbose:"). Note that Guido's style guide requires a single space after commas (in argument lists and tuples specifically). So e.g. def runTests(t1, t2, t3, t4, bs=0, round=0): not def runTests(t1,t2,t3,t4,bs=0,round=0): ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440170&group_id=5470 From noreply@sourceforge.net Wed Jul 11 23:22:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 15:22:52 -0700 Subject: [Patches] [ python-Patches-440170 ] Tests for fileinput module Message-ID: Patches item #440170, was opened at 2001-07-10 12:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440170&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Tim Peters (tim_one) Summary: Tests for fileinput module Initial Comment: Inspired by a Post by Tim to c.l.py this morning, I've decided to try my hand at writing real test cases for some of the modules formerly tested only by test_sundry.py. This is my second attempt: a set of tests for the fileinput.py module. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-11 15:22 Message: Logged In: YES user_id=31435 Too late ! Already checked in a fiddled version: Lib/test/test_fileinput.py, initial revision: 1.1 Lib/test/test_sundry.py, new revision: 1.6 ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-07-11 15:15 Message: Logged In: YES user_id=499 Tim says that tempfile is bad in unit tests, and TESTFN is good. I've uploaded a new version of test_fileinput.py that uses TESTFN. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-07-10 22:09 Message: Logged In: YES user_id=499 I've updated the tests for fileinput.py to do the right thing, and obey Guido's style guidelines. I don't know whether Sourceforge will let me replace the old ones, though. :/ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-10 21:14 Message: Logged In: YES user_id=31435 As with the uu test, please change this too not to need an expected-output file (make the print stmts conditional, under "if test_support.verbose:"). Note that Guido's style guide requires a single space after commas (in argument lists and tuples specifically). So e.g. def runTests(t1, t2, t3, t4, bs=0, round=0): not def runTests(t1,t2,t3,t4,bs=0,round=0): ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440170&group_id=5470 From noreply@sourceforge.net Thu Jul 12 00:18:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 16:18:06 -0700 Subject: [Patches] [ python-Patches-440487 ] int to the negative power -> float Message-ID: Patches item #440487, was opened at 2001-07-11 12:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440487&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) >Assigned to: Tim Peters (tim_one) Summary: int to the negative power -> float Initial Comment: Currently, int to the negative int power raises an exception. This was one of the two problems that the VPython users complained about. (The other was that integer division returns a truncated integer, but that's another story. :-) I propose to implement this in Python 2.2. Anybody have a problem with this? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 16:18 Message: Logged In: YES user_id=6380 OK, here's a new patch, for int and long. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 14:46 Message: Logged In: YES user_id=31435 Back to Guido. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 13:23 Message: Logged In: YES user_id=31435 I liked the first patch better. *Looks* like under the new patch pow(2, -3, 1) will raise a ValueError but 2 ** -3 % 1 will return 0.125. That's close to inexplicable. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 13:04 Message: Logged In: YES user_id=31435 Tough luck for you, you mean . I considered z != None and didn't care. They're going to be just as surprised by i**j returning a float if j accidentally becomes negative. When making a formerly exceptional case "mean something", potential surprise is unavoidable, and if in the new world 2 ** -3 % 1 returns 0.125 is will be just as surprising if pow(2, -3, 1) does not return 0.125. The new rules should be consistent with *themselves* more than with oddball cases across releases. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 12:59 Message: Logged In: YES user_id=6380 New patch that only falls back to float when 3rd arg is None. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 12:52 Message: Logged In: YES user_id=6380 Tough luck. :-) There may be something else wrong with the patch: it probably shouldn't fall back to float when z is not None. After all, pow(x, y, z) should compute x**y % z, and I'm sure that someone using this would be quite surprised to get a floating point number back if they accidentally let y become negative! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 12:46 Message: Logged In: YES user_id=31435 No objection so far as it goes, but surely long_pow() should also attempt the same kind of thing then. Should add some test cases and docs too (yes, I'm going to hold you to the same stds as contributors ). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440487&group_id=5470 From noreply@sourceforge.net Thu Jul 12 02:16:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 18:16:34 -0700 Subject: [Patches] [ python-Patches-440487 ] int to the negative power -> float Message-ID: Patches item #440487, was opened at 2001-07-11 12:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440487&group_id=5470 Category: core (C code) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Guido van Rossum (gvanrossum) >Assigned to: Guido van Rossum (gvanrossum) Summary: int to the negative power -> float Initial Comment: Currently, int to the negative int power raises an exception. This was one of the two problems that the VPython users complained about. (The other was that integer division returns a truncated integer, but that's another story. :-) I propose to implement this in Python 2.2. Anybody have a problem with this? ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-11 18:16 Message: Logged In: YES user_id=31435 Marked Accepted and back to Guido. The comments should say "the" instead of "both", since there are 3 arguments. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 16:18 Message: Logged In: YES user_id=6380 OK, here's a new patch, for int and long. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 14:46 Message: Logged In: YES user_id=31435 Back to Guido. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 13:23 Message: Logged In: YES user_id=31435 I liked the first patch better. *Looks* like under the new patch pow(2, -3, 1) will raise a ValueError but 2 ** -3 % 1 will return 0.125. That's close to inexplicable. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 13:04 Message: Logged In: YES user_id=31435 Tough luck for you, you mean . I considered z != None and didn't care. They're going to be just as surprised by i**j returning a float if j accidentally becomes negative. When making a formerly exceptional case "mean something", potential surprise is unavoidable, and if in the new world 2 ** -3 % 1 returns 0.125 is will be just as surprising if pow(2, -3, 1) does not return 0.125. The new rules should be consistent with *themselves* more than with oddball cases across releases. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 12:59 Message: Logged In: YES user_id=6380 New patch that only falls back to float when 3rd arg is None. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 12:52 Message: Logged In: YES user_id=6380 Tough luck. :-) There may be something else wrong with the patch: it probably shouldn't fall back to float when z is not None. After all, pow(x, y, z) should compute x**y % z, and I'm sure that someone using this would be quite surprised to get a floating point number back if they accidentally let y become negative! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 12:46 Message: Logged In: YES user_id=31435 No objection so far as it goes, but surely long_pow() should also attempt the same kind of thing then. Should add some test cases and docs too (yes, I'm going to hold you to the same stds as contributors ). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440487&group_id=5470 From noreply@sourceforge.net Thu Jul 12 02:41:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 18:41:03 -0700 Subject: [Patches] [ python-Patches-439364 ] GC for frames and generators Message-ID: Patches item #439364, was opened at 2001-07-07 15:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439364&group_id=5470 Category: core (C code) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Neil Schemenauer (nascheme) Summary: GC for frames and generators Initial Comment: For me, test_generators leaks, with or without this patch. The number of objects tracked by the GC does not increase but memory usage does. There must be other objects creating cycles that are not tracked by the GC. I haven't profiled the effect this change. I have another patch in the works that should minimize the performance hit. Please examine frame_traverse and frame_clear closely. I'm not 100% sure that I am chasing all the references necessary to find cycles or that I am dropping enough to break them. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-11 18:41 Message: Logged In: YES user_id=31435 Accepted, and back to Neil for checkin. I see no leaks anymore. Thank you! Disgustingly straightforward, wasn't it ? The fact that these cycles were so painful to track down (despite being straightforward!) convinces me there's no future in overlooking the leaks but trying to rationalize them away on performance grounds. The patch makes necessary progress, and we can worry about reclaiming performance as a separate project (btw, that's easier for me if this is checked in so there's a new baseline to work against). ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-07-11 13:31 Message: Logged In: YES user_id=35752 I believe this patch does the trick. The performance hit is larger than I would like however. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-10 20:45 Message: Logged In: YES user_id=31435 The newly attached bmoleak.py shows a similar leak without any generators, involving seqiterobjects alone. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-09 21:34 Message: Logged In: YES user_id=31435 I expect what's going on here is the obvious thing: clearing the LazyList dict stops the leak, but the dict only holds two things: a vanilla list of integers, and a bound method object. Since a list of ints can't cause a cycle, it must be the latter; and, indeed, a quick glance at methodobject.c shows GC doesn't chase PyCFunction_Type (yet). The bound method object in this case wraps the .next() method of a generator-iterator object, and there's a cycle: the LazyList fib maps fib.fetch to the fibgen() generator-iterator's .next method, from which we can get to the fibgen g-i, which in turn contains (indirect) references back to fib thanks to passing iter(fib) to the sum() and head() generators. Looks like breaking this by magic requires adding both seqiterobjects and PyCFunctionObjects to GC. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-09 14:08 Message: Logged In: YES user_id=31435 The attached fibleak.py is a self-contained massive leaker. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-09 13:48 Message: Logged In: YES user_id=31435 + Performance hit is about a 2.5% slowdown. More than I hoped, but less than I feared . + The leak after the patch is solely due to fun_tests. Comment out the other lines in the __test__ dict, and on my box it leaks about half a megabyte per second then -- very dramatic, and impossible to ascribe to anything but a leak. + I don't know what causes the leak. Offhand my first guess would be unchased pointers inside traceback objects. Indeed, the first thing I'd *try* is adding tracebackobject to GC too just to see whether that made the leak go away (much easier than thinking about it <0.9 wink>). ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-07-09 07:11 Message: Logged In: YES user_id=35752 Your right, it doesn't leak before the patch. The process size goes up slowly be eventually stops increasing. After the patch the size continues going up slowly. :-( I'll try to find what is still leaking. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-08 21:40 Message: Logged In: YES user_id=31435 Thanks, Neil! I've been too overwhelmed with merging descr- branch code to look at this until now. Clarification, please: when you say "test_generators leaks, with or without this patch", what exactly do you mean by "leak"? It does not leak for me before the patch (haven't yet tried it with the patch), and this is what I mean-- exactly -- by "does not leak": I change a stock CVS build by changing "if 0:" to "if 1:" in test_generators.py's test_main, then let it run and run and run. Now on Win98SE, the heap space *does* grow very slowly and steadily, until it reaches about 3600Kb. Sometimes a little more, sometimes a little less, depending on what else I'm doing at the time. It takes about 5 minutes of CPU time on a 866MHz box to reach that. But then it *stays* at this point forever after (well, after another 10 minutes of CPU time it hasn't budged -- Win98SE probably can't run forever ). This is presumably because Win98SE malloc is lazy about coalescing free()'d memory until it nears a 4Mb boundary (at which point it starts rearranging VM address space-- because 4Mb is all the address space the system allocates to the initial heap --and it's very reluctant to do that). So if you're seeing a very slow "leak" (are you?), you *may* just be seeing a platform malloc reluctant to defragment free()'d memory. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439364&group_id=5470 From wwwjessie@21cn.com Thu Jul 12 10:59:33 2001 From: wwwjessie@21cn.com (wwwjessie@21cn.com) Date: Thu, 12 Jul 2001 17:59:33 +0800 Subject: [Patches] =?gb2312?B?xvPStcnPzfijrNK7sr21vc67KFlvdXIgb25saW5lIGNvbXBhbnkp?= Message-ID: <324be01c10ab9$59e2d530$9300a8c0@ifood1gongxing> This is a multi-part message in MIME format. ------=_NextPart_000_324BF_01C10AFC.68061530 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 1/C+tLXEu+HUsaOsxPq6w6Oh0rzKs8a31tC5+s34t/7O8dDFz6K5qcT6ss6/vKO6ICANCg0K07XT 0NfUvLq1xM34yc+5q8u+o6zVucq+uavLvrL6xre6zbf+zvGjrMzhuN/G89K1vrrV+cGmLMT609DB vdbW0aHU8aO6DQoNCjEvIM341b62qNbGIDxodHRwOi8vd3d3Lmlmb29kMS5jb20vYWJvdXR1cy9v dXJzZXJ2aWNlcy93ZWIuYXNwPiAgOg0K19S8us6su6S4/NDCo6y53MDtx7DMqLrzzKijrLj5vt3G 89K10OjSqqOsvajBotfUvLq1xM34yc+5q8u+o6zK/b7dv+LEo7/pyM7E+tGh1PGjusnMx+nQxc+i t6KyvCzN+MnPsvrGt9W5yr6jrL/Nu6e3/s7x1tDQxCzN+MnPubrO78+1zbMsv827p7nYDQrPtbnc wO0szfjJz8LbzLMszfjJz7vh0unW0NDELM34yc/V0Ma4LM22xrHPtc2zLNfKwc/PwtTY1tDQxCzO yr7ttfey6Swg1dCx6rLJubrPtc2zLLfDzsrV382zvMa31s72LCDBxMzsytIovbvB96GizLjF0Cmh raGtDQoNCs/rwcu94sr9vt2/4sSjv+nR3cq+1tDQxKO/x+vBqs+1o7ogc2FsZXNAaWZvb2QxLmNv bSA8bWFpbHRvOnNhbGVzQGlmb29kMS5jb20+DQqhobXnu7CjujA3NTUtMzc4NjMwOaGhz/rK27K/ yfLQob3jDQoNCjIvINK8zfjNqCA8aHR0cDovL29uZXQuaWZvb2QxLmNvbS8+DQot19TW+sq9vajN +KOsstnX97zytaWjrLy0vai8tNPDo7q/ydW5yr4zMNXFu/K4/Lbg1dXGrKOs19TW+sq9zqy7pKOs v8nL5sqxuPzQws28xqy6zc7E19bE2sjdo6zU2s/ft6KyvLL6xrfQxc+ioaK5q8u+tq/MrLXIo6zU +cvNtv68trn6vMrT8sP7KA0KyOdodHRwOi8veW91cm5hbWUuaWZvb2QxLmNvbSmjrNPr0rzKs8a3 1tC5+s34KNKzw+bkr8DAwb/UwtPiMjAwzfK0zim99MPcway906OszOG438LyvNK6zbnLv823w87K wb+jrLaoxtrK1bW90rzKsw0KxrfW0Ln6zfjM4bmptcS/zbun0OjH87rNssm5utDFz6Khow0KDQoN Cg0KN9TCMzDI1cewyerH67KiuLa/7sq508PSvM34zaijrMzYsfDTxbvdvNszODAw1KovxOqjrNT5 y83M9cLrueO45rKiw+K30dTayrPGt9eo0rXU09a+v6+1x7mpo6zH86OstPrA7aOsus/X99DFz6IN Cs/rwcu94rj8tuA/IKGhx+vBqs+1o7ogc2FsZXNAaWZvb2QxLmNvbSA8bWFpbHRvOnNhbGVzQGlm b29kMS5jb20+DQqhobXnu7CjujA3NTUtMzc4NjMwOaGhoaHP+srbsr/J8tChveMNCrvyILfDzsrO 0sPHtcTN+NKzIDxodHRwOi8vd3d3Lmlmb29kMS5jb20vYWJvdXR1cy9vdXJzZXJ2aWNlcy9jcHNl cnZpY2UuYXNwPg0KOnd3dy5pZm9vZDEuY29tDQoNCrvY1rSjqMfrtKvV5qO6MDc1NS0zMjM5MDQ3 u/K3orXn19PTyrz+o7ogc2FsZXNAaWZvb2QxLmNvbSA8bWFpbHRvOnNhbGVzQGlmb29kMS5jb20+ IKOpDQoNCqH1ILG+uavLvrbUzfjVvrao1sa40NDLyKShoaGhICAgICAgICAgICAgICAgICAgICAg ofUgsb65q8u+ttTSvM34zai3/s7xuNDQy8ikDQoNCrmry77D+7PGo7pfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX1/Bqs+1yMujul9fX19fX19fX19fX19fX19fXw0K X19fX18gDQoNCrXnu7Cjul9fX19fX19fX19fX19fX19fX19fX7Sr1eajul9fX19fX19fX19fX19f X19fX19fX19FLW1haWyjul9fX19fX19fX19fX19fX18NCl9fX19fXyANCg0K ------=_NextPart_000_324BF_01C10AFC.68061530 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PEhUTUw+DQo8SEVBRD4NCjxUSVRMRT5VbnRpdGxlZCBEb2N1bWVudDwvVElUTEU+IDxNRVRBIEhU VFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMx MiI+IA0KPC9IRUFEPg0KDQo8Qk9EWSBCR0NPTE9SPSIjRkZGRkZGIiBURVhUPSIjMDAwMDAwIj4N CjxUQUJMRSBXSURUSD0iOTglIiBCT1JERVI9IjAiIENFTExTUEFDSU5HPSIwIiBDRUxMUEFERElO Rz0iMCI+PFRSPjxURD48UCBDTEFTUz1Nc29Ob3JtYWwgU1RZTEU9J21hcmdpbi1yaWdodDotMTcu ODVwdDtsaW5lLWhlaWdodDoxNTAlJz48Rk9OVCBTSVpFPSIyIj7X8L60tcS74dSxo6zE+rrDo6HS vMqzxrfW0Ln6zfi3/s7x0MXPormpxPqyzr+8o7ombmJzcDs8L0ZPTlQ+IA0KPC9QPjxQIENMQVNT PU1zb05vcm1hbCBTVFlMRT0nbWFyZ2luLXJpZ2h0Oi0xNy44NXB0O2xpbmUtaGVpZ2h0OjE1MCUn PjxGT05UIFNJWkU9IjIiPtO109DX1Ly6tcTN+MnPuavLvqOs1bnKvrmry76y+sa3us23/s7xo6zM 4bjfxvPStb661fnBpizE+tPQwb3W1tGh1PGjujxCUj48QlI+MS8gDQo8QQ0KSFJFRj0iaHR0cDov L3d3dy5pZm9vZDEuY29tL2Fib3V0dXMvb3Vyc2VydmljZXMvd2ViLmFzcCI+zfjVvrao1sY8L0E+ IDog19S8us6su6S4/NDCo6y53MDtx7DMqLrzzKijrLj5vt3G89K10OjSqqOsvajBotfUvLq1xM34 yc+5q8u+o6zK/b7dv+LEo7/pyM7E+tGh1PGjusnMx+nQxc+it6KyvCzN+MnPsvrGt9W5yr6jrL/N u6e3/s7x1tDQxCzN+MnPubrO78+1zbMsv827p7nYz7W53MDtLM34yc/C28yzLM34yc+74dLp1tDQ xCzN+MnP1dDGuCzNtsaxz7XNsyzXysHPz8LU2NbQ0MQszsq+7bX3suksIA0K1dCx6rLJubrPtc2z LLfDzsrV382zvMa31s72LCDBxMzsytIovbvB96GizLjF0CmhraGtPC9GT05UPjwvUD48UCBDTEFT Uz1Nc29Ob3JtYWwgU1RZTEU9J2xpbmUtaGVpZ2h0OjIwLjBwdCc+PEI+PEZPTlQgQ09MT1I9IiNG RjAwMDAiPs/rwcu94sr9vt2/4sSjv+nR3cq+1tDQxKO/PC9GT05UPjwvQj48Rk9OVCBTSVpFPSIy Ij7H68Gqz7WjujxBIEhSRUY9Im1haWx0bzpzYWxlc0BpZm9vZDEuY29tIj5zYWxlc0BpZm9vZDEu Y29tPC9BPiANCqGhtee7sKO6MDc1NS0zNzg2MzA5oaHP+srbsr/J8tChveM8L0ZPTlQ+PC9QPjxQ IENMQVNTPU1zb05vcm1hbCBTVFlMRT0nbGluZS1oZWlnaHQ6MjAuMHB0Jz48L1A+PFAgQ0xBU1M9 TXNvTm9ybWFsIFNUWUxFPSdsaW5lLWhlaWdodDoyMC4wcHQnPjxGT05UIFNJWkU9IjIiPjIvIA0K PEEgSFJFRj0iaHR0cDovL29uZXQuaWZvb2QxLmNvbS8iPtK8zfjNqDwvQT4t19TW+sq9vajN+KOs stnX97zytaWjrLy0vai8tNPDo7q/ydW5yr4zMNXFu/K4/Lbg1dXGrKOs19TW+sq9zqy7pKOsv8nL 5sqxuPzQws28xqy6zc7E19bE2sjdo6zU2s/ft6KyvLL6xrfQxc+ioaK5q8u+tq/MrLXIo6zU+cvN tv68trn6vMrT8sP7KMjnaHR0cDovL3lvdXJuYW1lLmlmb29kMS5jb20po6zT69K8yrPGt9bQufrN +CjSs8Pm5K/AwMG/1MLT4jIwMM3ytM4pvfTD3MGsvdOjrMzhuN/C8rzSus25y7/Nt8POysG/o6y2 qMbaytW1vdK8yrPGt9bQufrN+Mzhuam1xL/Nu6fQ6Mfzus2yybm60MXPoqGjPEJSPjwvRk9OVD48 L1A+PFAgQ0xBU1M9TXNvTm9ybWFsIFNUWUxFPSdtYXJnaW4tcmlnaHQ6LTE3Ljg1cHQ7bGluZS1o ZWlnaHQ6MTUwJSc+PEZPTlQgU0laRT0iMiI+PEJSPjwvRk9OVD4gDQo8Qj48Rk9OVCBDT0xPUj0i I0ZGMDAwMCI+NzwvRk9OVD48L0I+PEZPTlQgQ09MT1I9IiNGRjAwMDAiPjxCPtTCMzDI1cewyerH 67KiuLa/7sq508PSvM34zaijrMzYsfDTxbvdvNszODAw1KovxOqjrNT5y83M9cLrueO45rKiw+K3 0dTayrPGt9eo0rXU09a+v6+1x7mpo6zH86OstPrA7aOsus/X99DFz6I8L0I+PEJSPjwvRk9OVD4g DQo8Rk9OVCBTSVpFPSIyIj7P68HLveK4/LbgPyChocfrwarPtaO6PEEgSFJFRj0ibWFpbHRvOnNh bGVzQGlmb29kMS5jb20iPnNhbGVzQGlmb29kMS5jb208L0E+IA0KoaG157uwo7owNzU1LTM3ODYz MDmhoaGhz/rK27K/yfLQob3jPEJSPjwvRk9OVD48Rk9OVCBTSVpFPSIyIj678jxBDQpIUkVGPSJo dHRwOi8vd3d3Lmlmb29kMS5jb20vYWJvdXR1cy9vdXJzZXJ2aWNlcy9jcHNlcnZpY2UuYXNwIj63 w87KztLDx7XEzfjSszwvQT46d3d3Lmlmb29kMS5jb208L0ZPTlQ+PC9QPjxQIENMQVNTPU1zb05v cm1hbCBTVFlMRT0nbGluZS1oZWlnaHQ6MjAuMHB0JyBBTElHTj0iTEVGVCI+PC9QPjxQIENMQVNT PU1zb05vcm1hbCBBTElHTj1MRUZUIFNUWUxFPSdsaW5lLWhlaWdodDoyMC4wcHQnPjxGT05UIFNJ WkU9IjIiPjxCPrvY1rSjqMfrtKvV5qO6MDc1NS0zMjM5MDQ3u/K3orXn19PTyrz+o7o8L0I+PEEN CkhSRUY9Im1haWx0bzpzYWxlc0BpZm9vZDEuY29tIj5zYWxlc0BpZm9vZDEuY29tIDwvQT48Qj6j qTwvQj48L0ZPTlQ+PC9QPjxQPjxGT05UIFNJWkU9IjIiPqH1IA0Ksb65q8u+ttTN+NW+tqjWxrjQ 0MvIpKGhoaEmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IKH1ILG+uavLvrbU0rzN+M2ot/7O8bjQ0MvIpDwvRk9OVD48L1A+PFAgQ0xBU1M9TXNv Tm9ybWFsIFNUWUxFPSdsaW5lLWhlaWdodDoyMC4wcHQnPjxGT05UIFNJWkU9IjIiPrmry77D+7PG o7pfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1/Bqs+1yMujul9f X19fX19fX19fX19fX19fX19fX19fIA0KPEJSPiA8QlI+ILXnu7Cjul9fX19fX19fX19fX19fX19f X19fX7Sr1eajul9fX19fX19fX19fX19fX19fX19fX19FLW1haWyjul9fX19fX19fX19fX19fX19f X19fX18gDQo8L0ZPTlQ+PC9QPjxQIENMQVNTPU1zb05vcm1hbCBTVFlMRT0nbGluZS1oZWlnaHQ6 MjAuMHB0Jz48L1A+PC9URD48L1RSPjwvVEFCTEU+IA0KPC9CT0RZPg0KPC9IVE1MPg0K ------=_NextPart_000_324BF_01C10AFC.68061530-- From noreply@sourceforge.net Thu Jul 12 12:03:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Jul 2001 04:03:15 -0700 Subject: [Patches] [ python-Patches-432401 ] unicode encoding error callbacks Message-ID: Patches item #432401, was opened at 2001-06-12 06:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=432401&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: unicode encoding error callbacks Initial Comment: This patch adds unicode error handling callbacks to the encode functionality. With this patch it's possible to not only pass 'strict', 'ignore' or 'replace' as the errors argument to encode, but also a callable function, that will be called with the encoding name, the original unicode object and the position of the unencodable character. The callback must return a replacement unicode object that will be encoded instead of the original character. For example replacing unencodable characters with XML character references can be done in the following way. u"aäoöuüß".encode( "ascii", lambda enc, uni, pos: u"&#x%x;" % ord(uni[pos]) ) ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2001-07-12 04:03 Message: Logged In: YES user_id=89016 > > [...] > > so I guess we could change the replace handler > > to always return u'?'. This would make the > > implementation a little bit simpler, but the > > explanation of the callback feature *a lot* > > simpler. > > Go for it. OK, done! > [...] > > > Could you add these docs to the Misc/unicode.txt > > > file ? I will eventually take that file and turn > > > it into a PEP which will then serve as general > > > documentation for these things. > > > > I could, but first we should work out how the > > decoding callback API will work. > > Ok. BTW, Barry Warsaw already did the work of converting > the unicode.txt to PEP 100, so the docs should eventually > go there. OK. I guess it would be best to do this when everything is finished. > > > > BTW, I guess PyUnicode_EncodeUnicodeEscape > > > > could be reimplemented as PyUnicode_EncodeASCII > > > > with \uxxxx replacement callback. > > > > > > Hmm, wouldn't that result in a slowdown ? If so, > > > I'd rather leave the special encoder in place, > > > since it is being used a lot in Python and > > > probably some applications too. > > > > It would be a slowdown. But callbacks open many > > possiblities. > > True, but in this case I believe that we should stick with > the native implementation for "unicode-escape". Having > a standard callback error handler which does the \uXXXX > replacement would be nice to have though, since this would > also be usable with lots of other codecs (e.g. all the > code page ones). OK, done, now there's a PyCodec_EscapeReplaceUnicodeEncodeErrors/ codecs.escapereplace_unicodeencode_errors that uses \u (or \U if x>0xffff (with a wide build of Python)). > > For example: > > > > Why can't I print u"gürk"? > > > > is probably one of the most frequently asked > > questions in comp.lang.python. For printing > > Unicode stuff, print could be extended the use an > > error handling callback for Unicode strings (or > > objects where __str__ or tp_str returns a Unicode > > object) instead of using str() which always > > returns an 8bit string and uses strict encoding. > > There might even be a > > sys.setprintencodehandler()/sys.getprintencodehandler () > > There already is a print callback in Python (forgot the > name of the hook though), so this should be possible by > providing the encoding logic in the hook. True: sys.displayhook > [...] > > Should the old TranslateCharmap map to the new > > TranslateCharmapEx and inherit the > > "multicharacter replacement" feature, > > or should I leave it as it is? > > If possible, please also add the multichar replacement > to the old API. I think it is very useful and since the > old APIs work on raw buffers it would be a benefit to have > the functionality in the old implementation too. OK! I will try to find the time to implement that in the next days. > [Decoding error callbacks] > > About the return value: > > I'd suggest to always use the same tuple interface, e.g. > > callback(encoding, input_data, input_position, state) -> > (output_to_be_appended, new_input_position) > > (I think it's better to use absolute values for the > position rather than offsets.) > > Perhaps the encoding callbacks should use the same > interface... what do you think ? This would make the callback feature hypergeneric and a little slower, because tuples have to be created, but it (almost) unifies the encoding and decoding API. ("almost" because, for the encoder output_to_be_appended will be reencoded, for the decoder it will simply be appended.), so I'm for it. I implemented this and changed the encoders to only lookup the error handler on the first error. The UCS1 encoder now no longer uses the two-item stack strategy. (This strategy only makes sense for those encoder where the encoding itself is much more complicated than the looping/callback etc.) So now memory overflow tests are only done, when an unencodable error occurs, so now the UCS1 encoder should be as fast as it was without error callbacks. Do we want to enforce new_input_position>input_position, or should jumping back be allowed? > > > > One additional note: It is vital that errors > > > > is an assignable attribute of the StreamWriter. > > > > > > It is already ! > > > > I know, but IMHO it should be documented that an > > assignable errors attribute must be supported > > as part of the official codec API. > > > > Misc/unicode.txt is not clear on that: > > """ > > It is not required by the Unicode implementation > > to use these base classes, only the interfaces must > > match; this allows writing Codecs as extension types. > > """ > > Good point. I'll add that to the PEP 100. OK. Here's is the current todo list: 1. implement a new TranslateCharmap and fix the old. 2. New encoding API for string objects too. 3. Decoding 4. Documentation 5. Test cases I'm thinking about a different strategy for implementing callbacks (see http://mail.python.org/pipermail/i18n-sig/2001- July/001262.html) We coould have a error handler registry, which maps names to error handlers, then it would be possible to keep the errors argument as "const char *" instead of "PyObject *". Currently PyCodec_UnicodeEncodeHandlerForObject is a backwards compatibility hack that will never go away, because it's always more convenient to type u"...".encode("...", "strict") instead of import codecs u"...".encode("...", codecs.raise_encode_errors) But with an error handler registry this function would become the official lookup method for error handlers. (PyCodec_LookupUnicodeEncodeErrorHandler?) Python code would look like this: --- def xmlreplace(encoding, unicode, pos, state): return (u"&#%d;" % ord(uni[pos]), pos+1) import codec codec.registerError("xmlreplace",xmlreplace) --- and then the following call can be made: u"äöü".encode("ascii", "xmlreplace") As soon as the first error is encountered, the encoder uses its builtin error handling method if it recognizes the name ("strict", "replace" or "ignore") or looks up the error handling function in the registry if it doesn't. In this way the speed for the backwards compatible features is the same as before and "const char *error" can be kept as the parameter to all encoding functions. For speed common error handling names could even be implemented in the encoder itself. But for special one-shot error handlers, it might still be useful to pass the error handler directly, so maybe we should leave error as PyObject *, but implement the registry anyway? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-10 05:29 Message: Logged In: YES user_id=38388 Ok, here we go... > > > raise an exception). U+FFFD characters in the > replacement > > > string will be replaced with a character that the > encoder > > > chooses ('?' in all cases). > > > > Nice. > > But the special casing of U+FFFD makes the interface > somewhat > less clean than it could be. It was only done to be 100% > backwards compatible. With the original "replace" > error > handling the codec chose the replacement character. But as > far as I can tell none of the codecs uses anything other > than '?', True. > so I guess we could change the replace handler > to always return u'?'. This would make the implementation a > little bit simpler, but the explanation of the callback > feature *a lot* simpler. Go for it. > And if you still want to handle > an unencodable U+FFFD, you can write a special callback for > that, e.g. > > def FFFDreplace(enc, uni, pos): > if uni[pos] == "\ufffd": > return u"?" > else: > raise UnicodeError(...) > > > ...docs... > > > > Could you add these docs to the Misc/unicode.txt file ? I > > will eventually take that file and turn it into a PEP > which > > will then serve as general documentation for these things. > > I could, but first we should work out how the decoding > callback API will work. Ok. BTW, Barry Warsaw already did the work of converting the unicode.txt to PEP 100, so the docs should eventually go there. > > > BTW, I guess PyUnicode_EncodeUnicodeEscape could be > > > reimplemented as PyUnicode_EncodeASCII with a \uxxxx > > > replacement callback. > > > > Hmm, wouldn't that result in a slowdown ? If so, I'd > rather > > leave the special encoder in place, since it is being > used a > > lot in Python and probably some applications too. > > It would be a slowdown. But callbacks open many > possiblities. True, but in this case I believe that we should stick with the native implementation for "unicode-escape". Having a standard callback error handler which does the \uXXXX replacement would be nice to have though, since this would also be usable with lots of other codecs (e.g. all the code page ones). > For example: > > Why can't I print u"gürk"? > > is probably one of the most frequently asked questions in > comp.lang.python. For printing Unicode stuff, print could be > extended the use an error handling callback for Unicode > strings (or objects where __str__ or tp_str returns a > Unicode object) instead of using str() which always returns > an 8bit string and uses strict encoding. There might even > be a > sys.setprintencodehandler()/sys.getprintencodehandler() There already is a print callback in Python (forgot the name of the hook though), so this should be possible by providing the encoding logic in the hook. > > > I have not touched PyUnicode_TranslateCharmap yet, > > > should this function also support error callbacks? Why > > > would one want the insert None into the mapping to > call > > > the callback? > > > > 1. Yes. > > 2. The user may want to e.g. restrict usage of certain > > character ranges. In this case the codec would be used to > > verify the input and an exception would indeed be useful > > (e.g. say you want to restrict input to Hangul + ASCII). > > OK, do we want TranslateCharmap to work exactly like > encoding, > i.e. in case of an error should the returned replacement > string again be mapped through the translation mapping or > should it be copied to the output directly? The former would > be more in line with encoding, but IMHO the latter would > be much more useful. It's better to take the second approach (copy the callback output directly to the output string) to avoid endless recursion and other pitfalls. I suppose this will also simplify the implementation somewhat. > BTW, when I implement it I can implement patch #403100 > ("Multicharacter replacements in > PyUnicode_TranslateCharmap") > along the way. I've seen it; will comment on it later. > Should the old TranslateCharmap map to the new > TranslateCharmapEx > and inherit the "multicharacter replacement" feature, > or > should I leave it as it is? If possible, please also add the multichar replacement to the old API. I think it is very useful and since the old APIs work on raw buffers it would be a benefit to have the functionality in the old implementation too. [Decoding error callbacks] > > > A remaining problem is how to implement decoding error > > > callbacks. In Python 2.1 encoding and decoding errors > are > > > handled in the same way with a string value. But with > > > callbacks it doesn't make sense to use the same > callback > > > for encoding and decoding (like > codecs.StreamReaderWriter > > > and codecs.StreamRecoder do). Decoding callbacks have > a > > > different API. Which arguments should be passed to the > > > decoding callback, and what is the decoding callback > > > supposed to do? > > > > I'd suggest adding another set of PyCodec_UnicodeDecode... > () > > APIs for this. We'd then have to augment the base classes > of > > the StreamCodecs to provide two attributes for .errors > with > > a fallback solution for the string case (i.s. "strict" > can > > still be used for both directions). > > Sounds good. Now what is the decoding callback supposed to > do? > I guess it will be called in the same way as the encoding > callback, i.e. with encoding name, original string and > position of the error. It might returns a Unicode string > (i.e. an object of the decoding target type), that will be > emitted from the codec instead of the one offending byte. Or > it might return a tuple with replacement Unicode object and > a resynchronisation offset, i.e. returning (u"?", 1) > means > emit a '?' and skip the offending character. But to make > the offset really useful the callback has to know something > about the encoding, perhaps the codec should be allowed to > pass an additional state object to the callback? > > Maybe the same should be added to the encoding callbacks to? > Maybe the encoding callback should be able to tell the > encoder if the replacement returned should be reencoded > (in which case it's a Unicode object), or directly emitted > (in which case it's an 8bit string)? I like the idea of having an optional state object (basically this should be a codec-defined arbitrary Python object) which then allow the callback to apply additional tricks. The object should be documented to be modifyable in place (simplifies the interface). About the return value: I'd suggest to always use the same tuple interface, e.g. callback(encoding, input_data, input_position, state) -> (output_to_be_appended, new_input_position) (I think it's better to use absolute values for the position rather than offsets.) Perhaps the encoding callbacks should use the same interface... what do you think ? > > > One additional note: It is vital that errors is an > > > assignable attribute of the StreamWriter. > > > > It is already ! > > I know, but IMHO it should be documented that an assignable > errors attribute must be supported as part of the official > codec API. > > Misc/unicode.txt is not clear on that: > """ > It is not required by the Unicode implementation to use > these base classes, only the interfaces must match; this > allows writing Codecs as extension types. > """ Good point. I'll add that to the PEP 100. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-22 13:51 Message: Logged In: YES user_id=38388 Sorry to keep you waiting, Walter. I will look into this again next week -- this week was way too busy... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-13 10:00 Message: Logged In: YES user_id=38388 On your comment about the non-Unicode codecs: let's keep this separated from the current patch. Don't have much time today. I'll comment on the other things tomorrow. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-13 08:49 Message: Logged In: YES user_id=89016 Guido van Rossum wrote in python-dev: > True, the "codec" pattern can be used for other > encodings than Unicode. But it seems to me that the > entire codecs architecture is rather strongly geared > towards en/decoding Unicode, and it's not clear > how well other codecs fit in this pattern (e.g. I > noticed that all the non-Unicode codecs ignore the > error handling parameter or assert that > it is set to 'strict'). I noticed that too. asserting that errors=='strict' would mean that the encoder is not able to deal in any other way with unencodable stuff than by raising an error. But that is not the problem here, because for zlib, base64, quopri, hex and uu encoding there can be no unencodable characters. The encoders can simply ignore the errors parameter. Should I remove the asserts from those codecs and change the docstrings accordingly, or will this be done separately? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-13 06:57 Message: Logged In: YES user_id=89016 > > [...] > > raise an exception). U+FFFD characters in the replacement > > string will be replaced with a character that the encoder > > chooses ('?' in all cases). > > Nice. But the special casing of U+FFFD makes the interface somewhat less clean than it could be. It was only done to be 100% backwards compatible. With the original "replace" error handling the codec chose the replacement character. But as far as I can tell none of the codecs uses anything other than '?', so I guess we could change the replace handler to always return u'?'. This would make the implementation a little bit simpler, but the explanation of the callback feature *a lot* simpler. And if you still want to handle an unencodable U+FFFD, you can write a special callback for that, e.g. def FFFDreplace(enc, uni, pos): if uni[pos] == "\ufffd": return u"?" else: raise UnicodeError(...) > > The implementation of the loop through the string is done > > in the following way. A stack with two strings is kept > > and the loop always encodes a character from the string > > at the stacktop. If an error is encountered and the stack > > has only one entry (during encoding of the original string) > > the callback is called and the unicode object returned is > > pushed on the stack, so the encoding continues with the > > replacement string. If the stack has two entries when an > > error is encountered, the replacement string itself has > > an unencodable character and a normal exception raised. > > When the encoder has reached the end of it's current string > > there are two possibilities: when the stack contains two > > entries, this was the replacement string, so the replacement > > string will be poppep from the stack and encoding continues > > with the next character from the original string. If the > > stack had only one entry, encoding is finished. > > Very elegant solution ! I'll put it as a comment in the source. > > (I hope that's enough explanation of the API and > implementation) > > Could you add these docs to the Misc/unicode.txt file ? I > will eventually take that file and turn it into a PEP which > will then serve as general documentation for these things. I could, but first we should work out how the decoding callback API will work. > > I have renamed the static ...121 function to all lowercase > > names. > > Ok. > > > BTW, I guess PyUnicode_EncodeUnicodeEscape could be > > reimplemented as PyUnicode_EncodeASCII with a \uxxxx > > replacement callback. > > Hmm, wouldn't that result in a slowdown ? If so, I'd rather > leave the special encoder in place, since it is being used a > lot in Python and probably some applications too. It would be a slowdown. But callbacks open many possiblities. For example: Why can't I print u"gürk"? is probably one of the most frequently asked questions in comp.lang.python. For printing Unicode stuff, print could be extended the use an error handling callback for Unicode strings (or objects where __str__ or tp_str returns a Unicode object) instead of using str() which always returns an 8bit string and uses strict encoding. There might even be a sys.setprintencodehandler()/sys.getprintencodehandler() > [...] > I think it would be worthwhile to rename the callbacks to > include "Unicode" somewhere, e.g. > PyCodec_UnicodeReplaceEncodeErrors(). It's a long name, but > then it points out the application field of the callback > rather well. Same for the callbacks exposed through the > _codecsmodule. OK, done (and PyCodec_XMLCharRefReplaceUnicodeEncodeErrors really is a long name ;)) > > I have not touched PyUnicode_TranslateCharmap yet, > > should this function also support error callbacks? Why > > would one want the insert None into the mapping to call > > the callback? > > 1. Yes. > 2. The user may want to e.g. restrict usage of certain > character ranges. In this case the codec would be used to > verify the input and an exception would indeed be useful > (e.g. say you want to restrict input to Hangul + ASCII). OK, do we want TranslateCharmap to work exactly like encoding, i.e. in case of an error should the returned replacement string again be mapped through the translation mapping or should it be copied to the output directly? The former would be more in line with encoding, but IMHO the latter would be much more useful. BTW, when I implement it I can implement patch #403100 ("Multicharacter replacements in PyUnicode_TranslateCharmap") along the way. Should the old TranslateCharmap map to the new TranslateCharmapEx and inherit the "multicharacter replacement" feature, or should I leave it as it is? > > A remaining problem is how to implement decoding error > > callbacks. In Python 2.1 encoding and decoding errors are > > handled in the same way with a string value. But with > > callbacks it doesn't make sense to use the same callback > > for encoding and decoding (like codecs.StreamReaderWriter > > and codecs.StreamRecoder do). Decoding callbacks have a > > different API. Which arguments should be passed to the > > decoding callback, and what is the decoding callback > > supposed to do? > > I'd suggest adding another set of PyCodec_UnicodeDecode... () > APIs for this. We'd then have to augment the base classes of > the StreamCodecs to provide two attributes for .errors with > a fallback solution for the string case (i.s. "strict" can > still be used for both directions). Sounds good. Now what is the decoding callback supposed to do? I guess it will be called in the same way as the encoding callback, i.e. with encoding name, original string and position of the error. It might returns a Unicode string (i.e. an object of the decoding target type), that will be emitted from the codec instead of the one offending byte. Or it might return a tuple with replacement Unicode object and a resynchronisation offset, i.e. returning (u"?", 1) means emit a '?' and skip the offending character. But to make the offset really useful the callback has to know something about the encoding, perhaps the codec should be allowed to pass an additional state object to the callback? Maybe the same should be added to the encoding callbacks to? Maybe the encoding callback should be able to tell the encoder if the replacement returned should be reencoded (in which case it's a Unicode object), or directly emitted (in which case it's an 8bit string)? > > One additional note: It is vital that errors is an > > assignable attribute of the StreamWriter. > > It is already ! I know, but IMHO it should be documented that an assignable errors attribute must be supported as part of the official codec API. Misc/unicode.txt is not clear on that: """ It is not required by the Unicode implementation to use these base classes, only the interfaces must match; this allows writing Codecs as extension types. """ ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-13 01:05 Message: Logged In: YES user_id=38388 > How the callbacks work: > > A PyObject * named errors is passed in. This may by NULL, > Py_None, 'strict', u'strict', 'ignore', u'ignore', > 'replace', u'replace' or a callable object. > PyCodec_EncodeHandlerForObject maps all of these objects to > one of the three builtin error callbacks > PyCodec_RaiseEncodeErrors (raises an exception), > PyCodec_IgnoreEncodeErrors (returns an empty replacement > string, in effect ignoring the error), > PyCodec_ReplaceEncodeErrors (returns U+FFFD, the Unicode > replacement character to signify to the encoder that it > should choose a suitable replacement character) or directly > returns errors if it is a callable object. When an > unencodable character is encounterd the error handling > callback will be called with the encoding name, the original > unicode object and the error position and must return a > unicode object that will be encoded instead of the offending > character (or the callback may of course raise an > exception). U+FFFD characters in the replacement string will > be replaced with a character that the encoder chooses ('?' > in all cases). Nice. > The implementation of the loop through the string is done in > the following way. A stack with two strings is kept and the > loop always encodes a character from the string at the > stacktop. If an error is encountered and the stack has only > one entry (during encoding of the original string) the > callback is called and the unicode object returned is pushed > on the stack, so the encoding continues with the replacement > string. If the stack has two entries when an error is > encountered, the replacement string itself has an > unencodable character and a normal exception raised. When > the encoder has reached the end of it's current string there > are two possibilities: when the stack contains two entries, > this was the replacement string, so the replacement string > will be poppep from the stack and encoding continues with > the next character from the original string. If the stack > had only one entry, encoding is finished. Very elegant solution ! > (I hope that's enough explanation of the API and implementation) Could you add these docs to the Misc/unicode.txt file ? I will eventually take that file and turn it into a PEP which will then serve as general documentation for these things. > I have renamed the static ...121 function to all lowercase > names. Ok. > BTW, I guess PyUnicode_EncodeUnicodeEscape could be > reimplemented as PyUnicode_EncodeASCII with a \uxxxx > replacement callback. Hmm, wouldn't that result in a slowdown ? If so, I'd rather leave the special encoder in place, since it is being used a lot in Python and probably some applications too. > PyCodec_RaiseEncodeErrors, PyCodec_IgnoreEncodeErrors, > PyCodec_ReplaceEncodeErrors are globally visible because > they have to be available in _codecsmodule.c to wrap them as > Python function objects, but they can't be implemented in > _codecsmodule, because they need to be available to the > encoders in unicodeobject.c (through > PyCodec_EncodeHandlerForObject), but importing the codecs > module might result in an endless recursion, because > importing a module requires unpickling of the bytecode, > which might require decoding utf8, which ... (but this will > only happen, if we implement the same mechanism for the > decoding API) I think that codecs.c is the right place for these APIs. _codecsmodule.c is only meant as Python access wrapper for the internal codecs and nothing more. One thing I noted about the callbacks: they assume that they will always get Unicode objects as input. This is certainly not true in the general case (it is for the codecs you touch in the patch). I think it would be worthwhile to rename the callbacks to include "Unicode" somewhere, e.g. PyCodec_UnicodeReplaceEncodeErrors(). It's a long name, but then it points out the application field of the callback rather well. Same for the callbacks exposed through the _codecsmodule. > I have not touched PyUnicode_TranslateCharmap yet, > should this function also support error callbacks? Why would > one want the insert None into the mapping to call the callback? 1. Yes. 2. The user may want to e.g. restrict usage of certain character ranges. In this case the codec would be used to verify the input and an exception would indeed be useful (e.g. say you want to restrict input to Hangul + ASCII). > A remaining problem is how to implement decoding error > callbacks. In Python 2.1 encoding and decoding errors are > handled in the same way with a string value. But with > callbacks it doesn't make sense to use the same callback for > encoding and decoding (like codecs.StreamReaderWriter and > codecs.StreamRecoder do). Decoding callbacks have a > different API. Which arguments should be passed to the > decoding callback, and what is the decoding callback > supposed to do? I'd suggest adding another set of PyCodec_UnicodeDecode...() APIs for this. We'd then have to augment the base classes of the StreamCodecs to provide two attributes for .errors with a fallback solution for the string case (i.s. "strict" can still be used for both directions). > One additional note: It is vital that errors is an > assignable attribute of the StreamWriter. It is already ! > Consider the XML example: For writing an XML DOM tree one > StreamWriter object is used. When a text node is written, > the error handling has to be set to > codecs.xmlreplace_encode_errors, but inside a comment or > processing instruction replacing unencodable characters with > charrefs is not possible, so here codecs.raise_encode_errors > should be used (or better a custom error handler that raises > an error that says "sorry, you can't have unencodable > characters inside a comment") Sure. > BTW, should we continue the discussion in the i18n SIG > mailing list? An email program is much more comfortable than > a HTML textarea! ;) I'd rather keep the discussions on this patch here -- forking it off to the i18n sig will make it very hard to follow up on it. (This HTML area is indeed damn small ;-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 12:18 Message: Logged In: YES user_id=89016 One additional note: It is vital that errors is an assignable attribute of the StreamWriter. Consider the XML example: For writing an XML DOM tree one StreamWriter object is used. When a text node is written, the error handling has to be set to codecs.xmlreplace_encode_errors, but inside a comment or processing instruction replacing unencodable characters with charrefs is not possible, so here codecs.raise_encode_errors should be used (or better a custom error handler that raises an error that says "sorry, you can't have unencodable characters inside a comment") BTW, should we continue the discussion in the i18n SIG mailing list? An email program is much more comfortable than a HTML textarea! ;) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 11:59 Message: Logged In: YES user_id=89016 How the callbacks work: A PyObject * named errors is passed in. This may by NULL, Py_None, 'strict', u'strict', 'ignore', u'ignore', 'replace', u'replace' or a callable object. PyCodec_EncodeHandlerForObject maps all of these objects to one of the three builtin error callbacks PyCodec_RaiseEncodeErrors (raises an exception), PyCodec_IgnoreEncodeErrors (returns an empty replacement string, in effect ignoring the error), PyCodec_ReplaceEncodeErrors (returns U+FFFD, the Unicode replacement character to signify to the encoder that it should choose a suitable replacement character) or directly returns errors if it is a callable object. When an unencodable character is encounterd the error handling callback will be called with the encoding name, the original unicode object and the error position and must return a unicode object that will be encoded instead of the offending character (or the callback may of course raise an exception). U+FFFD characters in the replacement string will be replaced with a character that the encoder chooses ('?' in all cases). The implementation of the loop through the string is done in the following way. A stack with two strings is kept and the loop always encodes a character from the string at the stacktop. If an error is encountered and the stack has only one entry (during encoding of the original string) the callback is called and the unicode object returned is pushed on the stack, so the encoding continues with the replacement string. If the stack has two entries when an error is encountered, the replacement string itself has an unencodable character and a normal exception raised. When the encoder has reached the end of it's current string there are two possibilities: when the stack contains two entries, this was the replacement string, so the replacement string will be poppep from the stack and encoding continues with the next character from the original string. If the stack had only one entry, encoding is finished. (I hope that's enough explanation of the API and implementation) I have renamed the static ...121 function to all lowercase names. BTW, I guess PyUnicode_EncodeUnicodeEscape could be reimplemented as PyUnicode_EncodeASCII with a \uxxxx replacement callback. PyCodec_RaiseEncodeErrors, PyCodec_IgnoreEncodeErrors, PyCodec_ReplaceEncodeErrors are globally visible because they have to be available in _codecsmodule.c to wrap them as Python function objects, but they can't be implemented in _codecsmodule, because they need to be available to the encoders in unicodeobject.c (through PyCodec_EncodeHandlerForObject), but importing the codecs module might result in an endless recursion, because importing a module requires unpickling of the bytecode, which might require decoding utf8, which ... (but this will only happen, if we implement the same mechanism for the decoding API) I have not touched PyUnicode_TranslateCharmap yet, should this function also support error callbacks? Why would one want the insert None into the mapping to call the callback? A remaining problem is how to implement decoding error callbacks. In Python 2.1 encoding and decoding errors are handled in the same way with a string value. But with callbacks it doesn't make sense to use the same callback for encoding and decoding (like codecs.StreamReaderWriter and codecs.StreamRecoder do). Decoding callbacks have a different API. Which arguments should be passed to the decoding callback, and what is the decoding callback supposed to do? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-12 11:00 Message: Logged In: YES user_id=38388 About the Py_UNICODE*data, int size APIs: Ok, point taken. In general, I think we ought to keep the callback feature as open as possible, so passing in pointers and sizes would not be very useful. BTW, could you summarize how the callback works in a few lines ? About _Encode121: I'd name this _EncodeUCS1 since that's what it is ;-) About the new functions: I was referring to the new static functions which you gave PyUnicode_... names. If these are not supposed to turn into non-static functions, I'd rather have them use lower case names (since that's how the Python internals work too -- most of the times). ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 09:56 Message: Logged In: YES user_id=89016 > One thing which I don't like about your API change is that > you removed the Py_UNICODE*data, int size style arguments > -- > this makes it impossible to use the new APIs on non-Python > data or data which is not available as Unicode object. Another problem is, that the callback requires a Python object, so in the PyObject *version, the refcount is incref'd and the object is passed to the callback. The Py_UNICODE*/int version would have to create a new Unicode object from the data. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 09:32 Message: Logged In: YES user_id=89016 > * please don't place more than one C statement on one line > like in: > """ > + unicode = unicode2; unicodepos = > unicode2pos; > + unicode2 = NULL; unicode2pos = 0; > """ OK, done! > * Comments should start with a capital letter and be > prepended > to the section they apply to Fixed! > * There should be spaces between arguments in compares > (a == b) not (a==b) Fixed! > * Where does the name "...Encode121" originate ? encode one-to-one, it implements both ASCII and latin-1 encoding. > * module internal APIs should use lower case names (you > converted some of these to PyUnicode_...() -- this is > normally reserved for APIs which are either marked as > potential candidates for the public API or are very > prominent in the code) Which ones? I introduced a new function for every old one, that had a "const char *errors" argument, and a few new ones in codecs.h, of those PyCodec_EncodeHandlerForObject is vital, because it is used to map for old string arguments to the new function objects. PyCodec_RaiseEncodeErrors can be used in the encoder implementation to raise an encode error, but it could be made static in unicodeobject.h so only those encoders implemented there have access to it. > One thing which I don't like about your API change is that > you removed the Py_UNICODE*data, int size style arguments > -- > this makes it impossible to use the new APIs on non-Python > data or data which is not available as Unicode object. I look through the code and found no situation where the Py_UNICODE*/int version is really used and having two (PyObject *)s (the original and the replacement string), instead of UNICODE*/int and PyObject * made the implementation a little easier, but I can fix that. > Please separate the errors.c patch from this patch -- it > seems totally unrelated to Unicode. PyCodec_RaiseEncodeErrors uses this the have a \Uxxxx with four hex digits. I removed it. I'll upload a revised patch as soon as it's done. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-12 07:29 Message: Logged In: YES user_id=38388 Thanks for the patch -- it looks very impressive !. I'll give it a try later this week. Some first cosmetic tidbits: * please don't place more than one C statement on one line like in: """ + unicode = unicode2; unicodepos = unicode2pos; + unicode2 = NULL; unicode2pos = 0; """ * Comments should start with a capital letter and be prepended to the section they apply to * There should be spaces between arguments in compares (a == b) not (a==b) * Where does the name "...Encode121" originate ? * module internal APIs should use lower case names (you converted some of these to PyUnicode_...() -- this is normally reserved for APIs which are either marked as potential candidates for the public API or are very prominent in the code) One thing which I don't like about your API change is that you removed the Py_UNICODE*data, int size style arguments -- this makes it impossible to use the new APIs on non-Python data or data which is not available as Unicode object. Please separate the errors.c patch from this patch -- it seems totally unrelated to Unicode. Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=432401&group_id=5470 From noreply@sourceforge.net Thu Jul 12 12:29:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Jul 2001 04:29:33 -0700 Subject: [Patches] [ python-Patches-440487 ] int to the negative power -> float Message-ID: Patches item #440487, was opened at 2001-07-11 12:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440487&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Guido van Rossum (gvanrossum) >Assigned to: Tim Peters (tim_one) Summary: int to the negative power -> float Initial Comment: Currently, int to the negative int power raises an exception. This was one of the two problems that the VPython users complained about. (The other was that integer division returns a truncated integer, but that's another story. :-) I propose to implement this in Python 2.2. Anybody have a problem with this? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-12 04:29 Message: Logged In: YES user_id=6380 OK, checked in. Also updated the docs. Question: should we do a similar thing to negative_float to the fractional_power ? That could return a complex number rather than raising an exception. But it breaks the rule that we don't return complex numbers unless the user explicitly asks for it (otherwise the cmath module should be merged with the math module as well). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 18:16 Message: Logged In: YES user_id=31435 Marked Accepted and back to Guido. The comments should say "the" instead of "both", since there are 3 arguments. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 16:18 Message: Logged In: YES user_id=6380 OK, here's a new patch, for int and long. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 14:46 Message: Logged In: YES user_id=31435 Back to Guido. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 13:23 Message: Logged In: YES user_id=31435 I liked the first patch better. *Looks* like under the new patch pow(2, -3, 1) will raise a ValueError but 2 ** -3 % 1 will return 0.125. That's close to inexplicable. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 13:04 Message: Logged In: YES user_id=31435 Tough luck for you, you mean . I considered z != None and didn't care. They're going to be just as surprised by i**j returning a float if j accidentally becomes negative. When making a formerly exceptional case "mean something", potential surprise is unavoidable, and if in the new world 2 ** -3 % 1 returns 0.125 is will be just as surprising if pow(2, -3, 1) does not return 0.125. The new rules should be consistent with *themselves* more than with oddball cases across releases. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 12:59 Message: Logged In: YES user_id=6380 New patch that only falls back to float when 3rd arg is None. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 12:52 Message: Logged In: YES user_id=6380 Tough luck. :-) There may be something else wrong with the patch: it probably shouldn't fall back to float when z is not None. After all, pow(x, y, z) should compute x**y % z, and I'm sure that someone using this would be quite surprised to get a floating point number back if they accidentally let y become negative! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 12:46 Message: Logged In: YES user_id=31435 No objection so far as it goes, but surely long_pow() should also attempt the same kind of thing then. Should add some test cases and docs too (yes, I'm going to hold you to the same stds as contributors ). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440487&group_id=5470 From noreply@sourceforge.net Thu Jul 12 21:51:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Jul 2001 13:51:14 -0700 Subject: [Patches] [ python-Patches-440826 ] Tests for repr.py Message-ID: Patches item #440826, was opened at 2001-07-12 13:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440826&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Tests for repr.py Initial Comment: Here are some unittests for the repr.py module. These are in line with the unit tests I've been writing over the past few days, except that these use the unittest.py module. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440826&group_id=5470 From noreply@sourceforge.net Thu Jul 12 21:54:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Jul 2001 13:54:02 -0700 Subject: [Patches] [ python-Patches-440827 ] Tests for dircache.py Message-ID: Patches item #440827, was opened at 2001-07-12 13:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440827&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Tests for dircache.py Initial Comment: Another installment: unit tests for dircache.py. I'm not sure whether the functionality of dircache.annotate is as intended; it appends '/' instead of os.sep blindly, regardless of platform. I don't know whether this is a bug or a feature, so I'm just assuming that the current behavior is correct. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440827&group_id=5470 From noreply@sourceforge.net Fri Jul 13 00:02:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Jul 2001 16:02:35 -0700 Subject: [Patches] [ python-Patches-418659 ] Fixes for UnixWare and ReliantUnix Message-ID: Patches item #418659, was opened at 2001-04-24 14:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418659&group_id=5470 Category: Build Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Martin v. Löwis (loewis) Summary: Fixes for UnixWare and ReliantUnix Initial Comment: This patch fixes the build problems on UnixWare, by: a) backing out 1.215 of configure.in and 1.34 of Makefile.pre.in b) Adding a test to check whether the compiler supports -Kpthread, and using that instead of #defines and libraries for pthread support. This part is not only restricted to UnixWare, but should work on other SysV compilers as well (e.g. ReliantUnix, untested) With these patches, UnixWare still passes the test suite except for test_math. Compared to 2.1, this drops usage of a shared libpython2.1.so. Such a feature is highly problematic, and was implemented incorrectly in 2.1. It should be brought back only as a configure option, which should be off by default, and apply to all Unix systems that support shared libraries. These patches should be applied to both the mainline and the 2.1 maintenance branch. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-12 16:02 Message: Logged In: YES user_id=3066 Accepted and assigned back to Martin for checkin. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 21:28 Message: Logged In: YES user_id=3066 Assigned to me since the Reliant Unix issue is assigned to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418659&group_id=5470 From noreply@sourceforge.net Fri Jul 13 12:26:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Jul 2001 04:26:07 -0700 Subject: [Patches] [ python-Patches-432401 ] unicode encoding error callbacks Message-ID: Patches item #432401, was opened at 2001-06-12 06:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=432401&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: unicode encoding error callbacks Initial Comment: This patch adds unicode error handling callbacks to the encode functionality. With this patch it's possible to not only pass 'strict', 'ignore' or 'replace' as the errors argument to encode, but also a callable function, that will be called with the encoding name, the original unicode object and the position of the unencodable character. The callback must return a replacement unicode object that will be encoded instead of the original character. For example replacing unencodable characters with XML character references can be done in the following way. u"aäoöuüß".encode( "ascii", lambda enc, uni, pos: u"&#x%x;" % ord(uni[pos]) ) ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-13 04:26 Message: Logged In: YES user_id=38388 > > > > > BTW, I guess PyUnicode_EncodeUnicodeEscape > > > > > could be reimplemented as PyUnicode_EncodeASCII > > > > > with \uxxxx replacement callback. > > > > > > > > Hmm, wouldn't that result in a slowdown ? If so, > > > > I'd rather leave the special encoder in place, > > > > since it is being used a lot in Python and > > > > probably some applications too. > > > > > > It would be a slowdown. But callbacks open many > > > possiblities. > > > > True, but in this case I believe that we should stick with > > the native implementation for "unicode-escape". Having > > a standard callback error handler which does the \uXXXX > > replacement would be nice to have though, since this would > > also be usable with lots of other codecs (e.g. all the > > code page ones). > > OK, done, now there's a > PyCodec_EscapeReplaceUnicodeEncodeErrors/ > codecs.escapereplace_unicodeencode_errors > that uses \u (or \U if x>0xffff (with a wide build > of Python)). Great ! > > [...] > > > Should the old TranslateCharmap map to the new > > > TranslateCharmapEx and inherit the > > > "multicharacter replacement" feature, > > > or should I leave it as it is? > > > > If possible, please also add the multichar replacement > > to the old API. I think it is very useful and since the > > old APIs work on raw buffers it would be a benefit to have > > the functionality in the old implementation too. > > OK! I will try to find the time to implement that in the > next days. Good. > > [Decoding error callbacks] > > > > About the return value: > > > > I'd suggest to always use the same tuple interface, e.g. > > > > callback(encoding, input_data, input_position, > state) -> > > (output_to_be_appended, new_input_position) > > > > (I think it's better to use absolute values for the > > position rather than offsets.) > > > > Perhaps the encoding callbacks should use the same > > interface... what do you think ? > > This would make the callback feature hypergeneric and a > little slower, because tuples have to be created, but it > (almost) unifies the encoding and decoding API. ("almost" > because, for the encoder output_to_be_appended will be > reencoded, for the decoder it will simply be appended.), > so I'm for it. That's the point. Note that I don't think the tuple creation will hurt much (see the make_tuple() API in codecs.c) since small tuples are cached by Python internally. > I implemented this and changed the encoders to only > lookup the error handler on the first error. The UCS1 > encoder now no longer uses the two-item stack strategy. > (This strategy only makes sense for those encoder where > the encoding itself is much more complicated than the > looping/callback etc.) So now memory overflow tests are > only done, when an unencodable error occurs, so now the > UCS1 encoder should be as fast as it was without > error callbacks. > > Do we want to enforce new_input_position>input_position, > or should jumping back be allowed? No; moving backwards should be allowed (this may be useful in order to resynchronize with the input data). > Here's is the current todo list: > 1. implement a new TranslateCharmap and fix the old. > 2. New encoding API for string objects too. > 3. Decoding > 4. Documentation > 5. Test cases > > I'm thinking about a different strategy for implementing > callbacks > (see http://mail.python.org/pipermail/i18n-sig/2001- > July/001262.html) > > We coould have a error handler registry, which maps names > to error handlers, then it would be possible to keep the > errors argument as "const char *" instead of "PyObject *". > Currently PyCodec_UnicodeEncodeHandlerForObject is a > backwards compatibility hack that will never go away, > because > it's always more convenient to type > u"...".encode("...", "strict") > instead of > import codecs > u"...".encode("...", codecs.raise_encode_errors) > > But with an error handler registry this function would > become the official lookup method for error handlers. > (PyCodec_LookupUnicodeEncodeErrorHandler?) > Python code would look like this: > --- > def xmlreplace(encoding, unicode, pos, state): > return (u"&#%d;" % ord(uni[pos]), pos+1) > > import codec > > codec.registerError("xmlreplace",xmlreplace) > --- > and then the following call can be made: > u"äöü".encode("ascii", "xmlreplace") > As soon as the first error is encountered, the encoder uses > its builtin error handling method if it recognizes the name > ("strict", "replace" or "ignore") or looks up the error > handling function in the registry if it doesn't. In this way > the speed for the backwards compatible features is the same > as before and "const char *error" can be kept as the > parameter to all encoding functions. For speed common error > handling names could even be implemented in the encoder > itself. > > But for special one-shot error handlers, it might still be > useful to pass the error handler directly, so maybe we > should leave error as PyObject *, but implement the > registry anyway? Good idea ! One minor nit: codecs.registerError() should be named codecs.register_errorhandler() to be more inline with the Python coding style guide. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-07-12 04:03 Message: Logged In: YES user_id=89016 > > [...] > > so I guess we could change the replace handler > > to always return u'?'. This would make the > > implementation a little bit simpler, but the > > explanation of the callback feature *a lot* > > simpler. > > Go for it. OK, done! > [...] > > > Could you add these docs to the Misc/unicode.txt > > > file ? I will eventually take that file and turn > > > it into a PEP which will then serve as general > > > documentation for these things. > > > > I could, but first we should work out how the > > decoding callback API will work. > > Ok. BTW, Barry Warsaw already did the work of converting > the unicode.txt to PEP 100, so the docs should eventually > go there. OK. I guess it would be best to do this when everything is finished. > > > > BTW, I guess PyUnicode_EncodeUnicodeEscape > > > > could be reimplemented as PyUnicode_EncodeASCII > > > > with \uxxxx replacement callback. > > > > > > Hmm, wouldn't that result in a slowdown ? If so, > > > I'd rather leave the special encoder in place, > > > since it is being used a lot in Python and > > > probably some applications too. > > > > It would be a slowdown. But callbacks open many > > possiblities. > > True, but in this case I believe that we should stick with > the native implementation for "unicode-escape". Having > a standard callback error handler which does the \uXXXX > replacement would be nice to have though, since this would > also be usable with lots of other codecs (e.g. all the > code page ones). OK, done, now there's a PyCodec_EscapeReplaceUnicodeEncodeErrors/ codecs.escapereplace_unicodeencode_errors that uses \u (or \U if x>0xffff (with a wide build of Python)). > > For example: > > > > Why can't I print u"gürk"? > > > > is probably one of the most frequently asked > > questions in comp.lang.python. For printing > > Unicode stuff, print could be extended the use an > > error handling callback for Unicode strings (or > > objects where __str__ or tp_str returns a Unicode > > object) instead of using str() which always > > returns an 8bit string and uses strict encoding. > > There might even be a > > sys.setprintencodehandler()/sys.getprintencodehandler () > > There already is a print callback in Python (forgot the > name of the hook though), so this should be possible by > providing the encoding logic in the hook. True: sys.displayhook > [...] > > Should the old TranslateCharmap map to the new > > TranslateCharmapEx and inherit the > > "multicharacter replacement" feature, > > or should I leave it as it is? > > If possible, please also add the multichar replacement > to the old API. I think it is very useful and since the > old APIs work on raw buffers it would be a benefit to have > the functionality in the old implementation too. OK! I will try to find the time to implement that in the next days. > [Decoding error callbacks] > > About the return value: > > I'd suggest to always use the same tuple interface, e.g. > > callback(encoding, input_data, input_position, state) -> > (output_to_be_appended, new_input_position) > > (I think it's better to use absolute values for the > position rather than offsets.) > > Perhaps the encoding callbacks should use the same > interface... what do you think ? This would make the callback feature hypergeneric and a little slower, because tuples have to be created, but it (almost) unifies the encoding and decoding API. ("almost" because, for the encoder output_to_be_appended will be reencoded, for the decoder it will simply be appended.), so I'm for it. I implemented this and changed the encoders to only lookup the error handler on the first error. The UCS1 encoder now no longer uses the two-item stack strategy. (This strategy only makes sense for those encoder where the encoding itself is much more complicated than the looping/callback etc.) So now memory overflow tests are only done, when an unencodable error occurs, so now the UCS1 encoder should be as fast as it was without error callbacks. Do we want to enforce new_input_position>input_position, or should jumping back be allowed? > > > > One additional note: It is vital that errors > > > > is an assignable attribute of the StreamWriter. > > > > > > It is already ! > > > > I know, but IMHO it should be documented that an > > assignable errors attribute must be supported > > as part of the official codec API. > > > > Misc/unicode.txt is not clear on that: > > """ > > It is not required by the Unicode implementation > > to use these base classes, only the interfaces must > > match; this allows writing Codecs as extension types. > > """ > > Good point. I'll add that to the PEP 100. OK. Here's is the current todo list: 1. implement a new TranslateCharmap and fix the old. 2. New encoding API for string objects too. 3. Decoding 4. Documentation 5. Test cases I'm thinking about a different strategy for implementing callbacks (see http://mail.python.org/pipermail/i18n-sig/2001- July/001262.html) We coould have a error handler registry, which maps names to error handlers, then it would be possible to keep the errors argument as "const char *" instead of "PyObject *". Currently PyCodec_UnicodeEncodeHandlerForObject is a backwards compatibility hack that will never go away, because it's always more convenient to type u"...".encode("...", "strict") instead of import codecs u"...".encode("...", codecs.raise_encode_errors) But with an error handler registry this function would become the official lookup method for error handlers. (PyCodec_LookupUnicodeEncodeErrorHandler?) Python code would look like this: --- def xmlreplace(encoding, unicode, pos, state): return (u"&#%d;" % ord(uni[pos]), pos+1) import codec codec.registerError("xmlreplace",xmlreplace) --- and then the following call can be made: u"äöü".encode("ascii", "xmlreplace") As soon as the first error is encountered, the encoder uses its builtin error handling method if it recognizes the name ("strict", "replace" or "ignore") or looks up the error handling function in the registry if it doesn't. In this way the speed for the backwards compatible features is the same as before and "const char *error" can be kept as the parameter to all encoding functions. For speed common error handling names could even be implemented in the encoder itself. But for special one-shot error handlers, it might still be useful to pass the error handler directly, so maybe we should leave error as PyObject *, but implement the registry anyway? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-10 05:29 Message: Logged In: YES user_id=38388 Ok, here we go... > > > raise an exception). U+FFFD characters in the > replacement > > > string will be replaced with a character that the > encoder > > > chooses ('?' in all cases). > > > > Nice. > > But the special casing of U+FFFD makes the interface > somewhat > less clean than it could be. It was only done to be 100% > backwards compatible. With the original "replace" > error > handling the codec chose the replacement character. But as > far as I can tell none of the codecs uses anything other > than '?', True. > so I guess we could change the replace handler > to always return u'?'. This would make the implementation a > little bit simpler, but the explanation of the callback > feature *a lot* simpler. Go for it. > And if you still want to handle > an unencodable U+FFFD, you can write a special callback for > that, e.g. > > def FFFDreplace(enc, uni, pos): > if uni[pos] == "\ufffd": > return u"?" > else: > raise UnicodeError(...) > > > ...docs... > > > > Could you add these docs to the Misc/unicode.txt file ? I > > will eventually take that file and turn it into a PEP > which > > will then serve as general documentation for these things. > > I could, but first we should work out how the decoding > callback API will work. Ok. BTW, Barry Warsaw already did the work of converting the unicode.txt to PEP 100, so the docs should eventually go there. > > > BTW, I guess PyUnicode_EncodeUnicodeEscape could be > > > reimplemented as PyUnicode_EncodeASCII with a \uxxxx > > > replacement callback. > > > > Hmm, wouldn't that result in a slowdown ? If so, I'd > rather > > leave the special encoder in place, since it is being > used a > > lot in Python and probably some applications too. > > It would be a slowdown. But callbacks open many > possiblities. True, but in this case I believe that we should stick with the native implementation for "unicode-escape". Having a standard callback error handler which does the \uXXXX replacement would be nice to have though, since this would also be usable with lots of other codecs (e.g. all the code page ones). > For example: > > Why can't I print u"gürk"? > > is probably one of the most frequently asked questions in > comp.lang.python. For printing Unicode stuff, print could be > extended the use an error handling callback for Unicode > strings (or objects where __str__ or tp_str returns a > Unicode object) instead of using str() which always returns > an 8bit string and uses strict encoding. There might even > be a > sys.setprintencodehandler()/sys.getprintencodehandler() There already is a print callback in Python (forgot the name of the hook though), so this should be possible by providing the encoding logic in the hook. > > > I have not touched PyUnicode_TranslateCharmap yet, > > > should this function also support error callbacks? Why > > > would one want the insert None into the mapping to > call > > > the callback? > > > > 1. Yes. > > 2. The user may want to e.g. restrict usage of certain > > character ranges. In this case the codec would be used to > > verify the input and an exception would indeed be useful > > (e.g. say you want to restrict input to Hangul + ASCII). > > OK, do we want TranslateCharmap to work exactly like > encoding, > i.e. in case of an error should the returned replacement > string again be mapped through the translation mapping or > should it be copied to the output directly? The former would > be more in line with encoding, but IMHO the latter would > be much more useful. It's better to take the second approach (copy the callback output directly to the output string) to avoid endless recursion and other pitfalls. I suppose this will also simplify the implementation somewhat. > BTW, when I implement it I can implement patch #403100 > ("Multicharacter replacements in > PyUnicode_TranslateCharmap") > along the way. I've seen it; will comment on it later. > Should the old TranslateCharmap map to the new > TranslateCharmapEx > and inherit the "multicharacter replacement" feature, > or > should I leave it as it is? If possible, please also add the multichar replacement to the old API. I think it is very useful and since the old APIs work on raw buffers it would be a benefit to have the functionality in the old implementation too. [Decoding error callbacks] > > > A remaining problem is how to implement decoding error > > > callbacks. In Python 2.1 encoding and decoding errors > are > > > handled in the same way with a string value. But with > > > callbacks it doesn't make sense to use the same > callback > > > for encoding and decoding (like > codecs.StreamReaderWriter > > > and codecs.StreamRecoder do). Decoding callbacks have > a > > > different API. Which arguments should be passed to the > > > decoding callback, and what is the decoding callback > > > supposed to do? > > > > I'd suggest adding another set of PyCodec_UnicodeDecode... > () > > APIs for this. We'd then have to augment the base classes > of > > the StreamCodecs to provide two attributes for .errors > with > > a fallback solution for the string case (i.s. "strict" > can > > still be used for both directions). > > Sounds good. Now what is the decoding callback supposed to > do? > I guess it will be called in the same way as the encoding > callback, i.e. with encoding name, original string and > position of the error. It might returns a Unicode string > (i.e. an object of the decoding target type), that will be > emitted from the codec instead of the one offending byte. Or > it might return a tuple with replacement Unicode object and > a resynchronisation offset, i.e. returning (u"?", 1) > means > emit a '?' and skip the offending character. But to make > the offset really useful the callback has to know something > about the encoding, perhaps the codec should be allowed to > pass an additional state object to the callback? > > Maybe the same should be added to the encoding callbacks to? > Maybe the encoding callback should be able to tell the > encoder if the replacement returned should be reencoded > (in which case it's a Unicode object), or directly emitted > (in which case it's an 8bit string)? I like the idea of having an optional state object (basically this should be a codec-defined arbitrary Python object) which then allow the callback to apply additional tricks. The object should be documented to be modifyable in place (simplifies the interface). About the return value: I'd suggest to always use the same tuple interface, e.g. callback(encoding, input_data, input_position, state) -> (output_to_be_appended, new_input_position) (I think it's better to use absolute values for the position rather than offsets.) Perhaps the encoding callbacks should use the same interface... what do you think ? > > > One additional note: It is vital that errors is an > > > assignable attribute of the StreamWriter. > > > > It is already ! > > I know, but IMHO it should be documented that an assignable > errors attribute must be supported as part of the official > codec API. > > Misc/unicode.txt is not clear on that: > """ > It is not required by the Unicode implementation to use > these base classes, only the interfaces must match; this > allows writing Codecs as extension types. > """ Good point. I'll add that to the PEP 100. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-22 13:51 Message: Logged In: YES user_id=38388 Sorry to keep you waiting, Walter. I will look into this again next week -- this week was way too busy... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-13 10:00 Message: Logged In: YES user_id=38388 On your comment about the non-Unicode codecs: let's keep this separated from the current patch. Don't have much time today. I'll comment on the other things tomorrow. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-13 08:49 Message: Logged In: YES user_id=89016 Guido van Rossum wrote in python-dev: > True, the "codec" pattern can be used for other > encodings than Unicode. But it seems to me that the > entire codecs architecture is rather strongly geared > towards en/decoding Unicode, and it's not clear > how well other codecs fit in this pattern (e.g. I > noticed that all the non-Unicode codecs ignore the > error handling parameter or assert that > it is set to 'strict'). I noticed that too. asserting that errors=='strict' would mean that the encoder is not able to deal in any other way with unencodable stuff than by raising an error. But that is not the problem here, because for zlib, base64, quopri, hex and uu encoding there can be no unencodable characters. The encoders can simply ignore the errors parameter. Should I remove the asserts from those codecs and change the docstrings accordingly, or will this be done separately? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-13 06:57 Message: Logged In: YES user_id=89016 > > [...] > > raise an exception). U+FFFD characters in the replacement > > string will be replaced with a character that the encoder > > chooses ('?' in all cases). > > Nice. But the special casing of U+FFFD makes the interface somewhat less clean than it could be. It was only done to be 100% backwards compatible. With the original "replace" error handling the codec chose the replacement character. But as far as I can tell none of the codecs uses anything other than '?', so I guess we could change the replace handler to always return u'?'. This would make the implementation a little bit simpler, but the explanation of the callback feature *a lot* simpler. And if you still want to handle an unencodable U+FFFD, you can write a special callback for that, e.g. def FFFDreplace(enc, uni, pos): if uni[pos] == "\ufffd": return u"?" else: raise UnicodeError(...) > > The implementation of the loop through the string is done > > in the following way. A stack with two strings is kept > > and the loop always encodes a character from the string > > at the stacktop. If an error is encountered and the stack > > has only one entry (during encoding of the original string) > > the callback is called and the unicode object returned is > > pushed on the stack, so the encoding continues with the > > replacement string. If the stack has two entries when an > > error is encountered, the replacement string itself has > > an unencodable character and a normal exception raised. > > When the encoder has reached the end of it's current string > > there are two possibilities: when the stack contains two > > entries, this was the replacement string, so the replacement > > string will be poppep from the stack and encoding continues > > with the next character from the original string. If the > > stack had only one entry, encoding is finished. > > Very elegant solution ! I'll put it as a comment in the source. > > (I hope that's enough explanation of the API and > implementation) > > Could you add these docs to the Misc/unicode.txt file ? I > will eventually take that file and turn it into a PEP which > will then serve as general documentation for these things. I could, but first we should work out how the decoding callback API will work. > > I have renamed the static ...121 function to all lowercase > > names. > > Ok. > > > BTW, I guess PyUnicode_EncodeUnicodeEscape could be > > reimplemented as PyUnicode_EncodeASCII with a \uxxxx > > replacement callback. > > Hmm, wouldn't that result in a slowdown ? If so, I'd rather > leave the special encoder in place, since it is being used a > lot in Python and probably some applications too. It would be a slowdown. But callbacks open many possiblities. For example: Why can't I print u"gürk"? is probably one of the most frequently asked questions in comp.lang.python. For printing Unicode stuff, print could be extended the use an error handling callback for Unicode strings (or objects where __str__ or tp_str returns a Unicode object) instead of using str() which always returns an 8bit string and uses strict encoding. There might even be a sys.setprintencodehandler()/sys.getprintencodehandler() > [...] > I think it would be worthwhile to rename the callbacks to > include "Unicode" somewhere, e.g. > PyCodec_UnicodeReplaceEncodeErrors(). It's a long name, but > then it points out the application field of the callback > rather well. Same for the callbacks exposed through the > _codecsmodule. OK, done (and PyCodec_XMLCharRefReplaceUnicodeEncodeErrors really is a long name ;)) > > I have not touched PyUnicode_TranslateCharmap yet, > > should this function also support error callbacks? Why > > would one want the insert None into the mapping to call > > the callback? > > 1. Yes. > 2. The user may want to e.g. restrict usage of certain > character ranges. In this case the codec would be used to > verify the input and an exception would indeed be useful > (e.g. say you want to restrict input to Hangul + ASCII). OK, do we want TranslateCharmap to work exactly like encoding, i.e. in case of an error should the returned replacement string again be mapped through the translation mapping or should it be copied to the output directly? The former would be more in line with encoding, but IMHO the latter would be much more useful. BTW, when I implement it I can implement patch #403100 ("Multicharacter replacements in PyUnicode_TranslateCharmap") along the way. Should the old TranslateCharmap map to the new TranslateCharmapEx and inherit the "multicharacter replacement" feature, or should I leave it as it is? > > A remaining problem is how to implement decoding error > > callbacks. In Python 2.1 encoding and decoding errors are > > handled in the same way with a string value. But with > > callbacks it doesn't make sense to use the same callback > > for encoding and decoding (like codecs.StreamReaderWriter > > and codecs.StreamRecoder do). Decoding callbacks have a > > different API. Which arguments should be passed to the > > decoding callback, and what is the decoding callback > > supposed to do? > > I'd suggest adding another set of PyCodec_UnicodeDecode... () > APIs for this. We'd then have to augment the base classes of > the StreamCodecs to provide two attributes for .errors with > a fallback solution for the string case (i.s. "strict" can > still be used for both directions). Sounds good. Now what is the decoding callback supposed to do? I guess it will be called in the same way as the encoding callback, i.e. with encoding name, original string and position of the error. It might returns a Unicode string (i.e. an object of the decoding target type), that will be emitted from the codec instead of the one offending byte. Or it might return a tuple with replacement Unicode object and a resynchronisation offset, i.e. returning (u"?", 1) means emit a '?' and skip the offending character. But to make the offset really useful the callback has to know something about the encoding, perhaps the codec should be allowed to pass an additional state object to the callback? Maybe the same should be added to the encoding callbacks to? Maybe the encoding callback should be able to tell the encoder if the replacement returned should be reencoded (in which case it's a Unicode object), or directly emitted (in which case it's an 8bit string)? > > One additional note: It is vital that errors is an > > assignable attribute of the StreamWriter. > > It is already ! I know, but IMHO it should be documented that an assignable errors attribute must be supported as part of the official codec API. Misc/unicode.txt is not clear on that: """ It is not required by the Unicode implementation to use these base classes, only the interfaces must match; this allows writing Codecs as extension types. """ ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-13 01:05 Message: Logged In: YES user_id=38388 > How the callbacks work: > > A PyObject * named errors is passed in. This may by NULL, > Py_None, 'strict', u'strict', 'ignore', u'ignore', > 'replace', u'replace' or a callable object. > PyCodec_EncodeHandlerForObject maps all of these objects to > one of the three builtin error callbacks > PyCodec_RaiseEncodeErrors (raises an exception), > PyCodec_IgnoreEncodeErrors (returns an empty replacement > string, in effect ignoring the error), > PyCodec_ReplaceEncodeErrors (returns U+FFFD, the Unicode > replacement character to signify to the encoder that it > should choose a suitable replacement character) or directly > returns errors if it is a callable object. When an > unencodable character is encounterd the error handling > callback will be called with the encoding name, the original > unicode object and the error position and must return a > unicode object that will be encoded instead of the offending > character (or the callback may of course raise an > exception). U+FFFD characters in the replacement string will > be replaced with a character that the encoder chooses ('?' > in all cases). Nice. > The implementation of the loop through the string is done in > the following way. A stack with two strings is kept and the > loop always encodes a character from the string at the > stacktop. If an error is encountered and the stack has only > one entry (during encoding of the original string) the > callback is called and the unicode object returned is pushed > on the stack, so the encoding continues with the replacement > string. If the stack has two entries when an error is > encountered, the replacement string itself has an > unencodable character and a normal exception raised. When > the encoder has reached the end of it's current string there > are two possibilities: when the stack contains two entries, > this was the replacement string, so the replacement string > will be poppep from the stack and encoding continues with > the next character from the original string. If the stack > had only one entry, encoding is finished. Very elegant solution ! > (I hope that's enough explanation of the API and implementation) Could you add these docs to the Misc/unicode.txt file ? I will eventually take that file and turn it into a PEP which will then serve as general documentation for these things. > I have renamed the static ...121 function to all lowercase > names. Ok. > BTW, I guess PyUnicode_EncodeUnicodeEscape could be > reimplemented as PyUnicode_EncodeASCII with a \uxxxx > replacement callback. Hmm, wouldn't that result in a slowdown ? If so, I'd rather leave the special encoder in place, since it is being used a lot in Python and probably some applications too. > PyCodec_RaiseEncodeErrors, PyCodec_IgnoreEncodeErrors, > PyCodec_ReplaceEncodeErrors are globally visible because > they have to be available in _codecsmodule.c to wrap them as > Python function objects, but they can't be implemented in > _codecsmodule, because they need to be available to the > encoders in unicodeobject.c (through > PyCodec_EncodeHandlerForObject), but importing the codecs > module might result in an endless recursion, because > importing a module requires unpickling of the bytecode, > which might require decoding utf8, which ... (but this will > only happen, if we implement the same mechanism for the > decoding API) I think that codecs.c is the right place for these APIs. _codecsmodule.c is only meant as Python access wrapper for the internal codecs and nothing more. One thing I noted about the callbacks: they assume that they will always get Unicode objects as input. This is certainly not true in the general case (it is for the codecs you touch in the patch). I think it would be worthwhile to rename the callbacks to include "Unicode" somewhere, e.g. PyCodec_UnicodeReplaceEncodeErrors(). It's a long name, but then it points out the application field of the callback rather well. Same for the callbacks exposed through the _codecsmodule. > I have not touched PyUnicode_TranslateCharmap yet, > should this function also support error callbacks? Why would > one want the insert None into the mapping to call the callback? 1. Yes. 2. The user may want to e.g. restrict usage of certain character ranges. In this case the codec would be used to verify the input and an exception would indeed be useful (e.g. say you want to restrict input to Hangul + ASCII). > A remaining problem is how to implement decoding error > callbacks. In Python 2.1 encoding and decoding errors are > handled in the same way with a string value. But with > callbacks it doesn't make sense to use the same callback for > encoding and decoding (like codecs.StreamReaderWriter and > codecs.StreamRecoder do). Decoding callbacks have a > different API. Which arguments should be passed to the > decoding callback, and what is the decoding callback > supposed to do? I'd suggest adding another set of PyCodec_UnicodeDecode...() APIs for this. We'd then have to augment the base classes of the StreamCodecs to provide two attributes for .errors with a fallback solution for the string case (i.s. "strict" can still be used for both directions). > One additional note: It is vital that errors is an > assignable attribute of the StreamWriter. It is already ! > Consider the XML example: For writing an XML DOM tree one > StreamWriter object is used. When a text node is written, > the error handling has to be set to > codecs.xmlreplace_encode_errors, but inside a comment or > processing instruction replacing unencodable characters with > charrefs is not possible, so here codecs.raise_encode_errors > should be used (or better a custom error handler that raises > an error that says "sorry, you can't have unencodable > characters inside a comment") Sure. > BTW, should we continue the discussion in the i18n SIG > mailing list? An email program is much more comfortable than > a HTML textarea! ;) I'd rather keep the discussions on this patch here -- forking it off to the i18n sig will make it very hard to follow up on it. (This HTML area is indeed damn small ;-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 12:18 Message: Logged In: YES user_id=89016 One additional note: It is vital that errors is an assignable attribute of the StreamWriter. Consider the XML example: For writing an XML DOM tree one StreamWriter object is used. When a text node is written, the error handling has to be set to codecs.xmlreplace_encode_errors, but inside a comment or processing instruction replacing unencodable characters with charrefs is not possible, so here codecs.raise_encode_errors should be used (or better a custom error handler that raises an error that says "sorry, you can't have unencodable characters inside a comment") BTW, should we continue the discussion in the i18n SIG mailing list? An email program is much more comfortable than a HTML textarea! ;) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 11:59 Message: Logged In: YES user_id=89016 How the callbacks work: A PyObject * named errors is passed in. This may by NULL, Py_None, 'strict', u'strict', 'ignore', u'ignore', 'replace', u'replace' or a callable object. PyCodec_EncodeHandlerForObject maps all of these objects to one of the three builtin error callbacks PyCodec_RaiseEncodeErrors (raises an exception), PyCodec_IgnoreEncodeErrors (returns an empty replacement string, in effect ignoring the error), PyCodec_ReplaceEncodeErrors (returns U+FFFD, the Unicode replacement character to signify to the encoder that it should choose a suitable replacement character) or directly returns errors if it is a callable object. When an unencodable character is encounterd the error handling callback will be called with the encoding name, the original unicode object and the error position and must return a unicode object that will be encoded instead of the offending character (or the callback may of course raise an exception). U+FFFD characters in the replacement string will be replaced with a character that the encoder chooses ('?' in all cases). The implementation of the loop through the string is done in the following way. A stack with two strings is kept and the loop always encodes a character from the string at the stacktop. If an error is encountered and the stack has only one entry (during encoding of the original string) the callback is called and the unicode object returned is pushed on the stack, so the encoding continues with the replacement string. If the stack has two entries when an error is encountered, the replacement string itself has an unencodable character and a normal exception raised. When the encoder has reached the end of it's current string there are two possibilities: when the stack contains two entries, this was the replacement string, so the replacement string will be poppep from the stack and encoding continues with the next character from the original string. If the stack had only one entry, encoding is finished. (I hope that's enough explanation of the API and implementation) I have renamed the static ...121 function to all lowercase names. BTW, I guess PyUnicode_EncodeUnicodeEscape could be reimplemented as PyUnicode_EncodeASCII with a \uxxxx replacement callback. PyCodec_RaiseEncodeErrors, PyCodec_IgnoreEncodeErrors, PyCodec_ReplaceEncodeErrors are globally visible because they have to be available in _codecsmodule.c to wrap them as Python function objects, but they can't be implemented in _codecsmodule, because they need to be available to the encoders in unicodeobject.c (through PyCodec_EncodeHandlerForObject), but importing the codecs module might result in an endless recursion, because importing a module requires unpickling of the bytecode, which might require decoding utf8, which ... (but this will only happen, if we implement the same mechanism for the decoding API) I have not touched PyUnicode_TranslateCharmap yet, should this function also support error callbacks? Why would one want the insert None into the mapping to call the callback? A remaining problem is how to implement decoding error callbacks. In Python 2.1 encoding and decoding errors are handled in the same way with a string value. But with callbacks it doesn't make sense to use the same callback for encoding and decoding (like codecs.StreamReaderWriter and codecs.StreamRecoder do). Decoding callbacks have a different API. Which arguments should be passed to the decoding callback, and what is the decoding callback supposed to do? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-12 11:00 Message: Logged In: YES user_id=38388 About the Py_UNICODE*data, int size APIs: Ok, point taken. In general, I think we ought to keep the callback feature as open as possible, so passing in pointers and sizes would not be very useful. BTW, could you summarize how the callback works in a few lines ? About _Encode121: I'd name this _EncodeUCS1 since that's what it is ;-) About the new functions: I was referring to the new static functions which you gave PyUnicode_... names. If these are not supposed to turn into non-static functions, I'd rather have them use lower case names (since that's how the Python internals work too -- most of the times). ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 09:56 Message: Logged In: YES user_id=89016 > One thing which I don't like about your API change is that > you removed the Py_UNICODE*data, int size style arguments > -- > this makes it impossible to use the new APIs on non-Python > data or data which is not available as Unicode object. Another problem is, that the callback requires a Python object, so in the PyObject *version, the refcount is incref'd and the object is passed to the callback. The Py_UNICODE*/int version would have to create a new Unicode object from the data. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 09:32 Message: Logged In: YES user_id=89016 > * please don't place more than one C statement on one line > like in: > """ > + unicode = unicode2; unicodepos = > unicode2pos; > + unicode2 = NULL; unicode2pos = 0; > """ OK, done! > * Comments should start with a capital letter and be > prepended > to the section they apply to Fixed! > * There should be spaces between arguments in compares > (a == b) not (a==b) Fixed! > * Where does the name "...Encode121" originate ? encode one-to-one, it implements both ASCII and latin-1 encoding. > * module internal APIs should use lower case names (you > converted some of these to PyUnicode_...() -- this is > normally reserved for APIs which are either marked as > potential candidates for the public API or are very > prominent in the code) Which ones? I introduced a new function for every old one, that had a "const char *errors" argument, and a few new ones in codecs.h, of those PyCodec_EncodeHandlerForObject is vital, because it is used to map for old string arguments to the new function objects. PyCodec_RaiseEncodeErrors can be used in the encoder implementation to raise an encode error, but it could be made static in unicodeobject.h so only those encoders implemented there have access to it. > One thing which I don't like about your API change is that > you removed the Py_UNICODE*data, int size style arguments > -- > this makes it impossible to use the new APIs on non-Python > data or data which is not available as Unicode object. I look through the code and found no situation where the Py_UNICODE*/int version is really used and having two (PyObject *)s (the original and the replacement string), instead of UNICODE*/int and PyObject * made the implementation a little easier, but I can fix that. > Please separate the errors.c patch from this patch -- it > seems totally unrelated to Unicode. PyCodec_RaiseEncodeErrors uses this the have a \Uxxxx with four hex digits. I removed it. I'll upload a revised patch as soon as it's done. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-12 07:29 Message: Logged In: YES user_id=38388 Thanks for the patch -- it looks very impressive !. I'll give it a try later this week. Some first cosmetic tidbits: * please don't place more than one C statement on one line like in: """ + unicode = unicode2; unicodepos = unicode2pos; + unicode2 = NULL; unicode2pos = 0; """ * Comments should start with a capital letter and be prepended to the section they apply to * There should be spaces between arguments in compares (a == b) not (a==b) * Where does the name "...Encode121" originate ? * module internal APIs should use lower case names (you converted some of these to PyUnicode_...() -- this is normally reserved for APIs which are either marked as potential candidates for the public API or are very prominent in the code) One thing which I don't like about your API change is that you removed the Py_UNICODE*data, int size style arguments -- this makes it impossible to use the new APIs on non-Python data or data which is not available as Unicode object. Please separate the errors.c patch from this patch -- it seems totally unrelated to Unicode. Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=432401&group_id=5470 From noreply@sourceforge.net Fri Jul 13 16:42:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Jul 2001 08:42:19 -0700 Subject: [Patches] [ python-Patches-422471 ] Install IDLE Help File Message-ID: Patches item #422471, was opened at 2001-05-08 14:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422471&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Nobody/Anonymous (nobody) Summary: Install IDLE Help File Initial Comment: Installing Idle to site-packages via Distutils does not copy the Idle help.txt file. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2001-07-13 08:42 Message: Logged In: YES user_id=149084 I had uploaded twice because the first time I had the wrong MIME type. The second (lower) file is text/plain. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422471&group_id=5470 From noreply@sourceforge.net Fri Jul 13 17:22:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Jul 2001 09:22:42 -0700 Subject: [Patches] [ python-Patches-441091 ] Allow jython to complete test_zlib test Message-ID: Patches item #441091, was opened at 2001-07-13 09:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441091&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Nobody/Anonymous (nobody) Summary: Allow jython to complete test_zlib test Initial Comment: The more advanced flush options are not availabe in java. With the patch, test_zlib will only use the advanced flush options if they are defined in the zlib module. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441091&group_id=5470 From noreply@sourceforge.net Fri Jul 13 21:48:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Jul 2001 13:48:36 -0700 Subject: [Patches] [ python-Patches-441175 ] Tests for glob.py Message-ID: Patches item #441175, was opened at 2001-07-13 13:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441175&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Tests for glob.py Initial Comment: Another in the series. This file uses "unittest" to test the glob.py module. (Caveat: I've really tried to be as cross-platform as I know how, but there may be some problems remaining. At least it works on Unix!) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441175&group_id=5470 From noreply@sourceforge.net Sat Jul 14 01:12:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Jul 2001 17:12:05 -0700 Subject: [Patches] [ python-Patches-441229 ] f.readline() checks for errors Message-ID: Patches item #441229, was opened at 2001-07-13 17:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441229&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: f.readline() checks for errors Initial Comment: Previously, f.read() and f.readlines() checked for errors on their file object and possibly raised an IOError, but f.readline() didn't. This patch makes f.readline() behave like the others. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441229&group_id=5470 From noreply@sourceforge.net Sat Jul 14 19:07:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Jul 2001 11:07:00 -0700 Subject: [Patches] [ python-Patches-404997 ] Alternative to __future__ imports Message-ID: Patches item #404997, was opened at 2001-02-28 13:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: Postponed >Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Guido van Rossum (gvanrossum) Summary: Alternative to __future__ imports Initial Comment: This patch adds an alternative notation for selecting nested scopes on the module level, by means of a directive nested_scopes declaration. This is a declaration, and it may only appear at the "beginning" of a module. Even though it adds a keyword "directive", this is only a keyword if it appears as the first keyword in the file; as a result, def directive(): directive = 1 is still accepted (even without warning, but that could be changed if desired). The patch currently only accepts the directives that are also __future__ imports, although it can be extended to allow other things, e.g. directive source_encoding "latin-1" This is possible since the syntax allows an optional atom after the directive's name. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-20 13:08 Message: Logged In: YES user_id=6380 I'm postponing this now. I like the idea of directives, but I don't think we should disrupt the 2.1 release for this. So let's look at this again after 2.1. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-20 04:15 Message: Logged In: YES user_id=21627 Revised patch to match the draft PEP (244?): nested scopes are enabled by "directive transitional nested_scopes", and a warning is produced if "directive" is used as a name. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 21:22 Message: Logged In: YES user_id=31435 SourceForge is driving me nuts today. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 21:21 Message: Logged In: YES user_id=31435 Assigned to Guido: since the patch would replace the current future_statement implementation, doing anything with it before Friday would require BDFL decree. I personally like that future_statements don't look like general directives: directive integer_division directive left_hand_side_swap Over time, the set of names grows, and it won't be clear which directives are dead-serious business (like an incompatible language change) and which minor tweaking of pragmatics. An extension was briefly discussed on c.l.py, along the lines of adding another word, e.g. directive future integer_division directive pragma left_hand_side_swap Whatever, AFAIK that didn't get implemented, and there's no PEP for it (or this) in any case (BTW, while I would like to see a PEP for a general directive facility, I'm not going to write one). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:58 Message: Logged In: YES user_id=31435 @Home is major-league hosed; switching to another ISP to delete 3 of the 4(!) patch copies I managed to attach to this. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:11 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:10 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:08 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-19 20:04 Message: Logged In: YES user_id=31435 Trying to attach the patch (for whatever reason, it took about 15 minutes to retrive it from the URL given). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-02-28 22:09 Message: Logged In: YES user_id=21627 Sigh. The patch is now at http://www.informatik.hu-berlin.de/~loewis/python/directive.diff ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-02-28 22:06 Message: Logged In: YES user_id=21627 Retry uploading the patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 From noreply@sourceforge.net Sat Jul 14 19:07:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Jul 2001 11:07:47 -0700 Subject: [Patches] [ python-Patches-440487 ] int to the negative power -> float Message-ID: Patches item #440487, was opened at 2001-07-11 12:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440487&group_id=5470 Category: core (C code) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) >Assigned to: Guido van Rossum (gvanrossum) Summary: int to the negative power -> float Initial Comment: Currently, int to the negative int power raises an exception. This was one of the two problems that the VPython users complained about. (The other was that integer division returns a truncated integer, but that's another story. :-) I propose to implement this in Python 2.2. Anybody have a problem with this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-12 04:29 Message: Logged In: YES user_id=6380 OK, checked in. Also updated the docs. Question: should we do a similar thing to negative_float to the fractional_power ? That could return a complex number rather than raising an exception. But it breaks the rule that we don't return complex numbers unless the user explicitly asks for it (otherwise the cmath module should be merged with the math module as well). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 18:16 Message: Logged In: YES user_id=31435 Marked Accepted and back to Guido. The comments should say "the" instead of "both", since there are 3 arguments. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 16:18 Message: Logged In: YES user_id=6380 OK, here's a new patch, for int and long. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 14:46 Message: Logged In: YES user_id=31435 Back to Guido. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 13:23 Message: Logged In: YES user_id=31435 I liked the first patch better. *Looks* like under the new patch pow(2, -3, 1) will raise a ValueError but 2 ** -3 % 1 will return 0.125. That's close to inexplicable. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 13:04 Message: Logged In: YES user_id=31435 Tough luck for you, you mean . I considered z != None and didn't care. They're going to be just as surprised by i**j returning a float if j accidentally becomes negative. When making a formerly exceptional case "mean something", potential surprise is unavoidable, and if in the new world 2 ** -3 % 1 returns 0.125 is will be just as surprising if pow(2, -3, 1) does not return 0.125. The new rules should be consistent with *themselves* more than with oddball cases across releases. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 12:59 Message: Logged In: YES user_id=6380 New patch that only falls back to float when 3rd arg is None. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 12:52 Message: Logged In: YES user_id=6380 Tough luck. :-) There may be something else wrong with the patch: it probably shouldn't fall back to float when z is not None. After all, pow(x, y, z) should compute x**y % z, and I'm sure that someone using this would be quite surprised to get a floating point number back if they accidentally let y become negative! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 12:46 Message: Logged In: YES user_id=31435 No objection so far as it goes, but surely long_pow() should also attempt the same kind of thing then. Should add some test cases and docs too (yes, I'm going to hold you to the same stds as contributors ). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440487&group_id=5470 From noreply@sourceforge.net Sat Jul 14 23:18:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Jul 2001 15:18:55 -0700 Subject: [Patches] [ python-Patches-441348 ] Allow jython to complete test_charmap Message-ID: Patches item #441348, was opened at 2001-07-14 15:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441348&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Nobody/Anonymous (nobody) Summary: Allow jython to complete test_charmap Initial Comment: The repr of unicode strings in the output is different for jython. The attached patch allow jython to complete the test_charmapcodec test. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441348&group_id=5470 From noreply@sourceforge.net Sat Jul 14 23:46:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Jul 2001 15:46:14 -0700 Subject: [Patches] [ python-Patches-441350 ] Disutils config try_run broken Message-ID: Patches item #441350, was opened at 2001-07-14 15:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441350&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tarn Weisner Burton (twburton) Assigned to: Nobody/Anonymous (nobody) Summary: Disutils config try_run broken Initial Comment: The distutils.command.config try_run method is broken. First it doesn't save the name of the compiled prog, then it tries to execute the non-existent symbol "exe" Here is what it does now: --------- try: self._link(body, headers, include_dirs, libraries, library_dirs, lang) self.spawn([exe]) ok = 1 except (CompileError, LinkError, DistutilsExecError): ok = 0 --------- This will fix it: --------- try: src, obj, prog = self._link(body, headers, include_dirs, libraries, library_dirs, lang) self.spawn([prog]) ok = 1 except (CompileError, LinkError, DistutilsExecError): ok = 0 ---------- Tarn twburton@users.sf.net ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441350&group_id=5470 From friends@openxxx.net Sun Jul 15 04:28:20 2001 From: friends@openxxx.net (friends@openxxx.net) Date: Sat, 14 Jul 2001 23:28:20 -0400 Subject: [Patches] Hello, your friend recommended openxxx to you Message-ID: You have been invited to check out this adult site by one of your friends who visited us. our URL is http://www.openxxx.net/ enjoy, OpenXXX TEAM 2001 From noreply@sourceforge.net Sun Jul 15 23:25:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Jul 2001 15:25:51 -0700 Subject: [Patches] [ python-Patches-441527 ] unixccompiler preprocessor broken Message-ID: Patches item #441527, was opened at 2001-07-15 15:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441527&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tarn Weisner Burton (twburton) Assigned to: Nobody/Anonymous (nobody) Summary: unixccompiler preprocessor broken Initial Comment: The unix c compiler preprocessor is broken. First, the extra_postargs just get thrown away by the line: if extra_postargs: extra_postargs.extend (extra_postargs) which should be: if extra_postargs: pp_args.extend(extra_postargs) Second, preprocessing to stdout never happens unless force is on: if self.force or (output_file and newer(source, output_file)): instead this should be: if self.force or output_file is None or newer(source, output_file): Tarn twburton@users.sf.net ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441527&group_id=5470 From noreply@sourceforge.net Sun Jul 15 23:31:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Jul 2001 15:31:34 -0700 Subject: [Patches] [ python-Patches-441528 ] MSVC Preprocessor Message-ID: Patches item #441528, was opened at 2001-07-15 15:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441528&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tarn Weisner Burton (twburton) Assigned to: Nobody/Anonymous (nobody) Summary: MSVC Preprocessor Initial Comment: The attached script has a preprocessor method for the MSVC compiler. Tarn twburton@users.sf.net ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441528&group_id=5470 From noreply@sourceforge.net Sun Jul 15 23:32:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Jul 2001 15:32:55 -0700 Subject: [Patches] [ python-Patches-441528 ] MSVC Preprocessor Message-ID: Patches item #441528, was opened at 2001-07-15 15:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441528&group_id=5470 >Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tarn Weisner Burton (twburton) Assigned to: Nobody/Anonymous (nobody) Summary: MSVC Preprocessor Initial Comment: The attached script has a preprocessor method for the MSVC compiler. Tarn twburton@users.sf.net ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441528&group_id=5470 From wwwjessie@21cn.com Mon Jul 16 10:45:00 2001 From: wwwjessie@21cn.com (wwwjessie@21cn.com) Date: Mon, 16 Jul 2001 17:45:00 +0800 Subject: [Patches] =?gb2312?B?tPPBrC0yMDAxxOq5+rzKwszJq8qzxrfT68jLwOC9ob+1sqnAwLvhKA==?= =?gb2312?B?QWdybyBBbm51YWwgTWVldGluZyBDaGluYSAyMDAxKQ0=?= Message-ID: <2af2a01c10ddb$fb44e600$9300a8c0@ifood1gongxing> This is a multi-part message in MIME format. ------=_NextPart_000_2AF2B_01C10E1F.09682600 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MjAwMcTq1tC5+rn6vMrFqdK1v8a8vMTqu+ENCrn6vMrCzMmryrPGt9PryMvA4L2hv7WyqcDAu+G8 sNGnyvXM1sLbu+ENCg0KCQ0K1bnG2qO6IAmhoTIwMDHE6jnUwjTI1S03yNUJDQq12LXjo7ogCaGh tPPBrNDHuqO74dW51tDQxAkNCtb3sOyjuiAJoaHW0LuqyMvD8bmyus25+sWp0rWyvw0KoaHW0Ln6 v8bRp7y8yvXQrbvhDQqhobTzwazK0MjLw/HV/riuDQoJDQqz0LDso7ogCaGh1tC5+sLMyavKs8a3 t6LVudbQ0MQNCqGh1tC5+sWp0ae74Q0KoaHW0Ln6wszJq8qzxrfQrbvhDQqhobTzwazK0MWp0rW+ 1g0KoaG088Gs0Me6o7vh1bnW0NDEDQoJDQrN+MLnt/7O8czhuanJzKO60rzKs8a31tC5+s34IGh0 dHA6Ly93d3cuaWZvb2QxLmNvbQ0KPGh0dHA6Ly93d3cuaWZvb2QxLmNvbS9pbmRleC5hc3A/ZnI9 cGF0Y2hlc0BweXRob24ub3JnPiAJDQogCQ0Kofogzai5/dK8yrPGt9bQufrN+LGow/uyztW5o7q+ xdXb08W73SixyMjnz9bT0MO/uPYgM00gWCAzTSC1xLHq17zVuc671K2821JNQjQ1MDCjrM2ouf3O 0sPH1rvQ6Li2Uk1CNDA1MCmjrA0KsajD+73Y1rnI1cbaMjAwMcTqN9TCMjDI1SA8aHR0cDovL2dy ZWVuMjAwMS5pZm9vZDEuY29tL2Zyb20xLmFzcD4gDQqh+iC7ttOtIMPit9HXorLhIDxodHRwOi8v d3d3Lmlmb29kMS5jb20vc2lnbnVwL3NldmFncmVlbS5hc3A+ILPJzqq5q8u+u+HUsaGjDQo31MIy MMjVx7DXorLho6zE+r2r1No31MIyNcjVx7DNqLn9tefX09PKvP63vcq9w+K30bvxtcMzMMz1ssm5 utDFz6Khow0KyOe5+8T6srvP68rVtb3O0sPHtcTTyrz+o6zH6yDBqs+1ztLDxyA8bWFpbHRvOnVu c3Vic2NyaWJlQGlmb29kMS5jb20+IKOsztLDx9LUuvO9q7K71Nm3otPKvP64+MT6oaMNCrLp0a+j uiBzYWxlc0BpZm9vZDEuY29tIDxtYWlsdG86c2FsZXNAaWZvb2QxLmNvbT4gIKGhoaG157uwo7ow NzU1LTM3ODYzMDmhoc/6ytuyvw0KyfLQob3jILbFz8jJ+g0KDQoNCiANCg0Ku9gg1rQgo6jH67Sr 1eajujA3NTUtMzIzOTA0N7vyILeitefX09PKvP6juiBzYWxlc0BpZm9vZDEuY29tIDxtYWlsdG86 c2FsZXNAaWZvb2QxLmNvbT4NCqOpCQ0KofUgsb65q8u+09DS4s2ouf3SvMqzxrfW0Ln6zfiyztW5 IKGhoaEgofUgsb65q8u+xOK9+NK7sr3By73iuMOyqcDAu+GjrMfr0+vO0sPHwarPtQ0KDQq5q8u+ w/uzxqO6X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCsGqz7XIy6O6X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Ktee7sKO6X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KtKvV5qO6X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KRS1tYWlso7pfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoJDQogCQ0KIAkNCiAJDQogCQ0KIAkNCg== ------=_NextPart_000_2AF2B_01C10E1F.09682600 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5VbnRpdGxlZCBEb2N1bWVudDwvdGl0bGU+IDxtZXRhIGh0 dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMx MiI+IA0KPHN0eWxlIHR5cGU9InRleHQvY3NzIj4NCjwhLS0NCnRkIHsgIGxpbmUtaGVpZ2h0OiAy NHB4fQ0KLS0+DQo8L3N0eWxlPiANCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiIg dGV4dD0iIzAwMDAwMCI+DQo8ZGl2IGFsaWduPSJDRU5URVIiPjx0YWJsZSB3aWR0aD0iNzUlIiBi b3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCI+PHRyPjx0ZCBhbGlnbj0i Q0VOVEVSIj48YSBocmVmPSJodHRwOy8vZ3JlZW4yMDAxLmlmb29kMS5jb20iPjxiPjIwMDHE6tbQ ufq5+rzKxanStb/GvLzE6rvhPGJyPrn6vMrCzMmryrPGt9PryMvA4L2hv7WyqcDAu+G8sNGnyvXM 1sLbu+E8L2I+PC9hPjxicj48YnI+PC90ZD48L3RyPjx0cj48dGQgYWxpZ249IkNFTlRFUiI+PHRh YmxlIHdpZHRoPSI3NSUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIw Ij48dHI+PHRkIGhlaWdodD0iMTIiIHdpZHRoPSIzOSUiIGFsaWduPSJSSUdIVCI+PGI+PGZvbnQg c2l6ZT0iMiI+1bnG2qO6IA0KPC9mb250PjwvYj48L3RkPjx0ZCBoZWlnaHQ9IjEyIiB3aWR0aD0i NjElIj48Zm9udCBzaXplPSIyIj6hoTIwMDHE6jnUwjTI1S03yNU8L2ZvbnQ+PC90ZD48L3RyPjx0 cj48dGQgaGVpZ2h0PSIxMiIgd2lkdGg9IjM5JSIgYWxpZ249IlJJR0hUIj48Yj48Zm9udCBzaXpl PSIyIj612LXjo7ogDQo8L2ZvbnQ+PC9iPjwvdGQ+PHRkIGhlaWdodD0iMTIiIHdpZHRoPSI2MSUi Pjxmb250IHNpemU9IjIiPqGhtPPBrNDHuqO74dW51tDQxDwvZm9udD48L3RkPjwvdHI+PHRyPjx0 ZCBoZWlnaHQ9IjEyIiB3aWR0aD0iMzklIiBhbGlnbj0iUklHSFQiIHZhbGlnbj0iVE9QIj48Yj48 Zm9udCBzaXplPSIyIj7W97Dso7ogDQo8L2ZvbnQ+PC9iPjwvdGQ+PHRkIGhlaWdodD0iMTIiIHdp ZHRoPSI2MSUiPjxmb250IHNpemU9IjIiPqGhPC9mb250Pjxmb250IHNpemU9IjIiPtbQu6rIy8Px ubK6zbn6xanStbK/PGJyPqGh1tC5+r/G0ae8vMr10K274Txicj6hobTzwazK0MjLw/HV/riuPGJy PjwvZm9udD48L3RkPjwvdHI+PHRyPjx0ZCBoZWlnaHQ9IjEyIiB3aWR0aD0iMzklIiBhbGlnbj0i UklHSFQiIHZhbGlnbj0iVE9QIj48Yj48Zm9udCBzaXplPSIyIj6z0LDso7ogDQo8L2ZvbnQ+PC9i PjwvdGQ+PHRkIGhlaWdodD0iMTIiIHdpZHRoPSI2MSUiPjxmb250IHNpemU9IjIiPqGhPC9mb250 Pjxmb250IHNpemU9IjIiPtbQufrCzMmryrPGt7ei1bnW0NDEPGJyPqGh1tC5+sWp0ae74Txicj6h odbQufrCzMmryrPGt9Ctu+E8YnI+oaG088GsytDFqdK1vtY8YnI+oaG088Gs0Me6o7vh1bnW0NDE PGJyPjwvZm9udD48L3RkPjwvdHI+PHRyPjx0ZCBjb2xzcGFuPSIyIiBhbGlnbj0iQ0VOVEVSIj48 Zm9udCBzaXplPSIyIj7N+MLnt/7O8czhuanJzKO60rzKs8a31tC5+s34IA0KPGEgaHJlZj0iaHR0 cDovL3d3dy5pZm9vZDEuY29tL2luZGV4LmFzcD9mcj1wYXRjaGVzQHB5dGhvbi5vcmciPmh0dHA6 Ly93d3cuaWZvb2QxLmNvbTwvYT48L2ZvbnQ+PC90ZD48L3RyPjx0cj48dGQgY29sc3Bhbj0iMiIg YWxpZ249IkNFTlRFUiI+Jm5ic3A7PC90ZD48L3RyPjx0cj48dGQgY29sc3Bhbj0iMiIgYWxpZ249 IkxFRlQiPjxwPjxmb250IHNpemU9IjIiPqH6IA0Kzai5/dK8yrPGt9bQufrN+LGow/uyztW5o7o8 Yj48Zm9udCBzaXplPSIzIiBjb2xvcj0iI0ZGMDAwMCI+vsXV29PFu908L2ZvbnQ+PC9iPiixyMjn z9bT0MO/uPYgM00gWCAzTSANCrXEserXvNW5zrvUrbzbUk1CNDUwMKOszai5/c7Sw8fWu9DouLZS TUI0MDUwKaOsIDxhIGhyZWY9Imh0dHA6Ly9ncmVlbjIwMDEuaWZvb2QxLmNvbS9mcm9tMS5hc3Ai PjxiPjxmb250IHNpemU9IjMiIGNvbG9yPSIjRkYwMDAwIj6xqMP7vdjWucjVxtoyMDAxxOo31MIy MMjVPC9mb250PjwvYj48L2E+PGJyPqH6IA0Ku7bTrTxhIGhyZWY9Imh0dHA6Ly93d3cuaWZvb2Qx LmNvbS9zaWdudXAvc2V2YWdyZWVtLmFzcCI+w+K30deisuE8L2E+s8nOqrmry7674dSxoaMgPGZv bnQgY29sb3I9IiNGRjAwMDAiPjxiPjxmb250IHNpemU9IjMiPjfUwjIwyNXHsNeisuGjrMT6vavU 2jfUwjI1yNXHsM2ouf2159fT08q8/re9yr3D4rfRu/G1wzMwzPWyybm60MXPoqGjPC9mb250Pjwv Yj48L2ZvbnQ+PGJyPsjnufvE+rK7z+vK1bW9ztLDx7XE08q8/qOsx+s8YSBocmVmPSJtYWlsdG86 dW5zdWJzY3JpYmVAaWZvb2QxLmNvbSI+warPtc7Sw8c8L2E+o6zO0sPH0tS6872rsrvU2bei08q8 /rj4xPqhozxicj6y6dGvo7o8YSBocmVmPSJtYWlsdG86c2FsZXNAaWZvb2QxLmNvbSI+c2FsZXNA aWZvb2QxLmNvbTwvYT4gDQqhoaGhtee7sKO6MDc1NS0zNzg2MzA5oaHP+srbsr8gyfLQob3jILbF z8jJ+jxicj48L2ZvbnQ+PC9wPjxwPiZuYnNwOzwvcD48L3RkPjwvdHI+PHRyPjx0ZCBoZWlnaHQ9 IjMwIiBjb2xzcGFuPSIyIiBhbGlnbj0iQ0VOVEVSIj48Zm9udCBzaXplPSIyIj48Yj672CANCta0 IKOox+u0q9Xmo7owNzU1LTMyMzkwNDe78iC3orXn19PTyrz+o7ogPGEgaHJlZj0ibWFpbHRvOnNh bGVzQGlmb29kMS5jb20iPnNhbGVzQGlmb29kMS5jb208L2E+IA0Ko6k8L2I+PC9mb250PjwvdGQ+ PC90cj48dHI+PHRkIGhlaWdodD0iMTIiIGNvbHNwYW49IjIiPjxmb250IHNpemU9IjIiPqH1ILG+ uavLvtPQ0uLNqLn90rzKs8a31tC5+s34ss7VuSANCqGhoaEgofUgsb65q8u+xOK9+NK7sr3By73i uMOyqcDAu+GjrMfr0+vO0sPHwarPtTxicj48YnI+uavLvsP7s8ajul9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPsGqz7XIy6O6X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiI+tee7sKO6X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj60q9Xmo7pfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPkUtbWFpbKO6X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj48L2ZvbnQ+PC90ZD48L3RyPjx0cj48dGQgaGVpZ2h0PSIxMiIgY29sc3Bhbj0i MiIgYWxpZ249IkxFRlQiPiZuYnNwOzwvdGQ+PC90cj48dHI+PHRkIGhlaWdodD0iMTIiIGNvbHNw YW49IjIiIGFsaWduPSJMRUZUIj4mbmJzcDs8L3RkPjwvdHI+PHRyPjx0ZCBoZWlnaHQ9IjEyIiBj b2xzcGFuPSIyIiBhbGlnbj0iTEVGVCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+PC90ZD48L3Ry Pjx0cj48dGQ+Jm5ic3A7PC90ZD48L3RyPjx0cj48dGQ+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+ PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= ------=_NextPart_000_2AF2B_01C10E1F.09682600-- From noreply@sourceforge.net Mon Jul 16 14:22:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Jul 2001 06:22:42 -0700 Subject: [Patches] [ python-Patches-441527 ] unixccompiler preprocessor broken Message-ID: Patches item #441527, was opened at 2001-07-15 15:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441527&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tarn Weisner Burton (twburton) >Assigned to: A.M. Kuchling (akuchling) Summary: unixccompiler preprocessor broken Initial Comment: The unix c compiler preprocessor is broken. First, the extra_postargs just get thrown away by the line: if extra_postargs: extra_postargs.extend (extra_postargs) which should be: if extra_postargs: pp_args.extend(extra_postargs) Second, preprocessing to stdout never happens unless force is on: if self.force or (output_file and newer(source, output_file)): instead this should be: if self.force or output_file is None or newer(source, output_file): Tarn twburton@users.sf.net ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441527&group_id=5470 From noreply@sourceforge.net Mon Jul 16 14:23:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Jul 2001 06:23:20 -0700 Subject: [Patches] [ python-Patches-441528 ] MSVC Preprocessor Message-ID: Patches item #441528, was opened at 2001-07-15 15:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441528&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tarn Weisner Burton (twburton) >Assigned to: A.M. Kuchling (akuchling) Summary: MSVC Preprocessor Initial Comment: The attached script has a preprocessor method for the MSVC compiler. Tarn twburton@users.sf.net ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-16 06:23 Message: Logged In: YES user_id=6380 Or should this go to Thomas Heller? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441528&group_id=5470 From noreply@sourceforge.net Mon Jul 16 14:40:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Jul 2001 06:40:08 -0700 Subject: [Patches] [ python-Patches-441528 ] MSVC Preprocessor Message-ID: Patches item #441528, was opened at 2001-07-15 15:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441528&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tarn Weisner Burton (twburton) >Assigned to: Thomas Heller (theller) Summary: MSVC Preprocessor Initial Comment: The attached script has a preprocessor method for the MSVC compiler. Tarn twburton@users.sf.net ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-07-16 06:40 Message: Logged In: YES user_id=11375 Reassigning to Thomas, since I can't test anything with MSVC. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-16 06:23 Message: Logged In: YES user_id=6380 Or should this go to Thomas Heller? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441528&group_id=5470 From noreply@sourceforge.net Mon Jul 16 15:14:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Jul 2001 07:14:00 -0700 Subject: [Patches] [ python-Patches-417872 ] unset PYTHONHOME when running setup.py Message-ID: Patches item #417872, was opened at 2001-04-21 10:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417872&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Neil Schemenauer (nascheme) Assigned to: A.M. Kuchling (akuchling) Summary: unset PYTHONHOME when running setup.py Initial Comment: This should be applied to the 2.1-maint branch as well. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-07-16 07:14 Message: Logged In: YES user_id=11375 Applied at some point. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417872&group_id=5470 From noreply@sourceforge.net Mon Jul 16 15:21:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Jul 2001 07:21:31 -0700 Subject: [Patches] [ python-Patches-441527 ] unixccompiler preprocessor broken Message-ID: Patches item #441527, was opened at 2001-07-15 15:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441527&group_id=5470 Category: distutils Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Tarn Weisner Burton (twburton) Assigned to: A.M. Kuchling (akuchling) Summary: unixccompiler preprocessor broken Initial Comment: The unix c compiler preprocessor is broken. First, the extra_postargs just get thrown away by the line: if extra_postargs: extra_postargs.extend (extra_postargs) which should be: if extra_postargs: pp_args.extend(extra_postargs) Second, preprocessing to stdout never happens unless force is on: if self.force or (output_file and newer(source, output_file)): instead this should be: if self.force or output_file is None or newer(source, output_file): Tarn twburton@users.sf.net ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-07-16 07:21 Message: Logged In: YES user_id=11375 Excellent! I've applied your suggested changes to the CVS tree; they're in rev. 1.34 of distutils/unixccompiler.py, and will be in Python 2.2. If you follow the CVS tree, please check that I got the changes correct. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441527&group_id=5470 From noreply@sourceforge.net Mon Jul 16 15:27:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Jul 2001 07:27:32 -0700 Subject: [Patches] [ python-Patches-441691 ] BCPP Preprocessor Message-ID: Patches item #441691, was opened at 2001-07-16 07:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441691&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tarn Weisner Burton (twburton) Assigned to: Nobody/Anonymous (nobody) Summary: BCPP Preprocessor Initial Comment: Preprocessor method for bcppcompiler. The only missing functionality is the ability to send the output to stdout. cpp32 can't seem to do this. This doesn't really seem needed anyways. Tarn ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441691&group_id=5470 From noreply@sourceforge.net Mon Jul 16 15:28:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Jul 2001 07:28:11 -0700 Subject: [Patches] [ python-Patches-441691 ] BCPP Preprocessor Message-ID: Patches item #441691, was opened at 2001-07-16 07:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441691&group_id=5470 >Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tarn Weisner Burton (twburton) Assigned to: Nobody/Anonymous (nobody) Summary: BCPP Preprocessor Initial Comment: Preprocessor method for bcppcompiler. The only missing functionality is the ability to send the output to stdout. cpp32 can't seem to do this. This doesn't really seem needed anyways. Tarn ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441691&group_id=5470 From noreply@sourceforge.net Mon Jul 16 17:11:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Jul 2001 09:11:22 -0700 Subject: [Patches] [ python-Patches-417872 ] unset PYTHONHOME when running setup.py Message-ID: Patches item #417872, was opened at 2001-04-21 10:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417872&group_id=5470 Category: Build Group: None Status: Closed Resolution: Accepted Priority: 7 Submitted By: Neil Schemenauer (nascheme) Assigned to: A.M. Kuchling (akuchling) Summary: unset PYTHONHOME when running setup.py Initial Comment: This should be applied to the 2.1-maint branch as well. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-07-16 09:11 Message: Logged In: YES user_id=34209 I'm not able to find this actually applied in the 21-maint branch, AMK... are you sure you checked there ? Should I apply it or not ? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-07-16 07:14 Message: Logged In: YES user_id=11375 Applied at some point. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417872&group_id=5470 From noreply@sourceforge.net Mon Jul 16 20:34:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Jul 2001 12:34:14 -0700 Subject: [Patches] [ python-Patches-441791 ] Improvment to package import semantics Message-ID: Patches item #441791, was opened at 2001-07-16 12:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441791&group_id=5470 Category: core (C code) Group: 2.0.1 bugfix Status: Open Resolution: None Priority: 5 Submitted By: Alex Coventry (alex_coventry) Assigned to: Nobody/Anonymous (nobody) Summary: Improvment to package import semantics Initial Comment: I think it's nice to be able to do this: >>> import sys >>> sys.path.append('/l/alex_c/') >>> import mouse.foo Traceback (most recent call last): File "", line 1, in ? File "/l/alex_c/mouse/foo.py", line 1, in ? bar NameError: name 'bar' is not defined >>> import mouse.foo >>> reload(mouse.foo) # Works now that foo.py is corrected >>> from mouse import foo >>> foo.bar 1 However, at the moment, that's not possible, because if an error occurs in the loading of foo, foo is not added to mouse's dictionary, even though the module added to sys.modules under the key 'mouse.foo'. This has been driving me nuts, because I have large datasets that I need to load in each time I start python up, so I tend to test my scripts in a single interactive interpreter as I write them, so it's important for me to be able to reliably reload modules. I think it's also a sensible way for things to work in general, too. If there's enough controversy about this, I can write a PEP about it, or something. At any rate, here's a patch against the current CVS repository that changes the semantics as I've described. Alex. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441791&group_id=5470 From noreply@sourceforge.net Mon Jul 16 20:34:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Jul 2001 12:34:16 -0700 Subject: [Patches] [ python-Patches-441793 ] Improvment to package import semantics Message-ID: Patches item #441793, was opened at 2001-07-16 12:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441793&group_id=5470 Category: core (C code) Group: 2.0.1 bugfix Status: Open Resolution: None Priority: 5 Submitted By: Alex Coventry (alex_coventry) Assigned to: Nobody/Anonymous (nobody) Summary: Improvment to package import semantics Initial Comment: I think it's nice to be able to do this: >>> import sys >>> sys.path.append('/l/alex_c/') >>> import mouse.foo Traceback (most recent call last): File "", line 1, in ? File "/l/alex_c/mouse/foo.py", line 1, in ? bar NameError: name 'bar' is not defined >>> import mouse.foo >>> reload(mouse.foo) # Works now that foo.py is corrected >>> from mouse import foo >>> foo.bar 1 However, at the moment, that's not possible, because if an error occurs in the loading of foo, foo is not added to mouse's dictionary, even though the module added to sys.modules under the key 'mouse.foo'. This has been driving me nuts, because I have large datasets that I need to load in each time I start python up, so I tend to test my scripts in a single interactive interpreter as I write them, so it's important for me to be able to reliably reload modules. I think it's also a sensible way for things to work in general, too. If there's enough controversy about this, I can write a PEP about it, or something. At any rate, here's a patch against the current CVS repository that changes the semantics as I've described. Alex. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441793&group_id=5470 From noreply@sourceforge.net Mon Jul 16 20:42:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Jul 2001 12:42:30 -0700 Subject: [Patches] [ python-Patches-441791 ] Improvment to package import semantics Message-ID: Patches item #441791, was opened at 2001-07-16 12:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441791&group_id=5470 Category: core (C code) Group: 2.0.1 bugfix Status: Open Resolution: None Priority: 5 Submitted By: Alex Coventry (alex_coventry) Assigned to: Nobody/Anonymous (nobody) Summary: Improvment to package import semantics Initial Comment: I think it's nice to be able to do this: >>> import sys >>> sys.path.append('/l/alex_c/') >>> import mouse.foo Traceback (most recent call last): File "", line 1, in ? File "/l/alex_c/mouse/foo.py", line 1, in ? bar NameError: name 'bar' is not defined >>> import mouse.foo >>> reload(mouse.foo) # Works now that foo.py is corrected >>> from mouse import foo >>> foo.bar 1 However, at the moment, that's not possible, because if an error occurs in the loading of foo, foo is not added to mouse's dictionary, even though the module added to sys.modules under the key 'mouse.foo'. This has been driving me nuts, because I have large datasets that I need to load in each time I start python up, so I tend to test my scripts in a single interactive interpreter as I write them, so it's important for me to be able to reliably reload modules. I think it's also a sensible way for things to work in general, too. If there's enough controversy about this, I can write a PEP about it, or something. At any rate, here's a patch against the current CVS repository that changes the semantics as I've described. Alex. ---------------------------------------------------------------------- >Comment By: Alex Coventry (alex_coventry) Date: 2001-07-16 12:42 Message: Logged In: YES user_id=49686 a) Sorry about the duplicate submission b) I attached the patch I'm proposing to it, but can't see it on this page. Here it is, just in case: Index: Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.178 diff -c -r2.178 import.c *** Python/import.c 2001/07/05 03:47:53 2.178 --- Python/import.c 2001/07/16 19:04:05 *************** *** 1789,1795 **** import_submodule(PyObject *mod, char *subname, char *fullname) { PyObject *modules = PyImport_GetModuleDict(); ! PyObject *m; /* Require: if mod == None: subname == fullname --- 1789,1795 ---- import_submodule(PyObject *mod, char *subname, char *fullname) { PyObject *modules = PyImport_GetModuleDict(); ! PyObject *m, *resulting_module=NULL; /* Require: if mod == None: subname == fullname *************** *** 1829,1839 **** m = load_module(fullname, fp, buf, fdp->type); if (fp) fclose(fp); ! if (m != NULL && mod != Py_None) { ! if (PyObject_SetAttrString(mod, subname, m) < 0) { ! Py_DECREF(m); ! m = NULL; ! } } } --- 1829,1864 ---- m = load_module(fullname, fp, buf, fdp->type); if (fp) fclose(fp); ! if (mod != Py_None) { ! ! /* Irrespective of the success of this load, make a ! reference to it in the parent package module. */ ! ! /* ...a copy gets saved in the modules dictionary ! under the full name, so get a reference from ! there, if need be. */ ! if (m == NULL) { ! resulting_module = PyDict_GetItemString(modules, ! fullname); ! if (resulting_module == NULL) { ! ! /* ...failed to find the module under its full ! name; oops */ ! PyErr_Format(PyExc_SystemError, ! "Failed to create a sys.modules " \ ! "entry under %.200s", fullname); ! return NULL; ! } ! } else { ! resulting_module = m; ! } ! ! if (PyObject_SetAttrString(mod, subname, resulting_module) < 0) { ! if (m != NULL) { ! Py_DECREF(m); ! m = NULL; ! } ! } } } ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441791&group_id=5470 From noreply@sourceforge.net Mon Jul 16 20:58:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Jul 2001 12:58:57 -0700 Subject: [Patches] [ python-Patches-417872 ] unset PYTHONHOME when running setup.py Message-ID: Patches item #417872, was opened at 2001-04-21 10:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417872&group_id=5470 Category: Build Group: None Status: Closed Resolution: Accepted Priority: 7 Submitted By: Neil Schemenauer (nascheme) Assigned to: A.M. Kuchling (akuchling) Summary: unset PYTHONHOME when running setup.py Initial Comment: This should be applied to the 2.1-maint branch as well. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-07-16 12:58 Message: Logged In: YES user_id=11375 No, I didn't; it should be added to 2.1.1 in that case. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-16 09:11 Message: Logged In: YES user_id=34209 I'm not able to find this actually applied in the 21-maint branch, AMK... are you sure you checked there ? Should I apply it or not ? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-07-16 07:14 Message: Logged In: YES user_id=11375 Applied at some point. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417872&group_id=5470 From noreply@sourceforge.net Tue Jul 17 09:59:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Jul 2001 01:59:14 -0700 Subject: [Patches] [ python-Patches-441793 ] Improvment to package import semantics Message-ID: Patches item #441793, was opened at 2001-07-16 12:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441793&group_id=5470 Category: core (C code) Group: 2.0.1 bugfix >Status: Deleted >Resolution: Duplicate Priority: 5 Submitted By: Alex Coventry (alex_coventry) Assigned to: Nobody/Anonymous (nobody) Summary: Improvment to package import semantics Initial Comment: I think it's nice to be able to do this: >>> import sys >>> sys.path.append('/l/alex_c/') >>> import mouse.foo Traceback (most recent call last): File "", line 1, in ? File "/l/alex_c/mouse/foo.py", line 1, in ? bar NameError: name 'bar' is not defined >>> import mouse.foo >>> reload(mouse.foo) # Works now that foo.py is corrected >>> from mouse import foo >>> foo.bar 1 However, at the moment, that's not possible, because if an error occurs in the loading of foo, foo is not added to mouse's dictionary, even though the module added to sys.modules under the key 'mouse.foo'. This has been driving me nuts, because I have large datasets that I need to load in each time I start python up, so I tend to test my scripts in a single interactive interpreter as I write them, so it's important for me to be able to reliably reload modules. I think it's also a sensible way for things to work in general, too. If there's enough controversy about this, I can write a PEP about it, or something. At any rate, here's a patch against the current CVS repository that changes the semantics as I've described. Alex. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441793&group_id=5470 From noreply@sourceforge.net Tue Jul 17 10:00:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Jul 2001 02:00:11 -0700 Subject: [Patches] [ python-Patches-441791 ] Improvment to package import semantics Message-ID: Patches item #441791, was opened at 2001-07-16 12:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441791&group_id=5470 Category: core (C code) >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Coventry (alex_coventry) Assigned to: Nobody/Anonymous (nobody) Summary: Improvment to package import semantics Initial Comment: I think it's nice to be able to do this: >>> import sys >>> sys.path.append('/l/alex_c/') >>> import mouse.foo Traceback (most recent call last): File "", line 1, in ? File "/l/alex_c/mouse/foo.py", line 1, in ? bar NameError: name 'bar' is not defined >>> import mouse.foo >>> reload(mouse.foo) # Works now that foo.py is corrected >>> from mouse import foo >>> foo.bar 1 However, at the moment, that's not possible, because if an error occurs in the loading of foo, foo is not added to mouse's dictionary, even though the module added to sys.modules under the key 'mouse.foo'. This has been driving me nuts, because I have large datasets that I need to load in each time I start python up, so I tend to test my scripts in a single interactive interpreter as I write them, so it's important for me to be able to reliably reload modules. I think it's also a sensible way for things to work in general, too. If there's enough controversy about this, I can write a PEP about it, or something. At any rate, here's a patch against the current CVS repository that changes the semantics as I've described. Alex. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-07-17 02:00 Message: Logged In: YES user_id=34209 This is not a 2.0.1 bugfix candidate, or any bugfix candidate. Group changed. This is also a subject of occasional discussion on python-dev, see the archives ;P ---------------------------------------------------------------------- Comment By: Alex Coventry (alex_coventry) Date: 2001-07-16 12:42 Message: Logged In: YES user_id=49686 a) Sorry about the duplicate submission b) I attached the patch I'm proposing to it, but can't see it on this page. Here it is, just in case: Index: Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.178 diff -c -r2.178 import.c *** Python/import.c 2001/07/05 03:47:53 2.178 --- Python/import.c 2001/07/16 19:04:05 *************** *** 1789,1795 **** import_submodule(PyObject *mod, char *subname, char *fullname) { PyObject *modules = PyImport_GetModuleDict(); ! PyObject *m; /* Require: if mod == None: subname == fullname --- 1789,1795 ---- import_submodule(PyObject *mod, char *subname, char *fullname) { PyObject *modules = PyImport_GetModuleDict(); ! PyObject *m, *resulting_module=NULL; /* Require: if mod == None: subname == fullname *************** *** 1829,1839 **** m = load_module(fullname, fp, buf, fdp->type); if (fp) fclose(fp); ! if (m != NULL && mod != Py_None) { ! if (PyObject_SetAttrString(mod, subname, m) < 0) { ! Py_DECREF(m); ! m = NULL; ! } } } --- 1829,1864 ---- m = load_module(fullname, fp, buf, fdp->type); if (fp) fclose(fp); ! if (mod != Py_None) { ! ! /* Irrespective of the success of this load, make a ! reference to it in the parent package module. */ ! ! /* ...a copy gets saved in the modules dictionary ! under the full name, so get a reference from ! there, if need be. */ ! if (m == NULL) { ! resulting_module = PyDict_GetItemString(modules, ! fullname); ! if (resulting_module == NULL) { ! ! /* ...failed to find the module under its full ! name; oops */ ! PyErr_Format(PyExc_SystemError, ! "Failed to create a sys.modules " \ ! "entry under %.200s", fullname); ! return NULL; ! } ! } else { ! resulting_module = m; ! } ! ! if (PyObject_SetAttrString(mod, subname, resulting_module) < 0) { ! if (m != NULL) { ! Py_DECREF(m); ! m = NULL; ! } ! } } } ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441791&group_id=5470 From noreply@sourceforge.net Tue Jul 17 18:25:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Jul 2001 10:25:31 -0700 Subject: [Patches] [ python-Patches-429611 ] doc build on win32 with MiKTeX et al. Message-ID: Patches item #429611, was opened at 2001-06-02 08:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429611&group_id=5470 Category: documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: doc build on win32 with MiKTeX et al. Initial Comment: With this patch, everything build fine on win32 but for the following problems: - html/api/labels.pl not generated -> html/api/*.html uncorrect - lib/modindex.html not generated -> html/modindex.html uncorrect Problems worked out: - fancyhdr.sty is not in the Miktex distribution ... - Makefile content made compatible with the Windows command line (now runs fine with VC++'s nmake, or cygnus's make --win32) - misc. problems regarding the path formats - miktex 2.0's pdflatex would block on a mismatching macro level in python.sty -> fixed Hints on installing latex2html: - I had to work out some fixes in the config.pl script (2,000 lines of perl...) - make sure the paths to the ghostscript and miktex installations have no spaces!!!!!! latex2html will silently screw up its configuration process - looking at perl scripts gave me a serious trauma ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-17 10:25 Message: Logged In: YES user_id=3066 I've checked in some of the required changes, but others still need to be considered. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 21:30 Message: Logged In: YES user_id=3066 Assigned to the doc-tsar for review. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429611&group_id=5470 From noreply@sourceforge.net Tue Jul 17 19:15:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Jul 2001 11:15:54 -0700 Subject: [Patches] [ python-Patches-436258 ] Some cleanup of the cPickle module Message-ID: Patches item #436258, was opened at 2001-06-25 20:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=436258&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Minsk (rminsk) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Some cleanup of the cPickle module Initial Comment: While getting rid of compiler warning messages for another non-gcc compiler I found some dead code in cPickle.c. The attached patch fixes some possible type casting problems and removed some dead code. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-17 11:15 Message: Logged In: YES user_id=3066 Looks reasonable. Which compiler reported problems? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=436258&group_id=5470 From noreply@sourceforge.net Tue Jul 17 19:35:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Jul 2001 11:35:28 -0700 Subject: [Patches] [ python-Patches-436258 ] Some cleanup of the cPickle module Message-ID: Patches item #436258, was opened at 2001-06-25 20:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=436258&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Robert Minsk (rminsk) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Some cleanup of the cPickle module Initial Comment: While getting rid of compiler warning messages for another non-gcc compiler I found some dead code in cPickle.c. The attached patch fixes some possible type casting problems and removed some dead code. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-17 11:35 Message: Logged In: YES user_id=3066 Checked in as Modules/cPickle.c revision 2.60. (I'm still curious as to which compiler generated the warnings, though.) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-17 11:15 Message: Logged In: YES user_id=3066 Looks reasonable. Which compiler reported problems? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=436258&group_id=5470 From noreply@sourceforge.net Tue Jul 17 20:06:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Jul 2001 12:06:31 -0700 Subject: [Patches] [ python-Patches-436258 ] Some cleanup of the cPickle module Message-ID: Patches item #436258, was opened at 2001-06-25 20:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=436258&group_id=5470 Category: Modules Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Robert Minsk (rminsk) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Some cleanup of the cPickle module Initial Comment: While getting rid of compiler warning messages for another non-gcc compiler I found some dead code in cPickle.c. The attached patch fixes some possible type casting problems and removed some dead code. ---------------------------------------------------------------------- >Comment By: Robert Minsk (rminsk) Date: 2001-07-17 12:06 Message: Logged In: YES user_id=132786 The SGI 7.3.1.2m with the -fullwarn option turned on. I always compile with fullwarnings and try to get rid of what i can... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-17 11:35 Message: Logged In: YES user_id=3066 Checked in as Modules/cPickle.c revision 2.60. (I'm still curious as to which compiler generated the warnings, though.) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-17 11:15 Message: Logged In: YES user_id=3066 Looks reasonable. Which compiler reported problems? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=436258&group_id=5470 From noreply@sourceforge.net Tue Jul 17 20:12:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Jul 2001 12:12:49 -0700 Subject: [Patches] [ python-Patches-436258 ] Some cleanup of the cPickle module Message-ID: Patches item #436258, was opened at 2001-06-25 20:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=436258&group_id=5470 Category: Modules Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Robert Minsk (rminsk) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Some cleanup of the cPickle module Initial Comment: While getting rid of compiler warning messages for another non-gcc compiler I found some dead code in cPickle.c. The attached patch fixes some possible type casting problems and removed some dead code. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-17 12:12 Message: Logged In: YES user_id=3066 Thanks! Please don't hesitate to report any additional warnings that crop up; I don't expect we'll have access to SGI hardware any time soon. ---------------------------------------------------------------------- Comment By: Robert Minsk (rminsk) Date: 2001-07-17 12:06 Message: Logged In: YES user_id=132786 The SGI 7.3.1.2m with the -fullwarn option turned on. I always compile with fullwarnings and try to get rid of what i can... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-17 11:35 Message: Logged In: YES user_id=3066 Checked in as Modules/cPickle.c revision 2.60. (I'm still curious as to which compiler generated the warnings, though.) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-17 11:15 Message: Logged In: YES user_id=3066 Looks reasonable. Which compiler reported problems? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=436258&group_id=5470 From noreply@sourceforge.net Tue Jul 17 20:22:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Jul 2001 12:22:51 -0700 Subject: [Patches] [ python-Patches-442128 ] Creates zipfiles that java can read Message-ID: Patches item #442128, was opened at 2001-07-17 12:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442128&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Nobody/Anonymous (nobody) Summary: Creates zipfiles that java can read Initial Comment: Zip files create by zipfile.py cannot be read with java's zipfile support because the CRC/sizes when written after the file is not marked with a EXT header. With this patch java can reads zipfiles with entries added with writestr() and deflated files added with write(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442128&group_id=5470 From noreply@sourceforge.net Tue Jul 17 20:48:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Jul 2001 12:48:02 -0700 Subject: [Patches] [ python-Patches-436193 ] SGI cores on 1.0 / 0 Message-ID: Patches item #436193, was opened at 2001-06-25 13:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=436193&group_id=5470 >Category: core (C code) Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Robert Minsk (rminsk) >Assigned to: Tim Peters (tim_one) Summary: SGI cores on 1.0 / 0 Initial Comment: This fix is in reference to bug 435026. Please see bug for complete history. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-17 12:48 Message: Logged In: YES user_id=31435 Sorry for the delay! I discussed it with Guido, and we don't want to do this. The problem is that platform- specific #ifdef hacks don't go away again, and that makes the codebase ever more incomprehensible over time. Python used to do a lot of this, but not any more. It's especially unattractive for SGI boxes, because there are always a variety of -O bugs there. Note that the main README file has long said: """ WARNING: There are bugs in the optimizer of some versions of SGI's compilers that can cause bus errors or other strange behavior, especially on numerical operations. To avoid this, try building with "make OPT=". """ If you want to volunteer to maintain a separate collection of SGI patches for assorted SGI compilers, that would be cool, and I'd be happy to plant a line to that in the README; but we're not putting any broken-compiler #ifdef workarounds into the core. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=436193&group_id=5470 From noreply@sourceforge.net Tue Jul 17 21:00:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Jul 2001 13:00:49 -0700 Subject: [Patches] [ python-Patches-435492 ] tempnam(),tmpfile(),tmpnam() for Windows Message-ID: Patches item #435492, was opened at 2001-06-22 08:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=435492&group_id=5470 Category: Windows Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: tempnam(),tmpfile(),tmpnam() for Windows Initial Comment: This patch makes os.tempnam(), os.tmpfile(), and os.tmpnam() available on Windows. (And yes, I tested that the Windows version still compiles!) A user noted that the documentation did not indicate constrained availability, but these functions were not available -- appearantly he was on running Windows or MacOS. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-17 13:00 Message: Logged In: YES user_id=31435 Accepted and back to Fred, with the caution that I have no idea whether these functions work "as expected" on Windows, and that Fred noted by voice that we really have no tests for posixmodule functions. The patch looks fine, though. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=435492&group_id=5470 From noreply@sourceforge.net Tue Jul 17 21:41:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Jul 2001 13:41:40 -0700 Subject: [Patches] [ python-Patches-435492 ] tempnam(),tmpfile(),tmpnam() for Windows Message-ID: Patches item #435492, was opened at 2001-06-22 08:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=435492&group_id=5470 Category: Windows Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: tempnam(),tmpfile(),tmpnam() for Windows Initial Comment: This patch makes os.tempnam(), os.tmpfile(), and os.tmpnam() available on Windows. (And yes, I tested that the Windows version still compiles!) A user noted that the documentation did not indicate constrained availability, but these functions were not available -- appearantly he was on running Windows or MacOS. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-17 13:41 Message: Logged In: YES user_id=3066 Checked in as PC/config.h revision 1.56 and Modules/posixmodule.c revision 2.193. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-17 13:00 Message: Logged In: YES user_id=31435 Accepted and back to Fred, with the caution that I have no idea whether these functions work "as expected" on Windows, and that Fred noted by voice that we really have no tests for posixmodule functions. The patch looks fine, though. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=435492&group_id=5470 From noreply@sourceforge.net Wed Jul 18 08:58:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 00:58:25 -0700 Subject: [Patches] [ python-Patches-441528 ] MSVC Preprocessor Message-ID: Patches item #441528, was opened at 2001-07-15 15:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441528&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tarn Weisner Burton (twburton) Assigned to: Thomas Heller (theller) Summary: MSVC Preprocessor Initial Comment: The attached script has a preprocessor method for the MSVC compiler. Tarn twburton@users.sf.net ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2001-07-18 00:58 Message: Logged In: YES user_id=11105 Tarn, can you supply an example where this code would be executed? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-07-16 06:40 Message: Logged In: YES user_id=11375 Reassigning to Thomas, since I can't test anything with MSVC. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-16 06:23 Message: Logged In: YES user_id=6380 Or should this go to Thomas Heller? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441528&group_id=5470 From noreply@sourceforge.net Wed Jul 18 11:23:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 03:23:23 -0700 Subject: [Patches] [ python-Patches-442351 ] Copy of classes with __del_ in jython Message-ID: Patches item #442351, was opened at 2001-07-18 03:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442351&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Nobody/Anonymous (nobody) Summary: Copy of classes with __del_ in jython Initial Comment: The __del__ method is somewhat special in jython because it must exists when the instance is created. Adding a __del__ method to an existing instance have no effect in jython. This patch will ensure that the new copy will be created with a __del__ method if the source defined a __del__ method. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442351&group_id=5470 From noreply@sourceforge.net Wed Jul 18 16:31:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 08:31:54 -0700 Subject: [Patches] [ python-Patches-432117 ] Updated PullDOM patch Message-ID: Patches item #432117, was opened at 2001-06-11 08:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=432117&group_id=5470 Category: XML Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Martin v. Löwis (loewis) Summary: Updated PullDOM patch Initial Comment: Martin, here is an updated patch (see # 423394) for pulldom.py that follows the DOM REC regarding namespace declaration attribute handling. In short: namespace declaration attributes are now preserved, and the namespaceURI of a namespace decl attribute is "http://www.w3.org/2000/xmlns/". The localName is the prefix to be mapped, unless it is a plain "xmlns" (default ns declaration), in which case the localName is just "xmlns". I've tested this with a Python 2.1 (final release) install. Let me know if you need anything else. Thanks! B. Lloyd ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-18 08:31 Message: Logged In: YES user_id=21627 Committed as pulldom.py 1.22 (1.15 in PyXML). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=432117&group_id=5470 From noreply@sourceforge.net Wed Jul 18 17:03:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 09:03:32 -0700 Subject: [Patches] [ python-Patches-401196 ] IPv6 patch against 2.0 CVS tree, as of 20010624 Message-ID: Patches item #401196, was opened at 2000-08-16 05:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401196&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jun-ichiro itojun Hagino (itojun) >Assigned to: Martin v. Löwis (loewis) Summary: IPv6 patch against 2.0 CVS tree, as of 20010624 Initial Comment: ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-24 14:59 Message: Logged In: YES user_id=21627 I have uploaded a new version sent by itojun. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-09 12:15 Message: Logged In: YES user_id=21627 On the API, I have the following comments: - Why is it necessary to introduce gethostbyname2? I recommend to give gethostbyname an optional argument for the address family. - getaddrinfo, when raising a socket error, should include the EAI_ error number. Perhaps there should be a way tod istinguish EAI_ errnos from other errnos, e.g. by subclassing socket error. Otherwise, the API of the C part looks good to me. Ih aven't looked at the Lib part, yet. On the implementation: - I still have problems building the code. Currently, I get the following rejects: ./Lib/BaseHTTPServer.py.rej ./Lib/ftplib.py.rej ./Lib/poplib.py.rej ./Lib/smtplib.py.rej ./Modules/socketmodule.c.rej ./Objects/fileobject.c.rej - The fileobject.c chunk seems to be unnecessary. - On the test problem: It occurs in + test -d -a -f /lib.a ./configure: test: too many arguments which comes from ipv6libdir and ipv6libdir being empty. - The WIDE files should be included in the Modules directory, as they are only used from socketmodule.c. In particular, addrinfo.h should not be installed. - If you can, please include a patch to Doc/lib/libsocket.tex. If not, I will try to draft one. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-05-30 10:34 Message: Logged In: NO i looked at python-dev email. the proposal (split patches) looks fine, but the exact example given in python-dev email is not reasonable. i cannot just send out configure.in change separately from source code changes, period. i can split patches for *.py files separately though. there's more important issue, which is, APi changes for Socket class. i really hoped to get some comment on that part. i really appreciate your comments. i would like to propose that once we nailed down API changes, integrate the patch into the tree. with all #ifdef INET6 in place there should be no impact on IPv4-only builds. i have trouble tracking python development (i'm not a sourceforge expert!), so forgive me for delays in patch submissions. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-05-18 08:29 Message: Logged In: YES user_id=6380 See http://mail.python.org/pipermail/python-dev/2001-May/014889.html for comments from MvL. I'm unassigning this from Fred, he has nothing to do with this. ---------------------------------------------------------------------- Comment By: Jun-ichiro itojun Hagino (itojun) Date: 2001-02-26 02:24 Message: Logged In: YES user_id=63767 about /usr/bin/test argument: does linux /usr/bin/test have -d support? if not, we may need to change configure.in slightly. you are correct that fallback getaddrinfo/getnameinfo.c was missing in the patch. sorry. a question i need to ask is, do we need to supply Python function Socket.getaddrinfo on platforms that do not have getaddrinfo(3)? HAVE_ADDRINFO is used in Include/addrinfo.h, which is also missing in the patch set i have submitted. i've put the missing files into http://www.itojun.org/diary/20001230/missing.shar. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-02-23 23:58 Message: After a shallow review of this patch, I found the following issues: configure.in does not need to list both enable and disable options. When running configure, I got the following error message on Linux checking whether to enable ipv6... yes checking ipv6 stack type... linux-glibc ./configure: test: too many arguments using libc The call to /usr/bin/test should be corrected; I could not find out which specific invocation caused the problem. HAVE_ADDRINFO is not used. Perhaps getaddrinfo.c/getnameinfo.c is missing in the patch? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-04 07:51 Message: A new patch is available. I've changed the subject accordingly. Due to upload size restrictions, the patch is now at http://www.itojun.org/diary/20001230/python-2.0-v6-20001230.diff.gz ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2000-12-30 07:25 Message: I got *many* rejects when trying to apply this patch to today's CVS tree. I recommend that patches for generated files (config.h.in, configure) are not included in the patch because they outdate too easily. A number of changes in this patch have already been done by somebody else; others just don't fit into the current code anymore (perhaps due to indentation changes?). Anyway, I'll mark the patch as out-of-date. Please let me know when you upload a new version. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-08-16 07:00 Message: Postponed until Python 2.1 -- there's not enough time to review this and get it sufficiently tested on enough IPv6-connected platforms in time for 2.0, and we're already in feature freeze. This should go into the tree very quickly once Python 2.0 has been released. Assigned to myself to open it back up after Python 2.0. ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2000-08-16 06:07 Message: Assigned to Tim, since he's in charge of postponing new features. I'm to timid to postpone it myself. ---------------------------------------------------------------------- Comment By: Jun-ichiro itojun Hagino (itojun) Date: 2000-08-16 05:59 Message: this is revised version of patch #101186 (now with my SourceForge accout... i'm not familiar with the system here, so forgive my possible mistake). 1.6b1 patch applied mostly clean to 2.0. It is confirmed that: - 1.6b1 + IPv6 patch works fine on NetBSD 1.4.2 + KAME, and NetBSD 1.5 - 1.6b1 + IPv6 patch works fine on NetBSD 1.4.2 (NOT an IPv6 ready machine) - 2.0 CVS tree + IPv6 patch works fine on NetBSD + KAME forgot to attach the following into the diff - so i attach it (README.v6) here as comment. I have submitted the patch for 1.5.1, 1.5.2 and 1.6b1, all hit a bad timing - bad luck. contact: core@kame.net, or itojun@kame.net --- IPv6-ready python 1.6 KAME Project $KAME: README.v6,v 1.9 2000/08/15 02:40:38 itojun Exp $ This patchkit enables python 1.6 to perform AF_INET6 socket operations. The only affected module is Modules/socketmodule.c. Modules/socketmodule.c In most cases, IPv6 address can be placed where IPv4 address fits. sockaddr sockaddr tuple is formatted as follows: IPv4: (host, port) IPv6: socket class methods always generate (host, port, flowinfo, scopeid). socket class methods will accept 2, 3, or 4 tuple (for backward compatibility). Compatibility warning: Some of the scripts assume that the sockaddr structure is 2 tuple, like: host, port = sock.getpeername() this will fail if you are connected to IPv6 node. socket.getaddrinfo(host, port [, family, socktype, proto, flags]) host: String or None port: String, Int or None family, socktype, proto, flags: Int, can be omitted Perform getaddrinfo(3). Returns List of the following 5 tuple: (family, socktype, proto, canonname, sockaddr) family: Int socktype: Int proto: Int canonname: String sockaddr: sockaddr (see above) See Lib/httplib.py for typical usage on the client side. socket.getnameinfo(sockaddr, flags) sockaddr: sockaddr flags: Int Perform getnameinfo(3). Returns the following 2 tuple: host: String, numeric or hostname depending on flgags port: String, numeric or portname depending on flgags socket.gethostbyname2(host, af) host: String af: Int Performs gethostbyname2(3). Returns numeric address representation for "host". socket.gethostbyaddr(addr) (behavior change if IPv6 support is compiled in) addr: String Performs gethostbyaddr(3). Returns string address representation for "addr". The function can take IPv6 numeric address as well. This behavior is not problematical, because - if you pass numeric "addr" parameter, we can always identify address family for it - return value is string address reprsentation, where IPv6 and IPv4 are not distinguishable. socket.bind(sa), socket.connect(sa) and others. (No behavior change, but be careful) See above for sockaddr format change. With Python "addr" portion of sockaddr (first element) can be string hostname. When the string hostname resolved to numeric address, it will obey address family of the socket (which was specified when socket.socket() was called). If you give some string that does not give matching address family, you will get some error. s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) # this is okay, if 'localhost' resolves to both IPv4/v6 s.connect('localhost', 80) # this is not okay, of course s.connect('::1', 80) # this is not okay, as v6only.kame.net will not resolve to IPv4 s.connect('v6only.kame.net', 80) Lib/httplib.py IPv6 ready. "host" in HTTP(host) will accept the following 3 forms: [host]:port host:port there must be only single colon host This is to allow IPv6 numeric URL (http://[host]:port/) in documents. IMHO "host:port" parsing should be implemented in urllib.py, not here. Lib/ftplib.py IPv6 ready. This uses EPSV/EPRT on IPv6 ftp. See RFC2428 for protocol details. Lib/SocketServer.py IPv6 ready. Wildcard bind on TCPServer, i.e. TCPServer(('', port)), will bind to wildcard socket on TCPServer.address_family. TCPServer.addresss_family is set to AF_INET by default, so ('', port) will usually bind AF_INET. Lib/smtplib.py, Lib/telnetlib.py, Lib/poplib.py IPv6 ready. Not much to say about protocol details - they just use TCP over IPv6. configure Configure has extra option, --enable-ipv6 and --disable-ipv6. The option controls IPv6 support feature. dynamic link issues in Modules/socketmodule.c Modules/socketmodule.c can be dynamically loaded only in the following situations: - getaddrinfo(3) and getnameinfo(3) are supplied by OS vendor in libc, and libc is dynamic link library. - OS vendor is NOT supplying getaddrinfo(3) nor getnameinfo(3), and You are configuring this package with --disable-ipv6. In this case, you'll be using missing/get{addr,name}info.c and they will refer to gethostby{name,addr}. gethostnameby{name,addr} can usually be found in dynamic-linking libc. In other situations, such as the following, please link Modules/socketmodule.c into python itself. - getaddrinfo(3) and getnameinfo(3) are supplied by OS vendor, but they are in statically linked library like libinet6.a. (KAME falls into this category) python usually links Modules/socketmodule.c into python itself (due to its popularity) so there should be no problem. restrictions - The patched tree will not use gethostbyname_r and other thread-ready libraries. Instead, it will use getaddrinfo() and getnameinfo() throughout the operation. todo - Patch bunch of library files in Lib/*.py. compatibility issues with existing scripts If you disable IPv6 support (./configure --disable-ipv6), the patched code is mostly compatible with original Python (except files in "Lib" directory modified for dual stack support). User script may choke if: - IPv4/v6 dualstack libc is supplied, python is compiled for dual stack, and script assumes some of IPv4-only behavior (especially sockaddr) - IPv4/v6 dualstack libc is supplied, python is compiled for IPv4 only, and script assumes some of IPv4-only behavior. In this case, Python socket class itself does not support IPv6, however, name resolution functions can return IPv6 names since they use IPv6-ready libc functions! I do not recommend this configuration. - script assumes certain IPv4-only version behavior in Lib/*.py. compilation If you use IPv6 features, it is assumed that you have working getaddrinfo() and getnameinfo() library functions. We have noticed that some of IPv6 stack is shipped with broken getaddrinfo(). In such cases, use missing/get{addr,name}info.c instead (but then, you need to have working getipnodeby{name,addr}). If you compile this on IPv4-only machine without get{addr,name}info, missing/get{addr,name}info.c will be used. They are from KAME IPv6 distribution and is #ifdef'ed for IPv4 only support. They are fairly complete implementation and you don't need to bother with bind 8.2 (bind 8.2 get{addr,name}info() has bugs). When compiling this kit on IPv6 node, you may need to specify some additional library paths or cpp defs. (like -linet6 or -DINET6) --enable-ipv6 will give you some warning, if the IPv6 stack is unknown to the "configure" script. Currently, the following IPv6 stacks are officially supported (i.e. we've checked that the package works well): - KAME IPv6 stack, http://www.kame.net/ References RFC2553, for getaddrinfo(3) and getnameinfo(3). Author contacts http://www.kame.net/ mailto:core@kame.net ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401196&group_id=5470 From noreply@sourceforge.net Wed Jul 18 17:19:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 09:19:16 -0700 Subject: [Patches] [ python-Patches-412229 ] runtime RTLD_NOW control via sys Message-ID: Patches item #412229, was opened at 2001-03-29 08:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=412229&group_id=5470 Category: core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Bram Stolk (bram) Assigned to: Martin v. Löwis (loewis) Summary: runtime RTLD_NOW control via sys Initial Comment: This patch enables runtime control over the RTLD_NOW flag, which can be used to do lazy symbol resolving when loading a shared lib. It's an extention to the sys module: sys.setlazysymresolve(0|1) The patch is against the latest CVS code, and was generated by 'cvs diff'. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-18 09:19 Message: Logged In: YES user_id=21627 Committed as libsys.tex 1.47, pystate.h 2.17, NEWS 1.192, dynload_shlib.c 2.9, pystate.c 2.19, sysmodule.c 2.89. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-07 07:34 Message: Logged In: YES user_id=21627 The patch looks good to me now, so I recommend accepting it - except for the part that activates dlmodule by default. As for getting at the RTLD flags, I see three options: 1. setup.py could be changed to build dl wherever possible. 2. Administrators should activate dlmodule if they trust it. 3. Application authors somehow need to find out the values of RTLD_ on their system, e.g. by per-system hard-coded values, or by running h2py on dlfcn.h; that could be part of the Python distribution for systems known to support dlfcn.h. 3. the RTLD_ flags are exported from some other module as well; imp comes to mind. Actually, putting setdlopenflags into imp instead of sys might be worth a consideration. ---------------------------------------------------------------------- Comment By: Bram Stolk (bram) Date: 2001-06-07 03:52 Message: Logged In: YES user_id=14028 Ok, I've revised the patch as you suggested. Currently, you can get and set the flags just as you specified. Also, it should also build on platforms without RTLD_NOW, and even on platforms without LDOPEN altogether. However, I see one problem with this: After Python 1.5.2, the dl module seems to be removed from the default installation. This means that dl.RTLD_NOW and dl.RTLD_LAZY are not readilly available on a standard Python install. This is akward. The patch was generated with the command: cvs diff -c against the cvs tree of Thu Jun 7 12:44:18 MDT 2001 Bram ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-05 23:39 Message: Logged In: YES user_id=21627 The patch needs further work: The code currently compiles on systems which don't define RTLD_NOW (although I'm not sure what these systems are); your code doesn't. Also, the code allows to set the flags, but has no interface to query them. Finally, users often complain that Python should use RTLD_GLOBAL, so that they can share symbols across extension modules. Therefore, I propose that you allow setting arbitrary dlopen flags; users would have to write sys.setdlopenflags(0) to turn off RTLD_NOW, and use sys.setdlopenflags(dl.RTLD_NOW|dl.RTLD_GLOBAL) to add RTLD_GLOBAL. When you revise this patch, please submit unified (-u) or context (-c) diffs. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:48 Message: Logged In: YES user_id=6380 Sorry, no new features in 2.1. I'll look at this after 2.1 is released though. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=412229&group_id=5470 From noreply@sourceforge.net Wed Jul 18 19:24:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 11:24:39 -0700 Subject: [Patches] [ python-Patches-442512 ] SRE BIGCHARSET endianness fix Message-ID: Patches item #442512, was opened at 2001-07-18 11:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442512&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Fredrik Lundh (effbot) Summary: SRE BIGCHARSET endianness fix Initial Comment: The current sre_compile works only on little-endian machines for BIGCHARSET operations; the problem is that _sre.c addresses the block indices as a byte array, whereas sre_compile builds it as a short integer array. This patch fixes the problem reported in http://mail.python.org/pipermail/python-dev/2001-July/015947.html for SPARC Solaris. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442512&group_id=5470 From noreply@sourceforge.net Wed Jul 18 19:50:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 11:50:01 -0700 Subject: [Patches] [ python-Patches-423139 ] webbrowser.py fix for konqueror Message-ID: Patches item #423139, was opened at 2001-05-10 12:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423139&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joseph VanAndel (vanandel) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: webbrowser.py fix for konqueror Initial Comment: The 2.1 version of webbrowser.py uses kfmclient, and opens a new Konqueror window for each 'open' call. This patched version of webbrowser.py uses the KDE command line utility 'dcop' to either open a URL in an existing Konqueror window, or to open a new window. pydoc is much more useful with this version of webbrowser.py ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 11:50 Message: Logged In: YES user_id=3066 Err, the patch isn't here. Could you please try to attach the patch to this request, or at least point me to some reasonable documentation for the dcop program and Konqueror's control interface? Mandrake 7.2 does not include a man page for dcop, and "dcop --help" isn't very helpful. I would like to improve the Konqueror support. Thanks! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:31 Message: Logged In: YES user_id=3066 Assigned to me since webbrowser.py is my fault. ;-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423139&group_id=5470 From noreply@sourceforge.net Wed Jul 18 19:51:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 11:51:03 -0700 Subject: [Patches] [ python-Patches-423139 ] webbrowser.py fix for konqueror Message-ID: Patches item #423139, was opened at 2001-05-10 12:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423139&group_id=5470 Category: library Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: Joseph VanAndel (vanandel) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: webbrowser.py fix for konqueror Initial Comment: The 2.1 version of webbrowser.py uses kfmclient, and opens a new Konqueror window for each 'open' call. This patched version of webbrowser.py uses the KDE command line utility 'dcop' to either open a URL in an existing Konqueror window, or to open a new window. pydoc is much more useful with this version of webbrowser.py ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 11:51 Message: Logged In: YES user_id=3066 (Changed status to "Pending..." - it's supposed to re-open once a response is received.) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 11:50 Message: Logged In: YES user_id=3066 Err, the patch isn't here. Could you please try to attach the patch to this request, or at least point me to some reasonable documentation for the dcop program and Konqueror's control interface? Mandrake 7.2 does not include a man page for dcop, and "dcop --help" isn't very helpful. I would like to improve the Konqueror support. Thanks! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:31 Message: Logged In: YES user_id=3066 Assigned to me since webbrowser.py is my fault. ;-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423139&group_id=5470 From noreply@sourceforge.net Wed Jul 18 19:51:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 11:51:05 -0700 Subject: [Patches] [ python-Patches-442530 ] Distutils config buggy Message-ID: Patches item #442530, was opened at 2001-07-18 11:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442530&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tarn Weisner Burton (twburton) Assigned to: Nobody/Anonymous (nobody) Summary: Distutils config buggy Initial Comment: The config command of distutils has some types in it First every time the _preprocess or _compile method is called the include_dirs argument is omitted. Second the search_cpp method tries to do a re search with the line: if pattern.search(pattern): which should be if pattern.search(line): I've attached a complete corrected version from CVS. Tarn ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442530&group_id=5470 From noreply@sourceforge.net Wed Jul 18 19:53:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 11:53:58 -0700 Subject: [Patches] [ python-Patches-429136 ] BROWSER fix for webbrowser.py Message-ID: Patches item #429136, was opened at 2001-05-31 13:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429136&group_id=5470 Category: library Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Skip Montanaro (montanaro) Summary: BROWSER fix for webbrowser.py Initial Comment: webbrowser.py currently assumes the BROWSER environment variable was set by the user who will take care of registering that browser. In the case of Gnome+Mandrake 8.0 (at least), this is not the case. The attached patch attempts to register any browsers found in BROWSER that aren't in the _browser dict already. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 11:53 Message: Logged In: YES user_id=3066 Accepted; please check this in. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:25 Message: Logged In: YES user_id=3066 Assigned to me, since the webbrowser module is largely my fault, and the initialization has become more complex than it needs to be anyway. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429136&group_id=5470 From noreply@sourceforge.net Wed Jul 18 19:59:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 11:59:11 -0700 Subject: [Patches] [ python-Patches-441528 ] MSVC Preprocessor Message-ID: Patches item #441528, was opened at 2001-07-15 15:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441528&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tarn Weisner Burton (twburton) Assigned to: Thomas Heller (theller) Summary: MSVC Preprocessor Initial Comment: The attached script has a preprocessor method for the MSVC compiler. Tarn twburton@users.sf.net ---------------------------------------------------------------------- >Comment By: Tarn Weisner Burton (twburton) Date: 2001-07-18 11:59 Message: Logged In: YES user_id=21784 Added test script config.py To run: "python config.py config" Also added msvccompiler.py which fixes a bug from my first post of pp.py, and is a modification of the current CVS version. Tarn ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-07-18 00:58 Message: Logged In: YES user_id=11105 Tarn, can you supply an example where this code would be executed? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-07-16 06:40 Message: Logged In: YES user_id=11375 Reassigning to Thomas, since I can't test anything with MSVC. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-16 06:23 Message: Logged In: YES user_id=6380 Or should this go to Thomas Heller? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441528&group_id=5470 From noreply@sourceforge.net Wed Jul 18 20:22:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 12:22:26 -0700 Subject: [Patches] [ python-Patches-403948 ] uninstaller for bdist_wininst Message-ID: Patches item #403948, was opened at 2001-02-22 08:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403948&group_id=5470 Category: distutils Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: uninstaller for bdist_wininst Initial Comment: Uninstaller for bdist_wininst. Has been described fairly extensively in http://mail.python.org/pipermail/distutils-sig/2001-February/001991.html. This version differs from the posted beta-version in better error checking. The patch is not complete: distutils/command/bdist_wininst.py has to be regenerated after the C-code has been compiled. I'm requesting permission to check this in. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-02-28 12:37 Message: Logged In: YES user_id=11105 Assigned back to myself for further work :-) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-02-28 12:27 Message: Logged In: YES user_id=11375 Sure. There's also probably going to be a beta2, so it could be checked in for that release. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-02-28 12:17 Message: Logged In: YES user_id=11105 Andrew, I'm undecided what to do. I have some improvements to the uninstaller in mind, which should be done before. I have, however, not the time to do it this week. Can we release a separate distutils version AFTER 2.1 beta 1? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-02-27 11:01 Message: Logged In: YES user_id=11375 You have permission from me, though I can't really comment on the approach. No one else on python-dev seemed interested in inspecting it, and you're the Windows/Distutils installer expert, so go ahead. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-02-22 08:28 Message: Uninstaller for bdist_wininst. Has been described detailed in http://mail.python.org/pipermail/distutils-sig/2001-February/001991.html. This version differs from the posted beta-version in better error checking. The patch is not complete: distutils/command/bdist_wininst.py has to be regenerated after the C-code has been compiled. I'm requesting permission to check this in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403948&group_id=5470 From noreply@sourceforge.net Wed Jul 18 20:23:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 12:23:28 -0700 Subject: [Patches] [ python-Patches-410890 ] Example of Python startup script Message-ID: Patches item #410890, was opened at 2001-03-23 10:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410890&group_id=5470 Category: demos and tools Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Itamar Shtull-Trauring (itamar) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Example of Python startup script Initial Comment: Python has the ability to run a script at startup. However, this feature has no examples and I'm not sure how many people use it. I've written this script that (using readline): 1) Turns on auto-complete 2) Makes the command history saved between sessions 3) Is a good example of a startup script I think this should be in the examples or tools, so that Python packagers can integrate this on platforms where readline is available. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 12:23 Message: Logged In: YES user_id=3066 Checked in with a little bit of explanatory text as part of Doc/tut/tut.tex revisions 1.145 and 1.133.2.5. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410890&group_id=5470 From noreply@sourceforge.net Wed Jul 18 21:04:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 13:04:51 -0700 Subject: [Patches] [ python-Patches-429136 ] BROWSER fix for webbrowser.py Message-ID: Patches item #429136, was opened at 2001-05-31 13:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429136&group_id=5470 Category: library Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: BROWSER fix for webbrowser.py Initial Comment: webbrowser.py currently assumes the BROWSER environment variable was set by the user who will take care of registering that browser. In the case of Gnome+Mandrake 8.0 (at least), this is not the case. The attached patch attempts to register any browsers found in BROWSER that aren't in the _browser dict already. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2001-07-18 13:04 Message: Logged In: YES user_id=44345 checked in this change as v 1.19 of webbrowser.py ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 11:53 Message: Logged In: YES user_id=3066 Accepted; please check this in. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:25 Message: Logged In: YES user_id=3066 Assigned to me, since the webbrowser module is largely my fault, and the initialization has become more complex than it needs to be anyway. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429136&group_id=5470 From noreply@sourceforge.net Wed Jul 18 21:08:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 13:08:26 -0700 Subject: [Patches] [ python-Patches-429136 ] BROWSER fix for webbrowser.py Message-ID: Patches item #429136, was opened at 2001-05-31 13:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429136&group_id=5470 Category: library Group: None >Status: Open Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Thomas Wouters (twouters) Summary: BROWSER fix for webbrowser.py Initial Comment: webbrowser.py currently assumes the BROWSER environment variable was set by the user who will take care of registering that browser. In the case of Gnome+Mandrake 8.0 (at least), this is not the case. The attached patch attempts to register any browsers found in BROWSER that aren't in the _browser dict already. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 13:08 Message: Logged In: YES user_id=3066 Hmm... should this be part of the 2.1.1 release as well? It's not clear to me whether this is strictly a bugfix. Re-opening and assigning to Thomas for a ruling. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-07-18 13:04 Message: Logged In: YES user_id=44345 checked in this change as v 1.19 of webbrowser.py ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 11:53 Message: Logged In: YES user_id=3066 Accepted; please check this in. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:25 Message: Logged In: YES user_id=3066 Assigned to me, since the webbrowser module is largely my fault, and the initialization has become more complex than it needs to be anyway. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429136&group_id=5470 From noreply@sourceforge.net Wed Jul 18 22:39:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 14:39:42 -0700 Subject: [Patches] [ python-Patches-429136 ] BROWSER fix for webbrowser.py Message-ID: Patches item #429136, was opened at 2001-05-31 13:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429136&group_id=5470 Category: library Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Thomas Wouters (twouters) Summary: BROWSER fix for webbrowser.py Initial Comment: webbrowser.py currently assumes the BROWSER environment variable was set by the user who will take care of registering that browser. In the case of Gnome+Mandrake 8.0 (at least), this is not the case. The attached patch attempts to register any browsers found in BROWSER that aren't in the _browser dict already. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2001-07-18 14:39 Message: Logged In: YES user_id=44345 I think it should be. Without it, on systems running Gnome, the webbrowser module doesn't work. In particular, note that the 2.1 version of webbrowser.py made the (incorrect) assumption that the user would be the only person setting the BROWSER environment variable. If you eliminate that assumption, you have to assume that the user may not have registered all the browsers mentioned in BROWSER. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 13:08 Message: Logged In: YES user_id=3066 Hmm... should this be part of the 2.1.1 release as well? It's not clear to me whether this is strictly a bugfix. Re-opening and assigning to Thomas for a ruling. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-07-18 13:04 Message: Logged In: YES user_id=44345 checked in this change as v 1.19 of webbrowser.py ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 11:53 Message: Logged In: YES user_id=3066 Accepted; please check this in. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:25 Message: Logged In: YES user_id=3066 Assigned to me, since the webbrowser module is largely my fault, and the initialization has become more complex than it needs to be anyway. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429136&group_id=5470 From noreply@sourceforge.net Wed Jul 18 22:42:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 14:42:36 -0700 Subject: [Patches] [ python-Patches-429136 ] BROWSER fix for webbrowser.py Message-ID: Patches item #429136, was opened at 2001-05-31 13:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429136&group_id=5470 Category: library Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Skip Montanaro (montanaro) Summary: BROWSER fix for webbrowser.py Initial Comment: webbrowser.py currently assumes the BROWSER environment variable was set by the user who will take care of registering that browser. In the case of Gnome+Mandrake 8.0 (at least), this is not the case. The attached patch attempts to register any browsers found in BROWSER that aren't in the _browser dict already. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 14:42 Message: Logged In: YES user_id=3066 Assigning back to Skip for checkin on the release21-maint branch. Please checkin and close. Thanks! ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-07-18 14:39 Message: Logged In: YES user_id=44345 I think it should be. Without it, on systems running Gnome, the webbrowser module doesn't work. In particular, note that the 2.1 version of webbrowser.py made the (incorrect) assumption that the user would be the only person setting the BROWSER environment variable. If you eliminate that assumption, you have to assume that the user may not have registered all the browsers mentioned in BROWSER. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 13:08 Message: Logged In: YES user_id=3066 Hmm... should this be part of the 2.1.1 release as well? It's not clear to me whether this is strictly a bugfix. Re-opening and assigning to Thomas for a ruling. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-07-18 13:04 Message: Logged In: YES user_id=44345 checked in this change as v 1.19 of webbrowser.py ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 11:53 Message: Logged In: YES user_id=3066 Accepted; please check this in. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:25 Message: Logged In: YES user_id=3066 Assigned to me, since the webbrowser module is largely my fault, and the initialization has become more complex than it needs to be anyway. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429136&group_id=5470 From noreply@sourceforge.net Wed Jul 18 22:44:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 14:44:04 -0700 Subject: [Patches] [ python-Patches-428320 ] rich comparisons as operator.__lt__ etc. Message-ID: Patches item #428320, was opened at 2001-05-29 07:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428320&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: rich comparisons as operator.__lt__ etc. Initial Comment: Rich Comparisons (PEP 207) introduce new special names in classes (__lt__, __le__, __eq__, etc.). They should be available in the 'operator' module just like the other special names (__add__ and the like). This patch introduce 12 new names in 'operator': lt, le, eq, ne, gt, ge, __lt__, __le__, __eq__, __ne__, __gt__, __ge__. The first 6 are provided for uniformity with the rest of the module but I am not sure whether it is a good idea to clutter a namespace with names only two letters long; for example, could names like 'eq' accidentally break existing programs using from operator import * ? ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 14:44 Message: Logged In: YES user_id=3066 Have sent an email to the submitter regarding this; awaiting response. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:53 Message: Logged In: YES user_id=3066 I'd prefer to see the names that don't have underscores be lessthan, lessthanequal, equal, notequal, greaterthan, greaterthanequal. Not sure what others think. I doubt the issue is "from operator import *" -- no one should be doing that anyway. Also, the documentation fragment uses "informations" (note the 's') instead of "information". ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2001-05-29 08:01 Message: Logged In: YES user_id=4771 Sorry, I forgot to login when I posted the patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428320&group_id=5470 From noreply@sourceforge.net Wed Jul 18 22:48:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 14:48:57 -0700 Subject: [Patches] [ python-Patches-441691 ] BCPP Preprocessor Message-ID: Patches item #441691, was opened at 2001-07-16 07:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441691&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tarn Weisner Burton (twburton) >Assigned to: Greg Ward (gward) Summary: BCPP Preprocessor Initial Comment: Preprocessor method for bcppcompiler. The only missing functionality is the ability to send the output to stdout. cpp32 can't seem to do this. This doesn't really seem needed anyways. Tarn ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441691&group_id=5470 From noreply@sourceforge.net Wed Jul 18 22:49:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 14:49:30 -0700 Subject: [Patches] [ python-Patches-441350 ] Disutils config try_run broken Message-ID: Patches item #441350, was opened at 2001-07-14 15:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441350&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tarn Weisner Burton (twburton) >Assigned to: Greg Ward (gward) Summary: Disutils config try_run broken Initial Comment: The distutils.command.config try_run method is broken. First it doesn't save the name of the compiled prog, then it tries to execute the non-existent symbol "exe" Here is what it does now: --------- try: self._link(body, headers, include_dirs, libraries, library_dirs, lang) self.spawn([exe]) ok = 1 except (CompileError, LinkError, DistutilsExecError): ok = 0 --------- This will fix it: --------- try: src, obj, prog = self._link(body, headers, include_dirs, libraries, library_dirs, lang) self.spawn([prog]) ok = 1 except (CompileError, LinkError, DistutilsExecError): ok = 0 ---------- Tarn twburton@users.sf.net ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441350&group_id=5470 From noreply@sourceforge.net Wed Jul 18 22:53:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 14:53:44 -0700 Subject: [Patches] [ python-Patches-440153 ] sgmllib docstrings added Message-ID: Patches item #440153, was opened at 2001-07-10 11:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440153&group_id=5470 Category: documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Evelyn Mitchell (efm) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: sgmllib docstrings added Initial Comment: Diff is 2.1 released against CVS 1.32 Docstrings added to all methods. The text of the docstrings is from the existing # comments, which have been left intact. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440153&group_id=5470 From noreply@sourceforge.net Wed Jul 18 22:53:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 14:53:05 -0700 Subject: [Patches] [ python-Patches-441175 ] Tests for glob.py Message-ID: Patches item #441175, was opened at 2001-07-13 13:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441175&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Tests for glob.py Initial Comment: Another in the series. This file uses "unittest" to test the glob.py module. (Caveat: I've really tried to be as cross-platform as I know how, but there may be some problems remaining. At least it works on Unix!) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441175&group_id=5470 From noreply@sourceforge.net Wed Jul 18 22:53:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 14:53:05 -0700 Subject: [Patches] [ python-Patches-440827 ] Tests for dircache.py Message-ID: Patches item #440827, was opened at 2001-07-12 13:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440827&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Tests for dircache.py Initial Comment: Another installment: unit tests for dircache.py. I'm not sure whether the functionality of dircache.annotate is as intended; it appends '/' instead of os.sep blindly, regardless of platform. I don't know whether this is a bug or a feature, so I'm just assuming that the current behavior is correct. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440827&group_id=5470 From noreply@sourceforge.net Wed Jul 18 22:53:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 14:53:05 -0700 Subject: [Patches] [ python-Patches-440292 ] Test cases for pyclbr.py Message-ID: Patches item #440292, was opened at 2001-07-10 22:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440292&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Test cases for pyclbr.py Initial Comment: These test cases exercise the pyclbr module. They work by comparing the output of pyclbr to the results of module introspection for some of the largest modules in the Python distribution. They also skirt several limitations of pyclbr not mentioned in the BUGS section of pyclbr.py. For example, pyclbr.py does really bad in the presence of the string [ '"""' ]. (This keeps it from handling pydoc.py.) While writing these test cases, I also found a minor bug in pyclbr.py that would prevent it from finding functions (but not classes) declared in other modules. I'm also including a patch for this bug. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-07-10 22:22 Message: Logged In: YES user_id=499 (More information on the bug: whereas pyclbr.py can notice imports of the format: "from module import class", it wasn't able to handle "from module import fn". Now it can.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440292&group_id=5470 From noreply@sourceforge.net Wed Jul 18 22:53:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 14:53:05 -0700 Subject: [Patches] [ python-Patches-440826 ] Tests for repr.py Message-ID: Patches item #440826, was opened at 2001-07-12 13:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440826&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Tests for repr.py Initial Comment: Here are some unittests for the repr.py module. These are in line with the unit tests I've been writing over the past few days, except that these use the unittest.py module. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440826&group_id=5470 From noreply@sourceforge.net Wed Jul 18 22:53:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 14:53:06 -0700 Subject: [Patches] [ python-Patches-440291 ] Test cases for commands.py Message-ID: Patches item #440291, was opened at 2001-07-10 22:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440291&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Test cases for commands.py Initial Comment: Test cases for the commands.py module. These are only tested to work on SunOS and Linux, though they should work on any posix system. (This module needs an overhaul!) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440291&group_id=5470 From noreply@sourceforge.net Wed Jul 18 22:53:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 14:53:06 -0700 Subject: [Patches] [ python-Patches-440290 ] Tests for test_fpformat.py Message-ID: Patches item #440290, was opened at 2001-07-10 22:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440290&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Tests for test_fpformat.py Initial Comment: Another installment in the series of "Tests for the Testless". This time, we tackle the fpformat.py module, which does almost-but-not-exactly the same thing as certain options to the % operator. This test shows an inconsistencies in the behavior between fix and sci; and between fpformat and %. I'm not sure of the original authors' intent, so I'm just testing for the original behavior. This may not be best. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440290&group_id=5470 From noreply@sourceforge.net Wed Jul 18 22:54:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 14:54:30 -0700 Subject: [Patches] [ python-Patches-428320 ] rich comparisons as operator.__lt__ etc. Message-ID: Patches item #428320, was opened at 2001-05-29 07:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428320&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: rich comparisons as operator.__lt__ etc. Initial Comment: Rich Comparisons (PEP 207) introduce new special names in classes (__lt__, __le__, __eq__, etc.). They should be available in the 'operator' module just like the other special names (__add__ and the like). This patch introduce 12 new names in 'operator': lt, le, eq, ne, gt, ge, __lt__, __le__, __eq__, __ne__, __gt__, __ge__. The first 6 are provided for uniformity with the rest of the module but I am not sure whether it is a good idea to clutter a namespace with names only two letters long; for example, could names like 'eq' accidentally break existing programs using from operator import * ? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-18 14:54 Message: Logged In: YES user_id=6380 I disagree with Fred re the long names. These are too long to be typed. Now is not the time to try and argue over whether "le" etc. are good names -- the time was when the rich comparisons PEP was under discussion. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 14:44 Message: Logged In: YES user_id=3066 Have sent an email to the submitter regarding this; awaiting response. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:53 Message: Logged In: YES user_id=3066 I'd prefer to see the names that don't have underscores be lessthan, lessthanequal, equal, notequal, greaterthan, greaterthanequal. Not sure what others think. I doubt the issue is "from operator import *" -- no one should be doing that anyway. Also, the documentation fragment uses "informations" (note the 's') instead of "information". ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2001-05-29 08:01 Message: Logged In: YES user_id=4771 Sorry, I forgot to login when I posted the patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428320&group_id=5470 From noreply@sourceforge.net Wed Jul 18 22:55:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 14:55:26 -0700 Subject: [Patches] [ python-Patches-434992 ] Cleanup of warning messages Message-ID: Patches item #434992, was opened at 2001-06-20 18:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=434992&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Minsk (rminsk) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Cleanup of warning messages Initial Comment: I just compiled Python-2.1 of the SGI using the latest compilers (7.3.1.2m) with all the warning flags turned on. The following patch will get rid of most of the warning messages. I would like to see this incorporated into the next release. It is easier to spot real problems when you do not have to sort thru other warning messages. The included patch does not include other optional modules and the ones setup.py finds by default. I may have found 2 bugs in the process. Please see bugs 434989 and 434988. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 14:55 Message: Logged In: YES user_id=3066 Note that the separate cPickle has been integrated. Assigning this to me since I handled that one. ---------------------------------------------------------------------- Comment By: Robert Minsk (rminsk) Date: 2001-06-25 17:03 Message: Logged In: YES user_id=132786 > I'm not sure these patches are all correct. For the > patches introducing prototypes (e.g. tigetstr), isn't > there some header file that offers these prototypes? That is what my patch fixed. It was changing from #ifdef sgi extern char *tigetstr(char *); extern char *tparm(char *instring, ...); #endif to #ifdef __sgi #include #endif > For cPickle, looking up string_atol seems to be completely > unneeded. In turn, looking up string is unneeded, as well. > Likewise, don't just remove empty_str, remove the lookup > as well. Are you saying remove the UNLESS (PyString_FromString("")) return -1; also. I guess I missed that. > I think p should be unsigned > char*, and the casts should then be adjusted to unsigned. Should I fix that or are you looking into it? > Why is it necessary to cast the result of umask? Please > put a comment in the code, explaining that in detail (i.e. > "required for SGI" is not sufficient). Even on linux umask returns the type umask_t which may not be an int. I could change the code to int i; umask_t u; if (!PyArg_ParseTuple(args, "i:umask", &i)) return NULL; u = umask((mask_t)i); but is umask_t available on all machines? This is not a critical warning, in fact on the SGI it is only when you compile with -fullwarn and it's only an INFO message. The INFO messages are useful to identifiy potential errors. The casts should not add any overhead. This is one reason you should compile code on multiple compilers. Each compiler has it's own strength and weaknesses at identifing problems. This is not required for SGI but just to clean up messages from other compilers besides gcc. Other vendors compilers also give other warning messages. > Likewise for > alarm > (which returns long on Linux), and all other casts that > were introduced to convert system call results or > arguments. Linux (at least RedHat 6.2) does not return a long from alarm, it returns an unsigned int. Should I change the signal_alarm to PyInt_FromUnsignedLong(alarm(t))? Are there other platforms that return a signed long from alarm? I would rather cast to the type the function currently uses. The cast are just casting to the type the functions expect. This goes on if not explicity cast anywhy. So why not get rid of the implicit cast. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-23 13:25 Message: Logged In: YES user_id=21627 I'm not sure these patches are all correct. For the patches introducing prototypes (e.g. tigetstr), isn't there some header file that offers these prototypes? For cPickle, looking up string_atol seems to be completely unneeded. In turn, looking up string is unneeded, as well. Likewise, don't just remove empty_str, remove the lookup as well. On the save_float changes, you mask a range error: the values will be in 0..255, but you cast this value to char, which is potentially signed. I think p should be unsigned char*, and the casts should then be adjusted to unsigned. Since cPickle changes will need careful review, I recommend to submit them as a separate patch. Why is it necessary to cast the result of umask? Please put a comment in the code, explaining that in detail (i.e. "required for SGI" is not sufficient). Likewise for alarm (which returns long on Linux), and all other casts that were introduced to convert system call results or arguments. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-23 13:00 Message: Logged In: YES user_id=21627 Refiled as a patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=434992&group_id=5470 From mall.com" Advertise Your Website for FREE. http://www.mall.com/freetraffic We would like to take this opportunity to introduce you to a unique online marketing opportunity at Mall.com and the services which we provide hundreds of online merchants like you. The Merchant Marketing Center at Mall.com will provide you with information and pricing for Mall.com’s entire suite of online marketing services, including a FREE listing on the Mall.com website. By registering your business for a FREE listing, you will be exposed to millions of qualified shoppers throughout the world. Follow this URL for your FREE listing.... http://www.mall.com/freesignup Or, if you are interested in upgrading to a "Packaged" service, including logo placement in our exclusive Mall Maps, e-mail campaigns to hundreds of thousands of pre-qualified shoppers, product placement, search engine optimization, plus much more, then click below to learn more about Mall.com’s Marketing Packages. At Mall.com, our goal is to deliver qualified shoppers to our online partners at the most cost effective price. Please feel free to contact us at anytime with your questions or comments @ 1-888-989-6255. Or click below to fill out our FREE Online Marketing Inquiry form. One of our representatives will contact you within the next 2 business days. Mall.com Home Page http://www.mall.com/freetraffic Merchant Marketing Center http://www.mall.com/getinfo FREE Online Registration http://www.mall.com/freesignup /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ THIS MESSAGE IS BEING SENT IN COMPLIANCE OF THE EMAIL BILL: SECTION 301. PER SECTION, PARAGRAPH (a) (2) (c) of S. 1618. To discontinue receipt of further notice at not cost and to be removed from our database, please reply with the word "Remove" in subject. Any attempts to disrupt the removal email address etc., will not allow us to be able to retrieve and process the remove requests. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ From noreply@sourceforge.net Thu Jul 19 00:15:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 16:15:25 -0700 Subject: [Patches] [ python-Patches-429136 ] BROWSER fix for webbrowser.py Message-ID: Patches item #429136, was opened at 2001-05-31 13:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429136&group_id=5470 Category: library Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: BROWSER fix for webbrowser.py Initial Comment: webbrowser.py currently assumes the BROWSER environment variable was set by the user who will take care of registering that browser. In the case of Gnome+Mandrake 8.0 (at least), this is not the case. The attached patch attempts to register any browsers found in BROWSER that aren't in the _browser dict already. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2001-07-18 16:15 Message: Logged In: YES user_id=44345 checked in on release21-maint branch (v1.19). Closing again... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 14:42 Message: Logged In: YES user_id=3066 Assigning back to Skip for checkin on the release21-maint branch. Please checkin and close. Thanks! ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-07-18 14:39 Message: Logged In: YES user_id=44345 I think it should be. Without it, on systems running Gnome, the webbrowser module doesn't work. In particular, note that the 2.1 version of webbrowser.py made the (incorrect) assumption that the user would be the only person setting the BROWSER environment variable. If you eliminate that assumption, you have to assume that the user may not have registered all the browsers mentioned in BROWSER. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 13:08 Message: Logged In: YES user_id=3066 Hmm... should this be part of the 2.1.1 release as well? It's not clear to me whether this is strictly a bugfix. Re-opening and assigning to Thomas for a ruling. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-07-18 13:04 Message: Logged In: YES user_id=44345 checked in this change as v 1.19 of webbrowser.py ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 11:53 Message: Logged In: YES user_id=3066 Accepted; please check this in. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:25 Message: Logged In: YES user_id=3066 Assigned to me, since the webbrowser module is largely my fault, and the initialization has become more complex than it needs to be anyway. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429136&group_id=5470 From noreply@sourceforge.net Thu Jul 19 00:40:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 16:40:26 -0700 Subject: [Patches] [ python-Patches-429136 ] BROWSER fix for webbrowser.py Message-ID: Patches item #429136, was opened at 2001-05-31 13:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429136&group_id=5470 Category: library Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: BROWSER fix for webbrowser.py Initial Comment: webbrowser.py currently assumes the BROWSER environment variable was set by the user who will take care of registering that browser. In the case of Gnome+Mandrake 8.0 (at least), this is not the case. The attached patch attempts to register any browsers found in BROWSER that aren't in the _browser dict already. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 16:40 Message: Logged In: YES user_id=3066 Actually, it was 1.18.2.1 in the maintenance branch. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-07-18 16:15 Message: Logged In: YES user_id=44345 checked in on release21-maint branch (v1.19). Closing again... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 14:42 Message: Logged In: YES user_id=3066 Assigning back to Skip for checkin on the release21-maint branch. Please checkin and close. Thanks! ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-07-18 14:39 Message: Logged In: YES user_id=44345 I think it should be. Without it, on systems running Gnome, the webbrowser module doesn't work. In particular, note that the 2.1 version of webbrowser.py made the (incorrect) assumption that the user would be the only person setting the BROWSER environment variable. If you eliminate that assumption, you have to assume that the user may not have registered all the browsers mentioned in BROWSER. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 13:08 Message: Logged In: YES user_id=3066 Hmm... should this be part of the 2.1.1 release as well? It's not clear to me whether this is strictly a bugfix. Re-opening and assigning to Thomas for a ruling. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-07-18 13:04 Message: Logged In: YES user_id=44345 checked in this change as v 1.19 of webbrowser.py ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 11:53 Message: Logged In: YES user_id=3066 Accepted; please check this in. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:25 Message: Logged In: YES user_id=3066 Assigned to me, since the webbrowser module is largely my fault, and the initialization has become more complex than it needs to be anyway. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429136&group_id=5470 From noreply@sourceforge.net Thu Jul 19 00:48:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 16:48:32 -0700 Subject: [Patches] [ python-Patches-436376 ] C API Request Message-ID: Patches item #436376, was opened at 2001-06-26 06:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=436376&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Guido van Rossum (gvanrossum) Summary: C API Request Initial Comment: I would like to have the following 4 C API functions added to pystate.c so that advanced extension modules can more easily examine the internal state of the Python interpreter and its threads. The intent of these functions is to provide a mechanism for gaining portable read-only access to all of the current PyThreadState * structures. The primary use of this would be in advanced debugging applications. Cheers, Dave Beazley ------------------------------------------- /* included in pystate.c */ PyInterpreterState * PyInterpreterState_Head(void) { return interp_head; } PyInterpreterState * PyInterpreterState_Next(PyInterpreterState *interp) { return interp->next; } PyThreadState * PyInterpreterState_ThreadHead(PyInterpreterState *interp) { return interp->tstate_head; } PyThreadState * PyThreadState_Next(PyThreadState *tstate) { return tstate->next; } ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 16:48 Message: Logged In: YES user_id=3066 This looks fairly reasonable to me, but I'm not sure just what you have in mind. Assigning to Guido since he has a much better appreciation for debugger requirements than I do. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=436376&group_id=5470 From noreply@sourceforge.net Thu Jul 19 07:29:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 23:29:57 -0700 Subject: [Patches] [ python-Patches-441348 ] Allow jython to complete test_charmap Message-ID: Patches item #441348, was opened at 2001-07-14 15:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441348&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Nobody/Anonymous (nobody) Summary: Allow jython to complete test_charmap Initial Comment: The repr of unicode strings in the output is different for jython. The attached patch allow jython to complete the test_charmapcodec test. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-18 23:29 Message: Logged In: YES user_id=21627 I recommend to approve this patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441348&group_id=5470 From noreply@sourceforge.net Thu Jul 19 07:42:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 23:42:30 -0700 Subject: [Patches] [ python-Patches-438790 ] additional mappings for mimetypes.py Message-ID: Patches item #438790, was opened at 2001-07-05 08:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438790&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: additional mappings for mimetypes.py Initial Comment: added some additional mapping for mimetypes.py. Andreas ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-18 23:42 Message: Logged In: YES user_id=21627 I believe some of these types are not "official", in the sense that they are supported by an RFC; types that are not defined in an RFC MUST use the x- prefix. E.g. in what RFC is "text/xsl" or "text/xul" defined? IOW, only types listed in http://www.isi.edu/in-notes/iana/assignments/media-types/ should be supported without x-prefix. Could you please review the entire list of known types with this respect, and update the patch accordingly? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438790&group_id=5470 From noreply@sourceforge.net Thu Jul 19 07:48:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 23:48:47 -0700 Subject: [Patches] [ python-Patches-413333 ] Improved support for unicode conversions Message-ID: Patches item #413333, was opened at 2001-04-02 23:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413333&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: M.-A. Lemburg (lemburg) Summary: Improved support for unicode conversions Initial Comment: This patch is designed to increase the flexibility of the unicode conversion function. The proposed strategy is: def unicode( val ) if type( val ) == type.UnicodeType: return val else: return str_to_unicode( str( val ) ) This makes it possible to perform operations such as: unicode( 5 ) => u'5' without generating an exception. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-18 23:48 Message: Logged In: YES user_id=21627 I recommend to close this patch, as suggested by the submitter. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-04-22 11:45 Message: Logged In: YES user_id=108973 I would propose ignoring this patch, leaving the existing function as is, and adding an additional function to unicodeobject.c that does this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:35 Message: Logged In: YES user_id=6380 Too late for 2.1 -- no functionality changes allowed. Assigned to Marc-Andre, who's in charge of Unicode. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413333&group_id=5470 From noreply@sourceforge.net Thu Jul 19 13:20:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 05:20:27 -0700 Subject: [Patches] [ python-Patches-436376 ] C API Request Message-ID: Patches item #436376, was opened at 2001-06-26 06:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=436376&group_id=5470 Category: core (C code) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: C API Request Initial Comment: I would like to have the following 4 C API functions added to pystate.c so that advanced extension modules can more easily examine the internal state of the Python interpreter and its threads. The intent of these functions is to provide a mechanism for gaining portable read-only access to all of the current PyThreadState * structures. The primary use of this would be in advanced debugging applications. Cheers, Dave Beazley ------------------------------------------- /* included in pystate.c */ PyInterpreterState * PyInterpreterState_Head(void) { return interp_head; } PyInterpreterState * PyInterpreterState_Next(PyInterpreterState *interp) { return interp->next; } PyThreadState * PyInterpreterState_ThreadHead(PyInterpreterState *interp) { return interp->tstate_head; } PyThreadState * PyThreadState_Next(PyThreadState *tstate) { return tstate->next; } ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 05:20 Message: Logged In: YES user_id=6380 Hi David! Because it's you, I've checked this into CVS. Don't tell anyone else about this. :-) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 16:48 Message: Logged In: YES user_id=3066 This looks fairly reasonable to me, but I'm not sure just what you have in mind. Assigning to Guido since he has a much better appreciation for debugger requirements than I do. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=436376&group_id=5470 From noreply@sourceforge.net Thu Jul 19 13:32:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 05:32:50 -0700 Subject: [Patches] [ python-Patches-416254 ] documentation for new imaplib methods Message-ID: Patches item #416254, was opened at 2001-04-15 04:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416254&group_id=5470 Category: documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Piers Lauder (pierslauder) >Assigned to: Piers Lauder (pierslauder) Summary: documentation for new imaplib methods Initial Comment: This patch is against the current copy of dist/src/Doc/lib/libimaplib.tex and documents the new methods contained in my earlier imaplib patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416254&group_id=5470 From noreply@sourceforge.net Thu Jul 19 13:32:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 05:32:50 -0700 Subject: [Patches] [ python-Patches-416253 ] additions to imaplib Message-ID: Patches item #416253, was opened at 2001-04-15 04:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416253&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Piers Lauder (pierslauder) >Assigned to: Piers Lauder (pierslauder) Summary: additions to imaplib Initial Comment: This patch adds some new methods: GET/SETACL (submitted by Anthony Baxter); SORT (IMAP4rev1 extension); and some overridable methods to complete the ability to override all I/O. There are also some code cleanups (I've changed the evals into getattrs). The documentation changes for the new methods are submitted as a separate patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416253&group_id=5470 From noreply@sourceforge.net Thu Jul 19 13:32:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 05:32:50 -0700 Subject: [Patches] [ python-Patches-415331 ] add setacl/getacl to imaplib Message-ID: Patches item #415331, was opened at 2001-04-10 23:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415331&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) >Assigned to: Piers Lauder (pierslauder) Summary: add setacl/getacl to imaplib Initial Comment: Cyrus IMAP stores support the SETACL and GETACL commands. This patch add support for these to imaplib.py ---------------------------------------------------------------------- Comment By: Piers Lauder (pierslauder) Date: 2001-04-15 04:58 Message: Logged In: YES user_id=196212 I've incorporated this patch into my imaplib patch, submitted a few moments ago. (I've also documented it :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-13 08:45 Message: Logged In: YES user_id=6380 I've forwarded this to Piers Lauder, imaplib's author. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415331&group_id=5470 From noreply@sourceforge.net Thu Jul 19 13:56:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 05:56:01 -0700 Subject: [Patches] [ python-Patches-418659 ] Fixes for UnixWare and ReliantUnix Message-ID: Patches item #418659, was opened at 2001-04-24 14:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418659&group_id=5470 Category: Build Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Martin v. Löwis (loewis) Summary: Fixes for UnixWare and ReliantUnix Initial Comment: This patch fixes the build problems on UnixWare, by: a) backing out 1.215 of configure.in and 1.34 of Makefile.pre.in b) Adding a test to check whether the compiler supports -Kpthread, and using that instead of #defines and libraries for pthread support. This part is not only restricted to UnixWare, but should work on other SysV compilers as well (e.g. ReliantUnix, untested) With these patches, UnixWare still passes the test suite except for test_math. Compared to 2.1, this drops usage of a shared libpython2.1.so. Such a feature is highly problematic, and was implemented incorrectly in 2.1. It should be brought back only as a configure option, which should be off by default, and apply to all Unix systems that support shared libraries. These patches should be applied to both the mainline and the 2.1 maintenance branch. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-19 05:56 Message: Logged In: YES user_id=21627 Committed as configure.in 1.230, configure 1.222, Makefile.pre.in 1.42. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-12 16:02 Message: Logged In: YES user_id=3066 Accepted and assigned back to Martin for checkin. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 21:28 Message: Logged In: YES user_id=3066 Assigned to me since the Reliant Unix issue is assigned to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418659&group_id=5470 From noreply@sourceforge.net Thu Jul 19 15:26:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 07:26:43 -0700 Subject: [Patches] [ python-Patches-442512 ] SRE BIGCHARSET endianness fix Message-ID: Patches item #442512, was opened at 2001-07-18 11:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442512&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Nobody/Anonymous (nobody) Summary: SRE BIGCHARSET endianness fix Initial Comment: The current sre_compile works only on little-endian machines for BIGCHARSET operations; the problem is that _sre.c addresses the block indices as a byte array, whereas sre_compile builds it as a short integer array. This patch fixes the problem reported in http://mail.python.org/pipermail/python-dev/2001-July/015947.html for SPARC Solaris. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-19 07:26 Message: Logged In: YES user_id=21627 committed as sre_compile.py 1.39. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442512&group_id=5470 From noreply@sourceforge.net Thu Jul 19 20:40:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 12:40:54 -0700 Subject: [Patches] [ python-Patches-442863 ] Add switch to disable PYTHON{HOME,PATH} Message-ID: Patches item #442863, was opened at 2001-07-19 12:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442863&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Guido van Rossum (gvanrossum) Summary: Add switch to disable PYTHON{HOME,PATH} Initial Comment: This patch adds the -E command line switch. When specified, the PYTHONHOME and PYTHONPATH environment variables are ignored. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442863&group_id=5470 From noreply@sourceforge.net Thu Jul 19 20:46:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 12:46:00 -0700 Subject: [Patches] [ python-Patches-442866 ] Tests for codeop.py Message-ID: Patches item #442866, was opened at 2001-07-19 12:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442866&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Tests for codeop.py Initial Comment: Another installment of unit tests. This file contains a set of new test cases for the codeop module, which previously had none. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442866&group_id=5470 From noreply@sourceforge.net Thu Jul 19 20:47:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 12:47:29 -0700 Subject: [Patches] [ python-Patches-442867 ] Tests cases for mhlib.py Message-ID: Patches item #442867, was opened at 2001-07-19 12:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442867&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Tests cases for mhlib.py Initial Comment: Another installment. The mhlib module previously had no unit tests. The attatched file contains a relatively complete set of tests for mhlib.py ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442867&group_id=5470 From noreply@sourceforge.net Thu Jul 19 21:10:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 13:10:02 -0700 Subject: [Patches] [ python-Patches-440153 ] sgmllib docstrings added Message-ID: Patches item #440153, was opened at 2001-07-10 11:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440153&group_id=5470 Category: documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Evelyn Mitchell (efm) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: sgmllib docstrings added Initial Comment: Diff is 2.1 released against CVS 1.32 Docstrings added to all methods. The text of the docstrings is from the existing # comments, which have been left intact. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-19 13:10 Message: Logged In: YES user_id=3066 Checked in a modified version as Lib/sgmllib.py revision 1.35. No docstrings were added for internal routines, or example and placeholder methods that are intended to be overridden. Thanks, Evelyn! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440153&group_id=5470 From noreply@sourceforge.net Thu Jul 19 21:37:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 13:37:20 -0700 Subject: [Patches] [ python-Patches-442863 ] Add switch to disable PYTHON{HOME,PATH} Message-ID: Patches item #442863, was opened at 2001-07-19 12:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442863&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Neil Schemenauer (nascheme) Summary: Add switch to disable PYTHON{HOME,PATH} Initial Comment: This patch adds the -E command line switch. When specified, the PYTHONHOME and PYTHONPATH environment variables are ignored. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 13:37 Message: Logged In: YES user_id=6380 Cool, Neil! Nits: - The Makefile uses "-Ec" somewhere; I recommend to use "-E -c" instead. - Does -E suppress PYTHONSTARTUP or doesn't it? The comments are inconsistent with the help message. I think it should suppress *all* use of Python-specific environment variables. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442863&group_id=5470 From noreply@sourceforge.net Thu Jul 19 22:14:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 14:14:54 -0700 Subject: [Patches] [ python-Patches-442863 ] Add switch to disable PYTHON{HOME,PATH} Message-ID: Patches item #442863, was opened at 2001-07-19 12:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442863&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Neil Schemenauer (nascheme) Summary: Add switch to disable PYTHON{HOME,PATH} Initial Comment: This patch adds the -E command line switch. When specified, the PYTHONHOME and PYTHONPATH environment variables are ignored. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-07-19 14:14 Message: Logged In: YES user_id=35752 -E only suppress PYTHONHOME and PYTHONPATH. Are you sure about suppressing them all? There are quite a few (around 8). PYTHONHOME and PYTHONPATH seem to be the only ones that cause real trouble. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 13:37 Message: Logged In: YES user_id=6380 Cool, Neil! Nits: - The Makefile uses "-Ec" somewhere; I recommend to use "-E -c" instead. - Does -E suppress PYTHONSTARTUP or doesn't it? The comments are inconsistent with the help message. I think it should suppress *all* use of Python-specific environment variables. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442863&group_id=5470 From noreply@sourceforge.net Thu Jul 19 22:32:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 14:32:19 -0700 Subject: [Patches] [ python-Patches-434992 ] Cleanup of warning messages Message-ID: Patches item #434992, was opened at 2001-06-20 18:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=434992&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Minsk (rminsk) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Cleanup of warning messages Initial Comment: I just compiled Python-2.1 of the SGI using the latest compilers (7.3.1.2m) with all the warning flags turned on. The following patch will get rid of most of the warning messages. I would like to see this incorporated into the next release. It is easier to spot real problems when you do not have to sort thru other warning messages. The included patch does not include other optional modules and the ones setup.py finds by default. I may have found 2 bugs in the process. Please see bugs 434989 and 434988. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-19 14:32 Message: Logged In: YES user_id=3066 I've checked in a lot of the patches here in the Modules/ directory: _cursesmodule.c 2.54 pcremodule.c 2.28 posixmodule.c 2.194 selectmodule.c 2.53 signalmodule.c 2.59 socketmodule.c 1.151 unicodedata.c 2.13xreadlinesmodule.c 1.7 Some patches from the Modules/ directory appear to no longer apply. Please file a separate patch if anything additional is needed in the Modules/ directory. Starting on the rest of the patch. (Breaking this up more would have been good.) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 14:55 Message: Logged In: YES user_id=3066 Note that the separate cPickle has been integrated. Assigning this to me since I handled that one. ---------------------------------------------------------------------- Comment By: Robert Minsk (rminsk) Date: 2001-06-25 17:03 Message: Logged In: YES user_id=132786 > I'm not sure these patches are all correct. For the > patches introducing prototypes (e.g. tigetstr), isn't > there some header file that offers these prototypes? That is what my patch fixed. It was changing from #ifdef sgi extern char *tigetstr(char *); extern char *tparm(char *instring, ...); #endif to #ifdef __sgi #include #endif > For cPickle, looking up string_atol seems to be completely > unneeded. In turn, looking up string is unneeded, as well. > Likewise, don't just remove empty_str, remove the lookup > as well. Are you saying remove the UNLESS (PyString_FromString("")) return -1; also. I guess I missed that. > I think p should be unsigned > char*, and the casts should then be adjusted to unsigned. Should I fix that or are you looking into it? > Why is it necessary to cast the result of umask? Please > put a comment in the code, explaining that in detail (i.e. > "required for SGI" is not sufficient). Even on linux umask returns the type umask_t which may not be an int. I could change the code to int i; umask_t u; if (!PyArg_ParseTuple(args, "i:umask", &i)) return NULL; u = umask((mask_t)i); but is umask_t available on all machines? This is not a critical warning, in fact on the SGI it is only when you compile with -fullwarn and it's only an INFO message. The INFO messages are useful to identifiy potential errors. The casts should not add any overhead. This is one reason you should compile code on multiple compilers. Each compiler has it's own strength and weaknesses at identifing problems. This is not required for SGI but just to clean up messages from other compilers besides gcc. Other vendors compilers also give other warning messages. > Likewise for > alarm > (which returns long on Linux), and all other casts that > were introduced to convert system call results or > arguments. Linux (at least RedHat 6.2) does not return a long from alarm, it returns an unsigned int. Should I change the signal_alarm to PyInt_FromUnsignedLong(alarm(t))? Are there other platforms that return a signed long from alarm? I would rather cast to the type the function currently uses. The cast are just casting to the type the functions expect. This goes on if not explicity cast anywhy. So why not get rid of the implicit cast. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-23 13:25 Message: Logged In: YES user_id=21627 I'm not sure these patches are all correct. For the patches introducing prototypes (e.g. tigetstr), isn't there some header file that offers these prototypes? For cPickle, looking up string_atol seems to be completely unneeded. In turn, looking up string is unneeded, as well. Likewise, don't just remove empty_str, remove the lookup as well. On the save_float changes, you mask a range error: the values will be in 0..255, but you cast this value to char, which is potentially signed. I think p should be unsigned char*, and the casts should then be adjusted to unsigned. Since cPickle changes will need careful review, I recommend to submit them as a separate patch. Why is it necessary to cast the result of umask? Please put a comment in the code, explaining that in detail (i.e. "required for SGI" is not sufficient). Likewise for alarm (which returns long on Linux), and all other casts that were introduced to convert system call results or arguments. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-23 13:00 Message: Logged In: YES user_id=21627 Refiled as a patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=434992&group_id=5470 From noreply@sourceforge.net Thu Jul 19 22:50:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 14:50:38 -0700 Subject: [Patches] [ python-Patches-434992 ] Cleanup of warning messages Message-ID: Patches item #434992, was opened at 2001-06-20 18:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=434992&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Minsk (rminsk) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Cleanup of warning messages Initial Comment: I just compiled Python-2.1 of the SGI using the latest compilers (7.3.1.2m) with all the warning flags turned on. The following patch will get rid of most of the warning messages. I would like to see this incorporated into the next release. It is easier to spot real problems when you do not have to sort thru other warning messages. The included patch does not include other optional modules and the ones setup.py finds by default. I may have found 2 bugs in the process. Please see bugs 434989 and 434988. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-19 14:50 Message: Logged In: YES user_id=3066 Only a couple of patches still make sense in the Objects/ directory: fileobject.c 2.114 intobject.c 2.59 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-19 14:32 Message: Logged In: YES user_id=3066 I've checked in a lot of the patches here in the Modules/ directory: _cursesmodule.c 2.54 pcremodule.c 2.28 posixmodule.c 2.194 selectmodule.c 2.53 signalmodule.c 2.59 socketmodule.c 1.151 unicodedata.c 2.13xreadlinesmodule.c 1.7 Some patches from the Modules/ directory appear to no longer apply. Please file a separate patch if anything additional is needed in the Modules/ directory. Starting on the rest of the patch. (Breaking this up more would have been good.) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 14:55 Message: Logged In: YES user_id=3066 Note that the separate cPickle has been integrated. Assigning this to me since I handled that one. ---------------------------------------------------------------------- Comment By: Robert Minsk (rminsk) Date: 2001-06-25 17:03 Message: Logged In: YES user_id=132786 > I'm not sure these patches are all correct. For the > patches introducing prototypes (e.g. tigetstr), isn't > there some header file that offers these prototypes? That is what my patch fixed. It was changing from #ifdef sgi extern char *tigetstr(char *); extern char *tparm(char *instring, ...); #endif to #ifdef __sgi #include #endif > For cPickle, looking up string_atol seems to be completely > unneeded. In turn, looking up string is unneeded, as well. > Likewise, don't just remove empty_str, remove the lookup > as well. Are you saying remove the UNLESS (PyString_FromString("")) return -1; also. I guess I missed that. > I think p should be unsigned > char*, and the casts should then be adjusted to unsigned. Should I fix that or are you looking into it? > Why is it necessary to cast the result of umask? Please > put a comment in the code, explaining that in detail (i.e. > "required for SGI" is not sufficient). Even on linux umask returns the type umask_t which may not be an int. I could change the code to int i; umask_t u; if (!PyArg_ParseTuple(args, "i:umask", &i)) return NULL; u = umask((mask_t)i); but is umask_t available on all machines? This is not a critical warning, in fact on the SGI it is only when you compile with -fullwarn and it's only an INFO message. The INFO messages are useful to identifiy potential errors. The casts should not add any overhead. This is one reason you should compile code on multiple compilers. Each compiler has it's own strength and weaknesses at identifing problems. This is not required for SGI but just to clean up messages from other compilers besides gcc. Other vendors compilers also give other warning messages. > Likewise for > alarm > (which returns long on Linux), and all other casts that > were introduced to convert system call results or > arguments. Linux (at least RedHat 6.2) does not return a long from alarm, it returns an unsigned int. Should I change the signal_alarm to PyInt_FromUnsignedLong(alarm(t))? Are there other platforms that return a signed long from alarm? I would rather cast to the type the function currently uses. The cast are just casting to the type the functions expect. This goes on if not explicity cast anywhy. So why not get rid of the implicit cast. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-23 13:25 Message: Logged In: YES user_id=21627 I'm not sure these patches are all correct. For the patches introducing prototypes (e.g. tigetstr), isn't there some header file that offers these prototypes? For cPickle, looking up string_atol seems to be completely unneeded. In turn, looking up string is unneeded, as well. Likewise, don't just remove empty_str, remove the lookup as well. On the save_float changes, you mask a range error: the values will be in 0..255, but you cast this value to char, which is potentially signed. I think p should be unsigned char*, and the casts should then be adjusted to unsigned. Since cPickle changes will need careful review, I recommend to submit them as a separate patch. Why is it necessary to cast the result of umask? Please put a comment in the code, explaining that in detail (i.e. "required for SGI" is not sufficient). Likewise for alarm (which returns long on Linux), and all other casts that were introduced to convert system call results or arguments. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-23 13:00 Message: Logged In: YES user_id=21627 Refiled as a patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=434992&group_id=5470 From noreply@sourceforge.net Thu Jul 19 23:03:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 15:03:12 -0700 Subject: [Patches] [ python-Patches-434992 ] Cleanup of warning messages Message-ID: Patches item #434992, was opened at 2001-06-20 18:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=434992&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Robert Minsk (rminsk) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Cleanup of warning messages Initial Comment: I just compiled Python-2.1 of the SGI using the latest compilers (7.3.1.2m) with all the warning flags turned on. The following patch will get rid of most of the warning messages. I would like to see this incorporated into the next release. It is easier to spot real problems when you do not have to sort thru other warning messages. The included patch does not include other optional modules and the ones setup.py finds by default. I may have found 2 bugs in the process. Please see bugs 434989 and 434988. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-19 15:03 Message: Logged In: YES user_id=3066 The rest of the patches don't appear to apply worth anything any more (we've had an active month in the source tree!), so I'm closing this as "partly accepted". If there are any remaining warnings on the SGI, please submit a fresh patch, and send me an email so it doesn't go stale before I get to it. Thanks for all the work! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-19 14:50 Message: Logged In: YES user_id=3066 Only a couple of patches still make sense in the Objects/ directory: fileobject.c 2.114 intobject.c 2.59 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-19 14:32 Message: Logged In: YES user_id=3066 I've checked in a lot of the patches here in the Modules/ directory: _cursesmodule.c 2.54 pcremodule.c 2.28 posixmodule.c 2.194 selectmodule.c 2.53 signalmodule.c 2.59 socketmodule.c 1.151 unicodedata.c 2.13xreadlinesmodule.c 1.7 Some patches from the Modules/ directory appear to no longer apply. Please file a separate patch if anything additional is needed in the Modules/ directory. Starting on the rest of the patch. (Breaking this up more would have been good.) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-18 14:55 Message: Logged In: YES user_id=3066 Note that the separate cPickle has been integrated. Assigning this to me since I handled that one. ---------------------------------------------------------------------- Comment By: Robert Minsk (rminsk) Date: 2001-06-25 17:03 Message: Logged In: YES user_id=132786 > I'm not sure these patches are all correct. For the > patches introducing prototypes (e.g. tigetstr), isn't > there some header file that offers these prototypes? That is what my patch fixed. It was changing from #ifdef sgi extern char *tigetstr(char *); extern char *tparm(char *instring, ...); #endif to #ifdef __sgi #include #endif > For cPickle, looking up string_atol seems to be completely > unneeded. In turn, looking up string is unneeded, as well. > Likewise, don't just remove empty_str, remove the lookup > as well. Are you saying remove the UNLESS (PyString_FromString("")) return -1; also. I guess I missed that. > I think p should be unsigned > char*, and the casts should then be adjusted to unsigned. Should I fix that or are you looking into it? > Why is it necessary to cast the result of umask? Please > put a comment in the code, explaining that in detail (i.e. > "required for SGI" is not sufficient). Even on linux umask returns the type umask_t which may not be an int. I could change the code to int i; umask_t u; if (!PyArg_ParseTuple(args, "i:umask", &i)) return NULL; u = umask((mask_t)i); but is umask_t available on all machines? This is not a critical warning, in fact on the SGI it is only when you compile with -fullwarn and it's only an INFO message. The INFO messages are useful to identifiy potential errors. The casts should not add any overhead. This is one reason you should compile code on multiple compilers. Each compiler has it's own strength and weaknesses at identifing problems. This is not required for SGI but just to clean up messages from other compilers besides gcc. Other vendors compilers also give other warning messages. > Likewise for > alarm > (which returns long on Linux), and all other casts that > were introduced to convert system call results or > arguments. Linux (at least RedHat 6.2) does not return a long from alarm, it returns an unsigned int. Should I change the signal_alarm to PyInt_FromUnsignedLong(alarm(t))? Are there other platforms that return a signed long from alarm? I would rather cast to the type the function currently uses. The cast are just casting to the type the functions expect. This goes on if not explicity cast anywhy. So why not get rid of the implicit cast. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-23 13:25 Message: Logged In: YES user_id=21627 I'm not sure these patches are all correct. For the patches introducing prototypes (e.g. tigetstr), isn't there some header file that offers these prototypes? For cPickle, looking up string_atol seems to be completely unneeded. In turn, looking up string is unneeded, as well. Likewise, don't just remove empty_str, remove the lookup as well. On the save_float changes, you mask a range error: the values will be in 0..255, but you cast this value to char, which is potentially signed. I think p should be unsigned char*, and the casts should then be adjusted to unsigned. Since cPickle changes will need careful review, I recommend to submit them as a separate patch. Why is it necessary to cast the result of umask? Please put a comment in the code, explaining that in detail (i.e. "required for SGI" is not sufficient). Likewise for alarm (which returns long on Linux), and all other casts that were introduced to convert system call results or arguments. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-23 13:00 Message: Logged In: YES user_id=21627 Refiled as a patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=434992&group_id=5470 From noreply@sourceforge.net Thu Jul 19 23:21:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 15:21:26 -0700 Subject: [Patches] [ python-Patches-441791 ] Improvment to package import semantics Message-ID: Patches item #441791, was opened at 2001-07-16 12:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441791&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Coventry (alex_coventry) Assigned to: Nobody/Anonymous (nobody) Summary: Improvment to package import semantics Initial Comment: I think it's nice to be able to do this: >>> import sys >>> sys.path.append('/l/alex_c/') >>> import mouse.foo Traceback (most recent call last): File "", line 1, in ? File "/l/alex_c/mouse/foo.py", line 1, in ? bar NameError: name 'bar' is not defined >>> import mouse.foo >>> reload(mouse.foo) # Works now that foo.py is corrected >>> from mouse import foo >>> foo.bar 1 However, at the moment, that's not possible, because if an error occurs in the loading of foo, foo is not added to mouse's dictionary, even though the module added to sys.modules under the key 'mouse.foo'. This has been driving me nuts, because I have large datasets that I need to load in each time I start python up, so I tend to test my scripts in a single interactive interpreter as I write them, so it's important for me to be able to reliably reload modules. I think it's also a sensible way for things to work in general, too. If there's enough controversy about this, I can write a PEP about it, or something. At any rate, here's a patch against the current CVS repository that changes the semantics as I've described. Alex. ---------------------------------------------------------------------- >Comment By: Alex Coventry (alex_coventry) Date: 2001-07-19 15:21 Message: Logged In: YES user_id=49686 Hi, I've looked for pertinent thread in the python-dev archive, but I've been unable to find one. I've searched for keywords "import.c", "import_submodule", "reload", and lastly "package import", although I might have missed a thread matching that, as there were over a hundred hits. Could you point me at a thread? Alex. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-17 02:00 Message: Logged In: YES user_id=34209 This is not a 2.0.1 bugfix candidate, or any bugfix candidate. Group changed. This is also a subject of occasional discussion on python-dev, see the archives ;P ---------------------------------------------------------------------- Comment By: Alex Coventry (alex_coventry) Date: 2001-07-16 12:42 Message: Logged In: YES user_id=49686 a) Sorry about the duplicate submission b) I attached the patch I'm proposing to it, but can't see it on this page. Here it is, just in case: Index: Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.178 diff -c -r2.178 import.c *** Python/import.c 2001/07/05 03:47:53 2.178 --- Python/import.c 2001/07/16 19:04:05 *************** *** 1789,1795 **** import_submodule(PyObject *mod, char *subname, char *fullname) { PyObject *modules = PyImport_GetModuleDict(); ! PyObject *m; /* Require: if mod == None: subname == fullname --- 1789,1795 ---- import_submodule(PyObject *mod, char *subname, char *fullname) { PyObject *modules = PyImport_GetModuleDict(); ! PyObject *m, *resulting_module=NULL; /* Require: if mod == None: subname == fullname *************** *** 1829,1839 **** m = load_module(fullname, fp, buf, fdp->type); if (fp) fclose(fp); ! if (m != NULL && mod != Py_None) { ! if (PyObject_SetAttrString(mod, subname, m) < 0) { ! Py_DECREF(m); ! m = NULL; ! } } } --- 1829,1864 ---- m = load_module(fullname, fp, buf, fdp->type); if (fp) fclose(fp); ! if (mod != Py_None) { ! ! /* Irrespective of the success of this load, make a ! reference to it in the parent package module. */ ! ! /* ...a copy gets saved in the modules dictionary ! under the full name, so get a reference from ! there, if need be. */ ! if (m == NULL) { ! resulting_module = PyDict_GetItemString(modules, ! fullname); ! if (resulting_module == NULL) { ! ! /* ...failed to find the module under its full ! name; oops */ ! PyErr_Format(PyExc_SystemError, ! "Failed to create a sys.modules " \ ! "entry under %.200s", fullname); ! return NULL; ! } ! } else { ! resulting_module = m; ! } ! ! if (PyObject_SetAttrString(mod, subname, resulting_module) < 0) { ! if (m != NULL) { ! Py_DECREF(m); ! m = NULL; ! } ! } } } ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441791&group_id=5470 From noreply@sourceforge.net Thu Jul 19 23:29:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 15:29:26 -0700 Subject: [Patches] [ python-Patches-440826 ] Tests for repr.py Message-ID: Patches item #440826, was opened at 2001-07-12 13:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440826&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Tests for repr.py Initial Comment: Here are some unittests for the repr.py module. These are in line with the unit tests I've been writing over the past few days, except that these use the unittest.py module. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-19 15:29 Message: Logged In: YES user_id=3066 Wonderful, thanks! It would be nice to see additional tests added to this to check that changing the max* variables on the Repr instance actually affects the results, but that can be a separate patch. ;-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440826&group_id=5470 From noreply@sourceforge.net Fri Jul 20 00:02:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 16:02:28 -0700 Subject: [Patches] [ python-Patches-440827 ] Tests for dircache.py Message-ID: Patches item #440827, was opened at 2001-07-12 13:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440827&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Tests for dircache.py Initial Comment: Another installment: unit tests for dircache.py. I'm not sure whether the functionality of dircache.annotate is as intended; it appends '/' instead of os.sep blindly, regardless of platform. I don't know whether this is a bug or a feature, so I'm just assuming that the current behavior is correct. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-19 16:02 Message: Logged In: YES user_id=3066 Accepted with modifications: - Don't alias the functions being tested; write out their names so the tests are easier to understand. I.e., "dircache.listdir" instead of "ld". - Don't use a try/except or try/finally if not needed, and minimize the code in the try clause. - Don't tear down the test in the test_*() method, let the tearDown() method you already wrote do the work. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440827&group_id=5470 From noreply@sourceforge.net Fri Jul 20 00:05:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 16:05:58 -0700 Subject: [Patches] [ python-Patches-440290 ] Tests for test_fpformat.py Message-ID: Patches item #440290, was opened at 2001-07-10 22:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440290&group_id=5470 Category: None Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Tests for test_fpformat.py Initial Comment: Another installment in the series of "Tests for the Testless". This time, we tackle the fpformat.py module, which does almost-but-not-exactly the same thing as certain options to the % operator. This test shows an inconsistencies in the behavior between fix and sci; and between fpformat and %. I'm not sure of the original authors' intent, so I'm just testing for the original behavior. This may not be best. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-19 16:05 Message: Logged In: YES user_id=3066 Please adapt this to use unittest. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440290&group_id=5470 From noreply@sourceforge.net Fri Jul 20 01:22:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 17:22:56 -0700 Subject: [Patches] [ python-Patches-440291 ] Test cases for commands.py Message-ID: Patches item #440291, was opened at 2001-07-10 22:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440291&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Test cases for commands.py Initial Comment: Test cases for the commands.py module. These are only tested to work on SunOS and Linux, though they should work on any posix system. (This module needs an overhaul!) ---------------------------------------------------------------------- >Comment By: Nick Mathewson (nickm) Date: 2001-07-19 17:22 Message: Logged In: YES user_id=499 Updated to use unittest module ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440291&group_id=5470 From noreply@sourceforge.net Fri Jul 20 01:24:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 17:24:12 -0700 Subject: [Patches] [ python-Patches-440290 ] Tests for test_fpformat.py Message-ID: Patches item #440290, was opened at 2001-07-10 22:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440290&group_id=5470 Category: None Group: None >Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Tests for test_fpformat.py Initial Comment: Another installment in the series of "Tests for the Testless". This time, we tackle the fpformat.py module, which does almost-but-not-exactly the same thing as certain options to the % operator. This test shows an inconsistencies in the behavior between fix and sci; and between fpformat and %. I'm not sure of the original authors' intent, so I'm just testing for the original behavior. This may not be best. ---------------------------------------------------------------------- >Comment By: Nick Mathewson (nickm) Date: 2001-07-19 17:24 Message: Logged In: YES user_id=499 Updated as requested. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-19 16:05 Message: Logged In: YES user_id=3066 Please adapt this to use unittest. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440290&group_id=5470 From noreply@sourceforge.net Fri Jul 20 01:25:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 17:25:13 -0700 Subject: [Patches] [ python-Patches-440292 ] Test cases for pyclbr.py Message-ID: Patches item #440292, was opened at 2001-07-10 22:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440292&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Test cases for pyclbr.py Initial Comment: These test cases exercise the pyclbr module. They work by comparing the output of pyclbr to the results of module introspection for some of the largest modules in the Python distribution. They also skirt several limitations of pyclbr not mentioned in the BUGS section of pyclbr.py. For example, pyclbr.py does really bad in the presence of the string [ '"""' ]. (This keeps it from handling pydoc.py.) While writing these test cases, I also found a minor bug in pyclbr.py that would prevent it from finding functions (but not classes) declared in other modules. I'm also including a patch for this bug. ---------------------------------------------------------------------- >Comment By: Nick Mathewson (nickm) Date: 2001-07-19 17:25 Message: Logged In: YES user_id=499 Updated to use unittest, and to be generally a bit more legible. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-07-10 22:22 Message: Logged In: YES user_id=499 (More information on the bug: whereas pyclbr.py can notice imports of the format: "from module import class", it wasn't able to handle "from module import fn". Now it can.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440292&group_id=5470 From noreply@sourceforge.net Fri Jul 20 01:26:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 17:26:17 -0700 Subject: [Patches] [ python-Patches-440291 ] Test cases for commands.py Message-ID: Patches item #440291, was opened at 2001-07-10 22:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440291&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Test cases for commands.py Initial Comment: Test cases for the commands.py module. These are only tested to work on SunOS and Linux, though they should work on any posix system. (This module needs an overhaul!) ---------------------------------------------------------------------- >Comment By: Nick Mathewson (nickm) Date: 2001-07-19 17:26 Message: Logged In: YES user_id=499 Oops: forgot to check upload box. Uploading again ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-07-19 17:22 Message: Logged In: YES user_id=499 Updated to use unittest module ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440291&group_id=5470 From noreply@sourceforge.net Fri Jul 20 01:35:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 17:35:20 -0700 Subject: [Patches] [ python-Patches-442866 ] Tests for codeop.py Message-ID: Patches item #442866, was opened at 2001-07-19 12:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442866&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Tests for codeop.py Initial Comment: Another installment of unit tests. This file contains a set of new test cases for the codeop module, which previously had none. ---------------------------------------------------------------------- >Comment By: Nick Mathewson (nickm) Date: 2001-07-19 17:35 Message: Logged In: YES user_id=499 Based on comments for dircache, change test_codeop to _not_ alias compile_command as 'cc'. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442866&group_id=5470 From noreply@sourceforge.net Fri Jul 20 01:57:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 17:57:43 -0700 Subject: [Patches] [ python-Patches-415331 ] add setacl/getacl to imaplib Message-ID: Patches item #415331, was opened at 2001-04-10 23:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415331&group_id=5470 >Category: library Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Piers Lauder (pierslauder) Summary: add setacl/getacl to imaplib Initial Comment: Cyrus IMAP stores support the SETACL and GETACL commands. This patch add support for these to imaplib.py ---------------------------------------------------------------------- >Comment By: Piers Lauder (pierslauder) Date: 2001-07-19 17:57 Message: Logged In: YES user_id=196212 Incorporated into subsequent patch. ---------------------------------------------------------------------- Comment By: Piers Lauder (pierslauder) Date: 2001-04-15 04:58 Message: Logged In: YES user_id=196212 I've incorporated this patch into my imaplib patch, submitted a few moments ago. (I've also documented it :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-13 08:45 Message: Logged In: YES user_id=6380 I've forwarded this to Piers Lauder, imaplib's author. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415331&group_id=5470 From noreply@sourceforge.net Fri Jul 20 11:55:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 03:55:59 -0700 Subject: [Patches] [ python-Patches-416253 ] additions to imaplib Message-ID: Patches item #416253, was opened at 2001-04-15 04:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416253&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Piers Lauder (pierslauder) Assigned to: Piers Lauder (pierslauder) Summary: additions to imaplib Initial Comment: This patch adds some new methods: GET/SETACL (submitted by Anthony Baxter); SORT (IMAP4rev1 extension); and some overridable methods to complete the ability to override all I/O. There are also some code cleanups (I've changed the evals into getattrs). The documentation changes for the new methods are submitted as a separate patch. ---------------------------------------------------------------------- >Comment By: Piers Lauder (pierslauder) Date: 2001-07-20 03:55 Message: Logged In: YES user_id=196212 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416253&group_id=5470 From noreply@sourceforge.net Fri Jul 20 12:05:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 04:05:31 -0700 Subject: [Patches] [ python-Patches-416254 ] documentation for new imaplib methods Message-ID: Patches item #416254, was opened at 2001-04-15 04:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416254&group_id=5470 Category: documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Piers Lauder (pierslauder) Assigned to: Piers Lauder (pierslauder) Summary: documentation for new imaplib methods Initial Comment: This patch is against the current copy of dist/src/Doc/lib/libimaplib.tex and documents the new methods contained in my earlier imaplib patch. ---------------------------------------------------------------------- >Comment By: Piers Lauder (pierslauder) Date: 2001-07-20 04:05 Message: Logged In: YES user_id=196212 Patch applied. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416254&group_id=5470 From noreply@sourceforge.net Fri Jul 20 16:27:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 08:27:42 -0700 Subject: [Patches] [ python-Patches-442983 ] site.py rev 1.28 broke addsitedir() Message-ID: Patches item #442983, was opened at 2001-07-19 23:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442983&group_id=5470 >Category: None Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) >Assigned to: Nobody/Anonymous (nobody) Summary: site.py rev 1.28 broke addsitedir() Initial Comment: addsitedir() was changed to refer to global dirs_in_sys_path, but that global got explictly del'ed on line 152 too, so it doesn't exist when addsitedir() is called. Report from c.l.py follows: """ From: David Konerding Sent: Friday, July 20, 2001 1:56 AM To: python-list@python.org Subject: python 2.1.1 trouble with addsitedir Hi, I am checking my application's compatibility wiht 2.1.1 and I've run into a snag. We use "site.addsitedir" to add a directory to the loading path. As an example, the following works just fine on Python- 2.1: [dek@tolkien dek]$ python Python 2.1 (#2, Jul 19 2001, 20:48:59) [GCC 2.95.3 20010315 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import site >>> site.addsitedir("/tmp") >>> but running it with 2.1.1 gives the following: [dek@tolkien Python-2.1.1c1] $ /var/tmp/python/bin/python Python 2.1.1c1 (#1, Jul 19 2001, 22:49:25) [GCC 2.95.3 20010315 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import site >>> site.addsitedir("/tmp") Traceback (most recent call last): File "", line 1, in ? File "/var/tmp/python/lib/python2.1/site.py", line 100, in addsitedir if not dirs_in_sys_path.has_key(sitedircase): NameError: global name 'dirs_in_sys_path' is not defined """ ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-20 08:27 Message: Logged In: YES user_id=3066 After talking to Guido about this, agreed to let it ride for Python 2.1.1, but 2.2 should be more robust if we want to support making add*() publically available functions. I've attached a patch that does what I think is the right thing; still needs documentation. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-20 08:12 Message: Logged In: YES user_id=3066 I don't think that's the right fix. (In fact, I was about to check in the right fix, and encountered a conflict with yours -- the lack of reasonably quick email through digicool.com is a problem.) Specifically, just letting the dirs_in_sys_path value sit around assumes that the only use code which manipulates sys.path uses the helpers in site.py, which is a bad assumption given that these are undocumented. It is better to reset the dictionary to None and force it to be rebuilt for external calls. This way it doesn't break when other modules manipulate sys.path. Re-opening pending discussion -- keep it in the tracker so we can all see it! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 08:04 Message: Logged In: YES user_id=6380 I've fixed this by removing the 'del dirs_in_sys_path' line, both in 2.1.1 and in 2.2 (on the trunk). This fix will make it into the 2.1.1 release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442983&group_id=5470 From noreply@sourceforge.net Fri Jul 20 19:01:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 11:01:22 -0700 Subject: [Patches] [ python-Patches-442863 ] Add switch to disable PYTHON{HOME,PATH} Message-ID: Patches item #442863, was opened at 2001-07-19 12:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442863&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Guido van Rossum (gvanrossum) Summary: Add switch to disable PYTHON{HOME,PATH} Initial Comment: This patch adds the -E command line switch. When specified, the PYTHONHOME and PYTHONPATH environment variables are ignored. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-07-20 11:01 Message: Logged In: YES user_id=35752 Okay, here's an updated patch the adds a -E option which suppresses all PYTHON* environment variables. Suggestions for improvements welcome. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-07-19 14:14 Message: Logged In: YES user_id=35752 -E only suppress PYTHONHOME and PYTHONPATH. Are you sure about suppressing them all? There are quite a few (around 8). PYTHONHOME and PYTHONPATH seem to be the only ones that cause real trouble. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 13:37 Message: Logged In: YES user_id=6380 Cool, Neil! Nits: - The Makefile uses "-Ec" somewhere; I recommend to use "-E -c" instead. - Does -E suppress PYTHONSTARTUP or doesn't it? The comments are inconsistent with the help message. I think it should suppress *all* use of Python-specific environment variables. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442863&group_id=5470 From noreply@sourceforge.net Fri Jul 20 20:07:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 12:07:05 -0700 Subject: [Patches] [ python-Patches-442863 ] Add switch to disable PYTHON{HOME,PATH} Message-ID: Patches item #442863, was opened at 2001-07-19 12:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442863&group_id=5470 Category: None Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Neil Schemenauer (nascheme) Summary: Add switch to disable PYTHON{HOME,PATH} Initial Comment: This patch adds the -E command line switch. When specified, the PYTHONHOME and PYTHONPATH environment variables are ignored. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 12:07 Message: Logged In: YES user_id=6380 Very nice, Neil. Check it in please! Typo: the man page patch has a reference to PYTHOHHOME... ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-07-20 11:01 Message: Logged In: YES user_id=35752 Okay, here's an updated patch the adds a -E option which suppresses all PYTHON* environment variables. Suggestions for improvements welcome. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-07-19 14:14 Message: Logged In: YES user_id=35752 -E only suppress PYTHONHOME and PYTHONPATH. Are you sure about suppressing them all? There are quite a few (around 8). PYTHONHOME and PYTHONPATH seem to be the only ones that cause real trouble. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 13:37 Message: Logged In: YES user_id=6380 Cool, Neil! Nits: - The Makefile uses "-Ec" somewhere; I recommend to use "-E -c" instead. - Does -E suppress PYTHONSTARTUP or doesn't it? The comments are inconsistent with the help message. I think it should suppress *all* use of Python-specific environment variables. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442863&group_id=5470 From noreply@sourceforge.net Fri Jul 20 20:10:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 12:10:05 -0700 Subject: [Patches] [ python-Patches-429442 ] Cygwin sys.platform/get_platform() patch Message-ID: Patches item #429442, was opened at 2001-06-01 13:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429442&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Greg Ward (gward) Summary: Cygwin sys.platform/get_platform() patch Initial Comment: This patch corrects sys.platform and distutils.util.get_platform() problems caused by the cruft contained in Cygwin's uname -s. Please see the following for the gory details: http://www.cygwin.com/ml/cygwin-apps/2001-05/msg00106.html Note that the above also solicited input from the community in an attempt to prevent any potential heartache. Since no one responded it would appear that either the changes are acceptable or that no one really cares... :,) ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2001-07-20 12:10 Message: Logged In: YES user_id=86216 I noticed that Python 2.2a1 has been released. I have had requests from Cygwin Python users for this patch and I would very much like to get it into Python 2.2. Greg, if you are too busy to evaluate this patch, then please reassign it to someone else who has more cycles. Thanks. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-07-10 06:53 Message: Logged In: YES user_id=86216 Any status? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-06-07 13:00 Message: Logged In: YES user_id=31435 Assigned to GregW. Greg, note that since Cygwin is really a Unix derivative, your primary concern is probably just that this doesn't break other Unixoid systems. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429442&group_id=5470 From noreply@sourceforge.net Fri Jul 20 20:13:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 12:13:47 -0700 Subject: [Patches] [ python-Patches-429442 ] Cygwin sys.platform/get_platform() patch Message-ID: Patches item #429442, was opened at 2001-06-01 13:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429442&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) >Assigned to: A.M. Kuchling (akuchling) Summary: Cygwin sys.platform/get_platform() patch Initial Comment: This patch corrects sys.platform and distutils.util.get_platform() problems caused by the cruft contained in Cygwin's uname -s. Please see the following for the gory details: http://www.cygwin.com/ml/cygwin-apps/2001-05/msg00106.html Note that the above also solicited input from the community in an attempt to prevent any potential heartache. Since no one responded it would appear that either the changes are acceptable or that no one really cares... :,) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 12:13 Message: Logged In: YES user_id=6380 Reassigned to Andrew, he seems to be taking care of distutils of late. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-07-20 12:10 Message: Logged In: YES user_id=86216 I noticed that Python 2.2a1 has been released. I have had requests from Cygwin Python users for this patch and I would very much like to get it into Python 2.2. Greg, if you are too busy to evaluate this patch, then please reassign it to someone else who has more cycles. Thanks. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-07-10 06:53 Message: Logged In: YES user_id=86216 Any status? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-06-07 13:00 Message: Logged In: YES user_id=31435 Assigned to GregW. Greg, note that since Cygwin is really a Unix derivative, your primary concern is probably just that this doesn't break other Unixoid systems. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429442&group_id=5470 From noreply@sourceforge.net Fri Jul 20 20:41:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 12:41:59 -0700 Subject: [Patches] [ python-Patches-441791 ] Improvment to package import semantics Message-ID: Patches item #441791, was opened at 2001-07-16 12:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441791&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Coventry (alex_coventry) Assigned to: Nobody/Anonymous (nobody) Summary: Improvment to package import semantics Initial Comment: I think it's nice to be able to do this: >>> import sys >>> sys.path.append('/l/alex_c/') >>> import mouse.foo Traceback (most recent call last): File "", line 1, in ? File "/l/alex_c/mouse/foo.py", line 1, in ? bar NameError: name 'bar' is not defined >>> import mouse.foo >>> reload(mouse.foo) # Works now that foo.py is corrected >>> from mouse import foo >>> foo.bar 1 However, at the moment, that's not possible, because if an error occurs in the loading of foo, foo is not added to mouse's dictionary, even though the module added to sys.modules under the key 'mouse.foo'. This has been driving me nuts, because I have large datasets that I need to load in each time I start python up, so I tend to test my scripts in a single interactive interpreter as I write them, so it's important for me to be able to reliably reload modules. I think it's also a sensible way for things to work in general, too. If there's enough controversy about this, I can write a PEP about it, or something. At any rate, here's a patch against the current CVS repository that changes the semantics as I've described. Alex. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 12:41 Message: Logged In: YES user_id=6380 I've added a streamlined version that deals with the error handling a bit differently, and conforms to the C style guide (PEP 7). ---------------------------------------------------------------------- Comment By: Alex Coventry (alex_coventry) Date: 2001-07-19 15:21 Message: Logged In: YES user_id=49686 Hi, I've looked for pertinent thread in the python-dev archive, but I've been unable to find one. I've searched for keywords "import.c", "import_submodule", "reload", and lastly "package import", although I might have missed a thread matching that, as there were over a hundred hits. Could you point me at a thread? Alex. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-17 02:00 Message: Logged In: YES user_id=34209 This is not a 2.0.1 bugfix candidate, or any bugfix candidate. Group changed. This is also a subject of occasional discussion on python-dev, see the archives ;P ---------------------------------------------------------------------- Comment By: Alex Coventry (alex_coventry) Date: 2001-07-16 12:42 Message: Logged In: YES user_id=49686 a) Sorry about the duplicate submission b) I attached the patch I'm proposing to it, but can't see it on this page. Here it is, just in case: Index: Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.178 diff -c -r2.178 import.c *** Python/import.c 2001/07/05 03:47:53 2.178 --- Python/import.c 2001/07/16 19:04:05 *************** *** 1789,1795 **** import_submodule(PyObject *mod, char *subname, char *fullname) { PyObject *modules = PyImport_GetModuleDict(); ! PyObject *m; /* Require: if mod == None: subname == fullname --- 1789,1795 ---- import_submodule(PyObject *mod, char *subname, char *fullname) { PyObject *modules = PyImport_GetModuleDict(); ! PyObject *m, *resulting_module=NULL; /* Require: if mod == None: subname == fullname *************** *** 1829,1839 **** m = load_module(fullname, fp, buf, fdp->type); if (fp) fclose(fp); ! if (m != NULL && mod != Py_None) { ! if (PyObject_SetAttrString(mod, subname, m) < 0) { ! Py_DECREF(m); ! m = NULL; ! } } } --- 1829,1864 ---- m = load_module(fullname, fp, buf, fdp->type); if (fp) fclose(fp); ! if (mod != Py_None) { ! ! /* Irrespective of the success of this load, make a ! reference to it in the parent package module. */ ! ! /* ...a copy gets saved in the modules dictionary ! under the full name, so get a reference from ! there, if need be. */ ! if (m == NULL) { ! resulting_module = PyDict_GetItemString(modules, ! fullname); ! if (resulting_module == NULL) { ! ! /* ...failed to find the module under its full ! name; oops */ ! PyErr_Format(PyExc_SystemError, ! "Failed to create a sys.modules " \ ! "entry under %.200s", fullname); ! return NULL; ! } ! } else { ! resulting_module = m; ! } ! ! if (PyObject_SetAttrString(mod, subname, resulting_module) < 0) { ! if (m != NULL) { ! Py_DECREF(m); ! m = NULL; ! } ! } } } ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441791&group_id=5470 From noreply@sourceforge.net Fri Jul 20 20:43:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 12:43:45 -0700 Subject: [Patches] [ python-Patches-429442 ] Cygwin sys.platform/get_platform() patch Message-ID: Patches item #429442, was opened at 2001-06-01 13:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429442&group_id=5470 Category: distutils Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: A.M. Kuchling (akuchling) Summary: Cygwin sys.platform/get_platform() patch Initial Comment: This patch corrects sys.platform and distutils.util.get_platform() problems caused by the cruft contained in Cygwin's uname -s. Please see the following for the gory details: http://www.cygwin.com/ml/cygwin-apps/2001-05/msg00106.html Note that the above also solicited input from the community in an attempt to prevent any potential heartache. Since no one responded it would appear that either the changes are acceptable or that no one really cares... :,) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-07-20 12:43 Message: Logged In: YES user_id=11375 Accepted and checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 12:13 Message: Logged In: YES user_id=6380 Reassigned to Andrew, he seems to be taking care of distutils of late. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-07-20 12:10 Message: Logged In: YES user_id=86216 I noticed that Python 2.2a1 has been released. I have had requests from Cygwin Python users for this patch and I would very much like to get it into Python 2.2. Greg, if you are too busy to evaluate this patch, then please reassign it to someone else who has more cycles. Thanks. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-07-10 06:53 Message: Logged In: YES user_id=86216 Any status? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-06-07 13:00 Message: Logged In: YES user_id=31435 Assigned to GregW. Greg, note that since Cygwin is really a Unix derivative, your primary concern is probably just that this doesn't break other Unixoid systems. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429442&group_id=5470 From noreply@sourceforge.net Fri Jul 20 20:47:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 12:47:54 -0700 Subject: [Patches] [ python-Patches-441791 ] Improvment to package import semantics Message-ID: Patches item #441791, was opened at 2001-07-16 12:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441791&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Coventry (alex_coventry) Assigned to: Nobody/Anonymous (nobody) Summary: Improvment to package import semantics Initial Comment: I think it's nice to be able to do this: >>> import sys >>> sys.path.append('/l/alex_c/') >>> import mouse.foo Traceback (most recent call last): File "", line 1, in ? File "/l/alex_c/mouse/foo.py", line 1, in ? bar NameError: name 'bar' is not defined >>> import mouse.foo >>> reload(mouse.foo) # Works now that foo.py is corrected >>> from mouse import foo >>> foo.bar 1 However, at the moment, that's not possible, because if an error occurs in the loading of foo, foo is not added to mouse's dictionary, even though the module added to sys.modules under the key 'mouse.foo'. This has been driving me nuts, because I have large datasets that I need to load in each time I start python up, so I tend to test my scripts in a single interactive interpreter as I write them, so it's important for me to be able to reliably reload modules. I think it's also a sensible way for things to work in general, too. If there's enough controversy about this, I can write a PEP about it, or something. At any rate, here's a patch against the current CVS repository that changes the semantics as I've described. Alex. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 12:47 Message: Logged In: YES user_id=6380 Notice that when the module fails with a SyntaxError, my patch does nothing. propagating the SyntaxError normally, while the original error raised a SystemError, masking the SyntaxError. Clearly that was wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 12:41 Message: Logged In: YES user_id=6380 I've added a streamlined version that deals with the error handling a bit differently, and conforms to the C style guide (PEP 7). ---------------------------------------------------------------------- Comment By: Alex Coventry (alex_coventry) Date: 2001-07-19 15:21 Message: Logged In: YES user_id=49686 Hi, I've looked for pertinent thread in the python-dev archive, but I've been unable to find one. I've searched for keywords "import.c", "import_submodule", "reload", and lastly "package import", although I might have missed a thread matching that, as there were over a hundred hits. Could you point me at a thread? Alex. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-17 02:00 Message: Logged In: YES user_id=34209 This is not a 2.0.1 bugfix candidate, or any bugfix candidate. Group changed. This is also a subject of occasional discussion on python-dev, see the archives ;P ---------------------------------------------------------------------- Comment By: Alex Coventry (alex_coventry) Date: 2001-07-16 12:42 Message: Logged In: YES user_id=49686 a) Sorry about the duplicate submission b) I attached the patch I'm proposing to it, but can't see it on this page. Here it is, just in case: Index: Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.178 diff -c -r2.178 import.c *** Python/import.c 2001/07/05 03:47:53 2.178 --- Python/import.c 2001/07/16 19:04:05 *************** *** 1789,1795 **** import_submodule(PyObject *mod, char *subname, char *fullname) { PyObject *modules = PyImport_GetModuleDict(); ! PyObject *m; /* Require: if mod == None: subname == fullname --- 1789,1795 ---- import_submodule(PyObject *mod, char *subname, char *fullname) { PyObject *modules = PyImport_GetModuleDict(); ! PyObject *m, *resulting_module=NULL; /* Require: if mod == None: subname == fullname *************** *** 1829,1839 **** m = load_module(fullname, fp, buf, fdp->type); if (fp) fclose(fp); ! if (m != NULL && mod != Py_None) { ! if (PyObject_SetAttrString(mod, subname, m) < 0) { ! Py_DECREF(m); ! m = NULL; ! } } } --- 1829,1864 ---- m = load_module(fullname, fp, buf, fdp->type); if (fp) fclose(fp); ! if (mod != Py_None) { ! ! /* Irrespective of the success of this load, make a ! reference to it in the parent package module. */ ! ! /* ...a copy gets saved in the modules dictionary ! under the full name, so get a reference from ! there, if need be. */ ! if (m == NULL) { ! resulting_module = PyDict_GetItemString(modules, ! fullname); ! if (resulting_module == NULL) { ! ! /* ...failed to find the module under its full ! name; oops */ ! PyErr_Format(PyExc_SystemError, ! "Failed to create a sys.modules " \ ! "entry under %.200s", fullname); ! return NULL; ! } ! } else { ! resulting_module = m; ! } ! ! if (PyObject_SetAttrString(mod, subname, resulting_module) < 0) { ! if (m != NULL) { ! Py_DECREF(m); ! m = NULL; ! } ! } } } ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441791&group_id=5470 From noreply@sourceforge.net Fri Jul 20 21:05:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 13:05:52 -0700 Subject: [Patches] [ python-Patches-429442 ] Cygwin sys.platform/get_platform() patch Message-ID: Patches item #429442, was opened at 2001-06-01 13:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429442&group_id=5470 Category: distutils Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: A.M. Kuchling (akuchling) Summary: Cygwin sys.platform/get_platform() patch Initial Comment: This patch corrects sys.platform and distutils.util.get_platform() problems caused by the cruft contained in Cygwin's uname -s. Please see the following for the gory details: http://www.cygwin.com/ml/cygwin-apps/2001-05/msg00106.html Note that the above also solicited input from the community in an attempt to prevent any potential heartache. Since no one responded it would appear that either the changes are acceptable or that no one really cares... :,) ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2001-07-20 13:05 Message: Logged In: YES user_id=86216 Thanks for the speedy response -- it is much appreciated! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-07-20 12:43 Message: Logged In: YES user_id=11375 Accepted and checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 12:13 Message: Logged In: YES user_id=6380 Reassigned to Andrew, he seems to be taking care of distutils of late. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-07-20 12:10 Message: Logged In: YES user_id=86216 I noticed that Python 2.2a1 has been released. I have had requests from Cygwin Python users for this patch and I would very much like to get it into Python 2.2. Greg, if you are too busy to evaluate this patch, then please reassign it to someone else who has more cycles. Thanks. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-07-10 06:53 Message: Logged In: YES user_id=86216 Any status? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-06-07 13:00 Message: Logged In: YES user_id=31435 Assigned to GregW. Greg, note that since Cygwin is really a Unix derivative, your primary concern is probably just that this doesn't break other Unixoid systems. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429442&group_id=5470 From noreply@sourceforge.net Fri Jul 20 21:07:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 13:07:46 -0700 Subject: [Patches] [ python-Patches-442983 ] site.py rev 1.28 broke addsitedir() Message-ID: Patches item #442983, was opened at 2001-07-19 23:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442983&group_id=5470 >Category: library Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: site.py rev 1.28 broke addsitedir() Initial Comment: addsitedir() was changed to refer to global dirs_in_sys_path, but that global got explictly del'ed on line 152 too, so it doesn't exist when addsitedir() is called. Report from c.l.py follows: """ From: David Konerding Sent: Friday, July 20, 2001 1:56 AM To: python-list@python.org Subject: python 2.1.1 trouble with addsitedir Hi, I am checking my application's compatibility wiht 2.1.1 and I've run into a snag. We use "site.addsitedir" to add a directory to the loading path. As an example, the following works just fine on Python- 2.1: [dek@tolkien dek]$ python Python 2.1 (#2, Jul 19 2001, 20:48:59) [GCC 2.95.3 20010315 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import site >>> site.addsitedir("/tmp") >>> but running it with 2.1.1 gives the following: [dek@tolkien Python-2.1.1c1] $ /var/tmp/python/bin/python Python 2.1.1c1 (#1, Jul 19 2001, 22:49:25) [GCC 2.95.3 20010315 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import site >>> site.addsitedir("/tmp") Traceback (most recent call last): File "", line 1, in ? File "/var/tmp/python/lib/python2.1/site.py", line 100, in addsitedir if not dirs_in_sys_path.has_key(sitedircase): NameError: global name 'dirs_in_sys_path' is not defined """ ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-20 13:07 Message: Logged In: YES user_id=3066 Checked in as Lib/site.py revision 1.32. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-20 08:27 Message: Logged In: YES user_id=3066 After talking to Guido about this, agreed to let it ride for Python 2.1.1, but 2.2 should be more robust if we want to support making add*() publically available functions. I've attached a patch that does what I think is the right thing; still needs documentation. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-20 08:12 Message: Logged In: YES user_id=3066 I don't think that's the right fix. (In fact, I was about to check in the right fix, and encountered a conflict with yours -- the lack of reasonably quick email through digicool.com is a problem.) Specifically, just letting the dirs_in_sys_path value sit around assumes that the only use code which manipulates sys.path uses the helpers in site.py, which is a bad assumption given that these are undocumented. It is better to reset the dictionary to None and force it to be rebuilt for external calls. This way it doesn't break when other modules manipulate sys.path. Re-opening pending discussion -- keep it in the tracker so we can all see it! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 08:04 Message: Logged In: YES user_id=6380 I've fixed this by removing the 'del dirs_in_sys_path' line, both in 2.1.1 and in 2.2 (on the trunk). This fix will make it into the 2.1.1 release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442983&group_id=5470 From noreply@sourceforge.net Fri Jul 20 21:10:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 13:10:56 -0700 Subject: [Patches] [ python-Patches-442983 ] site.py rev 1.28 broke addsitedir() Message-ID: Patches item #442983, was opened at 2001-07-19 23:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442983&group_id=5470 Category: library Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: site.py rev 1.28 broke addsitedir() Initial Comment: addsitedir() was changed to refer to global dirs_in_sys_path, but that global got explictly del'ed on line 152 too, so it doesn't exist when addsitedir() is called. Report from c.l.py follows: """ From: David Konerding Sent: Friday, July 20, 2001 1:56 AM To: python-list@python.org Subject: python 2.1.1 trouble with addsitedir Hi, I am checking my application's compatibility wiht 2.1.1 and I've run into a snag. We use "site.addsitedir" to add a directory to the loading path. As an example, the following works just fine on Python- 2.1: [dek@tolkien dek]$ python Python 2.1 (#2, Jul 19 2001, 20:48:59) [GCC 2.95.3 20010315 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import site >>> site.addsitedir("/tmp") >>> but running it with 2.1.1 gives the following: [dek@tolkien Python-2.1.1c1] $ /var/tmp/python/bin/python Python 2.1.1c1 (#1, Jul 19 2001, 22:49:25) [GCC 2.95.3 20010315 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import site >>> site.addsitedir("/tmp") Traceback (most recent call last): File "", line 1, in ? File "/var/tmp/python/lib/python2.1/site.py", line 100, in addsitedir if not dirs_in_sys_path.has_key(sitedircase): NameError: global name 'dirs_in_sys_path' is not defined """ ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 13:10 Message: Logged In: YES user_id=6380 David Konerding, please check if your code works with Fred's latest version. If you can't access CVS, try viewcvs: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Lib/site.py?rev=1.32&content-type=text/vnd.viewcvs-markup ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-20 13:07 Message: Logged In: YES user_id=3066 Checked in as Lib/site.py revision 1.32. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-20 08:27 Message: Logged In: YES user_id=3066 After talking to Guido about this, agreed to let it ride for Python 2.1.1, but 2.2 should be more robust if we want to support making add*() publically available functions. I've attached a patch that does what I think is the right thing; still needs documentation. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-20 08:12 Message: Logged In: YES user_id=3066 I don't think that's the right fix. (In fact, I was about to check in the right fix, and encountered a conflict with yours -- the lack of reasonably quick email through digicool.com is a problem.) Specifically, just letting the dirs_in_sys_path value sit around assumes that the only use code which manipulates sys.path uses the helpers in site.py, which is a bad assumption given that these are undocumented. It is better to reset the dictionary to None and force it to be rebuilt for external calls. This way it doesn't break when other modules manipulate sys.path. Re-opening pending discussion -- keep it in the tracker so we can all see it! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 08:04 Message: Logged In: YES user_id=6380 I've fixed this by removing the 'del dirs_in_sys_path' line, both in 2.1.1 and in 2.2 (on the trunk). This fix will make it into the 2.1.1 release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442983&group_id=5470 From noreply@sourceforge.net Fri Jul 20 22:51:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 14:51:48 -0700 Subject: [Patches] [ python-Patches-405952 ] cmd.py uses raw_input(); eats SIGCLD Message-ID: Patches item #405952, was opened at 2001-03-04 23:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405952&group_id=5470 Category: library Group: None >Status: Open Resolution: Accepted Priority: 6 Submitted By: Anthony Baxter (anthony_baxter) Assigned to: Guido van Rossum (gvanrossum) Summary: cmd.py uses raw_input(); eats SIGCLD Initial Comment: I discovered a rather nasty side effect of the standard cmd.py library today. If it's sitting inside raw_input(), any SIGCLDs that get sent to your application get silently eaten and ignored. I'm assuming that this is something that readline is thoughtfully doing for me. This patch adds an instance attr that allows the user to select to not use raw_input(), but instead use sys.stdin.readline() ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-22 15:22 Message: Logged In: YES user_id=6656 nag, nag. the docs will get updated before 2.1, right? (not by me!) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-22 13:59 Message: Logged In: YES user_id=6380 OK, applied, ready for 2.1b2. I changed the try/except to only cover the raw_input() call. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405952&group_id=5470 From noreply@sourceforge.net Fri Jul 20 22:54:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 14:54:03 -0700 Subject: [Patches] [ python-Patches-441791 ] Improvment to package import semantics Message-ID: Patches item #441791, was opened at 2001-07-16 12:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441791&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Coventry (alex_coventry) Assigned to: Nobody/Anonymous (nobody) Summary: Improvment to package import semantics Initial Comment: I think it's nice to be able to do this: >>> import sys >>> sys.path.append('/l/alex_c/') >>> import mouse.foo Traceback (most recent call last): File "", line 1, in ? File "/l/alex_c/mouse/foo.py", line 1, in ? bar NameError: name 'bar' is not defined >>> import mouse.foo >>> reload(mouse.foo) # Works now that foo.py is corrected >>> from mouse import foo >>> foo.bar 1 However, at the moment, that's not possible, because if an error occurs in the loading of foo, foo is not added to mouse's dictionary, even though the module added to sys.modules under the key 'mouse.foo'. This has been driving me nuts, because I have large datasets that I need to load in each time I start python up, so I tend to test my scripts in a single interactive interpreter as I write them, so it's important for me to be able to reliably reload modules. I think it's also a sensible way for things to work in general, too. If there's enough controversy about this, I can write a PEP about it, or something. At any rate, here's a patch against the current CVS repository that changes the semantics as I've described. Alex. ---------------------------------------------------------------------- >Comment By: Alex Coventry (alex_coventry) Date: 2001-07-20 14:54 Message: Logged In: YES user_id=49686 Thanks for the corrections. For what it's worth, here's the unit test I have in my code for this change, along with something to catch the SyntaxError error, not that anyone else is likely to make that mistake:) Alex ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 12:47 Message: Logged In: YES user_id=6380 Notice that when the module fails with a SyntaxError, my patch does nothing. propagating the SyntaxError normally, while the original error raised a SystemError, masking the SyntaxError. Clearly that was wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 12:41 Message: Logged In: YES user_id=6380 I've added a streamlined version that deals with the error handling a bit differently, and conforms to the C style guide (PEP 7). ---------------------------------------------------------------------- Comment By: Alex Coventry (alex_coventry) Date: 2001-07-19 15:21 Message: Logged In: YES user_id=49686 Hi, I've looked for pertinent thread in the python-dev archive, but I've been unable to find one. I've searched for keywords "import.c", "import_submodule", "reload", and lastly "package import", although I might have missed a thread matching that, as there were over a hundred hits. Could you point me at a thread? Alex. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-17 02:00 Message: Logged In: YES user_id=34209 This is not a 2.0.1 bugfix candidate, or any bugfix candidate. Group changed. This is also a subject of occasional discussion on python-dev, see the archives ;P ---------------------------------------------------------------------- Comment By: Alex Coventry (alex_coventry) Date: 2001-07-16 12:42 Message: Logged In: YES user_id=49686 a) Sorry about the duplicate submission b) I attached the patch I'm proposing to it, but can't see it on this page. Here it is, just in case: Index: Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.178 diff -c -r2.178 import.c *** Python/import.c 2001/07/05 03:47:53 2.178 --- Python/import.c 2001/07/16 19:04:05 *************** *** 1789,1795 **** import_submodule(PyObject *mod, char *subname, char *fullname) { PyObject *modules = PyImport_GetModuleDict(); ! PyObject *m; /* Require: if mod == None: subname == fullname --- 1789,1795 ---- import_submodule(PyObject *mod, char *subname, char *fullname) { PyObject *modules = PyImport_GetModuleDict(); ! PyObject *m, *resulting_module=NULL; /* Require: if mod == None: subname == fullname *************** *** 1829,1839 **** m = load_module(fullname, fp, buf, fdp->type); if (fp) fclose(fp); ! if (m != NULL && mod != Py_None) { ! if (PyObject_SetAttrString(mod, subname, m) < 0) { ! Py_DECREF(m); ! m = NULL; ! } } } --- 1829,1864 ---- m = load_module(fullname, fp, buf, fdp->type); if (fp) fclose(fp); ! if (mod != Py_None) { ! ! /* Irrespective of the success of this load, make a ! reference to it in the parent package module. */ ! ! /* ...a copy gets saved in the modules dictionary ! under the full name, so get a reference from ! there, if need be. */ ! if (m == NULL) { ! resulting_module = PyDict_GetItemString(modules, ! fullname); ! if (resulting_module == NULL) { ! ! /* ...failed to find the module under its full ! name; oops */ ! PyErr_Format(PyExc_SystemError, ! "Failed to create a sys.modules " \ ! "entry under %.200s", fullname); ! return NULL; ! } ! } else { ! resulting_module = m; ! } ! ! if (PyObject_SetAttrString(mod, subname, resulting_module) < 0) { ! if (m != NULL) { ! Py_DECREF(m); ! m = NULL; ! } ! } } } ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441791&group_id=5470 From noreply@sourceforge.net Fri Jul 20 22:57:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 14:57:29 -0700 Subject: [Patches] [ python-Patches-405952 ] cmd.py uses raw_input(); eats SIGCLD Message-ID: Patches item #405952, was opened at 2001-03-04 23:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405952&group_id=5470 Category: library Group: None >Status: Closed Resolution: Accepted Priority: 6 Submitted By: Anthony Baxter (anthony_baxter) Assigned to: Guido van Rossum (gvanrossum) Summary: cmd.py uses raw_input(); eats SIGCLD Initial Comment: I discovered a rather nasty side effect of the standard cmd.py library today. If it's sitting inside raw_input(), any SIGCLDs that get sent to your application get silently eaten and ignored. I'm assuming that this is something that readline is thoughtfully doing for me. This patch adds an instance attr that allows the user to select to not use raw_input(), but instead use sys.stdin.readline() ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 14:57 Message: Logged In: YES user_id=6380 This was indeed documented. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-22 15:22 Message: Logged In: YES user_id=6656 nag, nag. the docs will get updated before 2.1, right? (not by me!) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-22 13:59 Message: Logged In: YES user_id=6380 OK, applied, ready for 2.1b2. I changed the try/except to only cover the raw_input() call. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405952&group_id=5470 From noreply@sourceforge.net Sat Jul 21 06:45:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 22:45:15 -0700 Subject: [Patches] [ python-Patches-440826 ] Tests for repr.py Message-ID: Patches item #440826, was opened at 2001-07-12 13:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440826&group_id=5470 Category: library Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Tests for repr.py Initial Comment: Here are some unittests for the repr.py module. These are in line with the unit tests I've been writing over the past few days, except that these use the unittest.py module. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-20 22:45 Message: Logged In: YES user_id=31435 FYI, the new test_repr just caught two long-standing repr.py bugs in descr-branch. "Any test is better than none" . ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-19 15:29 Message: Logged In: YES user_id=3066 Wonderful, thanks! It would be nice to see additional tests added to this to check that changing the max* variables on the Repr instance actually affects the results, but that can be a separate patch. ;-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440826&group_id=5470 From noreply@sourceforge.net Sat Jul 21 15:01:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 21 Jul 2001 07:01:10 -0700 Subject: [Patches] [ python-Patches-443337 ] incompatibilities in imputil's behavior Message-ID: Patches item #443337, was opened at 2001-07-21 07:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443337&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gordon B. McMillan (gmcm) Assigned to: Nobody/Anonymous (nobody) Summary: incompatibilities in imputil's behavior Initial Comment: 1) xml/__init__.py may swap itself for _xmlplus/__init__.py. Under regular mechanism, imports below xml will come from _xmlplus but have xml names in sys.modules and internally. In current imputil, they have _xmlplus names. 2) current imputil does not allow "import os.path". While it's bad practice, the normal import does allow this. "From" file in attached diff is current CVS imputil (1.19). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443337&group_id=5470 From noreply@sourceforge.net Sat Jul 21 19:55:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 21 Jul 2001 11:55:04 -0700 Subject: [Patches] [ python-Patches-401196 ] IPv6 patch against 2.0 CVS tree, as of 20010624 Message-ID: Patches item #401196, was opened at 2000-08-16 05:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401196&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jun-ichiro itojun Hagino (itojun) Assigned to: Martin v. Löwis (loewis) Summary: IPv6 patch against 2.0 CVS tree, as of 20010624 Initial Comment: ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-21 11:55 Message: Logged In: YES user_id=21627 The socketmodule.c part has been committed as socketmodule.c 1.153. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-24 14:59 Message: Logged In: YES user_id=21627 I have uploaded a new version sent by itojun. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-09 12:15 Message: Logged In: YES user_id=21627 On the API, I have the following comments: - Why is it necessary to introduce gethostbyname2? I recommend to give gethostbyname an optional argument for the address family. - getaddrinfo, when raising a socket error, should include the EAI_ error number. Perhaps there should be a way tod istinguish EAI_ errnos from other errnos, e.g. by subclassing socket error. Otherwise, the API of the C part looks good to me. Ih aven't looked at the Lib part, yet. On the implementation: - I still have problems building the code. Currently, I get the following rejects: ./Lib/BaseHTTPServer.py.rej ./Lib/ftplib.py.rej ./Lib/poplib.py.rej ./Lib/smtplib.py.rej ./Modules/socketmodule.c.rej ./Objects/fileobject.c.rej - The fileobject.c chunk seems to be unnecessary. - On the test problem: It occurs in + test -d -a -f /lib.a ./configure: test: too many arguments which comes from ipv6libdir and ipv6libdir being empty. - The WIDE files should be included in the Modules directory, as they are only used from socketmodule.c. In particular, addrinfo.h should not be installed. - If you can, please include a patch to Doc/lib/libsocket.tex. If not, I will try to draft one. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-05-30 10:34 Message: Logged In: NO i looked at python-dev email. the proposal (split patches) looks fine, but the exact example given in python-dev email is not reasonable. i cannot just send out configure.in change separately from source code changes, period. i can split patches for *.py files separately though. there's more important issue, which is, APi changes for Socket class. i really hoped to get some comment on that part. i really appreciate your comments. i would like to propose that once we nailed down API changes, integrate the patch into the tree. with all #ifdef INET6 in place there should be no impact on IPv4-only builds. i have trouble tracking python development (i'm not a sourceforge expert!), so forgive me for delays in patch submissions. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-05-18 08:29 Message: Logged In: YES user_id=6380 See http://mail.python.org/pipermail/python-dev/2001-May/014889.html for comments from MvL. I'm unassigning this from Fred, he has nothing to do with this. ---------------------------------------------------------------------- Comment By: Jun-ichiro itojun Hagino (itojun) Date: 2001-02-26 02:24 Message: Logged In: YES user_id=63767 about /usr/bin/test argument: does linux /usr/bin/test have -d support? if not, we may need to change configure.in slightly. you are correct that fallback getaddrinfo/getnameinfo.c was missing in the patch. sorry. a question i need to ask is, do we need to supply Python function Socket.getaddrinfo on platforms that do not have getaddrinfo(3)? HAVE_ADDRINFO is used in Include/addrinfo.h, which is also missing in the patch set i have submitted. i've put the missing files into http://www.itojun.org/diary/20001230/missing.shar. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-02-23 23:58 Message: After a shallow review of this patch, I found the following issues: configure.in does not need to list both enable and disable options. When running configure, I got the following error message on Linux checking whether to enable ipv6... yes checking ipv6 stack type... linux-glibc ./configure: test: too many arguments using libc The call to /usr/bin/test should be corrected; I could not find out which specific invocation caused the problem. HAVE_ADDRINFO is not used. Perhaps getaddrinfo.c/getnameinfo.c is missing in the patch? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-04 07:51 Message: A new patch is available. I've changed the subject accordingly. Due to upload size restrictions, the patch is now at http://www.itojun.org/diary/20001230/python-2.0-v6-20001230.diff.gz ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2000-12-30 07:25 Message: I got *many* rejects when trying to apply this patch to today's CVS tree. I recommend that patches for generated files (config.h.in, configure) are not included in the patch because they outdate too easily. A number of changes in this patch have already been done by somebody else; others just don't fit into the current code anymore (perhaps due to indentation changes?). Anyway, I'll mark the patch as out-of-date. Please let me know when you upload a new version. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-08-16 07:00 Message: Postponed until Python 2.1 -- there's not enough time to review this and get it sufficiently tested on enough IPv6-connected platforms in time for 2.0, and we're already in feature freeze. This should go into the tree very quickly once Python 2.0 has been released. Assigned to myself to open it back up after Python 2.0. ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2000-08-16 06:07 Message: Assigned to Tim, since he's in charge of postponing new features. I'm to timid to postpone it myself. ---------------------------------------------------------------------- Comment By: Jun-ichiro itojun Hagino (itojun) Date: 2000-08-16 05:59 Message: this is revised version of patch #101186 (now with my SourceForge accout... i'm not familiar with the system here, so forgive my possible mistake). 1.6b1 patch applied mostly clean to 2.0. It is confirmed that: - 1.6b1 + IPv6 patch works fine on NetBSD 1.4.2 + KAME, and NetBSD 1.5 - 1.6b1 + IPv6 patch works fine on NetBSD 1.4.2 (NOT an IPv6 ready machine) - 2.0 CVS tree + IPv6 patch works fine on NetBSD + KAME forgot to attach the following into the diff - so i attach it (README.v6) here as comment. I have submitted the patch for 1.5.1, 1.5.2 and 1.6b1, all hit a bad timing - bad luck. contact: core@kame.net, or itojun@kame.net --- IPv6-ready python 1.6 KAME Project $KAME: README.v6,v 1.9 2000/08/15 02:40:38 itojun Exp $ This patchkit enables python 1.6 to perform AF_INET6 socket operations. The only affected module is Modules/socketmodule.c. Modules/socketmodule.c In most cases, IPv6 address can be placed where IPv4 address fits. sockaddr sockaddr tuple is formatted as follows: IPv4: (host, port) IPv6: socket class methods always generate (host, port, flowinfo, scopeid). socket class methods will accept 2, 3, or 4 tuple (for backward compatibility). Compatibility warning: Some of the scripts assume that the sockaddr structure is 2 tuple, like: host, port = sock.getpeername() this will fail if you are connected to IPv6 node. socket.getaddrinfo(host, port [, family, socktype, proto, flags]) host: String or None port: String, Int or None family, socktype, proto, flags: Int, can be omitted Perform getaddrinfo(3). Returns List of the following 5 tuple: (family, socktype, proto, canonname, sockaddr) family: Int socktype: Int proto: Int canonname: String sockaddr: sockaddr (see above) See Lib/httplib.py for typical usage on the client side. socket.getnameinfo(sockaddr, flags) sockaddr: sockaddr flags: Int Perform getnameinfo(3). Returns the following 2 tuple: host: String, numeric or hostname depending on flgags port: String, numeric or portname depending on flgags socket.gethostbyname2(host, af) host: String af: Int Performs gethostbyname2(3). Returns numeric address representation for "host". socket.gethostbyaddr(addr) (behavior change if IPv6 support is compiled in) addr: String Performs gethostbyaddr(3). Returns string address representation for "addr". The function can take IPv6 numeric address as well. This behavior is not problematical, because - if you pass numeric "addr" parameter, we can always identify address family for it - return value is string address reprsentation, where IPv6 and IPv4 are not distinguishable. socket.bind(sa), socket.connect(sa) and others. (No behavior change, but be careful) See above for sockaddr format change. With Python "addr" portion of sockaddr (first element) can be string hostname. When the string hostname resolved to numeric address, it will obey address family of the socket (which was specified when socket.socket() was called). If you give some string that does not give matching address family, you will get some error. s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) # this is okay, if 'localhost' resolves to both IPv4/v6 s.connect('localhost', 80) # this is not okay, of course s.connect('::1', 80) # this is not okay, as v6only.kame.net will not resolve to IPv4 s.connect('v6only.kame.net', 80) Lib/httplib.py IPv6 ready. "host" in HTTP(host) will accept the following 3 forms: [host]:port host:port there must be only single colon host This is to allow IPv6 numeric URL (http://[host]:port/) in documents. IMHO "host:port" parsing should be implemented in urllib.py, not here. Lib/ftplib.py IPv6 ready. This uses EPSV/EPRT on IPv6 ftp. See RFC2428 for protocol details. Lib/SocketServer.py IPv6 ready. Wildcard bind on TCPServer, i.e. TCPServer(('', port)), will bind to wildcard socket on TCPServer.address_family. TCPServer.addresss_family is set to AF_INET by default, so ('', port) will usually bind AF_INET. Lib/smtplib.py, Lib/telnetlib.py, Lib/poplib.py IPv6 ready. Not much to say about protocol details - they just use TCP over IPv6. configure Configure has extra option, --enable-ipv6 and --disable-ipv6. The option controls IPv6 support feature. dynamic link issues in Modules/socketmodule.c Modules/socketmodule.c can be dynamically loaded only in the following situations: - getaddrinfo(3) and getnameinfo(3) are supplied by OS vendor in libc, and libc is dynamic link library. - OS vendor is NOT supplying getaddrinfo(3) nor getnameinfo(3), and You are configuring this package with --disable-ipv6. In this case, you'll be using missing/get{addr,name}info.c and they will refer to gethostby{name,addr}. gethostnameby{name,addr} can usually be found in dynamic-linking libc. In other situations, such as the following, please link Modules/socketmodule.c into python itself. - getaddrinfo(3) and getnameinfo(3) are supplied by OS vendor, but they are in statically linked library like libinet6.a. (KAME falls into this category) python usually links Modules/socketmodule.c into python itself (due to its popularity) so there should be no problem. restrictions - The patched tree will not use gethostbyname_r and other thread-ready libraries. Instead, it will use getaddrinfo() and getnameinfo() throughout the operation. todo - Patch bunch of library files in Lib/*.py. compatibility issues with existing scripts If you disable IPv6 support (./configure --disable-ipv6), the patched code is mostly compatible with original Python (except files in "Lib" directory modified for dual stack support). User script may choke if: - IPv4/v6 dualstack libc is supplied, python is compiled for dual stack, and script assumes some of IPv4-only behavior (especially sockaddr) - IPv4/v6 dualstack libc is supplied, python is compiled for IPv4 only, and script assumes some of IPv4-only behavior. In this case, Python socket class itself does not support IPv6, however, name resolution functions can return IPv6 names since they use IPv6-ready libc functions! I do not recommend this configuration. - script assumes certain IPv4-only version behavior in Lib/*.py. compilation If you use IPv6 features, it is assumed that you have working getaddrinfo() and getnameinfo() library functions. We have noticed that some of IPv6 stack is shipped with broken getaddrinfo(). In such cases, use missing/get{addr,name}info.c instead (but then, you need to have working getipnodeby{name,addr}). If you compile this on IPv4-only machine without get{addr,name}info, missing/get{addr,name}info.c will be used. They are from KAME IPv6 distribution and is #ifdef'ed for IPv4 only support. They are fairly complete implementation and you don't need to bother with bind 8.2 (bind 8.2 get{addr,name}info() has bugs). When compiling this kit on IPv6 node, you may need to specify some additional library paths or cpp defs. (like -linet6 or -DINET6) --enable-ipv6 will give you some warning, if the IPv6 stack is unknown to the "configure" script. Currently, the following IPv6 stacks are officially supported (i.e. we've checked that the package works well): - KAME IPv6 stack, http://www.kame.net/ References RFC2553, for getaddrinfo(3) and getnameinfo(3). Author contacts http://www.kame.net/ mailto:core@kame.net ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401196&group_id=5470 From noreply@sourceforge.net Sat Jul 21 21:38:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 21 Jul 2001 13:38:36 -0700 Subject: [Patches] [ python-Patches-440292 ] Test cases for pyclbr.py Message-ID: Patches item #440292, was opened at 2001-07-10 22:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440292&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Test cases for pyclbr.py Initial Comment: These test cases exercise the pyclbr module. They work by comparing the output of pyclbr to the results of module introspection for some of the largest modules in the Python distribution. They also skirt several limitations of pyclbr not mentioned in the BUGS section of pyclbr.py. For example, pyclbr.py does really bad in the presence of the string [ '"""' ]. (This keeps it from handling pydoc.py.) While writing these test cases, I also found a minor bug in pyclbr.py that would prevent it from finding functions (but not classes) declared in other modules. I'm also including a patch for this bug. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-21 13:38 Message: Logged In: YES user_id=3066 The test case doesn't cover the bug fixed in the patch; it should fail if I try it without applying the patch. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-07-19 17:25 Message: Logged In: YES user_id=499 Updated to use unittest, and to be generally a bit more legible. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-07-10 22:22 Message: Logged In: YES user_id=499 (More information on the bug: whereas pyclbr.py can notice imports of the format: "from module import class", it wasn't able to handle "from module import fn". Now it can.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440292&group_id=5470 From noreply@sourceforge.net Sun Jul 22 04:10:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 21 Jul 2001 20:10:48 -0700 Subject: [Patches] [ python-Patches-440292 ] Test cases for pyclbr.py Message-ID: Patches item #440292, was opened at 2001-07-10 22:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440292&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Test cases for pyclbr.py Initial Comment: These test cases exercise the pyclbr module. They work by comparing the output of pyclbr to the results of module introspection for some of the largest modules in the Python distribution. They also skirt several limitations of pyclbr not mentioned in the BUGS section of pyclbr.py. For example, pyclbr.py does really bad in the presence of the string [ '"""' ]. (This keeps it from handling pydoc.py.) While writing these test cases, I also found a minor bug in pyclbr.py that would prevent it from finding functions (but not classes) declared in other modules. I'm also including a patch for this bug. ---------------------------------------------------------------------- >Comment By: Nick Mathewson (nickm) Date: 2001-07-21 20:10 Message: Logged In: YES user_id=499 Well, there were two problems: 1) The test case didn't test the problem I thought it did. 2) The patch didn't fix the problem I thought I was testing! :) I'm uploading new versions of each. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-21 13:38 Message: Logged In: YES user_id=3066 The test case doesn't cover the bug fixed in the patch; it should fail if I try it without applying the patch. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-07-19 17:25 Message: Logged In: YES user_id=499 Updated to use unittest, and to be generally a bit more legible. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-07-10 22:22 Message: Logged In: YES user_id=499 (More information on the bug: whereas pyclbr.py can notice imports of the format: "from module import class", it wasn't able to handle "from module import fn". Now it can.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440292&group_id=5470 From noreply@sourceforge.net Sun Jul 22 05:21:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 21 Jul 2001 21:21:08 -0700 Subject: [Patches] [ python-Patches-443474 ] from __future__ import division Message-ID: Patches item #443474, was opened at 2001-07-21 21:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443474&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: from __future__ import division Initial Comment: This patch is a quick hack to implement one way of doing PEP 238 (non-integer division). There are two parts to it. Part 1: the // operator implements integer division. Part 2: when "from __future__ import division" is in effect, the / operator implements float division. The //= and /= operators are also affected. (This is part of why I chose // over the keyword 'div'; also because that would require a new keyword.) The implementation now has three division operations (of each variation: regular and inplace, and corresponding opcodes) where it used to have one: - Division for / without future statement - FloatDivision for / with future statement - IntDivision for // The actual implementations for IntDivision and FloatDivision are a bit lame: - (old) Division is unchanged (using nb_division) - IntDivision just calls Division, so only does the right thing for ints and longs - FloatDivision adds 0.0 to the second operand At some point in the future, to keep NumPy happy, the "as number" struct should grow extra slots for the additional operations, and the above operations should only be used as fallbacks. (Maybe the fallback for IntDivision should use the nb_divmod slot as fallback.) Enjoy! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443474&group_id=5470 From noreply@sourceforge.net Sun Jul 22 05:39:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 21 Jul 2001 21:39:55 -0700 Subject: [Patches] [ python-Patches-443474 ] from __future__ import division Message-ID: Patches item #443474, was opened at 2001-07-21 21:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443474&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: from __future__ import division Initial Comment: This patch is a quick hack to implement one way of doing PEP 238 (non-integer division). There are two parts to it. Part 1: the // operator implements integer division. Part 2: when "from __future__ import division" is in effect, the / operator implements float division. The //= and /= operators are also affected. (This is part of why I chose // over the keyword 'div'; also because that would require a new keyword.) The implementation now has three division operations (of each variation: regular and inplace, and corresponding opcodes) where it used to have one: - Division for / without future statement - FloatDivision for / with future statement - IntDivision for // The actual implementations for IntDivision and FloatDivision are a bit lame: - (old) Division is unchanged (using nb_division) - IntDivision just calls Division, so only does the right thing for ints and longs - FloatDivision adds 0.0 to the second operand At some point in the future, to keep NumPy happy, the "as number" struct should grow extra slots for the additional operations, and the above operations should only be used as fallbacks. (Maybe the fallback for IntDivision should use the nb_divmod slot as fallback.) Enjoy! ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-21 21:39 Message: Logged In: YES user_id=6380 Note, the patch doesn't include the changes for graminit.c (because they were big). This may cause problems on Windows, where that file is not automatically recreated when the grammar changes. I'm including the new graminit.c just in case. (graminit.h is unchanged.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443474&group_id=5470 From noreply@sourceforge.net Sun Jul 22 17:22:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Jul 2001 09:22:14 -0700 Subject: [Patches] [ python-Patches-443551 ] Minor change to pager choice in pydoc.py Message-ID: Patches item #443551, was opened at 2001-07-22 09:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443551&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Coventry (alex_coventry) Assigned to: Nobody/Anonymous (nobody) Summary: Minor change to pager choice in pydoc.py Initial Comment: If $PAGER is not set, and the "less" command works, then pydoc pipes its output to less. If $TERM is "dumb", or "emacs", this is a pretty inconvenient choice. This patch sends the output to stdout in those cases. I find it easier to use, especially when working with in a shell subordinate to emacs, where you can use the paging facilities of emacs itself anyway. Alex. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443551&group_id=5470 From noreply@sourceforge.net Sun Jul 22 17:27:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Jul 2001 09:27:46 -0700 Subject: [Patches] [ python-Patches-443551 ] Minor change to pager choice in pydoc.py Message-ID: Patches item #443551, was opened at 2001-07-22 09:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443551&group_id=5470 >Category: demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Coventry (alex_coventry) Assigned to: Nobody/Anonymous (nobody) Summary: Minor change to pager choice in pydoc.py Initial Comment: If $PAGER is not set, and the "less" command works, then pydoc pipes its output to less. If $TERM is "dumb", or "emacs", this is a pretty inconvenient choice. This patch sends the output to stdout in those cases. I find it easier to use, especially when working with in a shell subordinate to emacs, where you can use the paging facilities of emacs itself anyway. Alex. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-22 09:27 Message: Logged In: YES user_id=6380 Shouldn't it return plainpager rather than a function that doesn't page at all? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443551&group_id=5470 From noreply@sourceforge.net Sun Jul 22 23:12:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Jul 2001 15:12:29 -0700 Subject: [Patches] [ python-Patches-443626 ] TreeWidget cancellation problem Message-ID: Patches item #443626, was opened at 2001-07-22 15:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443626&group_id=5470 Category: IDLE Group: 2.0.1 bugfix Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: TreeWidget cancellation problem Initial Comment: TreeWidget was supposed to cancel editing when the user presses an Escape key. An entry was accepted anyways. Offending funcion : TreeWidget.TreeNode.edit_cancel Here is the origial: def edit_cancel(self, event=None): self.drawtext() self.canvas.focus_set() Here is the fix: def edit_cancel(self, event=None): try: self.entry.destroy() del self.entry except AttributeError: return self.drawtext() self.canvas.focus_set() The bug arose mainly because the edit_cancel did not destroy the Tkinter.Entry widget as part of the cancellation process. This obviously fixes that... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443626&group_id=5470 From noreply@sourceforge.net Mon Jul 23 03:03:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Jul 2001 19:03:01 -0700 Subject: [Patches] [ python-Patches-443669 ] Permit _tkinter to build on cygwin32 Message-ID: Patches item #443669, was opened at 2001-07-22 19:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443669&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Nobody/Anonymous (nobody) Summary: Permit _tkinter to build on cygwin32 Initial Comment: This is a patch to setup.py which allows the _tkinter module to be built on cygwin32. I have just tested it on a descr-branch checkout of the cvs tree. These instructions are based on those by Norman Vine, as found at http://www.vso.cape.com/~nhv/files/python/tinker.html . For this to work, you also need to install the "X11" headers available from that page. The patch does two things: * Search for tcl and tk libraries with version numbers like "80" as well as "8.0" * Do not attempt to link libX11 when compiling on cygwin It's not completely clear that the latter is always correct, because it is apparently legal to build X clients under cygwin. It is correct and necessary to build a _tkinter which can display to a win32 system. (Is there machinery to test whether -lX11 is necessary for -ltk, and include it only in that case?) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443669&group_id=5470 From noreply@sourceforge.net Mon Jul 23 03:20:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Jul 2001 19:20:56 -0700 Subject: [Patches] [ python-Patches-443673 ] Build _socket on cygwin32 Message-ID: Patches item #443673, was opened at 2001-07-22 19:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443673&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Nobody/Anonymous (nobody) Summary: Build _socket on cygwin32 Initial Comment: (just tested on a new install of cygwin32 and a fresh pull of descr-branch from cvs) Treat __CYGWIN32__ just like MS_WIN32 when deciding whether to declare h_errno in getaddrinfo.c The resulting socketmodule seems to work, including a successful 'python -c "import test.test_socket"' ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443673&group_id=5470 From noreply@sourceforge.net Mon Jul 23 03:45:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Jul 2001 19:45:07 -0700 Subject: [Patches] [ python-Patches-440292 ] Test cases for pyclbr.py Message-ID: Patches item #440292, was opened at 2001-07-10 22:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440292&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Test cases for pyclbr.py Initial Comment: These test cases exercise the pyclbr module. They work by comparing the output of pyclbr to the results of module introspection for some of the largest modules in the Python distribution. They also skirt several limitations of pyclbr not mentioned in the BUGS section of pyclbr.py. For example, pyclbr.py does really bad in the presence of the string [ '"""' ]. (This keeps it from handling pydoc.py.) While writing these test cases, I also found a minor bug in pyclbr.py that would prevent it from finding functions (but not classes) declared in other modules. I'm also including a patch for this bug. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-22 19:45 Message: Logged In: YES user_id=3066 Sorry -- the new test still doesn't fail without the patch, so there's appearantly something missing in the test. The patch will definately make more sense if there's an example of what breaks without it. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-07-21 20:10 Message: Logged In: YES user_id=499 Well, there were two problems: 1) The test case didn't test the problem I thought it did. 2) The patch didn't fix the problem I thought I was testing! :) I'm uploading new versions of each. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-21 13:38 Message: Logged In: YES user_id=3066 The test case doesn't cover the bug fixed in the patch; it should fail if I try it without applying the patch. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-07-19 17:25 Message: Logged In: YES user_id=499 Updated to use unittest, and to be generally a bit more legible. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-07-10 22:22 Message: Logged In: YES user_id=499 (More information on the bug: whereas pyclbr.py can notice imports of the format: "from module import class", it wasn't able to handle "from module import fn". Now it can.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440292&group_id=5470 From noreply@sourceforge.net Mon Jul 23 03:47:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Jul 2001 19:47:45 -0700 Subject: [Patches] [ python-Patches-440290 ] Tests for test_fpformat.py Message-ID: Patches item #440290, was opened at 2001-07-10 22:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440290&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Tests for test_fpformat.py Initial Comment: Another installment in the series of "Tests for the Testless". This time, we tackle the fpformat.py module, which does almost-but-not-exactly the same thing as certain options to the % operator. This test shows an inconsistencies in the behavior between fix and sci; and between fpformat and %. I'm not sure of the original authors' intent, so I'm just testing for the original behavior. This may not be best. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-22 19:47 Message: Logged In: YES user_id=3066 Checked in with small modifications; thanks! ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-07-19 17:24 Message: Logged In: YES user_id=499 Updated as requested. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-19 16:05 Message: Logged In: YES user_id=3066 Please adapt this to use unittest. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440290&group_id=5470 From noreply@sourceforge.net Mon Jul 23 05:08:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Jul 2001 21:08:32 -0700 Subject: [Patches] [ python-Patches-440291 ] Test cases for commands.py Message-ID: Patches item #440291, was opened at 2001-07-10 22:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440291&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Test cases for commands.py Initial Comment: Test cases for the commands.py module. These are only tested to work on SunOS and Linux, though they should work on any posix system. (This module needs an overhaul!) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-22 21:08 Message: Logged In: YES user_id=3066 Checked in with very minor modifications. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-07-19 17:26 Message: Logged In: YES user_id=499 Oops: forgot to check upload box. Uploading again ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-07-19 17:22 Message: Logged In: YES user_id=499 Updated to use unittest module ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=440291&group_id=5470 From noreply@sourceforge.net Mon Jul 23 11:46:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 03:46:00 -0700 Subject: [Patches] [ python-Patches-419652 ] Disable input look Tk event processing o Message-ID: Patches item #419652, was opened at 2001-04-27 15:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419652&group_id=5470 Category: core (C code) Group: 2.0.1 bugfix >Status: Closed Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) >Assigned to: Jack Jansen (jackjansen) Summary: Disable input look Tk event processing o Initial Comment: The Tk input handler on the Mac is too greedy, and file handlers are available but don't work. Disable mainloop Tk event handling at least makes the console usable again after using Tk. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-07-23 03:46 Message: Logged In: YES user_id=45365 This has been sitting in the tracker for 2 montsh now with nothing happening, so I've been bold and reassigned it to myself and checked it in. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-04-27 15:39 Message: Logged In: YES user_id=45365 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419652&group_id=5470 From noreply@sourceforge.net Mon Jul 23 12:02:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 04:02:10 -0700 Subject: [Patches] [ python-Patches-443759 ] Add Interface to readline's add_history Message-ID: Patches item #443759, was opened at 2001-07-23 04:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443759&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 3 Submitted By: Moshe Zadka (moshez) Assigned to: Nobody/Anonymous (nobody) Summary: Add Interface to readline's add_history Initial Comment: There is a function in GNU readline called add_history, which is used to manage the history list. Though Python uses this function internally, it does not expose it to the Python programmer. This patch adds direct interface to this function with documentation. This could be used by friendly modules to "seed" the history with commands. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443759&group_id=5470 From noreply@sourceforge.net Mon Jul 23 14:17:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 06:17:55 -0700 Subject: [Patches] [ python-Patches-443788 ] Small documentation fixes Message-ID: Patches item #443788, was opened at 2001-07-23 06:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443788&group_id=5470 Category: documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Small documentation fixes Initial Comment: Some minor fixes I collected while reading the documentation (from CVS) recently. Files affected: - dist/src/Doc/lib/libanydbm.tex - dist/src/Doc/lib/libexcs.tex - dist/src/Doc/lib/libos.tex - dist/src/Doc/lib/liburllib.tex ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443788&group_id=5470 From noreply@sourceforge.net Mon Jul 23 14:23:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 06:23:16 -0700 Subject: [Patches] [ python-Patches-441791 ] Improvment to package import semantics Message-ID: Patches item #441791, was opened at 2001-07-16 12:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441791&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Coventry (alex_coventry) >Assigned to: Guido van Rossum (gvanrossum) Summary: Improvment to package import semantics Initial Comment: I think it's nice to be able to do this: >>> import sys >>> sys.path.append('/l/alex_c/') >>> import mouse.foo Traceback (most recent call last): File "", line 1, in ? File "/l/alex_c/mouse/foo.py", line 1, in ? bar NameError: name 'bar' is not defined >>> import mouse.foo >>> reload(mouse.foo) # Works now that foo.py is corrected >>> from mouse import foo >>> foo.bar 1 However, at the moment, that's not possible, because if an error occurs in the loading of foo, foo is not added to mouse's dictionary, even though the module added to sys.modules under the key 'mouse.foo'. This has been driving me nuts, because I have large datasets that I need to load in each time I start python up, so I tend to test my scripts in a single interactive interpreter as I write them, so it's important for me to be able to reliably reload modules. I think it's also a sensible way for things to work in general, too. If there's enough controversy about this, I can write a PEP about it, or something. At any rate, here's a patch against the current CVS repository that changes the semantics as I've described. Alex. ---------------------------------------------------------------------- Comment By: Alex Coventry (alex_coventry) Date: 2001-07-20 14:54 Message: Logged In: YES user_id=49686 Thanks for the corrections. For what it's worth, here's the unit test I have in my code for this change, along with something to catch the SyntaxError error, not that anyone else is likely to make that mistake:) Alex ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 12:47 Message: Logged In: YES user_id=6380 Notice that when the module fails with a SyntaxError, my patch does nothing. propagating the SyntaxError normally, while the original error raised a SystemError, masking the SyntaxError. Clearly that was wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 12:41 Message: Logged In: YES user_id=6380 I've added a streamlined version that deals with the error handling a bit differently, and conforms to the C style guide (PEP 7). ---------------------------------------------------------------------- Comment By: Alex Coventry (alex_coventry) Date: 2001-07-19 15:21 Message: Logged In: YES user_id=49686 Hi, I've looked for pertinent thread in the python-dev archive, but I've been unable to find one. I've searched for keywords "import.c", "import_submodule", "reload", and lastly "package import", although I might have missed a thread matching that, as there were over a hundred hits. Could you point me at a thread? Alex. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-17 02:00 Message: Logged In: YES user_id=34209 This is not a 2.0.1 bugfix candidate, or any bugfix candidate. Group changed. This is also a subject of occasional discussion on python-dev, see the archives ;P ---------------------------------------------------------------------- Comment By: Alex Coventry (alex_coventry) Date: 2001-07-16 12:42 Message: Logged In: YES user_id=49686 a) Sorry about the duplicate submission b) I attached the patch I'm proposing to it, but can't see it on this page. Here it is, just in case: Index: Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.178 diff -c -r2.178 import.c *** Python/import.c 2001/07/05 03:47:53 2.178 --- Python/import.c 2001/07/16 19:04:05 *************** *** 1789,1795 **** import_submodule(PyObject *mod, char *subname, char *fullname) { PyObject *modules = PyImport_GetModuleDict(); ! PyObject *m; /* Require: if mod == None: subname == fullname --- 1789,1795 ---- import_submodule(PyObject *mod, char *subname, char *fullname) { PyObject *modules = PyImport_GetModuleDict(); ! PyObject *m, *resulting_module=NULL; /* Require: if mod == None: subname == fullname *************** *** 1829,1839 **** m = load_module(fullname, fp, buf, fdp->type); if (fp) fclose(fp); ! if (m != NULL && mod != Py_None) { ! if (PyObject_SetAttrString(mod, subname, m) < 0) { ! Py_DECREF(m); ! m = NULL; ! } } } --- 1829,1864 ---- m = load_module(fullname, fp, buf, fdp->type); if (fp) fclose(fp); ! if (mod != Py_None) { ! ! /* Irrespective of the success of this load, make a ! reference to it in the parent package module. */ ! ! /* ...a copy gets saved in the modules dictionary ! under the full name, so get a reference from ! there, if need be. */ ! if (m == NULL) { ! resulting_module = PyDict_GetItemString(modules, ! fullname); ! if (resulting_module == NULL) { ! ! /* ...failed to find the module under its full ! name; oops */ ! PyErr_Format(PyExc_SystemError, ! "Failed to create a sys.modules " \ ! "entry under %.200s", fullname); ! return NULL; ! } ! } else { ! resulting_module = m; ! } ! ! if (PyObject_SetAttrString(mod, subname, resulting_module) < 0) { ! if (m != NULL) { ! Py_DECREF(m); ! m = NULL; ! } ! } } } ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441791&group_id=5470 From noreply@sourceforge.net Mon Jul 23 14:30:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 06:30:24 -0700 Subject: [Patches] [ python-Patches-441791 ] Improvment to package import semantics Message-ID: Patches item #441791, was opened at 2001-07-16 12:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441791&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Coventry (alex_coventry) Assigned to: Guido van Rossum (gvanrossum) Summary: Improvment to package import semantics Initial Comment: I think it's nice to be able to do this: >>> import sys >>> sys.path.append('/l/alex_c/') >>> import mouse.foo Traceback (most recent call last): File "", line 1, in ? File "/l/alex_c/mouse/foo.py", line 1, in ? bar NameError: name 'bar' is not defined >>> import mouse.foo >>> reload(mouse.foo) # Works now that foo.py is corrected >>> from mouse import foo >>> foo.bar 1 However, at the moment, that's not possible, because if an error occurs in the loading of foo, foo is not added to mouse's dictionary, even though the module added to sys.modules under the key 'mouse.foo'. This has been driving me nuts, because I have large datasets that I need to load in each time I start python up, so I tend to test my scripts in a single interactive interpreter as I write them, so it's important for me to be able to reliably reload modules. I think it's also a sensible way for things to work in general, too. If there's enough controversy about this, I can write a PEP about it, or something. At any rate, here's a patch against the current CVS repository that changes the semantics as I've described. Alex. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-23 06:30 Message: Logged In: YES user_id=6380 Alex, I've checked in my version of the patch. Would you mind converting the unittest to something that I can drop into the test package? ---------------------------------------------------------------------- Comment By: Alex Coventry (alex_coventry) Date: 2001-07-20 14:54 Message: Logged In: YES user_id=49686 Thanks for the corrections. For what it's worth, here's the unit test I have in my code for this change, along with something to catch the SyntaxError error, not that anyone else is likely to make that mistake:) Alex ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 12:47 Message: Logged In: YES user_id=6380 Notice that when the module fails with a SyntaxError, my patch does nothing. propagating the SyntaxError normally, while the original error raised a SystemError, masking the SyntaxError. Clearly that was wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 12:41 Message: Logged In: YES user_id=6380 I've added a streamlined version that deals with the error handling a bit differently, and conforms to the C style guide (PEP 7). ---------------------------------------------------------------------- Comment By: Alex Coventry (alex_coventry) Date: 2001-07-19 15:21 Message: Logged In: YES user_id=49686 Hi, I've looked for pertinent thread in the python-dev archive, but I've been unable to find one. I've searched for keywords "import.c", "import_submodule", "reload", and lastly "package import", although I might have missed a thread matching that, as there were over a hundred hits. Could you point me at a thread? Alex. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-17 02:00 Message: Logged In: YES user_id=34209 This is not a 2.0.1 bugfix candidate, or any bugfix candidate. Group changed. This is also a subject of occasional discussion on python-dev, see the archives ;P ---------------------------------------------------------------------- Comment By: Alex Coventry (alex_coventry) Date: 2001-07-16 12:42 Message: Logged In: YES user_id=49686 a) Sorry about the duplicate submission b) I attached the patch I'm proposing to it, but can't see it on this page. Here it is, just in case: Index: Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.178 diff -c -r2.178 import.c *** Python/import.c 2001/07/05 03:47:53 2.178 --- Python/import.c 2001/07/16 19:04:05 *************** *** 1789,1795 **** import_submodule(PyObject *mod, char *subname, char *fullname) { PyObject *modules = PyImport_GetModuleDict(); ! PyObject *m; /* Require: if mod == None: subname == fullname --- 1789,1795 ---- import_submodule(PyObject *mod, char *subname, char *fullname) { PyObject *modules = PyImport_GetModuleDict(); ! PyObject *m, *resulting_module=NULL; /* Require: if mod == None: subname == fullname *************** *** 1829,1839 **** m = load_module(fullname, fp, buf, fdp->type); if (fp) fclose(fp); ! if (m != NULL && mod != Py_None) { ! if (PyObject_SetAttrString(mod, subname, m) < 0) { ! Py_DECREF(m); ! m = NULL; ! } } } --- 1829,1864 ---- m = load_module(fullname, fp, buf, fdp->type); if (fp) fclose(fp); ! if (mod != Py_None) { ! ! /* Irrespective of the success of this load, make a ! reference to it in the parent package module. */ ! ! /* ...a copy gets saved in the modules dictionary ! under the full name, so get a reference from ! there, if need be. */ ! if (m == NULL) { ! resulting_module = PyDict_GetItemString(modules, ! fullname); ! if (resulting_module == NULL) { ! ! /* ...failed to find the module under its full ! name; oops */ ! PyErr_Format(PyExc_SystemError, ! "Failed to create a sys.modules " \ ! "entry under %.200s", fullname); ! return NULL; ! } ! } else { ! resulting_module = m; ! } ! ! if (PyObject_SetAttrString(mod, subname, resulting_module) < 0) { ! if (m != NULL) { ! Py_DECREF(m); ! m = NULL; ! } ! } } } ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441791&group_id=5470 From noreply@sourceforge.net Mon Jul 23 14:40:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 06:40:34 -0700 Subject: [Patches] [ python-Patches-422106 ] Seg fault in sys.displayhook Message-ID: Patches item #422106, was opened at 2001-05-07 13:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422106&group_id=5470 Category: core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Gregory H. Ball (greg_ball) >Assigned to: Tim Peters (tim_one) Summary: Seg fault in sys.displayhook Initial Comment: If you do a very silly thing and delete the "__builtin__" entry from sys.modules, the default displayhook is defeated. This problem exists in 2.1 and current CVS, but not 2.0 (The old display loop held a reference to the builtin module instead of repeatedly fetching it in 2.0, I guess.) My patch just checks whether the module is in the expected location and raises an exception instead of dumping core. The error message is not especially illuminating, but then, anyone who actually does this deserves far worse ;-) ---------------------------------------------------------------------- >Comment By: Moshe Zadka (moshez) Date: 2001-07-23 06:40 Message: Logged In: YES user_id=11645 Tim, I'm assigning to you so you can check this in on the release branch. There's no section in the FAQ on how the new procedure works SF-wise. Checked into the main branch as Python/sysmodule version 2.90 ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-05-07 13:10 Message: Logged In: YES user_id=11365 The problem: Python 2.2a0 (#13, May 7 2001, 15:45:00) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import sys >>> del sys.modules['__builtin__'] >>> 1 Segmentation fault (core dumped) The solution: Python 2.2a0 (#16, May 7 2001, 16:03:33) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import sys >>> del sys.modules['__builtin__'] >>> 1 Traceback (most recent call last): File "", line 1, in ? RuntimeError: lost __builtin__ >>> ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422106&group_id=5470 From noreply@sourceforge.net Mon Jul 23 14:52:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 06:52:18 -0700 Subject: [Patches] [ python-Patches-414948 ] Check dynload_next.c (see description) Message-ID: Patches item #414948, was opened at 2001-04-09 09:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414948&group_id=5470 Category: library >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jonathan Wight (schwa) >Assigned to: Nobody/Anonymous (nobody) Summary: Check dynload_next.c (see description) Initial Comment: Fixes dynload_next.c to check to see library isn't already loaded. Fixes the NeXT dynloader (used on MacOS X 10.0) to check to see if a symbol has already been loaded before trying to load it again. Without this change running the following pseudocode more than once will cause the NeXT dyld loader to terminate the app. Py_Initialize(); PyRun_SimpleString("import string"); Py_Finalize(); So in effect Python isn't being returned into a 'good' state. NOTE: This is a follow-up to Patch #413005. In that Patch my browser failed to upload & attach the patch file. Apologies. ---------------------------------------------------------------------- >Comment By: Moshe Zadka (moshez) Date: 2001-07-23 06:52 Message: Logged In: YES user_id=11645 OK, someone else will need to check this....I have no idea and no time to check it. ---------------------------------------------------------------------- Comment By: Jonathan Wight (schwa) Date: 2001-04-11 10:40 Message: Logged In: YES user_id=29309 > This is irrelevant for 2.1 -- it is a Py2.0.1 bugfix I countered this bug in version 2.1b2a -- I then did a cvs checkout to get the latest version of the (buggy) code. Unless I'm missing something a fix isn't in 2.1 > (the author neglected to set the group up There wasn't an option for 2.1b2a in the group popup. Just "2.0.1" and "None" ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2001-04-11 00:26 Message: Logged In: YES user_id=11645 This is irrelevant for 2.1 -- it is a Py2.0.1 bugfix (the author neglected to set the group up, sadly, and I didn't have SF time before today to set this up). I'll check in some more patches to 201 this weekend, I think. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:25 Message: Logged In: YES user_id=6380 Assigned to Moshe since he assigned the other (failed) submission to himself also (Moshe, do you have the resources to test this before 2.1 goes out? If not, please unassign!) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414948&group_id=5470 From noreply@sourceforge.net Mon Jul 23 17:09:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 09:09:29 -0700 Subject: [Patches] [ python-Patches-441175 ] Tests for glob.py Message-ID: Patches item #441175, was opened at 2001-07-13 13:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441175&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Tests for glob.py Initial Comment: Another in the series. This file uses "unittest" to test the glob.py module. (Caveat: I've really tried to be as cross-platform as I know how, but there may be some problems remaining. At least it works on Unix!) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-23 09:09 Message: Logged In: YES user_id=3066 Checked in a heavily modified version that actually works on Windows. Thanks, Nick! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=441175&group_id=5470 From noreply@sourceforge.net Mon Jul 23 17:30:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 09:30:39 -0700 Subject: [Patches] [ python-Patches-442863 ] Add switch to disable PYTHON{HOME,PATH} Message-ID: Patches item #442863, was opened at 2001-07-19 12:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442863&group_id=5470 Category: None Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Neil Schemenauer (nascheme) Summary: Add switch to disable PYTHON{HOME,PATH} Initial Comment: This patch adds the -E command line switch. When specified, the PYTHONHOME and PYTHONPATH environment variables are ignored. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-07-23 09:30 Message: Logged In: YES user_id=35752 Commited with typo fix. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 12:07 Message: Logged In: YES user_id=6380 Very nice, Neil. Check it in please! Typo: the man page patch has a reference to PYTHOHHOME... ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-07-20 11:01 Message: Logged In: YES user_id=35752 Okay, here's an updated patch the adds a -E option which suppresses all PYTHON* environment variables. Suggestions for improvements welcome. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-07-19 14:14 Message: Logged In: YES user_id=35752 -E only suppress PYTHONHOME and PYTHONPATH. Are you sure about suppressing them all? There are quite a few (around 8). PYTHONHOME and PYTHONPATH seem to be the only ones that cause real trouble. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 13:37 Message: Logged In: YES user_id=6380 Cool, Neil! Nits: - The Makefile uses "-Ec" somewhere; I recommend to use "-E -c" instead. - Does -E suppress PYTHONSTARTUP or doesn't it? The comments are inconsistent with the help message. I think it should suppress *all* use of Python-specific environment variables. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442863&group_id=5470 From noreply@sourceforge.net Mon Jul 23 17:33:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 09:33:47 -0700 Subject: [Patches] [ python-Patches-439364 ] GC for frames and generators Message-ID: Patches item #439364, was opened at 2001-07-07 15:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439364&group_id=5470 Category: core (C code) Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Neil Schemenauer (nascheme) Summary: GC for frames and generators Initial Comment: For me, test_generators leaks, with or without this patch. The number of objects tracked by the GC does not increase but memory usage does. There must be other objects creating cycles that are not tracked by the GC. I haven't profiled the effect this change. I have another patch in the works that should minimize the performance hit. Please examine frame_traverse and frame_clear closely. I'm not 100% sure that I am chasing all the references necessary to find cycles or that I am dropping enough to break them. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-07-23 09:33 Message: Logged In: YES user_id=35752 Closing patch since it was checked in a while ago. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 18:41 Message: Logged In: YES user_id=31435 Accepted, and back to Neil for checkin. I see no leaks anymore. Thank you! Disgustingly straightforward, wasn't it ? The fact that these cycles were so painful to track down (despite being straightforward!) convinces me there's no future in overlooking the leaks but trying to rationalize them away on performance grounds. The patch makes necessary progress, and we can worry about reclaiming performance as a separate project (btw, that's easier for me if this is checked in so there's a new baseline to work against). ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-07-11 13:31 Message: Logged In: YES user_id=35752 I believe this patch does the trick. The performance hit is larger than I would like however. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-10 20:45 Message: Logged In: YES user_id=31435 The newly attached bmoleak.py shows a similar leak without any generators, involving seqiterobjects alone. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-09 21:34 Message: Logged In: YES user_id=31435 I expect what's going on here is the obvious thing: clearing the LazyList dict stops the leak, but the dict only holds two things: a vanilla list of integers, and a bound method object. Since a list of ints can't cause a cycle, it must be the latter; and, indeed, a quick glance at methodobject.c shows GC doesn't chase PyCFunction_Type (yet). The bound method object in this case wraps the .next() method of a generator-iterator object, and there's a cycle: the LazyList fib maps fib.fetch to the fibgen() generator-iterator's .next method, from which we can get to the fibgen g-i, which in turn contains (indirect) references back to fib thanks to passing iter(fib) to the sum() and head() generators. Looks like breaking this by magic requires adding both seqiterobjects and PyCFunctionObjects to GC. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-09 14:08 Message: Logged In: YES user_id=31435 The attached fibleak.py is a self-contained massive leaker. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-09 13:48 Message: Logged In: YES user_id=31435 + Performance hit is about a 2.5% slowdown. More than I hoped, but less than I feared . + The leak after the patch is solely due to fun_tests. Comment out the other lines in the __test__ dict, and on my box it leaks about half a megabyte per second then -- very dramatic, and impossible to ascribe to anything but a leak. + I don't know what causes the leak. Offhand my first guess would be unchased pointers inside traceback objects. Indeed, the first thing I'd *try* is adding tracebackobject to GC too just to see whether that made the leak go away (much easier than thinking about it <0.9 wink>). ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-07-09 07:11 Message: Logged In: YES user_id=35752 Your right, it doesn't leak before the patch. The process size goes up slowly be eventually stops increasing. After the patch the size continues going up slowly. :-( I'll try to find what is still leaking. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-08 21:40 Message: Logged In: YES user_id=31435 Thanks, Neil! I've been too overwhelmed with merging descr- branch code to look at this until now. Clarification, please: when you say "test_generators leaks, with or without this patch", what exactly do you mean by "leak"? It does not leak for me before the patch (haven't yet tried it with the patch), and this is what I mean-- exactly -- by "does not leak": I change a stock CVS build by changing "if 0:" to "if 1:" in test_generators.py's test_main, then let it run and run and run. Now on Win98SE, the heap space *does* grow very slowly and steadily, until it reaches about 3600Kb. Sometimes a little more, sometimes a little less, depending on what else I'm doing at the time. It takes about 5 minutes of CPU time on a 866MHz box to reach that. But then it *stays* at this point forever after (well, after another 10 minutes of CPU time it hasn't budged -- Win98SE probably can't run forever ). This is presumably because Win98SE malloc is lazy about coalescing free()'d memory until it nears a 4Mb boundary (at which point it starts rearranging VM address space-- because 4Mb is all the address space the system allocates to the initial heap --and it's very reluctant to do that). So if you're seeing a very slow "leak" (are you?), you *may* just be seeing a platform malloc reluctant to defragment free()'d memory. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=439364&group_id=5470 From noreply@sourceforge.net Mon Jul 23 18:03:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 10:03:41 -0700 Subject: [Patches] [ python-Patches-432401 ] unicode encoding error callbacks Message-ID: Patches item #432401, was opened at 2001-06-12 06:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=432401&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: unicode encoding error callbacks Initial Comment: This patch adds unicode error handling callbacks to the encode functionality. With this patch it's possible to not only pass 'strict', 'ignore' or 'replace' as the errors argument to encode, but also a callable function, that will be called with the encoding name, the original unicode object and the position of the unencodable character. The callback must return a replacement unicode object that will be encoded instead of the original character. For example replacing unencodable characters with XML character references can be done in the following way. u"aäoöuüß".encode( "ascii", lambda enc, uni, pos: u"&#x%x;" % ord(uni[pos]) ) ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2001-07-23 10:03 Message: Logged In: YES user_id=89016 New version of the patch with the error handling callback registry. > > OK, done, now there's a > > PyCodec_EscapeReplaceUnicodeEncodeErrors/ > > codecs.escapereplace_unicodeencode_errors > > that uses \u (or \U if x>0xffff (with a wide build > > of Python)). > > Great! Now PyCodec_EscapeReplaceUnicodeEncodeErrors uses \x in addition to \u and \U where appropriate. > > [...] > > But for special one-shot error handlers, it might still be > > useful to pass the error handler directly, so maybe we > > should leave error as PyObject *, but implement the > > registry anyway? > > Good idea ! > > One minor nit: codecs.registerError() should be named > codecs.register_errorhandler() to be more inline with > the Python coding style guide. OK, but these function are specific to unicode encoding, so now the functions are called: codecs.register_unicodeencodeerrorhandler codecs.lookup_unicodeencodeerrorhandler Now all callbacks (including the new ones: "xmlcharrefreplace" and "escapereplace") are registered in the codecs.c/_PyCodecRegistry_Init so using them is really simple: u"gürk".encode("ascii", "xmlcharrefreplace") ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-13 04:26 Message: Logged In: YES user_id=38388 > > > > > BTW, I guess PyUnicode_EncodeUnicodeEscape > > > > > could be reimplemented as PyUnicode_EncodeASCII > > > > > with \uxxxx replacement callback. > > > > > > > > Hmm, wouldn't that result in a slowdown ? If so, > > > > I'd rather leave the special encoder in place, > > > > since it is being used a lot in Python and > > > > probably some applications too. > > > > > > It would be a slowdown. But callbacks open many > > > possiblities. > > > > True, but in this case I believe that we should stick with > > the native implementation for "unicode-escape". Having > > a standard callback error handler which does the \uXXXX > > replacement would be nice to have though, since this would > > also be usable with lots of other codecs (e.g. all the > > code page ones). > > OK, done, now there's a > PyCodec_EscapeReplaceUnicodeEncodeErrors/ > codecs.escapereplace_unicodeencode_errors > that uses \u (or \U if x>0xffff (with a wide build > of Python)). Great ! > > [...] > > > Should the old TranslateCharmap map to the new > > > TranslateCharmapEx and inherit the > > > "multicharacter replacement" feature, > > > or should I leave it as it is? > > > > If possible, please also add the multichar replacement > > to the old API. I think it is very useful and since the > > old APIs work on raw buffers it would be a benefit to have > > the functionality in the old implementation too. > > OK! I will try to find the time to implement that in the > next days. Good. > > [Decoding error callbacks] > > > > About the return value: > > > > I'd suggest to always use the same tuple interface, e.g. > > > > callback(encoding, input_data, input_position, > state) -> > > (output_to_be_appended, new_input_position) > > > > (I think it's better to use absolute values for the > > position rather than offsets.) > > > > Perhaps the encoding callbacks should use the same > > interface... what do you think ? > > This would make the callback feature hypergeneric and a > little slower, because tuples have to be created, but it > (almost) unifies the encoding and decoding API. ("almost" > because, for the encoder output_to_be_appended will be > reencoded, for the decoder it will simply be appended.), > so I'm for it. That's the point. Note that I don't think the tuple creation will hurt much (see the make_tuple() API in codecs.c) since small tuples are cached by Python internally. > I implemented this and changed the encoders to only > lookup the error handler on the first error. The UCS1 > encoder now no longer uses the two-item stack strategy. > (This strategy only makes sense for those encoder where > the encoding itself is much more complicated than the > looping/callback etc.) So now memory overflow tests are > only done, when an unencodable error occurs, so now the > UCS1 encoder should be as fast as it was without > error callbacks. > > Do we want to enforce new_input_position>input_position, > or should jumping back be allowed? No; moving backwards should be allowed (this may be useful in order to resynchronize with the input data). > Here's is the current todo list: > 1. implement a new TranslateCharmap and fix the old. > 2. New encoding API for string objects too. > 3. Decoding > 4. Documentation > 5. Test cases > > I'm thinking about a different strategy for implementing > callbacks > (see http://mail.python.org/pipermail/i18n-sig/2001- > July/001262.html) > > We coould have a error handler registry, which maps names > to error handlers, then it would be possible to keep the > errors argument as "const char *" instead of "PyObject *". > Currently PyCodec_UnicodeEncodeHandlerForObject is a > backwards compatibility hack that will never go away, > because > it's always more convenient to type > u"...".encode("...", "strict") > instead of > import codecs > u"...".encode("...", codecs.raise_encode_errors) > > But with an error handler registry this function would > become the official lookup method for error handlers. > (PyCodec_LookupUnicodeEncodeErrorHandler?) > Python code would look like this: > --- > def xmlreplace(encoding, unicode, pos, state): > return (u"&#%d;" % ord(uni[pos]), pos+1) > > import codec > > codec.registerError("xmlreplace",xmlreplace) > --- > and then the following call can be made: > u"äöü".encode("ascii", "xmlreplace") > As soon as the first error is encountered, the encoder uses > its builtin error handling method if it recognizes the name > ("strict", "replace" or "ignore") or looks up the error > handling function in the registry if it doesn't. In this way > the speed for the backwards compatible features is the same > as before and "const char *error" can be kept as the > parameter to all encoding functions. For speed common error > handling names could even be implemented in the encoder > itself. > > But for special one-shot error handlers, it might still be > useful to pass the error handler directly, so maybe we > should leave error as PyObject *, but implement the > registry anyway? Good idea ! One minor nit: codecs.registerError() should be named codecs.register_errorhandler() to be more inline with the Python coding style guide. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-07-12 04:03 Message: Logged In: YES user_id=89016 > > [...] > > so I guess we could change the replace handler > > to always return u'?'. This would make the > > implementation a little bit simpler, but the > > explanation of the callback feature *a lot* > > simpler. > > Go for it. OK, done! > [...] > > > Could you add these docs to the Misc/unicode.txt > > > file ? I will eventually take that file and turn > > > it into a PEP which will then serve as general > > > documentation for these things. > > > > I could, but first we should work out how the > > decoding callback API will work. > > Ok. BTW, Barry Warsaw already did the work of converting > the unicode.txt to PEP 100, so the docs should eventually > go there. OK. I guess it would be best to do this when everything is finished. > > > > BTW, I guess PyUnicode_EncodeUnicodeEscape > > > > could be reimplemented as PyUnicode_EncodeASCII > > > > with \uxxxx replacement callback. > > > > > > Hmm, wouldn't that result in a slowdown ? If so, > > > I'd rather leave the special encoder in place, > > > since it is being used a lot in Python and > > > probably some applications too. > > > > It would be a slowdown. But callbacks open many > > possiblities. > > True, but in this case I believe that we should stick with > the native implementation for "unicode-escape". Having > a standard callback error handler which does the \uXXXX > replacement would be nice to have though, since this would > also be usable with lots of other codecs (e.g. all the > code page ones). OK, done, now there's a PyCodec_EscapeReplaceUnicodeEncodeErrors/ codecs.escapereplace_unicodeencode_errors that uses \u (or \U if x>0xffff (with a wide build of Python)). > > For example: > > > > Why can't I print u"gürk"? > > > > is probably one of the most frequently asked > > questions in comp.lang.python. For printing > > Unicode stuff, print could be extended the use an > > error handling callback for Unicode strings (or > > objects where __str__ or tp_str returns a Unicode > > object) instead of using str() which always > > returns an 8bit string and uses strict encoding. > > There might even be a > > sys.setprintencodehandler()/sys.getprintencodehandler () > > There already is a print callback in Python (forgot the > name of the hook though), so this should be possible by > providing the encoding logic in the hook. True: sys.displayhook > [...] > > Should the old TranslateCharmap map to the new > > TranslateCharmapEx and inherit the > > "multicharacter replacement" feature, > > or should I leave it as it is? > > If possible, please also add the multichar replacement > to the old API. I think it is very useful and since the > old APIs work on raw buffers it would be a benefit to have > the functionality in the old implementation too. OK! I will try to find the time to implement that in the next days. > [Decoding error callbacks] > > About the return value: > > I'd suggest to always use the same tuple interface, e.g. > > callback(encoding, input_data, input_position, state) -> > (output_to_be_appended, new_input_position) > > (I think it's better to use absolute values for the > position rather than offsets.) > > Perhaps the encoding callbacks should use the same > interface... what do you think ? This would make the callback feature hypergeneric and a little slower, because tuples have to be created, but it (almost) unifies the encoding and decoding API. ("almost" because, for the encoder output_to_be_appended will be reencoded, for the decoder it will simply be appended.), so I'm for it. I implemented this and changed the encoders to only lookup the error handler on the first error. The UCS1 encoder now no longer uses the two-item stack strategy. (This strategy only makes sense for those encoder where the encoding itself is much more complicated than the looping/callback etc.) So now memory overflow tests are only done, when an unencodable error occurs, so now the UCS1 encoder should be as fast as it was without error callbacks. Do we want to enforce new_input_position>input_position, or should jumping back be allowed? > > > > One additional note: It is vital that errors > > > > is an assignable attribute of the StreamWriter. > > > > > > It is already ! > > > > I know, but IMHO it should be documented that an > > assignable errors attribute must be supported > > as part of the official codec API. > > > > Misc/unicode.txt is not clear on that: > > """ > > It is not required by the Unicode implementation > > to use these base classes, only the interfaces must > > match; this allows writing Codecs as extension types. > > """ > > Good point. I'll add that to the PEP 100. OK. Here's is the current todo list: 1. implement a new TranslateCharmap and fix the old. 2. New encoding API for string objects too. 3. Decoding 4. Documentation 5. Test cases I'm thinking about a different strategy for implementing callbacks (see http://mail.python.org/pipermail/i18n-sig/2001- July/001262.html) We coould have a error handler registry, which maps names to error handlers, then it would be possible to keep the errors argument as "const char *" instead of "PyObject *". Currently PyCodec_UnicodeEncodeHandlerForObject is a backwards compatibility hack that will never go away, because it's always more convenient to type u"...".encode("...", "strict") instead of import codecs u"...".encode("...", codecs.raise_encode_errors) But with an error handler registry this function would become the official lookup method for error handlers. (PyCodec_LookupUnicodeEncodeErrorHandler?) Python code would look like this: --- def xmlreplace(encoding, unicode, pos, state): return (u"&#%d;" % ord(uni[pos]), pos+1) import codec codec.registerError("xmlreplace",xmlreplace) --- and then the following call can be made: u"äöü".encode("ascii", "xmlreplace") As soon as the first error is encountered, the encoder uses its builtin error handling method if it recognizes the name ("strict", "replace" or "ignore") or looks up the error handling function in the registry if it doesn't. In this way the speed for the backwards compatible features is the same as before and "const char *error" can be kept as the parameter to all encoding functions. For speed common error handling names could even be implemented in the encoder itself. But for special one-shot error handlers, it might still be useful to pass the error handler directly, so maybe we should leave error as PyObject *, but implement the registry anyway? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-10 05:29 Message: Logged In: YES user_id=38388 Ok, here we go... > > > raise an exception). U+FFFD characters in the > replacement > > > string will be replaced with a character that the > encoder > > > chooses ('?' in all cases). > > > > Nice. > > But the special casing of U+FFFD makes the interface > somewhat > less clean than it could be. It was only done to be 100% > backwards compatible. With the original "replace" > error > handling the codec chose the replacement character. But as > far as I can tell none of the codecs uses anything other > than '?', True. > so I guess we could change the replace handler > to always return u'?'. This would make the implementation a > little bit simpler, but the explanation of the callback > feature *a lot* simpler. Go for it. > And if you still want to handle > an unencodable U+FFFD, you can write a special callback for > that, e.g. > > def FFFDreplace(enc, uni, pos): > if uni[pos] == "\ufffd": > return u"?" > else: > raise UnicodeError(...) > > > ...docs... > > > > Could you add these docs to the Misc/unicode.txt file ? I > > will eventually take that file and turn it into a PEP > which > > will then serve as general documentation for these things. > > I could, but first we should work out how the decoding > callback API will work. Ok. BTW, Barry Warsaw already did the work of converting the unicode.txt to PEP 100, so the docs should eventually go there. > > > BTW, I guess PyUnicode_EncodeUnicodeEscape could be > > > reimplemented as PyUnicode_EncodeASCII with a \uxxxx > > > replacement callback. > > > > Hmm, wouldn't that result in a slowdown ? If so, I'd > rather > > leave the special encoder in place, since it is being > used a > > lot in Python and probably some applications too. > > It would be a slowdown. But callbacks open many > possiblities. True, but in this case I believe that we should stick with the native implementation for "unicode-escape". Having a standard callback error handler which does the \uXXXX replacement would be nice to have though, since this would also be usable with lots of other codecs (e.g. all the code page ones). > For example: > > Why can't I print u"gürk"? > > is probably one of the most frequently asked questions in > comp.lang.python. For printing Unicode stuff, print could be > extended the use an error handling callback for Unicode > strings (or objects where __str__ or tp_str returns a > Unicode object) instead of using str() which always returns > an 8bit string and uses strict encoding. There might even > be a > sys.setprintencodehandler()/sys.getprintencodehandler() There already is a print callback in Python (forgot the name of the hook though), so this should be possible by providing the encoding logic in the hook. > > > I have not touched PyUnicode_TranslateCharmap yet, > > > should this function also support error callbacks? Why > > > would one want the insert None into the mapping to > call > > > the callback? > > > > 1. Yes. > > 2. The user may want to e.g. restrict usage of certain > > character ranges. In this case the codec would be used to > > verify the input and an exception would indeed be useful > > (e.g. say you want to restrict input to Hangul + ASCII). > > OK, do we want TranslateCharmap to work exactly like > encoding, > i.e. in case of an error should the returned replacement > string again be mapped through the translation mapping or > should it be copied to the output directly? The former would > be more in line with encoding, but IMHO the latter would > be much more useful. It's better to take the second approach (copy the callback output directly to the output string) to avoid endless recursion and other pitfalls. I suppose this will also simplify the implementation somewhat. > BTW, when I implement it I can implement patch #403100 > ("Multicharacter replacements in > PyUnicode_TranslateCharmap") > along the way. I've seen it; will comment on it later. > Should the old TranslateCharmap map to the new > TranslateCharmapEx > and inherit the "multicharacter replacement" feature, > or > should I leave it as it is? If possible, please also add the multichar replacement to the old API. I think it is very useful and since the old APIs work on raw buffers it would be a benefit to have the functionality in the old implementation too. [Decoding error callbacks] > > > A remaining problem is how to implement decoding error > > > callbacks. In Python 2.1 encoding and decoding errors > are > > > handled in the same way with a string value. But with > > > callbacks it doesn't make sense to use the same > callback > > > for encoding and decoding (like > codecs.StreamReaderWriter > > > and codecs.StreamRecoder do). Decoding callbacks have > a > > > different API. Which arguments should be passed to the > > > decoding callback, and what is the decoding callback > > > supposed to do? > > > > I'd suggest adding another set of PyCodec_UnicodeDecode... > () > > APIs for this. We'd then have to augment the base classes > of > > the StreamCodecs to provide two attributes for .errors > with > > a fallback solution for the string case (i.s. "strict" > can > > still be used for both directions). > > Sounds good. Now what is the decoding callback supposed to > do? > I guess it will be called in the same way as the encoding > callback, i.e. with encoding name, original string and > position of the error. It might returns a Unicode string > (i.e. an object of the decoding target type), that will be > emitted from the codec instead of the one offending byte. Or > it might return a tuple with replacement Unicode object and > a resynchronisation offset, i.e. returning (u"?", 1) > means > emit a '?' and skip the offending character. But to make > the offset really useful the callback has to know something > about the encoding, perhaps the codec should be allowed to > pass an additional state object to the callback? > > Maybe the same should be added to the encoding callbacks to? > Maybe the encoding callback should be able to tell the > encoder if the replacement returned should be reencoded > (in which case it's a Unicode object), or directly emitted > (in which case it's an 8bit string)? I like the idea of having an optional state object (basically this should be a codec-defined arbitrary Python object) which then allow the callback to apply additional tricks. The object should be documented to be modifyable in place (simplifies the interface). About the return value: I'd suggest to always use the same tuple interface, e.g. callback(encoding, input_data, input_position, state) -> (output_to_be_appended, new_input_position) (I think it's better to use absolute values for the position rather than offsets.) Perhaps the encoding callbacks should use the same interface... what do you think ? > > > One additional note: It is vital that errors is an > > > assignable attribute of the StreamWriter. > > > > It is already ! > > I know, but IMHO it should be documented that an assignable > errors attribute must be supported as part of the official > codec API. > > Misc/unicode.txt is not clear on that: > """ > It is not required by the Unicode implementation to use > these base classes, only the interfaces must match; this > allows writing Codecs as extension types. > """ Good point. I'll add that to the PEP 100. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-22 13:51 Message: Logged In: YES user_id=38388 Sorry to keep you waiting, Walter. I will look into this again next week -- this week was way too busy... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-13 10:00 Message: Logged In: YES user_id=38388 On your comment about the non-Unicode codecs: let's keep this separated from the current patch. Don't have much time today. I'll comment on the other things tomorrow. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-13 08:49 Message: Logged In: YES user_id=89016 Guido van Rossum wrote in python-dev: > True, the "codec" pattern can be used for other > encodings than Unicode. But it seems to me that the > entire codecs architecture is rather strongly geared > towards en/decoding Unicode, and it's not clear > how well other codecs fit in this pattern (e.g. I > noticed that all the non-Unicode codecs ignore the > error handling parameter or assert that > it is set to 'strict'). I noticed that too. asserting that errors=='strict' would mean that the encoder is not able to deal in any other way with unencodable stuff than by raising an error. But that is not the problem here, because for zlib, base64, quopri, hex and uu encoding there can be no unencodable characters. The encoders can simply ignore the errors parameter. Should I remove the asserts from those codecs and change the docstrings accordingly, or will this be done separately? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-13 06:57 Message: Logged In: YES user_id=89016 > > [...] > > raise an exception). U+FFFD characters in the replacement > > string will be replaced with a character that the encoder > > chooses ('?' in all cases). > > Nice. But the special casing of U+FFFD makes the interface somewhat less clean than it could be. It was only done to be 100% backwards compatible. With the original "replace" error handling the codec chose the replacement character. But as far as I can tell none of the codecs uses anything other than '?', so I guess we could change the replace handler to always return u'?'. This would make the implementation a little bit simpler, but the explanation of the callback feature *a lot* simpler. And if you still want to handle an unencodable U+FFFD, you can write a special callback for that, e.g. def FFFDreplace(enc, uni, pos): if uni[pos] == "\ufffd": return u"?" else: raise UnicodeError(...) > > The implementation of the loop through the string is done > > in the following way. A stack with two strings is kept > > and the loop always encodes a character from the string > > at the stacktop. If an error is encountered and the stack > > has only one entry (during encoding of the original string) > > the callback is called and the unicode object returned is > > pushed on the stack, so the encoding continues with the > > replacement string. If the stack has two entries when an > > error is encountered, the replacement string itself has > > an unencodable character and a normal exception raised. > > When the encoder has reached the end of it's current string > > there are two possibilities: when the stack contains two > > entries, this was the replacement string, so the replacement > > string will be poppep from the stack and encoding continues > > with the next character from the original string. If the > > stack had only one entry, encoding is finished. > > Very elegant solution ! I'll put it as a comment in the source. > > (I hope that's enough explanation of the API and > implementation) > > Could you add these docs to the Misc/unicode.txt file ? I > will eventually take that file and turn it into a PEP which > will then serve as general documentation for these things. I could, but first we should work out how the decoding callback API will work. > > I have renamed the static ...121 function to all lowercase > > names. > > Ok. > > > BTW, I guess PyUnicode_EncodeUnicodeEscape could be > > reimplemented as PyUnicode_EncodeASCII with a \uxxxx > > replacement callback. > > Hmm, wouldn't that result in a slowdown ? If so, I'd rather > leave the special encoder in place, since it is being used a > lot in Python and probably some applications too. It would be a slowdown. But callbacks open many possiblities. For example: Why can't I print u"gürk"? is probably one of the most frequently asked questions in comp.lang.python. For printing Unicode stuff, print could be extended the use an error handling callback for Unicode strings (or objects where __str__ or tp_str returns a Unicode object) instead of using str() which always returns an 8bit string and uses strict encoding. There might even be a sys.setprintencodehandler()/sys.getprintencodehandler() > [...] > I think it would be worthwhile to rename the callbacks to > include "Unicode" somewhere, e.g. > PyCodec_UnicodeReplaceEncodeErrors(). It's a long name, but > then it points out the application field of the callback > rather well. Same for the callbacks exposed through the > _codecsmodule. OK, done (and PyCodec_XMLCharRefReplaceUnicodeEncodeErrors really is a long name ;)) > > I have not touched PyUnicode_TranslateCharmap yet, > > should this function also support error callbacks? Why > > would one want the insert None into the mapping to call > > the callback? > > 1. Yes. > 2. The user may want to e.g. restrict usage of certain > character ranges. In this case the codec would be used to > verify the input and an exception would indeed be useful > (e.g. say you want to restrict input to Hangul + ASCII). OK, do we want TranslateCharmap to work exactly like encoding, i.e. in case of an error should the returned replacement string again be mapped through the translation mapping or should it be copied to the output directly? The former would be more in line with encoding, but IMHO the latter would be much more useful. BTW, when I implement it I can implement patch #403100 ("Multicharacter replacements in PyUnicode_TranslateCharmap") along the way. Should the old TranslateCharmap map to the new TranslateCharmapEx and inherit the "multicharacter replacement" feature, or should I leave it as it is? > > A remaining problem is how to implement decoding error > > callbacks. In Python 2.1 encoding and decoding errors are > > handled in the same way with a string value. But with > > callbacks it doesn't make sense to use the same callback > > for encoding and decoding (like codecs.StreamReaderWriter > > and codecs.StreamRecoder do). Decoding callbacks have a > > different API. Which arguments should be passed to the > > decoding callback, and what is the decoding callback > > supposed to do? > > I'd suggest adding another set of PyCodec_UnicodeDecode... () > APIs for this. We'd then have to augment the base classes of > the StreamCodecs to provide two attributes for .errors with > a fallback solution for the string case (i.s. "strict" can > still be used for both directions). Sounds good. Now what is the decoding callback supposed to do? I guess it will be called in the same way as the encoding callback, i.e. with encoding name, original string and position of the error. It might returns a Unicode string (i.e. an object of the decoding target type), that will be emitted from the codec instead of the one offending byte. Or it might return a tuple with replacement Unicode object and a resynchronisation offset, i.e. returning (u"?", 1) means emit a '?' and skip the offending character. But to make the offset really useful the callback has to know something about the encoding, perhaps the codec should be allowed to pass an additional state object to the callback? Maybe the same should be added to the encoding callbacks to? Maybe the encoding callback should be able to tell the encoder if the replacement returned should be reencoded (in which case it's a Unicode object), or directly emitted (in which case it's an 8bit string)? > > One additional note: It is vital that errors is an > > assignable attribute of the StreamWriter. > > It is already ! I know, but IMHO it should be documented that an assignable errors attribute must be supported as part of the official codec API. Misc/unicode.txt is not clear on that: """ It is not required by the Unicode implementation to use these base classes, only the interfaces must match; this allows writing Codecs as extension types. """ ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-13 01:05 Message: Logged In: YES user_id=38388 > How the callbacks work: > > A PyObject * named errors is passed in. This may by NULL, > Py_None, 'strict', u'strict', 'ignore', u'ignore', > 'replace', u'replace' or a callable object. > PyCodec_EncodeHandlerForObject maps all of these objects to > one of the three builtin error callbacks > PyCodec_RaiseEncodeErrors (raises an exception), > PyCodec_IgnoreEncodeErrors (returns an empty replacement > string, in effect ignoring the error), > PyCodec_ReplaceEncodeErrors (returns U+FFFD, the Unicode > replacement character to signify to the encoder that it > should choose a suitable replacement character) or directly > returns errors if it is a callable object. When an > unencodable character is encounterd the error handling > callback will be called with the encoding name, the original > unicode object and the error position and must return a > unicode object that will be encoded instead of the offending > character (or the callback may of course raise an > exception). U+FFFD characters in the replacement string will > be replaced with a character that the encoder chooses ('?' > in all cases). Nice. > The implementation of the loop through the string is done in > the following way. A stack with two strings is kept and the > loop always encodes a character from the string at the > stacktop. If an error is encountered and the stack has only > one entry (during encoding of the original string) the > callback is called and the unicode object returned is pushed > on the stack, so the encoding continues with the replacement > string. If the stack has two entries when an error is > encountered, the replacement string itself has an > unencodable character and a normal exception raised. When > the encoder has reached the end of it's current string there > are two possibilities: when the stack contains two entries, > this was the replacement string, so the replacement string > will be poppep from the stack and encoding continues with > the next character from the original string. If the stack > had only one entry, encoding is finished. Very elegant solution ! > (I hope that's enough explanation of the API and implementation) Could you add these docs to the Misc/unicode.txt file ? I will eventually take that file and turn it into a PEP which will then serve as general documentation for these things. > I have renamed the static ...121 function to all lowercase > names. Ok. > BTW, I guess PyUnicode_EncodeUnicodeEscape could be > reimplemented as PyUnicode_EncodeASCII with a \uxxxx > replacement callback. Hmm, wouldn't that result in a slowdown ? If so, I'd rather leave the special encoder in place, since it is being used a lot in Python and probably some applications too. > PyCodec_RaiseEncodeErrors, PyCodec_IgnoreEncodeErrors, > PyCodec_ReplaceEncodeErrors are globally visible because > they have to be available in _codecsmodule.c to wrap them as > Python function objects, but they can't be implemented in > _codecsmodule, because they need to be available to the > encoders in unicodeobject.c (through > PyCodec_EncodeHandlerForObject), but importing the codecs > module might result in an endless recursion, because > importing a module requires unpickling of the bytecode, > which might require decoding utf8, which ... (but this will > only happen, if we implement the same mechanism for the > decoding API) I think that codecs.c is the right place for these APIs. _codecsmodule.c is only meant as Python access wrapper for the internal codecs and nothing more. One thing I noted about the callbacks: they assume that they will always get Unicode objects as input. This is certainly not true in the general case (it is for the codecs you touch in the patch). I think it would be worthwhile to rename the callbacks to include "Unicode" somewhere, e.g. PyCodec_UnicodeReplaceEncodeErrors(). It's a long name, but then it points out the application field of the callback rather well. Same for the callbacks exposed through the _codecsmodule. > I have not touched PyUnicode_TranslateCharmap yet, > should this function also support error callbacks? Why would > one want the insert None into the mapping to call the callback? 1. Yes. 2. The user may want to e.g. restrict usage of certain character ranges. In this case the codec would be used to verify the input and an exception would indeed be useful (e.g. say you want to restrict input to Hangul + ASCII). > A remaining problem is how to implement decoding error > callbacks. In Python 2.1 encoding and decoding errors are > handled in the same way with a string value. But with > callbacks it doesn't make sense to use the same callback for > encoding and decoding (like codecs.StreamReaderWriter and > codecs.StreamRecoder do). Decoding callbacks have a > different API. Which arguments should be passed to the > decoding callback, and what is the decoding callback > supposed to do? I'd suggest adding another set of PyCodec_UnicodeDecode...() APIs for this. We'd then have to augment the base classes of the StreamCodecs to provide two attributes for .errors with a fallback solution for the string case (i.s. "strict" can still be used for both directions). > One additional note: It is vital that errors is an > assignable attribute of the StreamWriter. It is already ! > Consider the XML example: For writing an XML DOM tree one > StreamWriter object is used. When a text node is written, > the error handling has to be set to > codecs.xmlreplace_encode_errors, but inside a comment or > processing instruction replacing unencodable characters with > charrefs is not possible, so here codecs.raise_encode_errors > should be used (or better a custom error handler that raises > an error that says "sorry, you can't have unencodable > characters inside a comment") Sure. > BTW, should we continue the discussion in the i18n SIG > mailing list? An email program is much more comfortable than > a HTML textarea! ;) I'd rather keep the discussions on this patch here -- forking it off to the i18n sig will make it very hard to follow up on it. (This HTML area is indeed damn small ;-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 12:18 Message: Logged In: YES user_id=89016 One additional note: It is vital that errors is an assignable attribute of the StreamWriter. Consider the XML example: For writing an XML DOM tree one StreamWriter object is used. When a text node is written, the error handling has to be set to codecs.xmlreplace_encode_errors, but inside a comment or processing instruction replacing unencodable characters with charrefs is not possible, so here codecs.raise_encode_errors should be used (or better a custom error handler that raises an error that says "sorry, you can't have unencodable characters inside a comment") BTW, should we continue the discussion in the i18n SIG mailing list? An email program is much more comfortable than a HTML textarea! ;) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 11:59 Message: Logged In: YES user_id=89016 How the callbacks work: A PyObject * named errors is passed in. This may by NULL, Py_None, 'strict', u'strict', 'ignore', u'ignore', 'replace', u'replace' or a callable object. PyCodec_EncodeHandlerForObject maps all of these objects to one of the three builtin error callbacks PyCodec_RaiseEncodeErrors (raises an exception), PyCodec_IgnoreEncodeErrors (returns an empty replacement string, in effect ignoring the error), PyCodec_ReplaceEncodeErrors (returns U+FFFD, the Unicode replacement character to signify to the encoder that it should choose a suitable replacement character) or directly returns errors if it is a callable object. When an unencodable character is encounterd the error handling callback will be called with the encoding name, the original unicode object and the error position and must return a unicode object that will be encoded instead of the offending character (or the callback may of course raise an exception). U+FFFD characters in the replacement string will be replaced with a character that the encoder chooses ('?' in all cases). The implementation of the loop through the string is done in the following way. A stack with two strings is kept and the loop always encodes a character from the string at the stacktop. If an error is encountered and the stack has only one entry (during encoding of the original string) the callback is called and the unicode object returned is pushed on the stack, so the encoding continues with the replacement string. If the stack has two entries when an error is encountered, the replacement string itself has an unencodable character and a normal exception raised. When the encoder has reached the end of it's current string there are two possibilities: when the stack contains two entries, this was the replacement string, so the replacement string will be poppep from the stack and encoding continues with the next character from the original string. If the stack had only one entry, encoding is finished. (I hope that's enough explanation of the API and implementation) I have renamed the static ...121 function to all lowercase names. BTW, I guess PyUnicode_EncodeUnicodeEscape could be reimplemented as PyUnicode_EncodeASCII with a \uxxxx replacement callback. PyCodec_RaiseEncodeErrors, PyCodec_IgnoreEncodeErrors, PyCodec_ReplaceEncodeErrors are globally visible because they have to be available in _codecsmodule.c to wrap them as Python function objects, but they can't be implemented in _codecsmodule, because they need to be available to the encoders in unicodeobject.c (through PyCodec_EncodeHandlerForObject), but importing the codecs module might result in an endless recursion, because importing a module requires unpickling of the bytecode, which might require decoding utf8, which ... (but this will only happen, if we implement the same mechanism for the decoding API) I have not touched PyUnicode_TranslateCharmap yet, should this function also support error callbacks? Why would one want the insert None into the mapping to call the callback? A remaining problem is how to implement decoding error callbacks. In Python 2.1 encoding and decoding errors are handled in the same way with a string value. But with callbacks it doesn't make sense to use the same callback for encoding and decoding (like codecs.StreamReaderWriter and codecs.StreamRecoder do). Decoding callbacks have a different API. Which arguments should be passed to the decoding callback, and what is the decoding callback supposed to do? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-12 11:00 Message: Logged In: YES user_id=38388 About the Py_UNICODE*data, int size APIs: Ok, point taken. In general, I think we ought to keep the callback feature as open as possible, so passing in pointers and sizes would not be very useful. BTW, could you summarize how the callback works in a few lines ? About _Encode121: I'd name this _EncodeUCS1 since that's what it is ;-) About the new functions: I was referring to the new static functions which you gave PyUnicode_... names. If these are not supposed to turn into non-static functions, I'd rather have them use lower case names (since that's how the Python internals work too -- most of the times). ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 09:56 Message: Logged In: YES user_id=89016 > One thing which I don't like about your API change is that > you removed the Py_UNICODE*data, int size style arguments > -- > this makes it impossible to use the new APIs on non-Python > data or data which is not available as Unicode object. Another problem is, that the callback requires a Python object, so in the PyObject *version, the refcount is incref'd and the object is passed to the callback. The Py_UNICODE*/int version would have to create a new Unicode object from the data. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 09:32 Message: Logged In: YES user_id=89016 > * please don't place more than one C statement on one line > like in: > """ > + unicode = unicode2; unicodepos = > unicode2pos; > + unicode2 = NULL; unicode2pos = 0; > """ OK, done! > * Comments should start with a capital letter and be > prepended > to the section they apply to Fixed! > * There should be spaces between arguments in compares > (a == b) not (a==b) Fixed! > * Where does the name "...Encode121" originate ? encode one-to-one, it implements both ASCII and latin-1 encoding. > * module internal APIs should use lower case names (you > converted some of these to PyUnicode_...() -- this is > normally reserved for APIs which are either marked as > potential candidates for the public API or are very > prominent in the code) Which ones? I introduced a new function for every old one, that had a "const char *errors" argument, and a few new ones in codecs.h, of those PyCodec_EncodeHandlerForObject is vital, because it is used to map for old string arguments to the new function objects. PyCodec_RaiseEncodeErrors can be used in the encoder implementation to raise an encode error, but it could be made static in unicodeobject.h so only those encoders implemented there have access to it. > One thing which I don't like about your API change is that > you removed the Py_UNICODE*data, int size style arguments > -- > this makes it impossible to use the new APIs on non-Python > data or data which is not available as Unicode object. I look through the code and found no situation where the Py_UNICODE*/int version is really used and having two (PyObject *)s (the original and the replacement string), instead of UNICODE*/int and PyObject * made the implementation a little easier, but I can fix that. > Please separate the errors.c patch from this patch -- it > seems totally unrelated to Unicode. PyCodec_RaiseEncodeErrors uses this the have a \Uxxxx with four hex digits. I removed it. I'll upload a revised patch as soon as it's done. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-12 07:29 Message: Logged In: YES user_id=38388 Thanks for the patch -- it looks very impressive !. I'll give it a try later this week. Some first cosmetic tidbits: * please don't place more than one C statement on one line like in: """ + unicode = unicode2; unicodepos = unicode2pos; + unicode2 = NULL; unicode2pos = 0; """ * Comments should start with a capital letter and be prepended to the section they apply to * There should be spaces between arguments in compares (a == b) not (a==b) * Where does the name "...Encode121" originate ? * module internal APIs should use lower case names (you converted some of these to PyUnicode_...() -- this is normally reserved for APIs which are either marked as potential candidates for the public API or are very prominent in the code) One thing which I don't like about your API change is that you removed the Py_UNICODE*data, int size style arguments -- this makes it impossible to use the new APIs on non-Python data or data which is not available as Unicode object. Please separate the errors.c patch from this patch -- it seems totally unrelated to Unicode. Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=432401&group_id=5470 From noreply@sourceforge.net Mon Jul 23 20:23:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 12:23:19 -0700 Subject: [Patches] [ python-Patches-443788 ] Small documentation fixes Message-ID: Patches item #443788, was opened at 2001-07-23 06:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443788&group_id=5470 Category: documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Small documentation fixes Initial Comment: Some minor fixes I collected while reading the documentation (from CVS) recently. Files affected: - dist/src/Doc/lib/libanydbm.tex - dist/src/Doc/lib/libexcs.tex - dist/src/Doc/lib/libos.tex - dist/src/Doc/lib/liburllib.tex ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-23 12:23 Message: Logged In: YES user_id=3066 (Patched emailed directly to me due to SF snafu.) Checked in as Doc/lib/liburllib.tex revision 1.37, Doc/lib/libexcs.tex revision 1.39, Doc/lib/libos.tex revision 1.62, and Doc/lib/libanydbm.tex revision 1.19. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443788&group_id=5470 From noreply@sourceforge.net Mon Jul 23 20:35:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 12:35:15 -0700 Subject: [Patches] [ python-Patches-443899 ] Minor fix to gzip.py module. Message-ID: Patches item #443899, was opened at 2001-07-23 12:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443899&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Titus Brown (titus) Assigned to: Nobody/Anonymous (nobody) Summary: Minor fix to gzip.py module. Initial Comment: --- from cStringIO import StringIO from gzip import GzipFile stringFile = StringIO() gzFile = GzipFile("test1", 'wb', 9, stringFile) gzFile.write('howdy there!') r = gzFile.read() --- the above code fragment gave a nonintuitive error response (attribute missing). Now, an exception is raised stating that the file is not opened for reading or writing. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443899&group_id=5470 From noreply@sourceforge.net Mon Jul 23 20:35:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 12:35:59 -0700 Subject: [Patches] [ python-Patches-442530 ] Distutils config buggy Message-ID: Patches item #442530, was opened at 2001-07-18 11:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442530&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tarn Weisner Burton (twburton) >Assigned to: Greg Ward (gward) Summary: Distutils config buggy Initial Comment: The config command of distutils has some types in it First every time the _preprocess or _compile method is called the include_dirs argument is omitted. Second the search_cpp method tries to do a re search with the line: if pattern.search(pattern): which should be if pattern.search(line): I've attached a complete corrected version from CVS. Tarn ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442530&group_id=5470 From noreply@sourceforge.net Mon Jul 23 20:36:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 12:36:35 -0700 Subject: [Patches] [ python-Patches-443899 ] Minor fix to gzip.py module. Message-ID: Patches item #443899, was opened at 2001-07-23 12:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443899&group_id=5470 Category: library Group: None Status: Open Resolution: None >Priority: 2 Submitted By: Titus Brown (titus) >Assigned to: A.M. Kuchling (akuchling) Summary: Minor fix to gzip.py module. Initial Comment: --- from cStringIO import StringIO from gzip import GzipFile stringFile = StringIO() gzFile = GzipFile("test1", 'wb', 9, stringFile) gzFile.write('howdy there!') r = gzFile.read() --- the above code fragment gave a nonintuitive error response (attribute missing). Now, an exception is raised stating that the file is not opened for reading or writing. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443899&group_id=5470 From noreply@sourceforge.net Mon Jul 23 20:37:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 12:37:44 -0700 Subject: [Patches] [ python-Patches-443899 ] Minor fix to gzip.py module. Message-ID: Patches item #443899, was opened at 2001-07-23 12:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443899&group_id=5470 Category: library Group: None Status: Open Resolution: None >Priority: 5 Submitted By: Titus Brown (titus) >Assigned to: Jeremy Hylton (jhylton) Summary: Minor fix to gzip.py module. Initial Comment: --- from cStringIO import StringIO from gzip import GzipFile stringFile = StringIO() gzFile = GzipFile("test1", 'wb', 9, stringFile) gzFile.write('howdy there!') r = gzFile.read() --- the above code fragment gave a nonintuitive error response (attribute missing). Now, an exception is raised stating that the file is not opened for reading or writing. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443899&group_id=5470 From noreply@sourceforge.net Mon Jul 23 20:48:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 12:48:59 -0700 Subject: [Patches] [ python-Patches-443551 ] Minor change to pager choice in pydoc.py Message-ID: Patches item #443551, was opened at 2001-07-22 09:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443551&group_id=5470 Category: demos and tools Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Alex Coventry (alex_coventry) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Minor change to pager choice in pydoc.py Initial Comment: If $PAGER is not set, and the "less" command works, then pydoc pipes its output to less. If $TERM is "dumb", or "emacs", this is a pretty inconvenient choice. This patch sends the output to stdout in those cases. I find it easier to use, especially when working with in a shell subordinate to emacs, where you can use the paging facilities of emacs itself anyway. Alex. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-23 12:48 Message: Logged In: YES user_id=3066 Checked in as Lib/pydoc.py revision 1.40, then changed to use plainpager in 1.41. Can't we just nuke all the dumb terminals? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-22 09:27 Message: Logged In: YES user_id=6380 Shouldn't it return plainpager rather than a function that doesn't page at all? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443551&group_id=5470 From noreply@sourceforge.net Mon Jul 23 21:53:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 13:53:36 -0700 Subject: [Patches] [ python-Patches-422106 ] Seg fault in sys.displayhook Message-ID: Patches item #422106, was opened at 2001-05-07 13:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422106&group_id=5470 Category: core (C code) Group: None Status: Closed Resolution: Accepted Priority: 7 Submitted By: Gregory H. Ball (greg_ball) >Assigned to: Moshe Zadka (moshez) Summary: Seg fault in sys.displayhook Initial Comment: If you do a very silly thing and delete the "__builtin__" entry from sys.modules, the default displayhook is defeated. This problem exists in 2.1 and current CVS, but not 2.0 (The old display loop held a reference to the builtin module instead of repeatedly fetching it in 2.0, I guess.) My patch just checks whether the module is in the expected location and raises an exception instead of dumping core. The error message is not especially illuminating, but then, anyone who actually does this deserves far worse ;-) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-23 13:53 Message: Logged In: YES user_id=31435 Back to you, as I don't know which branch you're talking about. If there's to be a 2.0.2 or 2.1.2 release I haven't heard about it, but if there is then this is something for the appropriate release manager to do. If you're talking about descr-branch, all checkins to the trunk automatically show up there (eventually). ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2001-07-23 06:40 Message: Logged In: YES user_id=11645 Tim, I'm assigning to you so you can check this in on the release branch. There's no section in the FAQ on how the new procedure works SF-wise. Checked into the main branch as Python/sysmodule version 2.90 ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-05-07 13:10 Message: Logged In: YES user_id=11365 The problem: Python 2.2a0 (#13, May 7 2001, 15:45:00) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import sys >>> del sys.modules['__builtin__'] >>> 1 Segmentation fault (core dumped) The solution: Python 2.2a0 (#16, May 7 2001, 16:03:33) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import sys >>> del sys.modules['__builtin__'] >>> 1 Traceback (most recent call last): File "", line 1, in ? RuntimeError: lost __builtin__ >>> ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422106&group_id=5470 From noreply@sourceforge.net Tue Jul 24 07:45:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 23:45:55 -0700 Subject: [Patches] [ python-Patches-443673 ] Build _socket on cygwin32 Message-ID: Patches item #443673, was opened at 2001-07-22 19:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443673&group_id=5470 Category: Windows Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Nobody/Anonymous (nobody) Summary: Build _socket on cygwin32 Initial Comment: (just tested on a new install of cygwin32 and a fresh pull of descr-branch from cvs) Treat __CYGWIN32__ just like MS_WIN32 when deciding whether to declare h_errno in getaddrinfo.c The resulting socketmodule seems to work, including a successful 'python -c "import test.test_socket"' ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-23 23:45 Message: Logged In: YES user_id=21627 This patch should be out of date now, since I just removed the declaration of h_errno. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443673&group_id=5470 From noreply@sourceforge.net Tue Jul 24 07:48:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 23:48:42 -0700 Subject: [Patches] [ python-Patches-443669 ] Permit _tkinter to build on cygwin32 Message-ID: Patches item #443669, was opened at 2001-07-22 19:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443669&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Nobody/Anonymous (nobody) Summary: Permit _tkinter to build on cygwin32 Initial Comment: This is a patch to setup.py which allows the _tkinter module to be built on cygwin32. I have just tested it on a descr-branch checkout of the cvs tree. These instructions are based on those by Norman Vine, as found at http://www.vso.cape.com/~nhv/files/python/tinker.html . For this to work, you also need to install the "X11" headers available from that page. The patch does two things: * Search for tcl and tk libraries with version numbers like "80" as well as "8.0" * Do not attempt to link libX11 when compiling on cygwin It's not completely clear that the latter is always correct, because it is apparently legal to build X clients under cygwin. It is correct and necessary to build a _tkinter which can display to a win32 system. (Is there machinery to test whether -lX11 is necessary for -ltk, and include it only in that case?) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-23 23:48 Message: Logged In: YES user_id=21627 I would not worry about an X11 Tk installation on Windows too much. This is not cygwin specific; you can also build the X11 libraries using MSVC. In any case, tk.dll should be linked itself with x11.dll (or whatever the library name is), so there should be no need to link it explicitly. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443669&group_id=5470 From noreply@sourceforge.net Tue Jul 24 07:55:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 23:55:07 -0700 Subject: [Patches] [ python-Patches-443669 ] Permit _tkinter to build on cygwin32 Message-ID: Patches item #443669, was opened at 2001-07-22 19:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443669&group_id=5470 Category: Windows Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Nobody/Anonymous (nobody) Summary: Permit _tkinter to build on cygwin32 Initial Comment: This is a patch to setup.py which allows the _tkinter module to be built on cygwin32. I have just tested it on a descr-branch checkout of the cvs tree. These instructions are based on those by Norman Vine, as found at http://www.vso.cape.com/~nhv/files/python/tinker.html . For this to work, you also need to install the "X11" headers available from that page. The patch does two things: * Search for tcl and tk libraries with version numbers like "80" as well as "8.0" * Do not attempt to link libX11 when compiling on cygwin It's not completely clear that the latter is always correct, because it is apparently legal to build X clients under cygwin. It is correct and necessary to build a _tkinter which can display to a win32 system. (Is there machinery to test whether -lX11 is necessary for -ltk, and include it only in that case?) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-23 23:55 Message: Logged In: YES user_id=21627 Thanks, this has been installed as setup.py 1.43. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-23 23:48 Message: Logged In: YES user_id=21627 I would not worry about an X11 Tk installation on Windows too much. This is not cygwin specific; you can also build the X11 libraries using MSVC. In any case, tk.dll should be linked itself with x11.dll (or whatever the library name is), so there should be no need to link it explicitly. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443669&group_id=5470 From noreply@sourceforge.net Tue Jul 24 08:00:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Jul 2001 00:00:06 -0700 Subject: [Patches] [ python-Patches-413011 ] Port to UnixWare 7.1.x for Python 2.1 Message-ID: Patches item #413011, was opened at 2001-04-02 00:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: Port to UnixWare 7.1.x for Python 2.1 Initial Comment: The attached file contains patches and files needed to allow Python-2.1(b2a) to be configured and compiled successfully on a SCO UnixWare 7.1.x system using the SCO Universal Development Kit (UDK). The compiled Python-2.1(2ba) executable did not fail any tests except for the atan2(0,1) math test. UnixWare returns pi instead of the expected 0.0 result. The Python-2.1 on UnixWare 7.1.x will have a shared Python-2.1 library, have dynamically loadable modules, and support for theads. The attached tar file (Python-2.1b2a-UW7.tar.gz) contains a README file describing the details of the changes. The MD5 checksum for the attached file is: 46704c26064c41f195decccd60adffab Billy G. Allie ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-24 00:00 Message: Logged In: YES user_id=21627 A part of this patch has been reverted for 2.2, namely usage of ld to link, detection of -Kpthread, and building of libpython as a shared library. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-22 10:56 Message: Logged In: YES user_id=21627 1. Instead of requiring administrators to set LD_RUN_PATH, configure should automatically set all proper options, -R/lib in this case. However, I still doubt that using a shared library offers advantages: a. According to my measurements, linking python statically brings a 50% speed-up in startup time when *not* using shared libraries. This is because: I. fewer shared libraries have to be located and loaded II. the LD_RUN_PATH is shorter, so fewer directories have to be searched III. The main part of the interpreter is not compiled with -KPIC; PIC code is typically slower since EBX is not available to the optimizer. The size of the executable is pointless; the system has to load libpython21.so in the shared case, which is 800k b. There is typically only a single executable relying on libpython.so, so the administrative overhead of replacing the library is the same as replacing the executable. There may be applications to a shared libpython, but given the pain that this causes, that should be a configuration option, and off by default. As an option, it should equally apply to all ELF-based systems, at a minimum. 3. crti and crtn are needed in *every* shared library, otherwise, constructors don't work. Use -# to see how the linker is invoked for -G, to notice that it not only links crti/crtn, but also libcrt. 4. I just checked that supporting -lpthread is required by Single Unix from conforming implementations, see http://www.opengroup.org/onlinepubs/007908799/xcu/c89.html So I'm surprised your UnixWare copy does not support it. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-21 15:38 Message: Logged In: YES user_id=8500 1. when compiling, you need to set LD_RUN_PATH to the directory that will contain the shared library. This is or should be standard operating procedure whenerve compiling programs that use shared libraries. Doing this prevents having to have LD_LIBRARY_PATH set when executing the program. For my use, I set LD_RUN_PATH=/usr/local/lib:/usr/local/pgsql/lib. Since I know I will be accessing PostgreSQL from python, I let python know that I will be using shared libraries contained in /usr/local/pgsql/lib. You would only need to set LD_LIBRARY_PATH=. when first building and testing python. The advantage of using a shared library includes, but is not limited to: a. Faster start-up times once the library is loaded into memory. Loading a 5k executable is faster than loading a 760k executable. b. Executables and other shared modules will not have to be recompiled if a fix needs to be made to one of the objects in the shared library (that does not invole change the parameter or return value of the object). 2. But the options do something - they make explicit the intent of the code. Also, what happens if the defaults change (not likely, I must admit, but possiple). Rather, then make matenance more difficult, I believe that it makes it easier, since the true intent is clear. But, I fear were are treading into the realm of philosopy and the "way to do things", where everyone has an (a differing, but equally valid) opinion, 3. I never said that they were not needed, only that they are included in the program using the shared library, not the library itself. 4. I have he save compiler version, but my cc(1) does not mention the -Kpthread flag. I will check into this and will change the UnixWare build to use it. It would appear to alieviate the need to implement the fork1() call. As to rolling out the patch, I disagree. Having the shared library does have some addvantages, and the proper setting/use of LD_RUN_PATH and LD_LIBRARY_PATH can be handled with a platform specific FAQ. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-21 06:18 Message: Logged In: YES user_id=21627 Dear Mr Allie, 0. cc -V reports Optimizing C Compilation System (CCS) 4.0 10/23/00 (UDK FS 7.1.1b) 1. Support for threads on UnixWare was there before the patch was applied. I don't think the patch really supports generating a shared Python library, though. When I compile Python 2.1, I get, after the first stage build, PYTHONPATH= ./python ./setup.py build dynamic linker : ./python : could not open libpython2.1.so *** Error code 137 (bu21) The cause is that the location of libpython2.1.so is not known to the dynamic linker. So your port does not work out of the box, the user is required to set LD_LIBRARY_PATH. This is precisely the reason why no other Unix port uses a shared libpython: it only causes problems, and gives no advantages. Why do you want libpython as a shared library? 2. It simplifies maintenance, since maintainers can reason whether some option needs to be carried over to a future release of the same system or a slightly similar system. Options that don't do anything cause confusion. 3. crti.o and crtn.o are certainly needed, they provide the .init and .fini section, and arrange to execute the .ctor and .dtor sections. See also bugreport 417491. 5. The mentioned compiler does support -Kpthread, cc(1) reports pthread Causes the same effect as -Kthread, except that in addition POSIX threads semantics are enabled at runtime for the fork(2), raise(3C), thr_exit(3thread), and pthread_exit(3pthread) calls. -lpthread is an acceptable synonym for -Kpthread. Therefore, even though there is no libpthread on the system, -lpthread can still be passed to the compiler, and the standard pthread detection routines in Python will work correctly. So in short, I think the entire patch should be backed out, and any remaining problems should be fixed differently. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-18 22:03 Message: Logged In: YES user_id=8500 loewis, First, a question. Are you using the SCO UDK compiler to compile Python? The UDK is the target compiler addressed by these patches (see the README file included with the patch). 1. This patch added support for using threads and to generate a shared Python library. 2. There is no reason to not explicitly specify the argument that are the defaults either. 3. I'll cede the point about using cc to link the shared modules, but the shared library does not need crti.o and crtn.o. They would be linked into the executable that references the shared library. 4. Perhaps, but my goal was to get UnixWare to compile with thread support and using shared libraries. I do not have access to those other systems, so I could not make chages to the way configure handles them (I wouldn't be able to test those changes). If others would like to make those changes, I would be willing to work with them to come up with a uniform way of teating the similar systems. 5. The UnixWare UDK requires the use of -Kthread to control the (correct) linking of the thread libraries. Using -lthread is specifically warned against. There is no -Kpthread option nor is there a libpthread library. The -Kthread option will load the POSIX thread routines if they are used. To reiterate, my goal was to be able to compile on UnixWare using shared libraries and including supprot for threads. I also wanted to do this in a manner that would not affect how other systems were handled. Again, I only have a UnisWare system on whick to build and test the changes. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-13 15:04 Message: Logged In: YES user_id=21627 Even though this patch has been applied, I'd like to express my concerns about it. First, Python 2.1b2 was compiling correctly on UnixWare even without this patch, atleast since configure.in 1.212. So what specific problem had been corrected with this patch? Next, the patch seems to overspecify compiler and linker options. Eg. -dy is the default, so there is no need to explicitly specify it. Also, in many cases, using cc to link executables and libraries is better than using ld, since cc will automatically pass missing options, object files, and libraries. E.g. with your options, crti.o and crtn.o won't be included into the shared libraries, but should be (See Notices in ld(1)). The patch adds code specific to UnixWare which would apply to many other systems (Solaris, Linux, ReliantUnix), and it would be good if these systems would be treated uniformly. E.g. it creates libpython as a shared library. Why only on Unixware, why not on Solaris or Linux? Likewise, why the special casing on threads? There are other systems (SysV variants) that also support -Kthread, so there should be a test whether the compiler supports the flag, not whether the system is Unixware. Also, shouldn't this be -Kpthread, not -Kthread? Finally, isn't just using -lpthread enough? ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 14:19 Message: Logged In: YES user_id=8500 Every thing looks fine (as far as I can tell). Thanks. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-11 14:00 Message: Logged In: YES user_id=6380 Thanks, that's much better! Applied now. (Please check that I checked everything in... :-) ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 13:13 Message: Logged In: YES user_id=8500 here is the MD5 checksum for the corrected patch: MD5 (Python-2.1b2a.UW7.p2.tar.gz) = 62941fcbdd0d4272767b52b2a42d9388 ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 13:08 Message: Logged In: YES user_id=8500 Here is a corrected patch file. I pulled the latest files from CVS and patched those. These should be fine. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:47 Message: Logged In: YES user_id=6380 Something went wrong with tabs and spaces in your patch; it appears the version of the sources you diffed against had some tabs replaced with spaces or vice versa. Unless yu can supply a correct context diff really fast, I won't be able to include this patch in Python 2.1. I don't have the time to review every change and to manually apply the chunks that patch rejects. (Esp. configure.in). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470 From noreply@sourceforge.net Tue Jul 24 08:04:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Jul 2001 00:04:56 -0700 Subject: [Patches] [ python-Patches-403743 ] [windows] Correction to bug #131273 Message-ID: Patches item #403743, was opened at 2001-02-12 01:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403743&group_id=5470 Category: Windows Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Christophe Gouiran (cgouiran) Assigned to: Mark Hammond (mhammond) Summary: [windows] Correction to bug #131273 Initial Comment: I found a bug in the posixmodule.c file, not killing children processes when exiting python. Now in the posixmodule i wrote a win32_atexit() function that does the trick. Then it's registered it in the INITFUNC function with the atexit() function. Now at exit, any children process are automatically killed. The patch must be applyed in the module directory, not at the python root one. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-24 00:04 Message: Logged In: YES user_id=21627 Since there has been no update to the patch for quite some time, I close it as "Invalid". If you still have the code and would like to contribute it, please submit a new patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 13:45 Message: Logged In: YES user_id=21627 It appears that the patch is a nearly empty file containing only garbage. Christophe, you probably should try uploading it again. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-02-12 08:07 Message: Assigned to Mark Hammond since the original bug is already assigned to him. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403743&group_id=5470 From noreply@sourceforge.net Tue Jul 24 09:20:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Jul 2001 01:20:04 -0700 Subject: [Patches] [ python-Patches-403743 ] [windows] Correction to bug #131273 Message-ID: Patches item #403743, was opened at 2001-02-12 01:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403743&group_id=5470 Category: Windows Group: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: Christophe Gouiran (cgouiran) Assigned to: Mark Hammond (mhammond) Summary: [windows] Correction to bug #131273 Initial Comment: I found a bug in the posixmodule.c file, not killing children processes when exiting python. Now in the posixmodule i wrote a win32_atexit() function that does the trick. Then it's registered it in the INITFUNC function with the atexit() function. Now at exit, any children process are automatically killed. The patch must be applyed in the module directory, not at the python root one. ---------------------------------------------------------------------- >Comment By: Christophe Gouiran (cgouiran) Date: 2001-07-24 01:20 Message: Logged In: YES user_id=45945 Hi, unfortunately i had a crashdisk few days ago. I can't no more put a hand on this patch, sorry. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-24 00:04 Message: Logged In: YES user_id=21627 Since there has been no update to the patch for quite some time, I close it as "Invalid". If you still have the code and would like to contribute it, please submit a new patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 13:45 Message: Logged In: YES user_id=21627 It appears that the patch is a nearly empty file containing only garbage. Christophe, you probably should try uploading it again. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-02-12 08:07 Message: Assigned to Mark Hammond since the original bug is already assigned to him. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403743&group_id=5470 From noreply@sourceforge.net Tue Jul 24 21:36:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Jul 2001 13:36:49 -0700 Subject: [Patches] [ python-Patches-401196 ] IPv6 patch against 2.0 CVS tree, as of 20010624 Message-ID: Patches item #401196, was opened at 2000-08-16 05:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401196&group_id=5470 Category: core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jun-ichiro itojun Hagino (itojun) Assigned to: Martin v. Löwis (loewis) Summary: IPv6 patch against 2.0 CVS tree, as of 20010624 Initial Comment: ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-24 13:36 Message: Logged In: YES user_id=21627 The last chunk of this patch was committed as BaseHTTPServer.py 1.16 SocketServer.py 1.26 ftplib.py 1.54 httplib.py 1.36 poplib.py 1.15 smtplib.py 1.37 telnetlib.py 1.12 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-21 11:55 Message: Logged In: YES user_id=21627 The socketmodule.c part has been committed as socketmodule.c 1.153. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-24 14:59 Message: Logged In: YES user_id=21627 I have uploaded a new version sent by itojun. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-09 12:15 Message: Logged In: YES user_id=21627 On the API, I have the following comments: - Why is it necessary to introduce gethostbyname2? I recommend to give gethostbyname an optional argument for the address family. - getaddrinfo, when raising a socket error, should include the EAI_ error number. Perhaps there should be a way tod istinguish EAI_ errnos from other errnos, e.g. by subclassing socket error. Otherwise, the API of the C part looks good to me. Ih aven't looked at the Lib part, yet. On the implementation: - I still have problems building the code. Currently, I get the following rejects: ./Lib/BaseHTTPServer.py.rej ./Lib/ftplib.py.rej ./Lib/poplib.py.rej ./Lib/smtplib.py.rej ./Modules/socketmodule.c.rej ./Objects/fileobject.c.rej - The fileobject.c chunk seems to be unnecessary. - On the test problem: It occurs in + test -d -a -f /lib.a ./configure: test: too many arguments which comes from ipv6libdir and ipv6libdir being empty. - The WIDE files should be included in the Modules directory, as they are only used from socketmodule.c. In particular, addrinfo.h should not be installed. - If you can, please include a patch to Doc/lib/libsocket.tex. If not, I will try to draft one. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-05-30 10:34 Message: Logged In: NO i looked at python-dev email. the proposal (split patches) looks fine, but the exact example given in python-dev email is not reasonable. i cannot just send out configure.in change separately from source code changes, period. i can split patches for *.py files separately though. there's more important issue, which is, APi changes for Socket class. i really hoped to get some comment on that part. i really appreciate your comments. i would like to propose that once we nailed down API changes, integrate the patch into the tree. with all #ifdef INET6 in place there should be no impact on IPv4-only builds. i have trouble tracking python development (i'm not a sourceforge expert!), so forgive me for delays in patch submissions. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-05-18 08:29 Message: Logged In: YES user_id=6380 See http://mail.python.org/pipermail/python-dev/2001-May/014889.html for comments from MvL. I'm unassigning this from Fred, he has nothing to do with this. ---------------------------------------------------------------------- Comment By: Jun-ichiro itojun Hagino (itojun) Date: 2001-02-26 02:24 Message: Logged In: YES user_id=63767 about /usr/bin/test argument: does linux /usr/bin/test have -d support? if not, we may need to change configure.in slightly. you are correct that fallback getaddrinfo/getnameinfo.c was missing in the patch. sorry. a question i need to ask is, do we need to supply Python function Socket.getaddrinfo on platforms that do not have getaddrinfo(3)? HAVE_ADDRINFO is used in Include/addrinfo.h, which is also missing in the patch set i have submitted. i've put the missing files into http://www.itojun.org/diary/20001230/missing.shar. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-02-23 23:58 Message: After a shallow review of this patch, I found the following issues: configure.in does not need to list both enable and disable options. When running configure, I got the following error message on Linux checking whether to enable ipv6... yes checking ipv6 stack type... linux-glibc ./configure: test: too many arguments using libc The call to /usr/bin/test should be corrected; I could not find out which specific invocation caused the problem. HAVE_ADDRINFO is not used. Perhaps getaddrinfo.c/getnameinfo.c is missing in the patch? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-04 07:51 Message: A new patch is available. I've changed the subject accordingly. Due to upload size restrictions, the patch is now at http://www.itojun.org/diary/20001230/python-2.0-v6-20001230.diff.gz ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2000-12-30 07:25 Message: I got *many* rejects when trying to apply this patch to today's CVS tree. I recommend that patches for generated files (config.h.in, configure) are not included in the patch because they outdate too easily. A number of changes in this patch have already been done by somebody else; others just don't fit into the current code anymore (perhaps due to indentation changes?). Anyway, I'll mark the patch as out-of-date. Please let me know when you upload a new version. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-08-16 07:00 Message: Postponed until Python 2.1 -- there's not enough time to review this and get it sufficiently tested on enough IPv6-connected platforms in time for 2.0, and we're already in feature freeze. This should go into the tree very quickly once Python 2.0 has been released. Assigned to myself to open it back up after Python 2.0. ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2000-08-16 06:07 Message: Assigned to Tim, since he's in charge of postponing new features. I'm to timid to postpone it myself. ---------------------------------------------------------------------- Comment By: Jun-ichiro itojun Hagino (itojun) Date: 2000-08-16 05:59 Message: this is revised version of patch #101186 (now with my SourceForge accout... i'm not familiar with the system here, so forgive my possible mistake). 1.6b1 patch applied mostly clean to 2.0. It is confirmed that: - 1.6b1 + IPv6 patch works fine on NetBSD 1.4.2 + KAME, and NetBSD 1.5 - 1.6b1 + IPv6 patch works fine on NetBSD 1.4.2 (NOT an IPv6 ready machine) - 2.0 CVS tree + IPv6 patch works fine on NetBSD + KAME forgot to attach the following into the diff - so i attach it (README.v6) here as comment. I have submitted the patch for 1.5.1, 1.5.2 and 1.6b1, all hit a bad timing - bad luck. contact: core@kame.net, or itojun@kame.net --- IPv6-ready python 1.6 KAME Project $KAME: README.v6,v 1.9 2000/08/15 02:40:38 itojun Exp $ This patchkit enables python 1.6 to perform AF_INET6 socket operations. The only affected module is Modules/socketmodule.c. Modules/socketmodule.c In most cases, IPv6 address can be placed where IPv4 address fits. sockaddr sockaddr tuple is formatted as follows: IPv4: (host, port) IPv6: socket class methods always generate (host, port, flowinfo, scopeid). socket class methods will accept 2, 3, or 4 tuple (for backward compatibility). Compatibility warning: Some of the scripts assume that the sockaddr structure is 2 tuple, like: host, port = sock.getpeername() this will fail if you are connected to IPv6 node. socket.getaddrinfo(host, port [, family, socktype, proto, flags]) host: String or None port: String, Int or None family, socktype, proto, flags: Int, can be omitted Perform getaddrinfo(3). Returns List of the following 5 tuple: (family, socktype, proto, canonname, sockaddr) family: Int socktype: Int proto: Int canonname: String sockaddr: sockaddr (see above) See Lib/httplib.py for typical usage on the client side. socket.getnameinfo(sockaddr, flags) sockaddr: sockaddr flags: Int Perform getnameinfo(3). Returns the following 2 tuple: host: String, numeric or hostname depending on flgags port: String, numeric or portname depending on flgags socket.gethostbyname2(host, af) host: String af: Int Performs gethostbyname2(3). Returns numeric address representation for "host". socket.gethostbyaddr(addr) (behavior change if IPv6 support is compiled in) addr: String Performs gethostbyaddr(3). Returns string address representation for "addr". The function can take IPv6 numeric address as well. This behavior is not problematical, because - if you pass numeric "addr" parameter, we can always identify address family for it - return value is string address reprsentation, where IPv6 and IPv4 are not distinguishable. socket.bind(sa), socket.connect(sa) and others. (No behavior change, but be careful) See above for sockaddr format change. With Python "addr" portion of sockaddr (first element) can be string hostname. When the string hostname resolved to numeric address, it will obey address family of the socket (which was specified when socket.socket() was called). If you give some string that does not give matching address family, you will get some error. s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) # this is okay, if 'localhost' resolves to both IPv4/v6 s.connect('localhost', 80) # this is not okay, of course s.connect('::1', 80) # this is not okay, as v6only.kame.net will not resolve to IPv4 s.connect('v6only.kame.net', 80) Lib/httplib.py IPv6 ready. "host" in HTTP(host) will accept the following 3 forms: [host]:port host:port there must be only single colon host This is to allow IPv6 numeric URL (http://[host]:port/) in documents. IMHO "host:port" parsing should be implemented in urllib.py, not here. Lib/ftplib.py IPv6 ready. This uses EPSV/EPRT on IPv6 ftp. See RFC2428 for protocol details. Lib/SocketServer.py IPv6 ready. Wildcard bind on TCPServer, i.e. TCPServer(('', port)), will bind to wildcard socket on TCPServer.address_family. TCPServer.addresss_family is set to AF_INET by default, so ('', port) will usually bind AF_INET. Lib/smtplib.py, Lib/telnetlib.py, Lib/poplib.py IPv6 ready. Not much to say about protocol details - they just use TCP over IPv6. configure Configure has extra option, --enable-ipv6 and --disable-ipv6. The option controls IPv6 support feature. dynamic link issues in Modules/socketmodule.c Modules/socketmodule.c can be dynamically loaded only in the following situations: - getaddrinfo(3) and getnameinfo(3) are supplied by OS vendor in libc, and libc is dynamic link library. - OS vendor is NOT supplying getaddrinfo(3) nor getnameinfo(3), and You are configuring this package with --disable-ipv6. In this case, you'll be using missing/get{addr,name}info.c and they will refer to gethostby{name,addr}. gethostnameby{name,addr} can usually be found in dynamic-linking libc. In other situations, such as the following, please link Modules/socketmodule.c into python itself. - getaddrinfo(3) and getnameinfo(3) are supplied by OS vendor, but they are in statically linked library like libinet6.a. (KAME falls into this category) python usually links Modules/socketmodule.c into python itself (due to its popularity) so there should be no problem. restrictions - The patched tree will not use gethostbyname_r and other thread-ready libraries. Instead, it will use getaddrinfo() and getnameinfo() throughout the operation. todo - Patch bunch of library files in Lib/*.py. compatibility issues with existing scripts If you disable IPv6 support (./configure --disable-ipv6), the patched code is mostly compatible with original Python (except files in "Lib" directory modified for dual stack support). User script may choke if: - IPv4/v6 dualstack libc is supplied, python is compiled for dual stack, and script assumes some of IPv4-only behavior (especially sockaddr) - IPv4/v6 dualstack libc is supplied, python is compiled for IPv4 only, and script assumes some of IPv4-only behavior. In this case, Python socket class itself does not support IPv6, however, name resolution functions can return IPv6 names since they use IPv6-ready libc functions! I do not recommend this configuration. - script assumes certain IPv4-only version behavior in Lib/*.py. compilation If you use IPv6 features, it is assumed that you have working getaddrinfo() and getnameinfo() library functions. We have noticed that some of IPv6 stack is shipped with broken getaddrinfo(). In such cases, use missing/get{addr,name}info.c instead (but then, you need to have working getipnodeby{name,addr}). If you compile this on IPv4-only machine without get{addr,name}info, missing/get{addr,name}info.c will be used. They are from KAME IPv6 distribution and is #ifdef'ed for IPv4 only support. They are fairly complete implementation and you don't need to bother with bind 8.2 (bind 8.2 get{addr,name}info() has bugs). When compiling this kit on IPv6 node, you may need to specify some additional library paths or cpp defs. (like -linet6 or -DINET6) --enable-ipv6 will give you some warning, if the IPv6 stack is unknown to the "configure" script. Currently, the following IPv6 stacks are officially supported (i.e. we've checked that the package works well): - KAME IPv6 stack, http://www.kame.net/ References RFC2553, for getaddrinfo(3) and getnameinfo(3). Author contacts http://www.kame.net/ mailto:core@kame.net ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401196&group_id=5470 From noreply@sourceforge.net Wed Jul 25 07:16:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Jul 2001 23:16:26 -0700 Subject: [Patches] [ python-Patches-444359 ] Remove unused imports Message-ID: Patches item #444359, was opened at 2001-07-24 23:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=444359&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Remove unused imports Initial Comment: This patch removes a number of unneeded import statements from the standard library. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=444359&group_id=5470 From noreply@sourceforge.net Wed Jul 25 15:20:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Jul 2001 07:20:42 -0700 Subject: [Patches] [ python-Patches-444359 ] Remove unused imports Message-ID: Patches item #444359, was opened at 2001-07-24 23:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=444359&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Remove unused imports Initial Comment: This patch removes a number of unneeded import statements from the standard library. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-25 07:20 Message: Logged In: YES user_id=6380 Note: pychecker sometimes lies about unised imports, e.g. when the import is only used during module initialization. Did you check that these are really unneeded? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=444359&group_id=5470 From noreply@sourceforge.net Wed Jul 25 15:40:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Jul 2001 07:40:27 -0700 Subject: [Patches] [ python-Patches-444359 ] Remove unused imports Message-ID: Patches item #444359, was opened at 2001-07-24 23:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=444359&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Remove unused imports Initial Comment: This patch removes a number of unneeded import statements from the standard library. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-25 07:40 Message: Logged In: YES user_id=21627 Yes, I've checked them all; I still may have made a mistake. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-25 07:20 Message: Logged In: YES user_id=6380 Note: pychecker sometimes lies about unised imports, e.g. when the import is only used during module initialization. Did you check that these are really unneeded? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=444359&group_id=5470 From noreply@sourceforge.net Wed Jul 25 21:07:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Jul 2001 13:07:32 -0700 Subject: [Patches] [ python-Patches-403977 ] Rename config.h to pyac_config.h, per SF bug #131774 Message-ID: Patches item #403977, was opened at 2001-02-23 13:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 Category: Build Group: None Status: Open Resolution: Postponed Priority: 1 Submitted By: Thomas Wouters (twouters) Assigned to: Thomas Wouters (twouters) Summary: Rename config.h to pyac_config.h, per SF bug #131774 Initial Comment: This patch fixes the UNIX and Windows builds to use 'pyac_config.h' instead of 'config.h', to avoid the problems summarized in SF bug #131774. It doesn't address the placing issue, however, because I believe it's intended to be like this. Most changes were done using a fairly intelligent shell+sed oneliner, but they should be correct. The Windows build *seems* correct, though I can't be sure. Someone will have to check ;) It is probably a good idea to remove 'config.h' before testing, to be sure I got all references. The UNIX build requires that autoconf is installed, and requires a 'autoheader ; autoconf' is done before running 'configure'. Removing config.h(.in) is also a good idea. I excluded the OS2 build files, and will be uploading those as a seperate patch to avoid making this one unreadable Though only two files are involved, they both list all dependencies for *all* files in its entirety, so the patch is quite large. If those files are auto-generated, someone please tell me so :-) I also didn't fix distutils, though it looks like it does need fixing. And I didn't do anything wrt. backwards compatibility. We should probably provide a config.h that just does #warning Warning: Use of Python-specific config.h is deprecated. Use pyac_config.h instead. #include The name is just my suggestion, changing it into something less acronymic would be no problem at all. I think 'pythonconfig.h' gives the wrong message though: the file isn't used to configure Python itself, after all ;) ---------------------------------------------------------------------- Comment By: Luis P Caamano (lcaamano) Date: 2001-07-25 13:07 Message: Logged In: YES user_id=279987 Because of this bug, PyGreSQl doesn't compile if prefix and exec_prefix are different. The reason being that "Python.h" goes to prefix and "config.h" goes to exec_prefix. As a result, gcc doesn't find "config.h" in the directory where Python.h, and ends up including .../pgsql/config.h instead. Workaround: Move Python.h from the prefix dir to the exec_prefix for every platform AND then remove it from the prefix dir. In other words, a fix for this is needed ASAP, but 2.1.1 just got out. When will we get a fix? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 13:59 Message: Logged In: YES user_id=21627 I think we should come to a conclusion for these patches, and applying one of them. I still like pyconfig.h better than pyac_config.h, but apart from that, *something* should get installed. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-04-11 05:43 Message: Logged In: YES user_id=34209 I'm not sure about the supersedence here. See my comment in #411138. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:15 Message: Logged In: YES user_id=6380 Is this superseded by patch #411138? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 16:09 Message: Logged In: YES user_id=6380 Let's do this after 2.1 is released. Status set to postponed and priority lowered. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-01 17:29 Message: Logged In: YES user_id=31435 Na, I don't mind the pyac name. I had forgotten (or perhaps never knew) that this thing is a generated file (on Windows it's done by hand). It's an internal implementation detail anyway, so it doesn't matter if the name "makes sense" to Windows geeks; at least pyac_config will make some sense to Linux dweebs. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2001-03-01 17:08 Message: Logged In: YES user_id=34892 Tim said: > BTW, I have no idea what "pyac" is supposed to bring > to mind. Is that some Unixism? In answer to that. How about just calling it "pyconfig.h". The reference to autoconf is not very accurate for Windows. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-02-28 01:07 Message: Logged In: YES user_id=34209 I forgot to mention that I think this should be postponed until 2.2 or 2.1.1 anyway. It's not that big a change, but it's big enough to have weird and unsuspected sideffects. The bug is now numbered #231774, by the way. The problem is that 'config.h' is an oft-used name, and if you include it but have another directory with another project's config.h earlier in your include path, you get the wrong one. Similar if you intend to use the other one, but get this one. Leaving a fake config.h would only cause this patch to fix half of those problems, but only the first problem was reported in the bugreport :) The 'pyac_config' name comes from 'python', 'autoconf', 'config', and is IMHO sufficiently vague that it implies it is autogenerated :-) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-02-27 23:14 Message: Logged In: YES user_id=31392 No time ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-02-27 13:53 Message: Logged In: YES user_id=35752 SF seems to have changed the bug ids! I can't find bug #131774. Unless there is a very good reason for the change I'm against it for 2.1. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-02-27 13:05 Message: Logged In: YES user_id=11375 Regarding Distutils: I think the only actual *code* that would change is in distutils/sysconfig.py, in the get_config_h_filename() method. For backward compat., this method would probably have to check the Python version and use pyac_config.h if the version is 2.1 or greater. There are also lots of references to config.h in comments; we can change those or not, as desired. (I probably *would* change most of them.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-02-27 12:48 Message: Logged In: YES user_id=31435 Pushed onto Jeremy. Jeremy, we want to do this much fiddling so late in the cycle? Thomas, don't worry about Windows. I only need a warning about that, and I've aware of this now (thanks!). Check in the new MS project files or don't, it's easy for me to fix 'em up regardless (indeed, it's not worth extra time to check it in advance). Note that "#warning" is not std C. I'm afraid you'll have to make it an #error. OTOH, if you leave a file *named* "config.h" in the distribution, it doesn't really address the bug report, right? BTW, I have no idea what "pyac" is supposed to bring to mind. Is that some Unixism? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-02-23 13:32 Message: Apologies for the large blurb in the 'details' section. I keep forgetting SF strips *all* whitespace from that block :( Assigning to Tim "The Windows Bot" Peters to test (and fix) the Windows build changes. Let me know if your patch still doesn't work and you want me to send you patched files instead, Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 From noreply@sourceforge.net Wed Jul 25 21:40:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Jul 2001 13:40:59 -0700 Subject: [Patches] [ python-Patches-403977 ] Rename config.h to pyac_config.h, per SF bug #131774 Message-ID: Patches item #403977, was opened at 2001-02-23 13:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 Category: Build Group: None Status: Open >Resolution: Accepted >Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Thomas Wouters (twouters) Summary: Rename config.h to pyac_config.h, per SF bug #131774 Initial Comment: This patch fixes the UNIX and Windows builds to use 'pyac_config.h' instead of 'config.h', to avoid the problems summarized in SF bug #131774. It doesn't address the placing issue, however, because I believe it's intended to be like this. Most changes were done using a fairly intelligent shell+sed oneliner, but they should be correct. The Windows build *seems* correct, though I can't be sure. Someone will have to check ;) It is probably a good idea to remove 'config.h' before testing, to be sure I got all references. The UNIX build requires that autoconf is installed, and requires a 'autoheader ; autoconf' is done before running 'configure'. Removing config.h(.in) is also a good idea. I excluded the OS2 build files, and will be uploading those as a seperate patch to avoid making this one unreadable Though only two files are involved, they both list all dependencies for *all* files in its entirety, so the patch is quite large. If those files are auto-generated, someone please tell me so :-) I also didn't fix distutils, though it looks like it does need fixing. And I didn't do anything wrt. backwards compatibility. We should probably provide a config.h that just does #warning Warning: Use of Python-specific config.h is deprecated. Use pyac_config.h instead. #include The name is just my suggestion, changing it into something less acronymic would be no problem at all. I think 'pythonconfig.h' gives the wrong message though: the file isn't used to configure Python itself, after all ;) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-25 13:40 Message: Logged In: YES user_id=6380 Yes, we should do something about this. I am for pyconfig.h. ---------------------------------------------------------------------- Comment By: Luis P Caamano (lcaamano) Date: 2001-07-25 13:07 Message: Logged In: YES user_id=279987 Because of this bug, PyGreSQl doesn't compile if prefix and exec_prefix are different. The reason being that "Python.h" goes to prefix and "config.h" goes to exec_prefix. As a result, gcc doesn't find "config.h" in the directory where Python.h, and ends up including .../pgsql/config.h instead. Workaround: Move Python.h from the prefix dir to the exec_prefix for every platform AND then remove it from the prefix dir. In other words, a fix for this is needed ASAP, but 2.1.1 just got out. When will we get a fix? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 13:59 Message: Logged In: YES user_id=21627 I think we should come to a conclusion for these patches, and applying one of them. I still like pyconfig.h better than pyac_config.h, but apart from that, *something* should get installed. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-04-11 05:43 Message: Logged In: YES user_id=34209 I'm not sure about the supersedence here. See my comment in #411138. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:15 Message: Logged In: YES user_id=6380 Is this superseded by patch #411138? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 16:09 Message: Logged In: YES user_id=6380 Let's do this after 2.1 is released. Status set to postponed and priority lowered. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-01 17:29 Message: Logged In: YES user_id=31435 Na, I don't mind the pyac name. I had forgotten (or perhaps never knew) that this thing is a generated file (on Windows it's done by hand). It's an internal implementation detail anyway, so it doesn't matter if the name "makes sense" to Windows geeks; at least pyac_config will make some sense to Linux dweebs. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2001-03-01 17:08 Message: Logged In: YES user_id=34892 Tim said: > BTW, I have no idea what "pyac" is supposed to bring > to mind. Is that some Unixism? In answer to that. How about just calling it "pyconfig.h". The reference to autoconf is not very accurate for Windows. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-02-28 01:07 Message: Logged In: YES user_id=34209 I forgot to mention that I think this should be postponed until 2.2 or 2.1.1 anyway. It's not that big a change, but it's big enough to have weird and unsuspected sideffects. The bug is now numbered #231774, by the way. The problem is that 'config.h' is an oft-used name, and if you include it but have another directory with another project's config.h earlier in your include path, you get the wrong one. Similar if you intend to use the other one, but get this one. Leaving a fake config.h would only cause this patch to fix half of those problems, but only the first problem was reported in the bugreport :) The 'pyac_config' name comes from 'python', 'autoconf', 'config', and is IMHO sufficiently vague that it implies it is autogenerated :-) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-02-27 23:14 Message: Logged In: YES user_id=31392 No time ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-02-27 13:53 Message: Logged In: YES user_id=35752 SF seems to have changed the bug ids! I can't find bug #131774. Unless there is a very good reason for the change I'm against it for 2.1. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-02-27 13:05 Message: Logged In: YES user_id=11375 Regarding Distutils: I think the only actual *code* that would change is in distutils/sysconfig.py, in the get_config_h_filename() method. For backward compat., this method would probably have to check the Python version and use pyac_config.h if the version is 2.1 or greater. There are also lots of references to config.h in comments; we can change those or not, as desired. (I probably *would* change most of them.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-02-27 12:48 Message: Logged In: YES user_id=31435 Pushed onto Jeremy. Jeremy, we want to do this much fiddling so late in the cycle? Thomas, don't worry about Windows. I only need a warning about that, and I've aware of this now (thanks!). Check in the new MS project files or don't, it's easy for me to fix 'em up regardless (indeed, it's not worth extra time to check it in advance). Note that "#warning" is not std C. I'm afraid you'll have to make it an #error. OTOH, if you leave a file *named* "config.h" in the distribution, it doesn't really address the bug report, right? BTW, I have no idea what "pyac" is supposed to bring to mind. Is that some Unixism? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-02-23 13:32 Message: Apologies for the large blurb in the 'details' section. I keep forgetting SF strips *all* whitespace from that block :( Assigning to Tim "The Windows Bot" Peters to test (and fix) the Windows build changes. Let me know if your patch still doesn't work and you want me to send you patched files instead, Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 From noreply@sourceforge.net Wed Jul 25 22:54:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Jul 2001 14:54:27 -0700 Subject: [Patches] [ python-Patches-437733 ] Additional Argument to Python/C Function Message-ID: Patches item #437733, was opened at 2001-07-01 09:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=437733&group_id=5470 Category: None Group: None >Status: Open Resolution: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Additional Argument to Python/C Function Initial Comment: this patch makes it possible that a python/c function gets an aditional void* argument. this makes it easier to use python with c++. PS:i'm a bad despriptor,so please look at the diff file. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-25 14:54 Message: Logged In: YES user_id=3066 Just for the record, I'm not ignoring your emailed plea for re-consideration; I just haven't had time to dig back into this matter. Here's the sample class from the email, so it will be easier to keep track of and for others to comment on the approach: class PyClass{ public: PyClass(); typedef PyObject* (PyClass::*PyCppFunction) (PyObject*); void addmethod(const char* name,PyCppFunction func); ~PyClass(); operator PyObject*(){return (PyObject*)obj;} private: struct PyClassObject{ PyObject_HEAD PyClass *self; }; std::vector methods; static PyObject *pycfunc(PyClassObject *self,PyObject *arg,void *p); static PyObject *getattr(PyClassObject *self,char *name); static void dealloc(PyClassObject *){} PyTypeObject typeobject; PyClassObject *obj; }; void PyClass::addmethod(const char *name,PyCppFunction func) { PyMethodDef meth={ strdup(name), (PyCFunction)pycfunc, METH_VARARGS|METH_USERARG, NULL, *(void**)&func }; methods.insert(methods.begin(),meth); } PyClass::~PyClass(){ for(vector::iterator i=methods.begin ();i!=methods.end();i++) free(i->ml_name); methods.resize(0); } PyObject *PyClass::pycfunc(PyClassObject *self,PyObject *arg,void *p){ PyCppFunction func=*(PyCppFunction*)&p; return (self->self->*func)(arg); } PyClass::PyClass(){ PyTypeObject Xxtype = { PyObject_HEAD_INIT(&PyType_Type) 0, /*ob_size*/ "xx", /*tp_name*/ sizeof(PyClassObject), /*tp_basicsize*/ 0, /*tp_itemsize*/ /* methods */ (destructor)dealloc, /*tp_dealloc*/ 0, /*tp_print*/ (getattrfunc)getattr, /*tp_getattr*/ (setattrfunc)0, /*tp_setattr*/ 0, /*tp_compare*/ 0, /*tp_repr*/ 0, /*tp_as_number*/ 0, /*tp_as_sequence*/ 0, /*tp_as_mappi ng*/ 0, /*tp_hash*/ }; typeobject=Xxtype; obj=PyObject_NEW(PyClassObject,&typeobject); obj->self=this; PyMethodDef md={0}; methods.push_back(md); } PyObject *PyClass::getattr(PyClassObject *self,char *name){ return Py_FindMethod(&self->self->methods[0], (PyObject*)self,name); } This class is meant to be a base class for other classes that represent python types. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 21:48 Message: Logged In: YES user_id=3066 The patch is easy enough to understand, but the motivation for this is not at all clear. Rejecting as code bloat. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=437733&group_id=5470 From noreply@sourceforge.net Wed Jul 25 22:58:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Jul 2001 14:58:31 -0700 Subject: [Patches] [ python-Patches-411138 ] Fix for #231774: pyconfig.h Message-ID: Patches item #411138, was opened at 2001-03-25 00:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411138&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Martin v. Löwis (loewis) Summary: Fix for #231774: pyconfig.h Initial Comment: This patch renames config.h to pyconfig.h, to allow autoconfiscation of python-based projects. In addition to the changes collected in this patch, the following actions are required when committing it: - re-run autoheader and autoconf - cvs add pyconfig.h (generated by autoheader), cvs remove config.h - rename PC/config.h, PC/os2vacpp/config.h, and RISCOS/config.h in CVS (probably using cvs add/remove) - globally replace config.h in PC/os2vacpp/makefile and PC/os2vacpp/makefile.omk; this change has been omitted from the patch because it is quite large. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-25 14:58 Message: Logged In: YES user_id=3066 Martin/Thomas: do you two still want to see one of these patches applied for 2.2? Which of the two patches makes the most sense to you? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-11 09:01 Message: Logged In: YES user_id=21627 I have created this patch because I was not aware of the other one; the bug #231774 log did not indicate that a patch was in progress. As for the specific differences between them: I like pyconfig.h better than pyac_config.h. The file object chunk was there by mistake; I have removed it. I don't think that the distutils as shipped with Python need to check for config.h, since the Python release having this version of distutils will use only pyconfig.h. For independent distutils releases, looking for config.h might be necessary. I also don't think that the documentation should mention config.h; Python documentation was always accurate only for the release in which it was included. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-04-11 05:40 Message: Logged In: YES user_id=34209 I may be biased, but I don't see the difference between this patch and my patch, except that there are some errors in this patch :) It includes a change in fileobject.h that isn't supposed to be there (I think), and it changes distutils in the wrong way (distutils, for backward compatibility, should check for both config.h and pyconfig.h) -- though my patch doesn't address the latter issue, it doesn't touch distutils at all. Documentation should also mention both config.h and pyconfig.h. Other than that, I don't care which patch gets accepted, by the way :) But maybe Martin can explain why he created this patch ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:11 Message: Logged In: YES user_id=6380 PS. Does this supersede patch #403978? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:09 Message: Logged In: YES user_id=6380 Let's do this after 2.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411138&group_id=5470 From noreply@sourceforge.net Thu Jul 26 07:51:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Jul 2001 23:51:44 -0700 Subject: [Patches] [ python-Patches-411138 ] Fix for #231774: pyconfig.h Message-ID: Patches item #411138, was opened at 2001-03-25 00:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411138&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Martin v. Löwis (loewis) Summary: Fix for #231774: pyconfig.h Initial Comment: This patch renames config.h to pyconfig.h, to allow autoconfiscation of python-based projects. In addition to the changes collected in this patch, the following actions are required when committing it: - re-run autoheader and autoconf - cvs add pyconfig.h (generated by autoheader), cvs remove config.h - rename PC/config.h, PC/os2vacpp/config.h, and RISCOS/config.h in CVS (probably using cvs add/remove) - globally replace config.h in PC/os2vacpp/makefile and PC/os2vacpp/makefile.omk; this change has been omitted from the patch because it is quite large. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-25 23:51 Message: Logged In: YES user_id=21627 I still think my patch should be applied as-is, following the instructions above. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-25 14:58 Message: Logged In: YES user_id=3066 Martin/Thomas: do you two still want to see one of these patches applied for 2.2? Which of the two patches makes the most sense to you? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-11 09:01 Message: Logged In: YES user_id=21627 I have created this patch because I was not aware of the other one; the bug #231774 log did not indicate that a patch was in progress. As for the specific differences between them: I like pyconfig.h better than pyac_config.h. The file object chunk was there by mistake; I have removed it. I don't think that the distutils as shipped with Python need to check for config.h, since the Python release having this version of distutils will use only pyconfig.h. For independent distutils releases, looking for config.h might be necessary. I also don't think that the documentation should mention config.h; Python documentation was always accurate only for the release in which it was included. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-04-11 05:40 Message: Logged In: YES user_id=34209 I may be biased, but I don't see the difference between this patch and my patch, except that there are some errors in this patch :) It includes a change in fileobject.h that isn't supposed to be there (I think), and it changes distutils in the wrong way (distutils, for backward compatibility, should check for both config.h and pyconfig.h) -- though my patch doesn't address the latter issue, it doesn't touch distutils at all. Documentation should also mention both config.h and pyconfig.h. Other than that, I don't care which patch gets accepted, by the way :) But maybe Martin can explain why he created this patch ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:11 Message: Logged In: YES user_id=6380 PS. Does this supersede patch #403978? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:09 Message: Logged In: YES user_id=6380 Let's do this after 2.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411138&group_id=5470 From noreply@sourceforge.net Thu Jul 26 12:20:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 04:20:55 -0700 Subject: [Patches] [ python-Patches-444750 ] os.statvfs support for BSD Message-ID: Patches item #444750, was opened at 2001-07-26 04:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=444750&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: os.statvfs support for BSD Initial Comment: BSD systems have the statfs(2) call; we use that one to fake statvfs(). See the code for more comments. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=444750&group_id=5470 From noreply@sourceforge.net Thu Jul 26 12:26:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 04:26:32 -0700 Subject: [Patches] [ python-Patches-444750 ] os.statvfs support for BSD Message-ID: Patches item #444750, was opened at 2001-07-26 04:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=444750&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: os.statvfs support for BSD Initial Comment: BSD systems have the statfs(2) call; we use that one to fake statvfs(). See the code for more comments. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-26 04:26 Message: Logged In: NO Oops, in case there are questions left, here's my email address: tg@FreeBSD.org. tg ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=444750&group_id=5470 From noreply@sourceforge.net Thu Jul 26 13:52:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 05:52:01 -0700 Subject: [Patches] [ python-Patches-411138 ] Fix for #231774: pyconfig.h Message-ID: Patches item #411138, was opened at 2001-03-25 00:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411138&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Martin v. Löwis (loewis) Summary: Fix for #231774: pyconfig.h Initial Comment: This patch renames config.h to pyconfig.h, to allow autoconfiscation of python-based projects. In addition to the changes collected in this patch, the following actions are required when committing it: - re-run autoheader and autoconf - cvs add pyconfig.h (generated by autoheader), cvs remove config.h - rename PC/config.h, PC/os2vacpp/config.h, and RISCOS/config.h in CVS (probably using cvs add/remove) - globally replace config.h in PC/os2vacpp/makefile and PC/os2vacpp/makefile.omk; this change has been omitted from the patch because it is quite large. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-07-26 05:52 Message: Logged In: YES user_id=34209 I honestly don't care which gets applied (I forget if there was any real difference in the patches anyway, except that mine didn't touch distutils) though I do think something that says "autoconf configuration" rather than "python configuration" would be better. But then again, it's not like it really matters :) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-25 23:51 Message: Logged In: YES user_id=21627 I still think my patch should be applied as-is, following the instructions above. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-25 14:58 Message: Logged In: YES user_id=3066 Martin/Thomas: do you two still want to see one of these patches applied for 2.2? Which of the two patches makes the most sense to you? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-11 09:01 Message: Logged In: YES user_id=21627 I have created this patch because I was not aware of the other one; the bug #231774 log did not indicate that a patch was in progress. As for the specific differences between them: I like pyconfig.h better than pyac_config.h. The file object chunk was there by mistake; I have removed it. I don't think that the distutils as shipped with Python need to check for config.h, since the Python release having this version of distutils will use only pyconfig.h. For independent distutils releases, looking for config.h might be necessary. I also don't think that the documentation should mention config.h; Python documentation was always accurate only for the release in which it was included. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-04-11 05:40 Message: Logged In: YES user_id=34209 I may be biased, but I don't see the difference between this patch and my patch, except that there are some errors in this patch :) It includes a change in fileobject.h that isn't supposed to be there (I think), and it changes distutils in the wrong way (distutils, for backward compatibility, should check for both config.h and pyconfig.h) -- though my patch doesn't address the latter issue, it doesn't touch distutils at all. Documentation should also mention both config.h and pyconfig.h. Other than that, I don't care which patch gets accepted, by the way :) But maybe Martin can explain why he created this patch ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:11 Message: Logged In: YES user_id=6380 PS. Does this supersede patch #403978? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:09 Message: Logged In: YES user_id=6380 Let's do this after 2.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411138&group_id=5470 From noreply@sourceforge.net Thu Jul 26 14:24:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 06:24:04 -0700 Subject: [Patches] [ python-Patches-411138 ] Fix for #231774: pyconfig.h Message-ID: Patches item #411138, was opened at 2001-03-25 00:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411138&group_id=5470 Category: Build Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Martin v. Löwis (loewis) Summary: Fix for #231774: pyconfig.h Initial Comment: This patch renames config.h to pyconfig.h, to allow autoconfiscation of python-based projects. In addition to the changes collected in this patch, the following actions are required when committing it: - re-run autoheader and autoconf - cvs add pyconfig.h (generated by autoheader), cvs remove config.h - rename PC/config.h, PC/os2vacpp/config.h, and RISCOS/config.h in CVS (probably using cvs add/remove) - globally replace config.h in PC/os2vacpp/makefile and PC/os2vacpp/makefile.omk; this change has been omitted from the patch because it is quite large. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 06:24 Message: Logged In: YES user_id=6380 I disagree with Thomas -- for the *users* of the file, the fact that it was generated by autoconf is irrelevant, but the fact that it belongs to Python is. Martin, please go ahead and apply this (if it still works). ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-26 05:52 Message: Logged In: YES user_id=34209 I honestly don't care which gets applied (I forget if there was any real difference in the patches anyway, except that mine didn't touch distutils) though I do think something that says "autoconf configuration" rather than "python configuration" would be better. But then again, it's not like it really matters :) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-25 23:51 Message: Logged In: YES user_id=21627 I still think my patch should be applied as-is, following the instructions above. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-25 14:58 Message: Logged In: YES user_id=3066 Martin/Thomas: do you two still want to see one of these patches applied for 2.2? Which of the two patches makes the most sense to you? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-11 09:01 Message: Logged In: YES user_id=21627 I have created this patch because I was not aware of the other one; the bug #231774 log did not indicate that a patch was in progress. As for the specific differences between them: I like pyconfig.h better than pyac_config.h. The file object chunk was there by mistake; I have removed it. I don't think that the distutils as shipped with Python need to check for config.h, since the Python release having this version of distutils will use only pyconfig.h. For independent distutils releases, looking for config.h might be necessary. I also don't think that the documentation should mention config.h; Python documentation was always accurate only for the release in which it was included. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-04-11 05:40 Message: Logged In: YES user_id=34209 I may be biased, but I don't see the difference between this patch and my patch, except that there are some errors in this patch :) It includes a change in fileobject.h that isn't supposed to be there (I think), and it changes distutils in the wrong way (distutils, for backward compatibility, should check for both config.h and pyconfig.h) -- though my patch doesn't address the latter issue, it doesn't touch distutils at all. Documentation should also mention both config.h and pyconfig.h. Other than that, I don't care which patch gets accepted, by the way :) But maybe Martin can explain why he created this patch ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:11 Message: Logged In: YES user_id=6380 PS. Does this supersede patch #403978? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:09 Message: Logged In: YES user_id=6380 Let's do this after 2.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411138&group_id=5470 From noreply@sourceforge.net Thu Jul 26 14:57:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 06:57:20 -0700 Subject: [Patches] [ python-Patches-411138 ] Fix for #231774: pyconfig.h Message-ID: Patches item #411138, was opened at 2001-03-25 00:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411138&group_id=5470 Category: Build Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Martin v. Löwis (loewis) Summary: Fix for #231774: pyconfig.h Initial Comment: This patch renames config.h to pyconfig.h, to allow autoconfiscation of python-based projects. In addition to the changes collected in this patch, the following actions are required when committing it: - re-run autoheader and autoconf - cvs add pyconfig.h (generated by autoheader), cvs remove config.h - rename PC/config.h, PC/os2vacpp/config.h, and RISCOS/config.h in CVS (probably using cvs add/remove) - globally replace config.h in PC/os2vacpp/makefile and PC/os2vacpp/makefile.omk; this change has been omitted from the patch because it is quite large. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-26 06:57 Message: Logged In: YES user_id=21627 Committed as Makefile.pre.in 1.45 config.h.in delete configure 1.228 configure.in 1.236 pyconfig.h.in 1.1 ext.tex 1.101 libexcs.tex 1.40 libsys.tex 1.51 Python.h 2.36 pgenheaders.h 2.25 pyport.h 2.28 cygwinccompiler.py 1.13 sysconfig.py 1.38 build_ext.py 1.75 Porting 3.2 _testcapimodule.c 1.10 getbuildinfo.c 2.7 posixmodule.c 2.195 config.h delete dl_nt.c 1.4 pyconfig.h 1.1 config.h delete makefile 1.4 makefile.omk 1.2 pyconfig.h 1.1 python20.wse 1.43 atof.c 2.8 fmod.c 2.14 getmtime.c 2.17 hypot.c 2.4 pyfpe.c 2.7 strtod.c 1.11 thread.c 2.37 config.h delete pyconfig.h 1.1 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 06:24 Message: Logged In: YES user_id=6380 I disagree with Thomas -- for the *users* of the file, the fact that it was generated by autoconf is irrelevant, but the fact that it belongs to Python is. Martin, please go ahead and apply this (if it still works). ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-26 05:52 Message: Logged In: YES user_id=34209 I honestly don't care which gets applied (I forget if there was any real difference in the patches anyway, except that mine didn't touch distutils) though I do think something that says "autoconf configuration" rather than "python configuration" would be better. But then again, it's not like it really matters :) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-25 23:51 Message: Logged In: YES user_id=21627 I still think my patch should be applied as-is, following the instructions above. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-25 14:58 Message: Logged In: YES user_id=3066 Martin/Thomas: do you two still want to see one of these patches applied for 2.2? Which of the two patches makes the most sense to you? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-11 09:01 Message: Logged In: YES user_id=21627 I have created this patch because I was not aware of the other one; the bug #231774 log did not indicate that a patch was in progress. As for the specific differences between them: I like pyconfig.h better than pyac_config.h. The file object chunk was there by mistake; I have removed it. I don't think that the distutils as shipped with Python need to check for config.h, since the Python release having this version of distutils will use only pyconfig.h. For independent distutils releases, looking for config.h might be necessary. I also don't think that the documentation should mention config.h; Python documentation was always accurate only for the release in which it was included. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-04-11 05:40 Message: Logged In: YES user_id=34209 I may be biased, but I don't see the difference between this patch and my patch, except that there are some errors in this patch :) It includes a change in fileobject.h that isn't supposed to be there (I think), and it changes distutils in the wrong way (distutils, for backward compatibility, should check for both config.h and pyconfig.h) -- though my patch doesn't address the latter issue, it doesn't touch distutils at all. Documentation should also mention both config.h and pyconfig.h. Other than that, I don't care which patch gets accepted, by the way :) But maybe Martin can explain why he created this patch ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:11 Message: Logged In: YES user_id=6380 PS. Does this supersede patch #403978? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:09 Message: Logged In: YES user_id=6380 Let's do this after 2.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411138&group_id=5470 From noreply@sourceforge.net Thu Jul 26 15:03:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 07:03:38 -0700 Subject: [Patches] [ python-Patches-403977 ] Rename config.h to pyac_config.h, per SF bug #131774 Message-ID: Patches item #403977, was opened at 2001-02-23 13:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 Category: Build Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Thomas Wouters (twouters) Summary: Rename config.h to pyac_config.h, per SF bug #131774 Initial Comment: This patch fixes the UNIX and Windows builds to use 'pyac_config.h' instead of 'config.h', to avoid the problems summarized in SF bug #131774. It doesn't address the placing issue, however, because I believe it's intended to be like this. Most changes were done using a fairly intelligent shell+sed oneliner, but they should be correct. The Windows build *seems* correct, though I can't be sure. Someone will have to check ;) It is probably a good idea to remove 'config.h' before testing, to be sure I got all references. The UNIX build requires that autoconf is installed, and requires a 'autoheader ; autoconf' is done before running 'configure'. Removing config.h(.in) is also a good idea. I excluded the OS2 build files, and will be uploading those as a seperate patch to avoid making this one unreadable Though only two files are involved, they both list all dependencies for *all* files in its entirety, so the patch is quite large. If those files are auto-generated, someone please tell me so :-) I also didn't fix distutils, though it looks like it does need fixing. And I didn't do anything wrt. backwards compatibility. We should probably provide a config.h that just does #warning Warning: Use of Python-specific config.h is deprecated. Use pyac_config.h instead. #include The name is just my suggestion, changing it into something less acronymic would be no problem at all. I think 'pythonconfig.h' gives the wrong message though: the file isn't used to configure Python itself, after all ;) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-26 07:03 Message: Logged In: YES user_id=21627 Patch #411138 has been committed, so this one can be closed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-25 13:40 Message: Logged In: YES user_id=6380 Yes, we should do something about this. I am for pyconfig.h. ---------------------------------------------------------------------- Comment By: Luis P Caamano (lcaamano) Date: 2001-07-25 13:07 Message: Logged In: YES user_id=279987 Because of this bug, PyGreSQl doesn't compile if prefix and exec_prefix are different. The reason being that "Python.h" goes to prefix and "config.h" goes to exec_prefix. As a result, gcc doesn't find "config.h" in the directory where Python.h, and ends up including .../pgsql/config.h instead. Workaround: Move Python.h from the prefix dir to the exec_prefix for every platform AND then remove it from the prefix dir. In other words, a fix for this is needed ASAP, but 2.1.1 just got out. When will we get a fix? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 13:59 Message: Logged In: YES user_id=21627 I think we should come to a conclusion for these patches, and applying one of them. I still like pyconfig.h better than pyac_config.h, but apart from that, *something* should get installed. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-04-11 05:43 Message: Logged In: YES user_id=34209 I'm not sure about the supersedence here. See my comment in #411138. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:15 Message: Logged In: YES user_id=6380 Is this superseded by patch #411138? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 16:09 Message: Logged In: YES user_id=6380 Let's do this after 2.1 is released. Status set to postponed and priority lowered. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-01 17:29 Message: Logged In: YES user_id=31435 Na, I don't mind the pyac name. I had forgotten (or perhaps never knew) that this thing is a generated file (on Windows it's done by hand). It's an internal implementation detail anyway, so it doesn't matter if the name "makes sense" to Windows geeks; at least pyac_config will make some sense to Linux dweebs. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2001-03-01 17:08 Message: Logged In: YES user_id=34892 Tim said: > BTW, I have no idea what "pyac" is supposed to bring > to mind. Is that some Unixism? In answer to that. How about just calling it "pyconfig.h". The reference to autoconf is not very accurate for Windows. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-02-28 01:07 Message: Logged In: YES user_id=34209 I forgot to mention that I think this should be postponed until 2.2 or 2.1.1 anyway. It's not that big a change, but it's big enough to have weird and unsuspected sideffects. The bug is now numbered #231774, by the way. The problem is that 'config.h' is an oft-used name, and if you include it but have another directory with another project's config.h earlier in your include path, you get the wrong one. Similar if you intend to use the other one, but get this one. Leaving a fake config.h would only cause this patch to fix half of those problems, but only the first problem was reported in the bugreport :) The 'pyac_config' name comes from 'python', 'autoconf', 'config', and is IMHO sufficiently vague that it implies it is autogenerated :-) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-02-27 23:14 Message: Logged In: YES user_id=31392 No time ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-02-27 13:53 Message: Logged In: YES user_id=35752 SF seems to have changed the bug ids! I can't find bug #131774. Unless there is a very good reason for the change I'm against it for 2.1. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-02-27 13:05 Message: Logged In: YES user_id=11375 Regarding Distutils: I think the only actual *code* that would change is in distutils/sysconfig.py, in the get_config_h_filename() method. For backward compat., this method would probably have to check the Python version and use pyac_config.h if the version is 2.1 or greater. There are also lots of references to config.h in comments; we can change those or not, as desired. (I probably *would* change most of them.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-02-27 12:48 Message: Logged In: YES user_id=31435 Pushed onto Jeremy. Jeremy, we want to do this much fiddling so late in the cycle? Thomas, don't worry about Windows. I only need a warning about that, and I've aware of this now (thanks!). Check in the new MS project files or don't, it's easy for me to fix 'em up regardless (indeed, it's not worth extra time to check it in advance). Note that "#warning" is not std C. I'm afraid you'll have to make it an #error. OTOH, if you leave a file *named* "config.h" in the distribution, it doesn't really address the bug report, right? BTW, I have no idea what "pyac" is supposed to bring to mind. Is that some Unixism? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-02-23 13:32 Message: Apologies for the large blurb in the 'details' section. I keep forgetting SF strips *all* whitespace from that block :( Assigning to Tim "The Windows Bot" Peters to test (and fix) the Windows build changes. Let me know if your patch still doesn't work and you want me to send you patched files instead, Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 From noreply@sourceforge.net Thu Jul 26 15:04:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 07:04:18 -0700 Subject: [Patches] [ python-Patches-403978 ] config.h -&gt; pyac_config.h change for OS2 Message-ID: Patches item #403978, was opened at 2001-02-23 13:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403978&group_id=5470 Category: Build Group: None >Status: Closed Resolution: Postponed Priority: 1 Submitted By: Thomas Wouters (twouters) Assigned to: Thomas Wouters (twouters) Summary: config.h -&gt; pyac_config.h change for OS2 Initial Comment: Companion to SF patch #103977, the OS2 part. To keep the size down, I didn't include pyac_config.h. If you want to test this patch, you'll have to rename config.h to pyac_config.h manually. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-26 07:04 Message: Logged In: YES user_id=21627 The OS/2 changes have been applied as part of committing #411138. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:11 Message: Logged In: YES user_id=6380 Is this superseded by patch #411138? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-02-28 01:01 Message: Logged In: YES user_id=34209 Postponed, it's too late to get it into 2.1 (I actually intended to mark it postponed from the start, but forgot to.) The companion patch is now numbered '#403977', by the way. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403978&group_id=5470 From noreply@sourceforge.net Thu Jul 26 17:55:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 09:55:19 -0700 Subject: [Patches] [ python-Patches-444854 ] Distutils config _link doesn't clean up Message-ID: Patches item #444854, was opened at 2001-07-26 09:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=444854&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tarn Weisner Burton (twburton) Assigned to: Nobody/Anonymous (nobody) Summary: Distutils config _link doesn't clean up Initial Comment: The distutils.config.config._link method doesn't return the right program name for win32 and hence doesn't clean up after itself properly. There's a comment about this in the source...is there a reason this isn't done? Anyways, the offending code is: prog = os.path.splitext(os.path.basename(src))[0] self.temp_files.append(prog) which should be changed to prog = os.path.splitext(os.path.basename(src))[0] if sys.platform == 'win32': prog = prog + '.exe' self.temp_files.append(prog) The sys module needs to imported also. thanks, Tarn ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=444854&group_id=5470 From noreply@sourceforge.net Thu Jul 26 21:19:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 13:19:21 -0700 Subject: [Patches] [ python-Patches-411138 ] Fix for #231774: pyconfig.h Message-ID: Patches item #411138, was opened at 2001-03-25 00:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411138&group_id=5470 Category: Build Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Martin v. Löwis (loewis) Summary: Fix for #231774: pyconfig.h Initial Comment: This patch renames config.h to pyconfig.h, to allow autoconfiscation of python-based projects. In addition to the changes collected in this patch, the following actions are required when committing it: - re-run autoheader and autoconf - cvs add pyconfig.h (generated by autoheader), cvs remove config.h - rename PC/config.h, PC/os2vacpp/config.h, and RISCOS/config.h in CVS (probably using cvs add/remove) - globally replace config.h in PC/os2vacpp/makefile and PC/os2vacpp/makefile.omk; this change has been omitted from the patch because it is quite large. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-26 06:57 Message: Logged In: YES user_id=21627 Committed as Makefile.pre.in 1.45 config.h.in delete configure 1.228 configure.in 1.236 pyconfig.h.in 1.1 ext.tex 1.101 libexcs.tex 1.40 libsys.tex 1.51 Python.h 2.36 pgenheaders.h 2.25 pyport.h 2.28 cygwinccompiler.py 1.13 sysconfig.py 1.38 build_ext.py 1.75 Porting 3.2 _testcapimodule.c 1.10 getbuildinfo.c 2.7 posixmodule.c 2.195 config.h delete dl_nt.c 1.4 pyconfig.h 1.1 config.h delete makefile 1.4 makefile.omk 1.2 pyconfig.h 1.1 python20.wse 1.43 atof.c 2.8 fmod.c 2.14 getmtime.c 2.17 hypot.c 2.4 pyfpe.c 2.7 strtod.c 1.11 thread.c 2.37 config.h delete pyconfig.h 1.1 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 06:24 Message: Logged In: YES user_id=6380 I disagree with Thomas -- for the *users* of the file, the fact that it was generated by autoconf is irrelevant, but the fact that it belongs to Python is. Martin, please go ahead and apply this (if it still works). ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-26 05:52 Message: Logged In: YES user_id=34209 I honestly don't care which gets applied (I forget if there was any real difference in the patches anyway, except that mine didn't touch distutils) though I do think something that says "autoconf configuration" rather than "python configuration" would be better. But then again, it's not like it really matters :) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-25 23:51 Message: Logged In: YES user_id=21627 I still think my patch should be applied as-is, following the instructions above. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-25 14:58 Message: Logged In: YES user_id=3066 Martin/Thomas: do you two still want to see one of these patches applied for 2.2? Which of the two patches makes the most sense to you? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-11 09:01 Message: Logged In: YES user_id=21627 I have created this patch because I was not aware of the other one; the bug #231774 log did not indicate that a patch was in progress. As for the specific differences between them: I like pyconfig.h better than pyac_config.h. The file object chunk was there by mistake; I have removed it. I don't think that the distutils as shipped with Python need to check for config.h, since the Python release having this version of distutils will use only pyconfig.h. For independent distutils releases, looking for config.h might be necessary. I also don't think that the documentation should mention config.h; Python documentation was always accurate only for the release in which it was included. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-04-11 05:40 Message: Logged In: YES user_id=34209 I may be biased, but I don't see the difference between this patch and my patch, except that there are some errors in this patch :) It includes a change in fileobject.h that isn't supposed to be there (I think), and it changes distutils in the wrong way (distutils, for backward compatibility, should check for both config.h and pyconfig.h) -- though my patch doesn't address the latter issue, it doesn't touch distutils at all. Documentation should also mention both config.h and pyconfig.h. Other than that, I don't care which patch gets accepted, by the way :) But maybe Martin can explain why he created this patch ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:11 Message: Logged In: YES user_id=6380 PS. Does this supersede patch #403978? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:09 Message: Logged In: YES user_id=6380 Let's do this after 2.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411138&group_id=5470 From noreply@sourceforge.net Thu Jul 26 21:45:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 13:45:33 -0700 Subject: [Patches] [ python-Patches-444854 ] Distutils config _link doesn't clean up Message-ID: Patches item #444854, was opened at 2001-07-26 09:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=444854&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tarn Weisner Burton (twburton) Assigned to: Nobody/Anonymous (nobody) Summary: Distutils config _link doesn't clean up Initial Comment: The distutils.config.config._link method doesn't return the right program name for win32 and hence doesn't clean up after itself properly. There's a comment about this in the source...is there a reason this isn't done? Anyways, the offending code is: prog = os.path.splitext(os.path.basename(src))[0] self.temp_files.append(prog) which should be changed to prog = os.path.splitext(os.path.basename(src))[0] if sys.platform == 'win32': prog = prog + '.exe' self.temp_files.append(prog) The sys module needs to imported also. thanks, Tarn ---------------------------------------------------------------------- >Comment By: Tarn Weisner Burton (twburton) Date: 2001-07-26 13:45 Message: Logged In: YES user_id=21784 Sorry, previous fix doesn't quite work. The lines: if sys.platform == 'win32': prog = prog + '.exe' self.temp_files.append(prog) need to be placed after the line: self.compiler.link_executable(... otherwise the executable gets the wrong name ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=444854&group_id=5470 From noreply@sourceforge.net Fri Jul 27 04:55:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 20:55:37 -0700 Subject: [Patches] [ python-Patches-432401 ] unicode encoding error callbacks Message-ID: Patches item #432401, was opened at 2001-06-12 06:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=432401&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: unicode encoding error callbacks Initial Comment: This patch adds unicode error handling callbacks to the encode functionality. With this patch it's possible to not only pass 'strict', 'ignore' or 'replace' as the errors argument to encode, but also a callable function, that will be called with the encoding name, the original unicode object and the position of the unencodable character. The callback must return a replacement unicode object that will be encoded instead of the original character. For example replacing unencodable characters with XML character references can be done in the following way. u"aäoöuüß".encode( "ascii", lambda enc, uni, pos: u"&#x%x;" % ord(uni[pos]) ) ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2001-07-26 20:55 Message: Logged In: YES user_id=89016 Changing the decoding API is done now. There are new functions codec.register_unicodedecodeerrorhandler and codec.lookup_unicodedecodeerrorhandler. Only the standard handlers for 'strict', 'ignore' and 'replace' are preregistered. There may be many reasons for decoding errors in the byte string, so I added an additional argument to the decoding API: reason, which gives the reason for the failure, e.g.: >>> "\U1111111".decode("unicode_escape") Traceback (most recent call last): File "", line 1, in ? UnicodeError: encoding 'unicodeescape' can't decode byte 0x31 in position 8: truncated \UXXXXXXXX escape >>> "\U11111111".decode("unicode_escape") Traceback (most recent call last): File "", line 1, in ? UnicodeError: encoding 'unicodeescape' can't decode byte 0x31 in position 9: illegal Unicode character For symmetry I added this to the encoding API too: >>> u"\xff".encode("ascii") Traceback (most recent call last): File "", line 1, in ? UnicodeError: encoding 'ascii' can't decode byte 0xff in position 0: ordinal not in range(128) The parameters passed to the callbacks now are: encoding, unicode, position, reason, state. The encoding and decoding API for strings has been adapted too, so now the new API should be usable everywhere: >>> unicode("a\xffb\xffc", "ascii", ... lambda enc, uni, pos, rea, sta: (u"", pos+1)) u'abc' >>> "a\xffb\xffc".decode("ascii", ... lambda enc, uni, pos, rea, sta: (u"", pos+1)) u'abc' I had a problem with the decoding API: all the functions in _codecsmodule.c used the t# format specifier. I changed that to O! with &PyString_Type, because otherwise we would have the problem that the decoding API would must pass buffer object around instead of strings, and the callback would have to call str() on the buffer anyway to access a specific character, so this wouldn't be any faster than calling str() on the buffer before decoding. It seems that buffers aren't used anyway. I changed all the old function to call the new ones so bugfixes don't have to be done in two places. There are two exceptions: I didn't change PyString_AsEncodedString and PyString_AsDecodedString because they are documented as deprecated anyway (although they are called in a few spots) This means that I duplicated part of their functionality in PyString_AsEncodedObjectEx and PyString_AsDecodedObjectEx. There are still a few spots that call the old API: E.g. PyString_Format still calls PyUnicode_Decode (but with strict decoding) because it passes the rest of the format string to PyUnicode_Format when it encounters a Unicode object. Should we switch to the new API everywhere even if strict encoding/decoding is used? The size of this patch begins to scare me. I guess we need an extensive test script for all the new features and documentation. I hope you have time to do that, as I'll be busy with other projects in the next weeks. (BTW, I have't touched PyUnicode_TranslateCharmap yet.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-07-23 10:03 Message: Logged In: YES user_id=89016 New version of the patch with the error handling callback registry. > > OK, done, now there's a > > PyCodec_EscapeReplaceUnicodeEncodeErrors/ > > codecs.escapereplace_unicodeencode_errors > > that uses \u (or \U if x>0xffff (with a wide build > > of Python)). > > Great! Now PyCodec_EscapeReplaceUnicodeEncodeErrors uses \x in addition to \u and \U where appropriate. > > [...] > > But for special one-shot error handlers, it might still be > > useful to pass the error handler directly, so maybe we > > should leave error as PyObject *, but implement the > > registry anyway? > > Good idea ! > > One minor nit: codecs.registerError() should be named > codecs.register_errorhandler() to be more inline with > the Python coding style guide. OK, but these function are specific to unicode encoding, so now the functions are called: codecs.register_unicodeencodeerrorhandler codecs.lookup_unicodeencodeerrorhandler Now all callbacks (including the new ones: "xmlcharrefreplace" and "escapereplace") are registered in the codecs.c/_PyCodecRegistry_Init so using them is really simple: u"gürk".encode("ascii", "xmlcharrefreplace") ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-13 04:26 Message: Logged In: YES user_id=38388 > > > > > BTW, I guess PyUnicode_EncodeUnicodeEscape > > > > > could be reimplemented as PyUnicode_EncodeASCII > > > > > with \uxxxx replacement callback. > > > > > > > > Hmm, wouldn't that result in a slowdown ? If so, > > > > I'd rather leave the special encoder in place, > > > > since it is being used a lot in Python and > > > > probably some applications too. > > > > > > It would be a slowdown. But callbacks open many > > > possiblities. > > > > True, but in this case I believe that we should stick with > > the native implementation for "unicode-escape". Having > > a standard callback error handler which does the \uXXXX > > replacement would be nice to have though, since this would > > also be usable with lots of other codecs (e.g. all the > > code page ones). > > OK, done, now there's a > PyCodec_EscapeReplaceUnicodeEncodeErrors/ > codecs.escapereplace_unicodeencode_errors > that uses \u (or \U if x>0xffff (with a wide build > of Python)). Great ! > > [...] > > > Should the old TranslateCharmap map to the new > > > TranslateCharmapEx and inherit the > > > "multicharacter replacement" feature, > > > or should I leave it as it is? > > > > If possible, please also add the multichar replacement > > to the old API. I think it is very useful and since the > > old APIs work on raw buffers it would be a benefit to have > > the functionality in the old implementation too. > > OK! I will try to find the time to implement that in the > next days. Good. > > [Decoding error callbacks] > > > > About the return value: > > > > I'd suggest to always use the same tuple interface, e.g. > > > > callback(encoding, input_data, input_position, > state) -> > > (output_to_be_appended, new_input_position) > > > > (I think it's better to use absolute values for the > > position rather than offsets.) > > > > Perhaps the encoding callbacks should use the same > > interface... what do you think ? > > This would make the callback feature hypergeneric and a > little slower, because tuples have to be created, but it > (almost) unifies the encoding and decoding API. ("almost" > because, for the encoder output_to_be_appended will be > reencoded, for the decoder it will simply be appended.), > so I'm for it. That's the point. Note that I don't think the tuple creation will hurt much (see the make_tuple() API in codecs.c) since small tuples are cached by Python internally. > I implemented this and changed the encoders to only > lookup the error handler on the first error. The UCS1 > encoder now no longer uses the two-item stack strategy. > (This strategy only makes sense for those encoder where > the encoding itself is much more complicated than the > looping/callback etc.) So now memory overflow tests are > only done, when an unencodable error occurs, so now the > UCS1 encoder should be as fast as it was without > error callbacks. > > Do we want to enforce new_input_position>input_position, > or should jumping back be allowed? No; moving backwards should be allowed (this may be useful in order to resynchronize with the input data). > Here's is the current todo list: > 1. implement a new TranslateCharmap and fix the old. > 2. New encoding API for string objects too. > 3. Decoding > 4. Documentation > 5. Test cases > > I'm thinking about a different strategy for implementing > callbacks > (see http://mail.python.org/pipermail/i18n-sig/2001- > July/001262.html) > > We coould have a error handler registry, which maps names > to error handlers, then it would be possible to keep the > errors argument as "const char *" instead of "PyObject *". > Currently PyCodec_UnicodeEncodeHandlerForObject is a > backwards compatibility hack that will never go away, > because > it's always more convenient to type > u"...".encode("...", "strict") > instead of > import codecs > u"...".encode("...", codecs.raise_encode_errors) > > But with an error handler registry this function would > become the official lookup method for error handlers. > (PyCodec_LookupUnicodeEncodeErrorHandler?) > Python code would look like this: > --- > def xmlreplace(encoding, unicode, pos, state): > return (u"&#%d;" % ord(uni[pos]), pos+1) > > import codec > > codec.registerError("xmlreplace",xmlreplace) > --- > and then the following call can be made: > u"äöü".encode("ascii", "xmlreplace") > As soon as the first error is encountered, the encoder uses > its builtin error handling method if it recognizes the name > ("strict", "replace" or "ignore") or looks up the error > handling function in the registry if it doesn't. In this way > the speed for the backwards compatible features is the same > as before and "const char *error" can be kept as the > parameter to all encoding functions. For speed common error > handling names could even be implemented in the encoder > itself. > > But for special one-shot error handlers, it might still be > useful to pass the error handler directly, so maybe we > should leave error as PyObject *, but implement the > registry anyway? Good idea ! One minor nit: codecs.registerError() should be named codecs.register_errorhandler() to be more inline with the Python coding style guide. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-07-12 04:03 Message: Logged In: YES user_id=89016 > > [...] > > so I guess we could change the replace handler > > to always return u'?'. This would make the > > implementation a little bit simpler, but the > > explanation of the callback feature *a lot* > > simpler. > > Go for it. OK, done! > [...] > > > Could you add these docs to the Misc/unicode.txt > > > file ? I will eventually take that file and turn > > > it into a PEP which will then serve as general > > > documentation for these things. > > > > I could, but first we should work out how the > > decoding callback API will work. > > Ok. BTW, Barry Warsaw already did the work of converting > the unicode.txt to PEP 100, so the docs should eventually > go there. OK. I guess it would be best to do this when everything is finished. > > > > BTW, I guess PyUnicode_EncodeUnicodeEscape > > > > could be reimplemented as PyUnicode_EncodeASCII > > > > with \uxxxx replacement callback. > > > > > > Hmm, wouldn't that result in a slowdown ? If so, > > > I'd rather leave the special encoder in place, > > > since it is being used a lot in Python and > > > probably some applications too. > > > > It would be a slowdown. But callbacks open many > > possiblities. > > True, but in this case I believe that we should stick with > the native implementation for "unicode-escape". Having > a standard callback error handler which does the \uXXXX > replacement would be nice to have though, since this would > also be usable with lots of other codecs (e.g. all the > code page ones). OK, done, now there's a PyCodec_EscapeReplaceUnicodeEncodeErrors/ codecs.escapereplace_unicodeencode_errors that uses \u (or \U if x>0xffff (with a wide build of Python)). > > For example: > > > > Why can't I print u"gürk"? > > > > is probably one of the most frequently asked > > questions in comp.lang.python. For printing > > Unicode stuff, print could be extended the use an > > error handling callback for Unicode strings (or > > objects where __str__ or tp_str returns a Unicode > > object) instead of using str() which always > > returns an 8bit string and uses strict encoding. > > There might even be a > > sys.setprintencodehandler()/sys.getprintencodehandler () > > There already is a print callback in Python (forgot the > name of the hook though), so this should be possible by > providing the encoding logic in the hook. True: sys.displayhook > [...] > > Should the old TranslateCharmap map to the new > > TranslateCharmapEx and inherit the > > "multicharacter replacement" feature, > > or should I leave it as it is? > > If possible, please also add the multichar replacement > to the old API. I think it is very useful and since the > old APIs work on raw buffers it would be a benefit to have > the functionality in the old implementation too. OK! I will try to find the time to implement that in the next days. > [Decoding error callbacks] > > About the return value: > > I'd suggest to always use the same tuple interface, e.g. > > callback(encoding, input_data, input_position, state) -> > (output_to_be_appended, new_input_position) > > (I think it's better to use absolute values for the > position rather than offsets.) > > Perhaps the encoding callbacks should use the same > interface... what do you think ? This would make the callback feature hypergeneric and a little slower, because tuples have to be created, but it (almost) unifies the encoding and decoding API. ("almost" because, for the encoder output_to_be_appended will be reencoded, for the decoder it will simply be appended.), so I'm for it. I implemented this and changed the encoders to only lookup the error handler on the first error. The UCS1 encoder now no longer uses the two-item stack strategy. (This strategy only makes sense for those encoder where the encoding itself is much more complicated than the looping/callback etc.) So now memory overflow tests are only done, when an unencodable error occurs, so now the UCS1 encoder should be as fast as it was without error callbacks. Do we want to enforce new_input_position>input_position, or should jumping back be allowed? > > > > One additional note: It is vital that errors > > > > is an assignable attribute of the StreamWriter. > > > > > > It is already ! > > > > I know, but IMHO it should be documented that an > > assignable errors attribute must be supported > > as part of the official codec API. > > > > Misc/unicode.txt is not clear on that: > > """ > > It is not required by the Unicode implementation > > to use these base classes, only the interfaces must > > match; this allows writing Codecs as extension types. > > """ > > Good point. I'll add that to the PEP 100. OK. Here's is the current todo list: 1. implement a new TranslateCharmap and fix the old. 2. New encoding API for string objects too. 3. Decoding 4. Documentation 5. Test cases I'm thinking about a different strategy for implementing callbacks (see http://mail.python.org/pipermail/i18n-sig/2001- July/001262.html) We coould have a error handler registry, which maps names to error handlers, then it would be possible to keep the errors argument as "const char *" instead of "PyObject *". Currently PyCodec_UnicodeEncodeHandlerForObject is a backwards compatibility hack that will never go away, because it's always more convenient to type u"...".encode("...", "strict") instead of import codecs u"...".encode("...", codecs.raise_encode_errors) But with an error handler registry this function would become the official lookup method for error handlers. (PyCodec_LookupUnicodeEncodeErrorHandler?) Python code would look like this: --- def xmlreplace(encoding, unicode, pos, state): return (u"&#%d;" % ord(uni[pos]), pos+1) import codec codec.registerError("xmlreplace",xmlreplace) --- and then the following call can be made: u"äöü".encode("ascii", "xmlreplace") As soon as the first error is encountered, the encoder uses its builtin error handling method if it recognizes the name ("strict", "replace" or "ignore") or looks up the error handling function in the registry if it doesn't. In this way the speed for the backwards compatible features is the same as before and "const char *error" can be kept as the parameter to all encoding functions. For speed common error handling names could even be implemented in the encoder itself. But for special one-shot error handlers, it might still be useful to pass the error handler directly, so maybe we should leave error as PyObject *, but implement the registry anyway? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-10 05:29 Message: Logged In: YES user_id=38388 Ok, here we go... > > > raise an exception). U+FFFD characters in the > replacement > > > string will be replaced with a character that the > encoder > > > chooses ('?' in all cases). > > > > Nice. > > But the special casing of U+FFFD makes the interface > somewhat > less clean than it could be. It was only done to be 100% > backwards compatible. With the original "replace" > error > handling the codec chose the replacement character. But as > far as I can tell none of the codecs uses anything other > than '?', True. > so I guess we could change the replace handler > to always return u'?'. This would make the implementation a > little bit simpler, but the explanation of the callback > feature *a lot* simpler. Go for it. > And if you still want to handle > an unencodable U+FFFD, you can write a special callback for > that, e.g. > > def FFFDreplace(enc, uni, pos): > if uni[pos] == "\ufffd": > return u"?" > else: > raise UnicodeError(...) > > > ...docs... > > > > Could you add these docs to the Misc/unicode.txt file ? I > > will eventually take that file and turn it into a PEP > which > > will then serve as general documentation for these things. > > I could, but first we should work out how the decoding > callback API will work. Ok. BTW, Barry Warsaw already did the work of converting the unicode.txt to PEP 100, so the docs should eventually go there. > > > BTW, I guess PyUnicode_EncodeUnicodeEscape could be > > > reimplemented as PyUnicode_EncodeASCII with a \uxxxx > > > replacement callback. > > > > Hmm, wouldn't that result in a slowdown ? If so, I'd > rather > > leave the special encoder in place, since it is being > used a > > lot in Python and probably some applications too. > > It would be a slowdown. But callbacks open many > possiblities. True, but in this case I believe that we should stick with the native implementation for "unicode-escape". Having a standard callback error handler which does the \uXXXX replacement would be nice to have though, since this would also be usable with lots of other codecs (e.g. all the code page ones). > For example: > > Why can't I print u"gürk"? > > is probably one of the most frequently asked questions in > comp.lang.python. For printing Unicode stuff, print could be > extended the use an error handling callback for Unicode > strings (or objects where __str__ or tp_str returns a > Unicode object) instead of using str() which always returns > an 8bit string and uses strict encoding. There might even > be a > sys.setprintencodehandler()/sys.getprintencodehandler() There already is a print callback in Python (forgot the name of the hook though), so this should be possible by providing the encoding logic in the hook. > > > I have not touched PyUnicode_TranslateCharmap yet, > > > should this function also support error callbacks? Why > > > would one want the insert None into the mapping to > call > > > the callback? > > > > 1. Yes. > > 2. The user may want to e.g. restrict usage of certain > > character ranges. In this case the codec would be used to > > verify the input and an exception would indeed be useful > > (e.g. say you want to restrict input to Hangul + ASCII). > > OK, do we want TranslateCharmap to work exactly like > encoding, > i.e. in case of an error should the returned replacement > string again be mapped through the translation mapping or > should it be copied to the output directly? The former would > be more in line with encoding, but IMHO the latter would > be much more useful. It's better to take the second approach (copy the callback output directly to the output string) to avoid endless recursion and other pitfalls. I suppose this will also simplify the implementation somewhat. > BTW, when I implement it I can implement patch #403100 > ("Multicharacter replacements in > PyUnicode_TranslateCharmap") > along the way. I've seen it; will comment on it later. > Should the old TranslateCharmap map to the new > TranslateCharmapEx > and inherit the "multicharacter replacement" feature, > or > should I leave it as it is? If possible, please also add the multichar replacement to the old API. I think it is very useful and since the old APIs work on raw buffers it would be a benefit to have the functionality in the old implementation too. [Decoding error callbacks] > > > A remaining problem is how to implement decoding error > > > callbacks. In Python 2.1 encoding and decoding errors > are > > > handled in the same way with a string value. But with > > > callbacks it doesn't make sense to use the same > callback > > > for encoding and decoding (like > codecs.StreamReaderWriter > > > and codecs.StreamRecoder do). Decoding callbacks have > a > > > different API. Which arguments should be passed to the > > > decoding callback, and what is the decoding callback > > > supposed to do? > > > > I'd suggest adding another set of PyCodec_UnicodeDecode... > () > > APIs for this. We'd then have to augment the base classes > of > > the StreamCodecs to provide two attributes for .errors > with > > a fallback solution for the string case (i.s. "strict" > can > > still be used for both directions). > > Sounds good. Now what is the decoding callback supposed to > do? > I guess it will be called in the same way as the encoding > callback, i.e. with encoding name, original string and > position of the error. It might returns a Unicode string > (i.e. an object of the decoding target type), that will be > emitted from the codec instead of the one offending byte. Or > it might return a tuple with replacement Unicode object and > a resynchronisation offset, i.e. returning (u"?", 1) > means > emit a '?' and skip the offending character. But to make > the offset really useful the callback has to know something > about the encoding, perhaps the codec should be allowed to > pass an additional state object to the callback? > > Maybe the same should be added to the encoding callbacks to? > Maybe the encoding callback should be able to tell the > encoder if the replacement returned should be reencoded > (in which case it's a Unicode object), or directly emitted > (in which case it's an 8bit string)? I like the idea of having an optional state object (basically this should be a codec-defined arbitrary Python object) which then allow the callback to apply additional tricks. The object should be documented to be modifyable in place (simplifies the interface). About the return value: I'd suggest to always use the same tuple interface, e.g. callback(encoding, input_data, input_position, state) -> (output_to_be_appended, new_input_position) (I think it's better to use absolute values for the position rather than offsets.) Perhaps the encoding callbacks should use the same interface... what do you think ? > > > One additional note: It is vital that errors is an > > > assignable attribute of the StreamWriter. > > > > It is already ! > > I know, but IMHO it should be documented that an assignable > errors attribute must be supported as part of the official > codec API. > > Misc/unicode.txt is not clear on that: > """ > It is not required by the Unicode implementation to use > these base classes, only the interfaces must match; this > allows writing Codecs as extension types. > """ Good point. I'll add that to the PEP 100. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-22 13:51 Message: Logged In: YES user_id=38388 Sorry to keep you waiting, Walter. I will look into this again next week -- this week was way too busy... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-13 10:00 Message: Logged In: YES user_id=38388 On your comment about the non-Unicode codecs: let's keep this separated from the current patch. Don't have much time today. I'll comment on the other things tomorrow. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-13 08:49 Message: Logged In: YES user_id=89016 Guido van Rossum wrote in python-dev: > True, the "codec" pattern can be used for other > encodings than Unicode. But it seems to me that the > entire codecs architecture is rather strongly geared > towards en/decoding Unicode, and it's not clear > how well other codecs fit in this pattern (e.g. I > noticed that all the non-Unicode codecs ignore the > error handling parameter or assert that > it is set to 'strict'). I noticed that too. asserting that errors=='strict' would mean that the encoder is not able to deal in any other way with unencodable stuff than by raising an error. But that is not the problem here, because for zlib, base64, quopri, hex and uu encoding there can be no unencodable characters. The encoders can simply ignore the errors parameter. Should I remove the asserts from those codecs and change the docstrings accordingly, or will this be done separately? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-13 06:57 Message: Logged In: YES user_id=89016 > > [...] > > raise an exception). U+FFFD characters in the replacement > > string will be replaced with a character that the encoder > > chooses ('?' in all cases). > > Nice. But the special casing of U+FFFD makes the interface somewhat less clean than it could be. It was only done to be 100% backwards compatible. With the original "replace" error handling the codec chose the replacement character. But as far as I can tell none of the codecs uses anything other than '?', so I guess we could change the replace handler to always return u'?'. This would make the implementation a little bit simpler, but the explanation of the callback feature *a lot* simpler. And if you still want to handle an unencodable U+FFFD, you can write a special callback for that, e.g. def FFFDreplace(enc, uni, pos): if uni[pos] == "\ufffd": return u"?" else: raise UnicodeError(...) > > The implementation of the loop through the string is done > > in the following way. A stack with two strings is kept > > and the loop always encodes a character from the string > > at the stacktop. If an error is encountered and the stack > > has only one entry (during encoding of the original string) > > the callback is called and the unicode object returned is > > pushed on the stack, so the encoding continues with the > > replacement string. If the stack has two entries when an > > error is encountered, the replacement string itself has > > an unencodable character and a normal exception raised. > > When the encoder has reached the end of it's current string > > there are two possibilities: when the stack contains two > > entries, this was the replacement string, so the replacement > > string will be poppep from the stack and encoding continues > > with the next character from the original string. If the > > stack had only one entry, encoding is finished. > > Very elegant solution ! I'll put it as a comment in the source. > > (I hope that's enough explanation of the API and > implementation) > > Could you add these docs to the Misc/unicode.txt file ? I > will eventually take that file and turn it into a PEP which > will then serve as general documentation for these things. I could, but first we should work out how the decoding callback API will work. > > I have renamed the static ...121 function to all lowercase > > names. > > Ok. > > > BTW, I guess PyUnicode_EncodeUnicodeEscape could be > > reimplemented as PyUnicode_EncodeASCII with a \uxxxx > > replacement callback. > > Hmm, wouldn't that result in a slowdown ? If so, I'd rather > leave the special encoder in place, since it is being used a > lot in Python and probably some applications too. It would be a slowdown. But callbacks open many possiblities. For example: Why can't I print u"gürk"? is probably one of the most frequently asked questions in comp.lang.python. For printing Unicode stuff, print could be extended the use an error handling callback for Unicode strings (or objects where __str__ or tp_str returns a Unicode object) instead of using str() which always returns an 8bit string and uses strict encoding. There might even be a sys.setprintencodehandler()/sys.getprintencodehandler() > [...] > I think it would be worthwhile to rename the callbacks to > include "Unicode" somewhere, e.g. > PyCodec_UnicodeReplaceEncodeErrors(). It's a long name, but > then it points out the application field of the callback > rather well. Same for the callbacks exposed through the > _codecsmodule. OK, done (and PyCodec_XMLCharRefReplaceUnicodeEncodeErrors really is a long name ;)) > > I have not touched PyUnicode_TranslateCharmap yet, > > should this function also support error callbacks? Why > > would one want the insert None into the mapping to call > > the callback? > > 1. Yes. > 2. The user may want to e.g. restrict usage of certain > character ranges. In this case the codec would be used to > verify the input and an exception would indeed be useful > (e.g. say you want to restrict input to Hangul + ASCII). OK, do we want TranslateCharmap to work exactly like encoding, i.e. in case of an error should the returned replacement string again be mapped through the translation mapping or should it be copied to the output directly? The former would be more in line with encoding, but IMHO the latter would be much more useful. BTW, when I implement it I can implement patch #403100 ("Multicharacter replacements in PyUnicode_TranslateCharmap") along the way. Should the old TranslateCharmap map to the new TranslateCharmapEx and inherit the "multicharacter replacement" feature, or should I leave it as it is? > > A remaining problem is how to implement decoding error > > callbacks. In Python 2.1 encoding and decoding errors are > > handled in the same way with a string value. But with > > callbacks it doesn't make sense to use the same callback > > for encoding and decoding (like codecs.StreamReaderWriter > > and codecs.StreamRecoder do). Decoding callbacks have a > > different API. Which arguments should be passed to the > > decoding callback, and what is the decoding callback > > supposed to do? > > I'd suggest adding another set of PyCodec_UnicodeDecode... () > APIs for this. We'd then have to augment the base classes of > the StreamCodecs to provide two attributes for .errors with > a fallback solution for the string case (i.s. "strict" can > still be used for both directions). Sounds good. Now what is the decoding callback supposed to do? I guess it will be called in the same way as the encoding callback, i.e. with encoding name, original string and position of the error. It might returns a Unicode string (i.e. an object of the decoding target type), that will be emitted from the codec instead of the one offending byte. Or it might return a tuple with replacement Unicode object and a resynchronisation offset, i.e. returning (u"?", 1) means emit a '?' and skip the offending character. But to make the offset really useful the callback has to know something about the encoding, perhaps the codec should be allowed to pass an additional state object to the callback? Maybe the same should be added to the encoding callbacks to? Maybe the encoding callback should be able to tell the encoder if the replacement returned should be reencoded (in which case it's a Unicode object), or directly emitted (in which case it's an 8bit string)? > > One additional note: It is vital that errors is an > > assignable attribute of the StreamWriter. > > It is already ! I know, but IMHO it should be documented that an assignable errors attribute must be supported as part of the official codec API. Misc/unicode.txt is not clear on that: """ It is not required by the Unicode implementation to use these base classes, only the interfaces must match; this allows writing Codecs as extension types. """ ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-13 01:05 Message: Logged In: YES user_id=38388 > How the callbacks work: > > A PyObject * named errors is passed in. This may by NULL, > Py_None, 'strict', u'strict', 'ignore', u'ignore', > 'replace', u'replace' or a callable object. > PyCodec_EncodeHandlerForObject maps all of these objects to > one of the three builtin error callbacks > PyCodec_RaiseEncodeErrors (raises an exception), > PyCodec_IgnoreEncodeErrors (returns an empty replacement > string, in effect ignoring the error), > PyCodec_ReplaceEncodeErrors (returns U+FFFD, the Unicode > replacement character to signify to the encoder that it > should choose a suitable replacement character) or directly > returns errors if it is a callable object. When an > unencodable character is encounterd the error handling > callback will be called with the encoding name, the original > unicode object and the error position and must return a > unicode object that will be encoded instead of the offending > character (or the callback may of course raise an > exception). U+FFFD characters in the replacement string will > be replaced with a character that the encoder chooses ('?' > in all cases). Nice. > The implementation of the loop through the string is done in > the following way. A stack with two strings is kept and the > loop always encodes a character from the string at the > stacktop. If an error is encountered and the stack has only > one entry (during encoding of the original string) the > callback is called and the unicode object returned is pushed > on the stack, so the encoding continues with the replacement > string. If the stack has two entries when an error is > encountered, the replacement string itself has an > unencodable character and a normal exception raised. When > the encoder has reached the end of it's current string there > are two possibilities: when the stack contains two entries, > this was the replacement string, so the replacement string > will be poppep from the stack and encoding continues with > the next character from the original string. If the stack > had only one entry, encoding is finished. Very elegant solution ! > (I hope that's enough explanation of the API and implementation) Could you add these docs to the Misc/unicode.txt file ? I will eventually take that file and turn it into a PEP which will then serve as general documentation for these things. > I have renamed the static ...121 function to all lowercase > names. Ok. > BTW, I guess PyUnicode_EncodeUnicodeEscape could be > reimplemented as PyUnicode_EncodeASCII with a \uxxxx > replacement callback. Hmm, wouldn't that result in a slowdown ? If so, I'd rather leave the special encoder in place, since it is being used a lot in Python and probably some applications too. > PyCodec_RaiseEncodeErrors, PyCodec_IgnoreEncodeErrors, > PyCodec_ReplaceEncodeErrors are globally visible because > they have to be available in _codecsmodule.c to wrap them as > Python function objects, but they can't be implemented in > _codecsmodule, because they need to be available to the > encoders in unicodeobject.c (through > PyCodec_EncodeHandlerForObject), but importing the codecs > module might result in an endless recursion, because > importing a module requires unpickling of the bytecode, > which might require decoding utf8, which ... (but this will > only happen, if we implement the same mechanism for the > decoding API) I think that codecs.c is the right place for these APIs. _codecsmodule.c is only meant as Python access wrapper for the internal codecs and nothing more. One thing I noted about the callbacks: they assume that they will always get Unicode objects as input. This is certainly not true in the general case (it is for the codecs you touch in the patch). I think it would be worthwhile to rename the callbacks to include "Unicode" somewhere, e.g. PyCodec_UnicodeReplaceEncodeErrors(). It's a long name, but then it points out the application field of the callback rather well. Same for the callbacks exposed through the _codecsmodule. > I have not touched PyUnicode_TranslateCharmap yet, > should this function also support error callbacks? Why would > one want the insert None into the mapping to call the callback? 1. Yes. 2. The user may want to e.g. restrict usage of certain character ranges. In this case the codec would be used to verify the input and an exception would indeed be useful (e.g. say you want to restrict input to Hangul + ASCII). > A remaining problem is how to implement decoding error > callbacks. In Python 2.1 encoding and decoding errors are > handled in the same way with a string value. But with > callbacks it doesn't make sense to use the same callback for > encoding and decoding (like codecs.StreamReaderWriter and > codecs.StreamRecoder do). Decoding callbacks have a > different API. Which arguments should be passed to the > decoding callback, and what is the decoding callback > supposed to do? I'd suggest adding another set of PyCodec_UnicodeDecode...() APIs for this. We'd then have to augment the base classes of the StreamCodecs to provide two attributes for .errors with a fallback solution for the string case (i.s. "strict" can still be used for both directions). > One additional note: It is vital that errors is an > assignable attribute of the StreamWriter. It is already ! > Consider the XML example: For writing an XML DOM tree one > StreamWriter object is used. When a text node is written, > the error handling has to be set to > codecs.xmlreplace_encode_errors, but inside a comment or > processing instruction replacing unencodable characters with > charrefs is not possible, so here codecs.raise_encode_errors > should be used (or better a custom error handler that raises > an error that says "sorry, you can't have unencodable > characters inside a comment") Sure. > BTW, should we continue the discussion in the i18n SIG > mailing list? An email program is much more comfortable than > a HTML textarea! ;) I'd rather keep the discussions on this patch here -- forking it off to the i18n sig will make it very hard to follow up on it. (This HTML area is indeed damn small ;-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 12:18 Message: Logged In: YES user_id=89016 One additional note: It is vital that errors is an assignable attribute of the StreamWriter. Consider the XML example: For writing an XML DOM tree one StreamWriter object is used. When a text node is written, the error handling has to be set to codecs.xmlreplace_encode_errors, but inside a comment or processing instruction replacing unencodable characters with charrefs is not possible, so here codecs.raise_encode_errors should be used (or better a custom error handler that raises an error that says "sorry, you can't have unencodable characters inside a comment") BTW, should we continue the discussion in the i18n SIG mailing list? An email program is much more comfortable than a HTML textarea! ;) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 11:59 Message: Logged In: YES user_id=89016 How the callbacks work: A PyObject * named errors is passed in. This may by NULL, Py_None, 'strict', u'strict', 'ignore', u'ignore', 'replace', u'replace' or a callable object. PyCodec_EncodeHandlerForObject maps all of these objects to one of the three builtin error callbacks PyCodec_RaiseEncodeErrors (raises an exception), PyCodec_IgnoreEncodeErrors (returns an empty replacement string, in effect ignoring the error), PyCodec_ReplaceEncodeErrors (returns U+FFFD, the Unicode replacement character to signify to the encoder that it should choose a suitable replacement character) or directly returns errors if it is a callable object. When an unencodable character is encounterd the error handling callback will be called with the encoding name, the original unicode object and the error position and must return a unicode object that will be encoded instead of the offending character (or the callback may of course raise an exception). U+FFFD characters in the replacement string will be replaced with a character that the encoder chooses ('?' in all cases). The implementation of the loop through the string is done in the following way. A stack with two strings is kept and the loop always encodes a character from the string at the stacktop. If an error is encountered and the stack has only one entry (during encoding of the original string) the callback is called and the unicode object returned is pushed on the stack, so the encoding continues with the replacement string. If the stack has two entries when an error is encountered, the replacement string itself has an unencodable character and a normal exception raised. When the encoder has reached the end of it's current string there are two possibilities: when the stack contains two entries, this was the replacement string, so the replacement string will be poppep from the stack and encoding continues with the next character from the original string. If the stack had only one entry, encoding is finished. (I hope that's enough explanation of the API and implementation) I have renamed the static ...121 function to all lowercase names. BTW, I guess PyUnicode_EncodeUnicodeEscape could be reimplemented as PyUnicode_EncodeASCII with a \uxxxx replacement callback. PyCodec_RaiseEncodeErrors, PyCodec_IgnoreEncodeErrors, PyCodec_ReplaceEncodeErrors are globally visible because they have to be available in _codecsmodule.c to wrap them as Python function objects, but they can't be implemented in _codecsmodule, because they need to be available to the encoders in unicodeobject.c (through PyCodec_EncodeHandlerForObject), but importing the codecs module might result in an endless recursion, because importing a module requires unpickling of the bytecode, which might require decoding utf8, which ... (but this will only happen, if we implement the same mechanism for the decoding API) I have not touched PyUnicode_TranslateCharmap yet, should this function also support error callbacks? Why would one want the insert None into the mapping to call the callback? A remaining problem is how to implement decoding error callbacks. In Python 2.1 encoding and decoding errors are handled in the same way with a string value. But with callbacks it doesn't make sense to use the same callback for encoding and decoding (like codecs.StreamReaderWriter and codecs.StreamRecoder do). Decoding callbacks have a different API. Which arguments should be passed to the decoding callback, and what is the decoding callback supposed to do? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-12 11:00 Message: Logged In: YES user_id=38388 About the Py_UNICODE*data, int size APIs: Ok, point taken. In general, I think we ought to keep the callback feature as open as possible, so passing in pointers and sizes would not be very useful. BTW, could you summarize how the callback works in a few lines ? About _Encode121: I'd name this _EncodeUCS1 since that's what it is ;-) About the new functions: I was referring to the new static functions which you gave PyUnicode_... names. If these are not supposed to turn into non-static functions, I'd rather have them use lower case names (since that's how the Python internals work too -- most of the times). ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 09:56 Message: Logged In: YES user_id=89016 > One thing which I don't like about your API change is that > you removed the Py_UNICODE*data, int size style arguments > -- > this makes it impossible to use the new APIs on non-Python > data or data which is not available as Unicode object. Another problem is, that the callback requires a Python object, so in the PyObject *version, the refcount is incref'd and the object is passed to the callback. The Py_UNICODE*/int version would have to create a new Unicode object from the data. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 09:32 Message: Logged In: YES user_id=89016 > * please don't place more than one C statement on one line > like in: > """ > + unicode = unicode2; unicodepos = > unicode2pos; > + unicode2 = NULL; unicode2pos = 0; > """ OK, done! > * Comments should start with a capital letter and be > prepended > to the section they apply to Fixed! > * There should be spaces between arguments in compares > (a == b) not (a==b) Fixed! > * Where does the name "...Encode121" originate ? encode one-to-one, it implements both ASCII and latin-1 encoding. > * module internal APIs should use lower case names (you > converted some of these to PyUnicode_...() -- this is > normally reserved for APIs which are either marked as > potential candidates for the public API or are very > prominent in the code) Which ones? I introduced a new function for every old one, that had a "const char *errors" argument, and a few new ones in codecs.h, of those PyCodec_EncodeHandlerForObject is vital, because it is used to map for old string arguments to the new function objects. PyCodec_RaiseEncodeErrors can be used in the encoder implementation to raise an encode error, but it could be made static in unicodeobject.h so only those encoders implemented there have access to it. > One thing which I don't like about your API change is that > you removed the Py_UNICODE*data, int size style arguments > -- > this makes it impossible to use the new APIs on non-Python > data or data which is not available as Unicode object. I look through the code and found no situation where the Py_UNICODE*/int version is really used and having two (PyObject *)s (the original and the replacement string), instead of UNICODE*/int and PyObject * made the implementation a little easier, but I can fix that. > Please separate the errors.c patch from this patch -- it > seems totally unrelated to Unicode. PyCodec_RaiseEncodeErrors uses this the have a \Uxxxx with four hex digits. I removed it. I'll upload a revised patch as soon as it's done. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-12 07:29 Message: Logged In: YES user_id=38388 Thanks for the patch -- it looks very impressive !. I'll give it a try later this week. Some first cosmetic tidbits: * please don't place more than one C statement on one line like in: """ + unicode = unicode2; unicodepos = unicode2pos; + unicode2 = NULL; unicode2pos = 0; """ * Comments should start with a capital letter and be prepended to the section they apply to * There should be spaces between arguments in compares (a == b) not (a==b) * Where does the name "...Encode121" originate ? * module internal APIs should use lower case names (you converted some of these to PyUnicode_...() -- this is normally reserved for APIs which are either marked as potential candidates for the public API or are very prominent in the code) One thing which I don't like about your API change is that you removed the Py_UNICODE*data, int size style arguments -- this makes it impossible to use the new APIs on non-Python data or data which is not available as Unicode object. Please separate the errors.c patch from this patch -- it seems totally unrelated to Unicode. Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=432401&group_id=5470 From noreply@sourceforge.net Sat Jul 28 05:16:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Jul 2001 21:16:18 -0700 Subject: [Patches] [ python-Patches-445412 ] extract ndiff functionality to difflib Message-ID: Patches item #445412, was opened at 2001-07-27 21:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445412&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Nobody/Anonymous (nobody) Summary: extract ndiff functionality to difflib Initial Comment: This is a followup to patch 438331, "make ndiff.py into a library module" (http://sourceforge.net/ tracker/?func=detail&atid=305470&aid=438331& group_id=5470). Tools/scripts/ndiff.py: - Extracted useful functionality to Lib/difflib.py. - Moved most explanatory comments to difflib.py, some as docstrings, some as comments. Lib/difflib.py: - Functionality from ndiff.py now accessible from class Differ, and convenience functions ndiff() and restore(). Fully docstringed and doctested. - Rearranged SequenceMatcher docstrings: removed duplicates (class docs were in class AND module docstrings). - Bumped version up to 1.7.0 (if it matters). TeX documentation patch posted separately. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445412&group_id=5470 From noreply@sourceforge.net Sat Jul 28 05:28:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Jul 2001 21:28:54 -0700 Subject: [Patches] [ python-Patches-445413 ] docs for Lib/difflib.py patch Message-ID: Patches item #445413, was opened at 2001-07-27 21:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445413&group_id=5470 Category: documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Nobody/Anonymous (nobody) Summary: docs for Lib/difflib.py patch Initial Comment: Docs for http://sourceforge.net/tracker/ index.php?func=detail&aid=445412&group_id= 5470&atid=305470 ; followup to patch 438331, "make ndiff.py into a library module" (http:// sourceforge.net/tracker/?func=detail&atid= 305470&aid=438331&group_id=5470). - Added docs for class Differ; functions ndiff(), restore(), IS_LINE_JUNK(), IS_CHARACTER_JUNK. - Rearranged the module overview part; hope you like it. - New subsection for each of Differ class & examples. - Minor edits to SequenceMatcher subsection to account for Tools/scripts/ndiff.py functionality extraction. - Since there are now two Examples subsections, renamed "difflib-examples" to "sequencematcher- examples". This patch is untested as I don't have LaTeX installed; hopefully there aren't (too many) errors. Apologies in advance if there are. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445413&group_id=5470 From noreply@sourceforge.net Sat Jul 28 05:36:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Jul 2001 21:36:01 -0700 Subject: [Patches] [ python-Patches-438331 ] make ndiff.py into a library module Message-ID: Patches item #438331, was opened at 2001-07-03 12:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438331&group_id=5470 Category: demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Tim Peters (tim_one) Summary: make ndiff.py into a library module Initial Comment: Here's a patch to make ndiff.py's functionality generally available to Python programs. It should move from Tools/scripts/ to Lib/. ndiff.py's functionality is very useful for making comparisons human-readable. I wanted to use it from my Python code (unittest's of generated XML), but unfortunately ndiff.py wasn't written that way. So I refactored out the lists-of-strings comparison code from fcompare() into lcompare(), and parameterized the formerly hard-coded IS_*_JUNK filters. I'd like to see it further converted to return a diff string, rather than only spew to stdout. It's easy enough to capture stdout, but klugey. I will do the mods if they have a good-to-certain chance of making it in. (Please let me know.) Also, give me the word and I will whip up some TeX docs if Tim doesn't have the time. ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2001-07-27 21:36 Message: Logged In: YES user_id=7733 Submitted new patches for difflib & ndiff (http:// sourceforge.net/tracker/?func=detail&aid=445412& group_id=5470&atid=305470), and docs (http:// sourceforge.net/tracker/?func=detail&aid=445413& group_id=5470&atid=305470). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-10 20:51 Message: Logged In: YES user_id=31435 David, Guido has given his blessing to this. Refactoring released functionality is too minor to require a PEP, so long as ndiff "still works" in the end -- all that changes is (I hope) that difflib grews a new capability. Just don't forget the docstrings . ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2001-07-04 20:49 Message: Logged In: YES user_id=7733 Tim: Your doctest example is spot-on. That's exactly what I'm using ndiff for, within unit tests. I will work on a clean class to add to difflib.py, implementing the ndiff functionality. PEP required? (No, I'm not going for a record.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-04 19:27 Message: Logged In: YES user_id=31435 Fred, I think I understand what David's after. ndiff has a great deal of logic for comparing "files" as sequences of lines which are in turn sequences of characters, on top of what difflib.py provides (in fact, only the easiest part was factored out). Whether that should go into the std library is a legit question, though. I'll ask Guido about it; if he's at all inclined to say "yes", I bet it would only be because he trusts me to maintain it for the rest of my life <0.7 wink>. I've wanted this at times too; e.g., doctest would love to do a clearer job of showing "expected" vs "but got" outcomes than just listing both in full without any correlation. David, if you want to do this you should supply a proper "file-like object" comparison class instead. You appear to be aiming more at minimal changes here than at clean library design. I'd rather see a clean new class added to difflib.py, the use of which could reduce ndiff.py to a one-pager (or so). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 21:26 Message: Logged In: YES user_id=3066 Is this still relevant in light of ndiff being factored into the ndiff.py script and the difflib library module? difflib is already documented. Assigning to Tim since this is his baby. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=438331&group_id=5470 From noreply@sourceforge.net Sat Jul 28 07:31:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Jul 2001 23:31:07 -0700 Subject: [Patches] [ python-Patches-445433 ] a getPart method for mimetools.Message Message-ID: Patches item #445433, was opened at 2001-07-27 23:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445433&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: a getPart method for mimetools.Message Initial Comment: This is a getPart method for the mimetools.Message class. The code comes from the roundup project (roundup.sf.net) ... it seems odd that mimetools.Message doesn't provide this out-of-the-box. Anyway, it's simple enough. There is a unit test for this code in the roundup test directory. class Message(mimetools.Message): def getPart(self) boundary = self.getparam('boundary') mid, end = '--'+boundary, '--'+boundary+'--' s = cStringIO.StringIO() while 1: line = self.fp.readline() if not line: break if line.strip() in (mid, end): break s.write(line) if not s.getvalue().strip(): return None s.seek(0) return Message(s) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445433&group_id=5470 From noreply@sourceforge.net Sat Jul 28 10:10:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 28 Jul 2001 02:10:25 -0700 Subject: [Patches] [ python-Patches-444750 ] os.statvfs support for BSD Message-ID: Patches item #444750, was opened at 2001-07-26 04:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=444750&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: os.statvfs support for BSD Initial Comment: BSD systems have the statfs(2) call; we use that one to fake statvfs(). See the code for more comments. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-28 02:10 Message: Logged In: YES user_id=21627 I think fstatfs cannot be used to emulate statvfs, since it expects a file descriptor, not a path. It would be very confusing if the function is there on some system but does not expect a path. In general, I feel that this emulation is not appropriate. posix exposes system calls as-is, so it should add statfs and fstatfs calls, instead of trying to emulate statvfs. It might then be useful to put a function into os to portably access pieces of information, e.g. free disk space. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-26 04:26 Message: Logged In: NO Oops, in case there are questions left, here's my email address: tg@FreeBSD.org. tg ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=444750&group_id=5470 From noreply@sourceforge.net Sat Jul 28 12:38:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 28 Jul 2001 04:38:21 -0700 Subject: [Patches] [ python-Patches-416079 ] Improvements in 'telnetlib' Message-ID: Patches item #416079, was opened at 2001-04-14 00:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416079&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lionel Ulmer (bbrox) Assigned to: Nobody/Anonymous (nobody) Summary: Improvements in 'telnetlib' Initial Comment: This patch does the following : - fix the debug string output when receiving telnet commands (the 'c' was reprinted whereas it's 'opt' that we want to see on the screen) - added all the telnet options known to arpa/telnet.h - added the possibility for the user to have it's own option negotiation callback, thus overriding Python's default WILL/WONT => DONT, DO/DONT => WONT behaviour Now, on a design perspective, I did not know what was best : do as I did or add a __default_callback function in the telnetlib file that would do the default behavious and thus preventing the 'if callback:' tests. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-28 04:38 Message: Logged In: YES user_id=21627 The patch looks good, but I'd like you to improve standards conformance of the telnet options. I.e. you should document which version of arpa/telnet.h you've used as a basis. In addition, you should consider adding telnet options not listed in this file. In the past, they were all collected in an RFC; the last one who did this was RFC 2400. Now, IANA has a separate table, http://www.iana.org/assignments/telnet-options. I recommend that you add all those constants in addition to their telnet.h names, e.g. TOPT_XDL, TOPT_3270, TOPT_X_3. As for the callback design: Another option would be to allow subclassing the telnet class, e.g. a self.do_option method. I'm not sure what it best here, your current approach seems fine. Please also try to draft a patch for Doc/lib/libtelnetlib.tex. At a minimum, this should document the callback and the existence of the constants; if possible, it should give an example of option negotiation. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416079&group_id=5470 From noreply@sourceforge.net Sat Jul 28 15:46:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 28 Jul 2001 07:46:05 -0700 Subject: [Patches] [ python-Patches-416224 ] add readline completion to cmd.Cmd Message-ID: Patches item #416224, was opened at 2001-04-14 20:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416224&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: add readline completion to cmd.Cmd Initial Comment: Adds command completion to Cmd class. Can be disabled by calling __init__ with completekey=None or can use a different key, it defaults to 'tab'. Not sure if this is really the best way to enable/disable it, but it works. (oh, prolly requires doc updates too) Would also be nifty to provide command-specific completion with something like complete_(...) funcs, but this is not possible with python's current readline interface. (doh) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-28 07:46 Message: Logged In: YES user_id=21627 Thanks for your patch, this was committed as cmd.py 1.25. I also fixed the pstats base class __init__ call, and added text to Misc/NEWS and libcmd.tex. ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2001-04-14 23:08 Message: Logged In: YES user_id=65253 Oh, also note that if you try to test it with pstats you have to at the very least make its __init__ call Cmd.__init__, since it doesn't do that currently.. ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2001-04-14 23:06 Message: Logged In: YES user_id=65253 Ok, heres a new patch that implements command specific completion as well. It is diffed against a clean cmd.py, not the previous patch. I also have a patch against pstats.py to make its interactive mode take advantage of this, should I submit it in a seperate report? ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2001-04-14 21:27 Message: Logged In: YES user_id=65253 Hm, actually I just looked into the readline module a bit deeper and it looks like it is possible after, all I was going only on what was passed to the complete func but with the get_line_buffer and friends it should be possible.. so, I'll see if I can work up a patch that includes command specific completion. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416224&group_id=5470 From noreply@sourceforge.net Sat Jul 28 18:45:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 28 Jul 2001 10:45:43 -0700 Subject: [Patches] [ python-Patches-419145 ] SocketServer test (UDP/TCP Thread/Fork) Message-ID: Patches item #419145, was opened at 2001-04-26 07:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419145&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Luke Kenneth Casson Leighton (lkcl) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer test (UDP/TCP Thread/Fork) Initial Comment: this is a _completely_ inappropriate location to put in a patch: stupid-netscape word-wraps it. well, too bad :) --- src/Python-2.1/Lib/SocketServer.py Wed Apr 11 05:02:05 2001 +++ SocketServer2.py Thu Apr 26 16:23:32 2001 @@ -110,15 +110,22 @@ BaseServer: - split generic "request" functionality out into BaseServer class. - Copyright (C) 2000 Luke Kenneth Casson Leighton example: read entries from a SQL database (requires overriding get_request() to return a table entry from the database). entry is processed by a RequestHandlerClass. +Test Method: +simple echo server, ForkingTCPServer and ThreadingTCPServer. +send data on port 10000, it will be received back, verbatim. +run test with --client to create 20 such test connections, +which will send 20 tests each and expect them to be received. + +TODO: write a UDPServer test, too. + """ -# Author of the BaseServer patch: Luke Kenneth Casson Leighton +# Author of the BaseServer and test() patch: Luke Kenneth Casson Leighton __version__ = "0.3" @@ -555,3 +562,171 @@ def finish(self): self.socket.sendto(self.wfile.getvalue(), self.client_address) + + +class EchoHandler: + """ an example handler that reads data from a socket + and sends it back. + """ + + def handle(self): + """ simple read line, write it. + we don't even do a select on the socket, just read + it. + """ + eof = None + data = None + + print 'received connection request' + data = self.rfile.readline() + print 'received data:', repr(data) + self.wfile.write(data) + self.wfile.flush() + +class EchoUDPHandler(EchoHandler,DatagramRequestHandler): pass +class EchoTCPHandler(EchoHandler,StreamRequestHandler): pass + + +class TestConnection: + """ simple test connector, has send and recv methods. + code is ripped / stripped from HTTPConnection :) + """ + + def __init__(self, host, port=None, socket_type=socket.SOCK_STREAM): + self.sock = None + self.host = host + self.port = port + self.socket_type = socket_type + + def connect(self): + """Connect to the host and port specified in __init__.""" + self.sock = socket.socket(socket.AF_INET, self.socket_type) + self.sock.connect((self.host, self.port)) + + # hmm, don't know enough about UDP / python to know if + # this works as expected! + self.fp = self.sock.makefile('wrb', 0) + + def close(self): + """Close the connection to the server.""" + if self.sock: + self.sock.close() # close it manually... there may be other refs + self.sock = None + + def send(self, str): + """Send `str' to the server.""" + if self.sock is None: + self.connect() + + try: + self.fp.write(str) + except socket.error, v: + if v[0] == 32: # Broken pipe + self.close() + raise + + def read(self, len=0): + """read from socket + """ + return self.fp.read(len) + + +def test(): + """ test method for SocketServer.py + """ + + def test_client_fn(server_addr='127.0.0.1', server_port=10000, + sock_type=socket.SOCK_STREAM): + + clients = [] + for n in range(20): + clients.append(TestConnection(server_addr, server_port, sock_type)) + + for i in range(len(clients)): + c = clients[i] + c.send("echo test %d\n" % i) + + for i in range(len(clients)): + c = clients[i] + expected_data = "echo test %d\n" % i + data = c.read(len(expected_data)) + if data != expected_data: + print "client %d failed test" + + + def test_server_fn(ServerClass, server_addr, HandlerClass): + + srv = ServerClass(('', 10000), HandlerClass) + srv.max_children = 50 + srv.serve_forever() + + def usage(): + print "usage: --client, -c a test client" + print " --thread-server, -t to run a threading server" + print " --fork-server, -f to run a forking server" + print " --udp, to run a UDP server" + print " --tcp to run a TCP server" + sys.exit(0) + + from getopt import getopt + + if len(sys.argv) == 1: + usage() + + opts, args = getopt(sys.argv[1:], 'hftc', + ['help', 'fork-server', 'thread-server', + 'udp', 'tcp', + 'client']) + + threading = None + forking = None + tcp = None + udp = None + testclass = None + testhandlerclass = None + sock_type = None + testclient = None + + for (opt, value) in opts: + + if opt == '--help' or opt == '-h': + usage() + + if opt == '--tcp': + tcp = 1 + sock_type = socket.SOCK_STREAM + + if opt == '--udp': + udp = 1 + sock_type = socket.SOCK_DGRAM + + if opt == '--fork-server' or opt == '-f': + forking = 1 + + if opt == '--thread-server' or opt == '-t': + threading = 1 + + if opt == '--client' or opt == '-c': + testclient = 1 + + if tcp and forking: + testclass = ForkingTCPServer + testhandlerclass = EchoTCPHandler + if tcp and threading: + testclass = ThreadingTCPServer + testhandlerclass = EchoTCPHandler + if udp and forking: + testclass = ForkingUDPServer + testhandlerclass = EchoUDPHandler + if udp and threading: + testclass = ThreadingUDPServer + testhandlerclass = EchoUDPHandler + + if testclass: + test_server_fn(testclass, 10000, testhandlerclass) + + if testclient: + test_client_fn('127.0.0.1', 10000, sock_type) + +if __name__ == '__main__': + test() ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-28 10:45 Message: Logged In: YES user_id=21627 I've attached the patch as a proper diff file. Is it still needed even though we have test_socketserver.py? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419145&group_id=5470 From noreply@sourceforge.net Sat Jul 28 21:30:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 28 Jul 2001 13:30:16 -0700 Subject: [Patches] [ python-Patches-445538 ] add completion for pstats.py sort cmd Message-ID: Patches item #445538, was opened at 2001-07-28 13:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445538&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: add completion for pstats.py sort cmd Initial Comment: Small patch to make use of the cmd.py completion support to enable completion of sort args in pstats interactive mode. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445538&group_id=5470 From noreply@sourceforge.net Sat Jul 28 21:34:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 28 Jul 2001 13:34:27 -0700 Subject: [Patches] [ python-Patches-443337 ] incompatibilities in imputil's behavior Message-ID: Patches item #443337, was opened at 2001-07-21 07:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443337&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gordon B. McMillan (gmcm) Assigned to: Nobody/Anonymous (nobody) Summary: incompatibilities in imputil's behavior Initial Comment: 1) xml/__init__.py may swap itself for _xmlplus/__init__.py. Under regular mechanism, imports below xml will come from _xmlplus but have xml names in sys.modules and internally. In current imputil, they have _xmlplus names. 2) current imputil does not allow "import os.path". While it's bad practice, the normal import does allow this. "From" file in attached diff is current CVS imputil (1.19). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-28 13:34 Message: Logged In: YES user_id=21627 Thanks for the patch, I've committed it as imputil.py 1.21. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443337&group_id=5470 From noreply@sourceforge.net Sat Jul 28 21:34:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 28 Jul 2001 13:34:44 -0700 Subject: [Patches] [ python-Patches-443337 ] incompatibilities in imputil's behavior Message-ID: Patches item #443337, was opened at 2001-07-21 07:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443337&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gordon B. McMillan (gmcm) Assigned to: Nobody/Anonymous (nobody) Summary: incompatibilities in imputil's behavior Initial Comment: 1) xml/__init__.py may swap itself for _xmlplus/__init__.py. Under regular mechanism, imports below xml will come from _xmlplus but have xml names in sys.modules and internally. In current imputil, they have _xmlplus names. 2) current imputil does not allow "import os.path". While it's bad practice, the normal import does allow this. "From" file in attached diff is current CVS imputil (1.19). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-28 13:34 Message: Logged In: YES user_id=21627 Thanks for the patch, I've committed it as imputil.py 1.21. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443337&group_id=5470 From noreply@sourceforge.net Sat Jul 28 21:36:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 28 Jul 2001 13:36:42 -0700 Subject: [Patches] [ python-Patches-416224 ] add readline completion to cmd.Cmd Message-ID: Patches item #416224, was opened at 2001-04-14 20:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416224&group_id=5470 Category: library Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: add readline completion to cmd.Cmd Initial Comment: Adds command completion to Cmd class. Can be disabled by calling __init__ with completekey=None or can use a different key, it defaults to 'tab'. Not sure if this is really the best way to enable/disable it, but it works. (oh, prolly requires doc updates too) Would also be nifty to provide command-specific completion with something like complete_(...) funcs, but this is not possible with python's current readline interface. (doh) ---------------------------------------------------------------------- >Comment By: Matthew Mueller (donut) Date: 2001-07-28 13:36 Message: Logged In: YES user_id=65253 You're welcome. I've also just posted the pstats patch (for the sort command) as #445538. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-28 07:46 Message: Logged In: YES user_id=21627 Thanks for your patch, this was committed as cmd.py 1.25. I also fixed the pstats base class __init__ call, and added text to Misc/NEWS and libcmd.tex. ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2001-04-14 23:08 Message: Logged In: YES user_id=65253 Oh, also note that if you try to test it with pstats you have to at the very least make its __init__ call Cmd.__init__, since it doesn't do that currently.. ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2001-04-14 23:06 Message: Logged In: YES user_id=65253 Ok, heres a new patch that implements command specific completion as well. It is diffed against a clean cmd.py, not the previous patch. I also have a patch against pstats.py to make its interactive mode take advantage of this, should I submit it in a seperate report? ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2001-04-14 21:27 Message: Logged In: YES user_id=65253 Hm, actually I just looked into the readline module a bit deeper and it looks like it is possible after, all I was going only on what was passed to the complete func but with the get_line_buffer and friends it should be possible.. so, I'll see if I can work up a patch that includes command specific completion. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416224&group_id=5470 From noreply@sourceforge.net Sat Jul 28 22:38:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 28 Jul 2001 14:38:36 -0700 Subject: [Patches] [ python-Patches-419145 ] SocketServer test (UDP/TCP Thread/Fork) Message-ID: Patches item #419145, was opened at 2001-04-26 07:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419145&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Luke Kenneth Casson Leighton (lkcl) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer test (UDP/TCP Thread/Fork) Initial Comment: this is a _completely_ inappropriate location to put in a patch: stupid-netscape word-wraps it. well, too bad :) --- src/Python-2.1/Lib/SocketServer.py Wed Apr 11 05:02:05 2001 +++ SocketServer2.py Thu Apr 26 16:23:32 2001 @@ -110,15 +110,22 @@ BaseServer: - split generic "request" functionality out into BaseServer class. - Copyright (C) 2000 Luke Kenneth Casson Leighton example: read entries from a SQL database (requires overriding get_request() to return a table entry from the database). entry is processed by a RequestHandlerClass. +Test Method: +simple echo server, ForkingTCPServer and ThreadingTCPServer. +send data on port 10000, it will be received back, verbatim. +run test with --client to create 20 such test connections, +which will send 20 tests each and expect them to be received. + +TODO: write a UDPServer test, too. + """ -# Author of the BaseServer patch: Luke Kenneth Casson Leighton +# Author of the BaseServer and test() patch: Luke Kenneth Casson Leighton __version__ = "0.3" @@ -555,3 +562,171 @@ def finish(self): self.socket.sendto(self.wfile.getvalue(), self.client_address) + + +class EchoHandler: + """ an example handler that reads data from a socket + and sends it back. + """ + + def handle(self): + """ simple read line, write it. + we don't even do a select on the socket, just read + it. + """ + eof = None + data = None + + print 'received connection request' + data = self.rfile.readline() + print 'received data:', repr(data) + self.wfile.write(data) + self.wfile.flush() + +class EchoUDPHandler(EchoHandler,DatagramRequestHandler): pass +class EchoTCPHandler(EchoHandler,StreamRequestHandler): pass + + +class TestConnection: + """ simple test connector, has send and recv methods. + code is ripped / stripped from HTTPConnection :) + """ + + def __init__(self, host, port=None, socket_type=socket.SOCK_STREAM): + self.sock = None + self.host = host + self.port = port + self.socket_type = socket_type + + def connect(self): + """Connect to the host and port specified in __init__.""" + self.sock = socket.socket(socket.AF_INET, self.socket_type) + self.sock.connect((self.host, self.port)) + + # hmm, don't know enough about UDP / python to know if + # this works as expected! + self.fp = self.sock.makefile('wrb', 0) + + def close(self): + """Close the connection to the server.""" + if self.sock: + self.sock.close() # close it manually... there may be other refs + self.sock = None + + def send(self, str): + """Send `str' to the server.""" + if self.sock is None: + self.connect() + + try: + self.fp.write(str) + except socket.error, v: + if v[0] == 32: # Broken pipe + self.close() + raise + + def read(self, len=0): + """read from socket + """ + return self.fp.read(len) + + +def test(): + """ test method for SocketServer.py + """ + + def test_client_fn(server_addr='127.0.0.1', server_port=10000, + sock_type=socket.SOCK_STREAM): + + clients = [] + for n in range(20): + clients.append(TestConnection(server_addr, server_port, sock_type)) + + for i in range(len(clients)): + c = clients[i] + c.send("echo test %d\n" % i) + + for i in range(len(clients)): + c = clients[i] + expected_data = "echo test %d\n" % i + data = c.read(len(expected_data)) + if data != expected_data: + print "client %d failed test" + + + def test_server_fn(ServerClass, server_addr, HandlerClass): + + srv = ServerClass(('', 10000), HandlerClass) + srv.max_children = 50 + srv.serve_forever() + + def usage(): + print "usage: --client, -c a test client" + print " --thread-server, -t to run a threading server" + print " --fork-server, -f to run a forking server" + print " --udp, to run a UDP server" + print " --tcp to run a TCP server" + sys.exit(0) + + from getopt import getopt + + if len(sys.argv) == 1: + usage() + + opts, args = getopt(sys.argv[1:], 'hftc', + ['help', 'fork-server', 'thread-server', + 'udp', 'tcp', + 'client']) + + threading = None + forking = None + tcp = None + udp = None + testclass = None + testhandlerclass = None + sock_type = None + testclient = None + + for (opt, value) in opts: + + if opt == '--help' or opt == '-h': + usage() + + if opt == '--tcp': + tcp = 1 + sock_type = socket.SOCK_STREAM + + if opt == '--udp': + udp = 1 + sock_type = socket.SOCK_DGRAM + + if opt == '--fork-server' or opt == '-f': + forking = 1 + + if opt == '--thread-server' or opt == '-t': + threading = 1 + + if opt == '--client' or opt == '-c': + testclient = 1 + + if tcp and forking: + testclass = ForkingTCPServer + testhandlerclass = EchoTCPHandler + if tcp and threading: + testclass = ThreadingTCPServer + testhandlerclass = EchoTCPHandler + if udp and forking: + testclass = ForkingUDPServer + testhandlerclass = EchoUDPHandler + if udp and threading: + testclass = ThreadingUDPServer + testhandlerclass = EchoUDPHandler + + if testclass: + test_server_fn(testclass, 10000, testhandlerclass) + + if testclient: + test_client_fn('127.0.0.1', 10000, sock_type) + +if __name__ == '__main__': + test() ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-28 14:38 Message: Logged In: YES user_id=6380 Thanks, Martin. I don't like having this much test code in the module, and the important part of the test is done by test_socketmodule.py, but I think there's one aspect that this test code does better: it starts 20 test clients in parallel. Maybe that idea could be merged into test_socketmodule.py. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-28 10:45 Message: Logged In: YES user_id=21627 I've attached the patch as a proper diff file. Is it still needed even though we have test_socketserver.py? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419145&group_id=5470 From noreply@sourceforge.net Sun Jul 29 18:15:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 29 Jul 2001 10:15:37 -0700 Subject: [Patches] [ python-Patches-445717 ] Detect UCS2/4 incompatibilities Message-ID: Patches item #445717, was opened at 2001-07-29 10:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445717&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Detect UCS2/4 incompatibilities Initial Comment: This patch introduces the LSB of PYTHON_API_VERSION to indicate whether we have a wide or a narrow build. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445717&group_id=5470 From noreply@sourceforge.net Sun Jul 29 20:33:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 29 Jul 2001 12:33:20 -0700 Subject: [Patches] [ python-Patches-445744 ] PEP 250 Implementation Message-ID: Patches item #445744, was opened at 2001-07-29 12:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445744&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 250 Implementation Initial Comment: Distutils patch required for the implementation of PEP 250. This should go into Python 2.2. There is an associated patch to the wininst Windows installer, which Thomas Heller has created. Thomas' patch should be applied along with this one. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445744&group_id=5470 From noreply@sourceforge.net Sun Jul 29 22:13:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 29 Jul 2001 14:13:37 -0700 Subject: [Patches] [ python-Patches-445762 ] Support --disable-unicode Message-ID: Patches item #445762, was opened at 2001-07-29 14:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445762&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Support --disable-unicode Initial Comment: This patch implements the option --disable-unicode. In particular, it: - does not compile unicodeobject, unicodectype, _codecsmodule, and unicodedata if Unicode is disabled - checks for Py_Unicode in all places that use Unicode functions - disables unicode literals, the builtin functions, and the string encode and decode methods, - avoids Unicode literals in a few places in the libraries - adds the types.StringTypes list Most of the test suite passes with these changes. A number of tests fail, mostly because they use Unicode literals. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445762&group_id=5470 From noreply@sourceforge.net Sun Jul 29 23:06:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 29 Jul 2001 15:06:57 -0700 Subject: [Patches] [ python-Patches-445770 ] Make calendar.py work forever. Message-ID: Patches item #445770, was opened at 2001-07-29 15:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445770&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joseph A Knapka (jknapka) Assigned to: Nobody/Anonymous (nobody) Summary: Make calendar.py work forever. Initial Comment: Changes to calendar.py (using a lot of code stolen from Pmw) to make it work for essentially any date, and handle Julian vs. Gregorian dating properly. julian=[-1|0|1] and papal=[0|1] arguments added to many functions, with appropriate defaults. If julian==1, Julian dating is used; if julian==0 Gregorian dating is used; if julian==-1 the code decides based on the date which dating system to use. If papal==1 the Gregorian reformation is applied in October 1582, the year of the edict; if papal==0 the reformation is applied in September 1752, the year in which Britain applied the change. julian defaults to -1 and papal to 0, so normally no one will need to care about them. Dependencies on the "time" module have been removed. Added functions: ymdtojdn(y,m,d) - convert year,month,day to Julian day number jdntoymd(jdn) - convert jdn to (year,month,day) tuple. jdntodow(jdn) - compute the day-of-week (0-6) of a Julian day number. Modified all existing code to use the new date and day-of-week code. So "prcal()" for example does the right thing. Testing: it gets the same answers as the "cal" program for a selection of months between 01/01 and 9999/12, including Oct 1582 and Sept 1752, when papal=0. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445770&group_id=5470 From noreply@sourceforge.net Sun Jul 29 23:29:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 29 Jul 2001 15:29:32 -0700 Subject: [Patches] [ python-Patches-445770 ] Make calendar.py work forever. Message-ID: Patches item #445770, was opened at 2001-07-29 15:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445770&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joseph A Knapka (jknapka) Assigned to: Nobody/Anonymous (nobody) Summary: Make calendar.py work forever. Initial Comment: Changes to calendar.py (using a lot of code stolen from Pmw) to make it work for essentially any date, and handle Julian vs. Gregorian dating properly. julian=[-1|0|1] and papal=[0|1] arguments added to many functions, with appropriate defaults. If julian==1, Julian dating is used; if julian==0 Gregorian dating is used; if julian==-1 the code decides based on the date which dating system to use. If papal==1 the Gregorian reformation is applied in October 1582, the year of the edict; if papal==0 the reformation is applied in September 1752, the year in which Britain applied the change. julian defaults to -1 and papal to 0, so normally no one will need to care about them. Dependencies on the "time" module have been removed. Added functions: ymdtojdn(y,m,d) - convert year,month,day to Julian day number jdntoymd(jdn) - convert jdn to (year,month,day) tuple. jdntodow(jdn) - compute the day-of-week (0-6) of a Julian day number. Modified all existing code to use the new date and day-of-week code. So "prcal()" for example does the right thing. Testing: it gets the same answers as the "cal" program for a selection of months between 01/01 and 9999/12, including Oct 1582 and Sept 1752, when papal=0. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-29 15:29 Message: Logged In: YES user_id=6380 Apart from the novelty value, what's the point of supporting calendars hundreds of years back? Why does this belong in the standard library? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445770&group_id=5470 From noreply@sourceforge.net Mon Jul 30 11:21:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Jul 2001 03:21:43 -0700 Subject: [Patches] [ python-Patches-445538 ] add completion for pstats.py sort cmd Message-ID: Patches item #445538, was opened at 2001-07-28 13:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445538&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: add completion for pstats.py sort cmd Initial Comment: Small patch to make use of the cmd.py completion support to enable completion of sort args in pstats interactive mode. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-30 03:21 Message: Logged In: YES user_id=21627 Thanks, committed as pstats.py 1.20. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445538&group_id=5470 From noreply@sourceforge.net Mon Jul 30 13:31:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Jul 2001 05:31:36 -0700 Subject: [Patches] [ python-Patches-442866 ] Tests for codeop.py Message-ID: Patches item #442866, was opened at 2001-07-19 12:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442866&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Tests for codeop.py Initial Comment: Another installment of unit tests. This file contains a set of new test cases for the codeop module, which previously had none. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-30 05:31 Message: Logged In: YES user_id=21627 Accepted with modifications: - TESTFN does not appear to be used - the test fails on 2.1 since your version made use of nested scopes. Changed to explicitly pass "eval" for the eval tests. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-07-19 17:35 Message: Logged In: YES user_id=499 Based on comments for dircache, change test_codeop to _not_ alias compile_command as 'cc'. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442866&group_id=5470 From noreply@sourceforge.net Mon Jul 30 13:55:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Jul 2001 05:55:19 -0700 Subject: [Patches] [ python-Patches-445717 ] Detect UCS2/4 incompatibilities Message-ID: Patches item #445717, was opened at 2001-07-29 10:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445717&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Detect UCS2/4 incompatibilities Initial Comment: This patch introduces the LSB of PYTHON_API_VERSION to indicate whether we have a wide or a narrow build. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-30 05:55 Message: Logged In: YES user_id=38388 Thanks for the patch. I would like to discuss this on python-dev first though... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445717&group_id=5470 From noreply@sourceforge.net Mon Jul 30 14:06:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Jul 2001 06:06:48 -0700 Subject: [Patches] [ python-Patches-445762 ] Support --disable-unicode Message-ID: Patches item #445762, was opened at 2001-07-29 14:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445762&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Support --disable-unicode Initial Comment: This patch implements the option --disable-unicode. In particular, it: - does not compile unicodeobject, unicodectype, _codecsmodule, and unicodedata if Unicode is disabled - checks for Py_Unicode in all places that use Unicode functions - disables unicode literals, the builtin functions, and the string encode and decode methods, - avoids Unicode literals in a few places in the libraries - adds the types.StringTypes list Most of the test suite passes with these changes. A number of tests fail, mostly because they use Unicode literals. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-30 06:06 Message: Logged In: YES user_id=38388 Nice work, Martin ! Some comments: - I think that we could save some of the #ifdefs by simply assuming that an optimizing will not generate code for "if (0)" == "if (PyUnicode_Check(obj))"; this would make the code more readable - the _codecmodule.c should not be disabled by the configure option... codecs are useful for non-Unicode applications as well - the PyString_Encode/Decode() APIs should not be disabled for the same reason - the tokenizer/compiler should generate errors with an explicit message stating that the Python version was compiled without Unicode support - dito for the Unicode parser markers (I think that open() on Windows will fail without "es"... ?) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445762&group_id=5470 From noreply@sourceforge.net Mon Jul 30 15:30:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Jul 2001 07:30:52 -0700 Subject: [Patches] [ python-Patches-445762 ] Support --disable-unicode Message-ID: Patches item #445762, was opened at 2001-07-29 14:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445762&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Support --disable-unicode Initial Comment: This patch implements the option --disable-unicode. In particular, it: - does not compile unicodeobject, unicodectype, _codecsmodule, and unicodedata if Unicode is disabled - checks for Py_Unicode in all places that use Unicode functions - disables unicode literals, the builtin functions, and the string encode and decode methods, - avoids Unicode literals in a few places in the libraries - adds the types.StringTypes list Most of the test suite passes with these changes. A number of tests fail, mostly because they use Unicode literals. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-30 07:30 Message: Logged In: YES user_id=21627 This patch already makes use of the assumption that PyUnicode_Check will always return 0. In all the remaining cases, the code will also call some function of the Unicode module, which will result in a compile time error since the functions are not declared anymore. Even if it was declared, it would probably result in a linker error since not all compilers will remove the entire code block. Only in cases where the if-block does not call any Unicode functions directly, that approach can be used. I can try to re-enable the _codecs module, although only register and lookup would remain. I cannot re-enable PyString_Decode/Encode, since they use PyUnicode_GetDefaultEncoding, which is not available since unicodeobject.c is not compiled. I will try to have the tokenizer generate more specific error messages. Support for "es", "et" is still there; they only work for strings, though, and they never call any codecs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-30 06:06 Message: Logged In: YES user_id=38388 Nice work, Martin ! Some comments: - I think that we could save some of the #ifdefs by simply assuming that an optimizing will not generate code for "if (0)" == "if (PyUnicode_Check(obj))"; this would make the code more readable - the _codecmodule.c should not be disabled by the configure option... codecs are useful for non-Unicode applications as well - the PyString_Encode/Decode() APIs should not be disabled for the same reason - the tokenizer/compiler should generate errors with an explicit message stating that the Python version was compiled without Unicode support - dito for the Unicode parser markers (I think that open() on Windows will fail without "es"... ?) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445762&group_id=5470 From noreply@sourceforge.net Mon Jul 30 15:39:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Jul 2001 07:39:32 -0700 Subject: [Patches] [ python-Patches-445762 ] Support --disable-unicode Message-ID: Patches item #445762, was opened at 2001-07-29 14:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445762&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Support --disable-unicode Initial Comment: This patch implements the option --disable-unicode. In particular, it: - does not compile unicodeobject, unicodectype, _codecsmodule, and unicodedata if Unicode is disabled - checks for Py_Unicode in all places that use Unicode functions - disables unicode literals, the builtin functions, and the string encode and decode methods, - avoids Unicode literals in a few places in the libraries - adds the types.StringTypes list Most of the test suite passes with these changes. A number of tests fail, mostly because they use Unicode literals. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-30 07:39 Message: Logged In: YES user_id=38388 Ok, I see your point about the API references. About the PyString_Encode/Decode: on platforms without Unicode, the encoding should not have a default, so passing NULL as encoding should result in an error. I am not even sure, whether it should have a default on Unicode builds... probably not. Trimming down the _codecmodule.c to register and lookup is OK; there are a few codecs in 2.2 which don't use Unicode at all. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-30 07:30 Message: Logged In: YES user_id=21627 This patch already makes use of the assumption that PyUnicode_Check will always return 0. In all the remaining cases, the code will also call some function of the Unicode module, which will result in a compile time error since the functions are not declared anymore. Even if it was declared, it would probably result in a linker error since not all compilers will remove the entire code block. Only in cases where the if-block does not call any Unicode functions directly, that approach can be used. I can try to re-enable the _codecs module, although only register and lookup would remain. I cannot re-enable PyString_Decode/Encode, since they use PyUnicode_GetDefaultEncoding, which is not available since unicodeobject.c is not compiled. I will try to have the tokenizer generate more specific error messages. Support for "es", "et" is still there; they only work for strings, though, and they never call any codecs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-30 06:06 Message: Logged In: YES user_id=38388 Nice work, Martin ! Some comments: - I think that we could save some of the #ifdefs by simply assuming that an optimizing will not generate code for "if (0)" == "if (PyUnicode_Check(obj))"; this would make the code more readable - the _codecmodule.c should not be disabled by the configure option... codecs are useful for non-Unicode applications as well - the PyString_Encode/Decode() APIs should not be disabled for the same reason - the tokenizer/compiler should generate errors with an explicit message stating that the Python version was compiled without Unicode support - dito for the Unicode parser markers (I think that open() on Windows will fail without "es"... ?) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445762&group_id=5470 From noreply@sourceforge.net Tue Jul 31 07:18:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Jul 2001 23:18:35 -0700 Subject: [Patches] [ python-Patches-409097 ] sys.excepthook Message-ID: Patches item #409097, was opened at 2001-03-16 04:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409097&group_id=5470 Category: core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Ka-Ping Yee (ping) Assigned to: Ka-Ping Yee (ping) Summary: sys.excepthook Initial Comment: This patch separates out the traceback-displaying functionality of PyErr_PrintEx into a new routine, PyErr_Display(exc, val, tb). PyErr_PrintEx finds and calls sys.excepthook, and the new function sys.excepthook calls PyErr_Display. This allows user customization of top-level exception handling (in particular, you can write Python routines to install as sys.excepthook that display function arguments or format tracebacks nicely in HTML for CGI scripts). This is a minimal patch just to implement sys.excepthook. A more complete patch, postponed for 2.2, factors out the SystemExit handling in PyErr_PrintEx into a separate routine and replaces all of the C code in PyErr_Display and PyTraceBack_Print with shorter, more maintainable Python code in the traceback module. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-30 23:18 Message: Logged In: YES user_id=6380 This is in 2.2 now. Dunno why the patch wasn't closed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-21 16:07 Message: Logged In: YES user_id=6380 Postponing this until after 2.1 -- there are too many little nagging design decisions about the API. Ping is disappointed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 15:57 Message: Logged In: YES user_id=6380 Ping, I was testing this in a loop looking for leaks (none found BTW) and I noticed that it couldn't be killed by control-C. Can you see a reason why? Also, I was looking at the Python code in traceback.py and it has a limit on how many frames it prints (which defaults to sys.tracebacklimit). Would it make sense to be able to pass that into sys.excepthook() as well? Note; I'm seeing enough little questions that make me think this is best left until after 2.1 is released... Would you be very disappointed? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-03-18 15:33 Message: Logged In: NO PS-- I would suggest to store a copy in sys.__excepthook__, just like sys.__stdout__. Guido (too lazy to log in on SF) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 15:10 Message: Logged In: YES user_id=6380 Very close. Thanks, Ping! Mandatory improvement:most of the times where you use fprintf(stderr, ...) you should be using PySys_WriteStderr(...). The only time when it's OK to use stderr directly is is when sys.stderr is not found. An idea which I'm not sure of: maybe the PyErr_Display() function could take a PyObject * 4th argument being the file object to which the traceback should be written. This makes the logic of its callers a bit more convoluted, unless you let it default to NULL (which might be the best thing anyway). Also... I guess we need a few lines of documentation for sys.excepthook, for PyErr_Display(), and for the changed semantics of PyErr_Print[Ex](). ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2001-03-16 04:50 Message: Logged In: YES user_id=45338 Upload got botched. Trying again. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409097&group_id=5470 From noreply@sourceforge.net Tue Jul 31 08:48:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Jul 2001 00:48:10 -0700 Subject: [Patches] [ python-Patches-445762 ] Support --disable-unicode Message-ID: Patches item #445762, was opened at 2001-07-29 14:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445762&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Support --disable-unicode Initial Comment: This patch implements the option --disable-unicode. In particular, it: - does not compile unicodeobject, unicodectype, _codecsmodule, and unicodedata if Unicode is disabled - checks for Py_Unicode in all places that use Unicode functions - disables unicode literals, the builtin functions, and the string encode and decode methods, - avoids Unicode literals in a few places in the libraries - adds the types.StringTypes list Most of the test suite passes with these changes. A number of tests fail, mostly because they use Unicode literals. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-31 00:48 Message: Logged In: YES user_id=21627 The new version of the patch implements all features that have been discussed. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-30 07:39 Message: Logged In: YES user_id=38388 Ok, I see your point about the API references. About the PyString_Encode/Decode: on platforms without Unicode, the encoding should not have a default, so passing NULL as encoding should result in an error. I am not even sure, whether it should have a default on Unicode builds... probably not. Trimming down the _codecmodule.c to register and lookup is OK; there are a few codecs in 2.2 which don't use Unicode at all. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-30 07:30 Message: Logged In: YES user_id=21627 This patch already makes use of the assumption that PyUnicode_Check will always return 0. In all the remaining cases, the code will also call some function of the Unicode module, which will result in a compile time error since the functions are not declared anymore. Even if it was declared, it would probably result in a linker error since not all compilers will remove the entire code block. Only in cases where the if-block does not call any Unicode functions directly, that approach can be used. I can try to re-enable the _codecs module, although only register and lookup would remain. I cannot re-enable PyString_Decode/Encode, since they use PyUnicode_GetDefaultEncoding, which is not available since unicodeobject.c is not compiled. I will try to have the tokenizer generate more specific error messages. Support for "es", "et" is still there; they only work for strings, though, and they never call any codecs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-30 06:06 Message: Logged In: YES user_id=38388 Nice work, Martin ! Some comments: - I think that we could save some of the #ifdefs by simply assuming that an optimizing will not generate code for "if (0)" == "if (PyUnicode_Check(obj))"; this would make the code more readable - the _codecmodule.c should not be disabled by the configure option... codecs are useful for non-Unicode applications as well - the PyString_Encode/Decode() APIs should not be disabled for the same reason - the tokenizer/compiler should generate errors with an explicit message stating that the Python version was compiled without Unicode support - dito for the Unicode parser markers (I think that open() on Windows will fail without "es"... ?) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445762&group_id=5470 From noreply@sourceforge.net Tue Jul 31 08:54:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Jul 2001 00:54:23 -0700 Subject: [Patches] [ python-Patches-445717 ] Detect UCS2/4 incompatibilities Message-ID: Patches item #445717, was opened at 2001-07-29 10:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445717&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Detect UCS2/4 incompatibilities Initial Comment: This patch introduces the LSB of PYTHON_API_VERSION to indicate whether we have a wide or a narrow build. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-31 00:54 Message: Logged In: YES user_id=21627 This version of the patch implements a function PyUnicode_Wide in unicodemodule, and offers a helper macro PyUnicode_WidthCheck for use in extension modules. It also demonstrates its use in pyexpat. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-30 05:55 Message: Logged In: YES user_id=38388 Thanks for the patch. I would like to discuss this on python-dev first though... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445717&group_id=5470 From noreply@sourceforge.net Tue Jul 31 08:56:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Jul 2001 00:56:03 -0700 Subject: [Patches] [ python-Patches-445762 ] Support --disable-unicode Message-ID: Patches item #445762, was opened at 2001-07-29 14:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445762&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Support --disable-unicode Initial Comment: This patch implements the option --disable-unicode. In particular, it: - does not compile unicodeobject, unicodectype, _codecsmodule, and unicodedata if Unicode is disabled - checks for Py_Unicode in all places that use Unicode functions - disables unicode literals, the builtin functions, and the string encode and decode methods, - avoids Unicode literals in a few places in the libraries - adds the types.StringTypes list Most of the test suite passes with these changes. A number of tests fail, mostly because they use Unicode literals. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-31 00:56 Message: Logged In: YES user_id=21627 Replaced patch, since it contained unrelated fragments. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-31 00:48 Message: Logged In: YES user_id=21627 The new version of the patch implements all features that have been discussed. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-30 07:39 Message: Logged In: YES user_id=38388 Ok, I see your point about the API references. About the PyString_Encode/Decode: on platforms without Unicode, the encoding should not have a default, so passing NULL as encoding should result in an error. I am not even sure, whether it should have a default on Unicode builds... probably not. Trimming down the _codecmodule.c to register and lookup is OK; there are a few codecs in 2.2 which don't use Unicode at all. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-30 07:30 Message: Logged In: YES user_id=21627 This patch already makes use of the assumption that PyUnicode_Check will always return 0. In all the remaining cases, the code will also call some function of the Unicode module, which will result in a compile time error since the functions are not declared anymore. Even if it was declared, it would probably result in a linker error since not all compilers will remove the entire code block. Only in cases where the if-block does not call any Unicode functions directly, that approach can be used. I can try to re-enable the _codecs module, although only register and lookup would remain. I cannot re-enable PyString_Decode/Encode, since they use PyUnicode_GetDefaultEncoding, which is not available since unicodeobject.c is not compiled. I will try to have the tokenizer generate more specific error messages. Support for "es", "et" is still there; they only work for strings, though, and they never call any codecs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-30 06:06 Message: Logged In: YES user_id=38388 Nice work, Martin ! Some comments: - I think that we could save some of the #ifdefs by simply assuming that an optimizing will not generate code for "if (0)" == "if (PyUnicode_Check(obj))"; this would make the code more readable - the _codecmodule.c should not be disabled by the configure option... codecs are useful for non-Unicode applications as well - the PyString_Encode/Decode() APIs should not be disabled for the same reason - the tokenizer/compiler should generate errors with an explicit message stating that the Python version was compiled without Unicode support - dito for the Unicode parser markers (I think that open() on Windows will fail without "es"... ?) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445762&group_id=5470 From noreply@sourceforge.net Tue Jul 31 20:33:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Jul 2001 12:33:29 -0700 Subject: [Patches] [ python-Patches-443474 ] from __future__ import division Message-ID: Patches item #443474, was opened at 2001-07-21 21:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443474&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: from __future__ import division Initial Comment: This patch is a quick hack to implement one way of doing PEP 238 (non-integer division). There are two parts to it. Part 1: the // operator implements integer division. Part 2: when "from __future__ import division" is in effect, the / operator implements float division. The //= and /= operators are also affected. (This is part of why I chose // over the keyword 'div'; also because that would require a new keyword.) The implementation now has three division operations (of each variation: regular and inplace, and corresponding opcodes) where it used to have one: - Division for / without future statement - FloatDivision for / with future statement - IntDivision for // The actual implementations for IntDivision and FloatDivision are a bit lame: - (old) Division is unchanged (using nb_division) - IntDivision just calls Division, so only does the right thing for ints and longs - FloatDivision adds 0.0 to the second operand At some point in the future, to keep NumPy happy, the "as number" struct should grow extra slots for the additional operations, and the above operations should only be used as fallbacks. (Maybe the fallback for IntDivision should use the nb_divmod slot as fallback.) Enjoy! ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-31 12:33 Message: Logged In: YES user_id=6380 Uploading a new version. This includes the patch for graminit.c. This follows the revised PEP: terminology changed to true and floor division, actual slots in type objects used. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-21 21:39 Message: Logged In: YES user_id=6380 Note, the patch doesn't include the changes for graminit.c (because they were big). This may cause problems on Windows, where that file is not automatically recreated when the grammar changes. I'm including the new graminit.c just in case. (graminit.h is unchanged.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443474&group_id=5470