From sullivan@fotoasia.com Sat Sep 1 04:44:12 2001 From: sullivan@fotoasia.com (sullivan@fotoasia.com) Date: Sat, 1 Sep 2001 11:44:12 +0800 Subject: [Patches] Something to brighten your day! Message-ID: <004631244030191SERVER2@server2.magix.com.sg> This is a multi-part message in MIME format. ------=_NextPart_000_0B6D_01C132DB.6B59FA10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit This is a HTML document. If you are unable to view this page, copy this link http://www.fotoasia.com/email/HTML/newsletter/newsletter_200109.html into your web browser to view our complete range of Inspirational Posters. Wow! Great! Good Average Poor It sucks! ------=_NextPart_000_0B6D_01C132DB.6B59FA10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0D=0DFotoAsia Newsletter 2001 = September=0D=0D=0D=0D=0D=0D
=0D =0D This is a HTML = document. If you are unable to view this page, copy this link http://www.fotoasia.com/email/HTML/newsletter/newslette= r_200109.html
=0D into your web browser to view our = complete range of Inspirational Posters.=0D
=0D=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D = =0D
=0D =0D =0D =0D
=0D  =0D =0D
=0D   =0D =0D =0D
=
=0D=0D ------=_NextPart_000_0B6D_01C132DB.6B59FA10-- From noreply@sourceforge.net Sat Sep 1 20:44:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 01 Sep 2001 12:44:57 -0700 Subject: [Patches] [ python-Patches-451305 ] Indeterminate progress bars Message-ID: Patches item #451305, was opened at 2001-08-15 13:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=451305&group_id=5470 Category: Macintosh Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jack Jansen (jackjansen) Summary: Indeterminate progress bars Initial Comment: Support for indeterminate progress bars has been added to EasyDialogs. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-09-01 12:44 Message: Logged In: YES user_id=45365 I got the patch offline and applied it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=451305&group_id=5470 From noreply@sourceforge.net Sun Sep 2 11:20:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Sep 2001 03:20:59 -0700 Subject: [Patches] [ python-Patches-457713 ] Allow "itemconfigure" for Listboxes. Message-ID: Patches item #457713, was opened at 2001-09-02 03:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=457713&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joseph A Knapka (jknapka) Assigned to: Nobody/Anonymous (nobody) Summary: Allow "itemconfigure" for Listboxes. Initial Comment: This patch allows foreground and background colors to be configured for individual items in a Listbox. The "itemconfigure" and "itemcget" code from Canvas is pulled out into a new mixin class which is inherited by Canvas and Listbox. It seems to "just work", unless I am neglecting some subtle aspect of Tkinter code. The patch is against the Python 2.1.1 Tkinter.py file. (Note: this patch addresses #426880, for which someone neglected to provide code. I am not, incidentally, the individual who submitted the earlier patch :-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=457713&group_id=5470 From noreply@sourceforge.net Sun Sep 2 14:48:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Sep 2001 06:48:57 -0700 Subject: [Patches] [ python-Patches-457713 ] Allow "itemconfigure" for Listboxes. Message-ID: Patches item #457713, was opened at 2001-09-02 03:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=457713&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joseph A Knapka (jknapka) Assigned to: Nobody/Anonymous (nobody) >Summary: Allow "itemconfigure" for Listboxes. Initial Comment: This patch allows foreground and background colors to be configured for individual items in a Listbox. The "itemconfigure" and "itemcget" code from Canvas is pulled out into a new mixin class which is inherited by Canvas and Listbox. It seems to "just work", unless I am neglecting some subtle aspect of Tkinter code. The patch is against the Python 2.1.1 Tkinter.py file. (Note: this patch addresses #426880, for which someone neglected to provide code. I am not, incidentally, the individual who submitted the earlier patch :-) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-02 06:48 Message: Logged In: YES user_id=6380 Hm, I just checked in yet another contributed patch that added Listbox.itemconfigure, but without refactoring and without itemcget. Would you mind integrating that into your patch? See bug #457487. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=457713&group_id=5470 From noreply@sourceforge.net Sun Sep 2 17:24:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Sep 2001 09:24:43 -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: library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Finn Bock (bckfnn) 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. ---------------------------------------------------------------------- >Comment By: Finn Bock (bckfnn) Date: 2001-09-02 09:24 Message: Logged In: YES user_id=4201 Commited to revision 1.6 and 1.5.10.1 by bwarsaw. Note: the commit message on the checkin reference the wrong PR. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-21 16:06 Message: Logged In: YES user_id=12800 This one looks fine to me too. Same caveat with passing the standard test suite for CPython applies. Note: do not merge this into the 2.2a2 branch. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-20 21:12 Message: Logged In: YES user_id=12800 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442351&group_id=5470 From noreply@sourceforge.net Sun Sep 2 17:25:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Sep 2001 09:25:02 -0700 Subject: [Patches] [ python-Patches-457713 ] Allow "itemconfigure" for Listboxes. Message-ID: Patches item #457713, was opened at 2001-09-02 03:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=457713&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joseph A Knapka (jknapka) Assigned to: Nobody/Anonymous (nobody) >Summary: Allow "itemconfigure" for Listboxes. Initial Comment: This patch allows foreground and background colors to be configured for individual items in a Listbox. The "itemconfigure" and "itemcget" code from Canvas is pulled out into a new mixin class which is inherited by Canvas and Listbox. It seems to "just work", unless I am neglecting some subtle aspect of Tkinter code. The patch is against the Python 2.1.1 Tkinter.py file. (Note: this patch addresses #426880, for which someone neglected to provide code. I am not, incidentally, the individual who submitted the earlier patch :-) ---------------------------------------------------------------------- >Comment By: Joseph A Knapka (jknapka) Date: 2001-09-02 09:25 Message: Logged In: YES user_id=118570 Err... are you saying you'd prefer to have the item configuration code duplicated in Canvas and Listbox? The only difference between this patch and the bug 457487 one is that that one uses cut+paste, and this one uses inheritance. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-02 06:48 Message: Logged In: YES user_id=6380 Hm, I just checked in yet another contributed patch that added Listbox.itemconfigure, but without refactoring and without itemcget. Would you mind integrating that into your patch? See bug #457487. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=457713&group_id=5470 From noreply@sourceforge.net Sun Sep 2 22:24:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Sep 2001 14:24:26 -0700 Subject: [Patches] [ python-Patches-457713 ] Allow "itemconfigure" for Listboxes. Message-ID: Patches item #457713, was opened at 2001-09-02 03:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=457713&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joseph A Knapka (jknapka) >Assigned to: Guido van Rossum (gvanrossum) >Summary: Allow "itemconfigure" for Listboxes. Initial Comment: This patch allows foreground and background colors to be configured for individual items in a Listbox. The "itemconfigure" and "itemcget" code from Canvas is pulled out into a new mixin class which is inherited by Canvas and Listbox. It seems to "just work", unless I am neglecting some subtle aspect of Tkinter code. The patch is against the Python 2.1.1 Tkinter.py file. (Note: this patch addresses #426880, for which someone neglected to provide code. I am not, incidentally, the individual who submitted the earlier patch :-) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-02 14:24 Message: Logged In: YES user_id=6380 No, I just meant that I hate doing double work myself, and unless your patch provides something extra, I'm reluctant to put more effort in. Given the sheer size of Tkinter.py, one little bit of code sharing doesn't make much of a difference. ---------------------------------------------------------------------- Comment By: Joseph A Knapka (jknapka) Date: 2001-09-02 09:25 Message: Logged In: YES user_id=118570 Err... are you saying you'd prefer to have the item configuration code duplicated in Canvas and Listbox? The only difference between this patch and the bug 457487 one is that that one uses cut+paste, and this one uses inheritance. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-02 06:48 Message: Logged In: YES user_id=6380 Hm, I just checked in yet another contributed patch that added Listbox.itemconfigure, but without refactoring and without itemcget. Would you mind integrating that into your patch? See bug #457487. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=457713&group_id=5470 From noreply@sourceforge.net Sun Sep 2 23:15:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Sep 2001 15:15:47 -0700 Subject: [Patches] [ python-Patches-457713 ] Allow "itemconfigure" for Listboxes. Message-ID: Patches item #457713, was opened at 2001-09-02 03:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=457713&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joseph A Knapka (jknapka) Assigned to: Guido van Rossum (gvanrossum) >Summary: Allow "itemconfigure" for Listboxes. Initial Comment: This patch allows foreground and background colors to be configured for individual items in a Listbox. The "itemconfigure" and "itemcget" code from Canvas is pulled out into a new mixin class which is inherited by Canvas and Listbox. It seems to "just work", unless I am neglecting some subtle aspect of Tkinter code. The patch is against the Python 2.1.1 Tkinter.py file. (Note: this patch addresses #426880, for which someone neglected to provide code. I am not, incidentally, the individual who submitted the earlier patch :-) ---------------------------------------------------------------------- >Comment By: Joseph A Knapka (jknapka) Date: 2001-09-02 15:15 Message: Logged In: YES user_id=118570 Well, in that case the easy thing would be to just copy the definition of the "itemcget" method out of Canvas and paste it into Listbox. Hardly worth producing a patch file for that. I think it is desirable to have both itemconfig and itemcget, because not doing so violates the expectations of those familiar with Tk. It's a small detail, but attention to detail is what makes Python great, right? (OK, among other things :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-02 14:24 Message: Logged In: YES user_id=6380 No, I just meant that I hate doing double work myself, and unless your patch provides something extra, I'm reluctant to put more effort in. Given the sheer size of Tkinter.py, one little bit of code sharing doesn't make much of a difference. ---------------------------------------------------------------------- Comment By: Joseph A Knapka (jknapka) Date: 2001-09-02 09:25 Message: Logged In: YES user_id=118570 Err... are you saying you'd prefer to have the item configuration code duplicated in Canvas and Listbox? The only difference between this patch and the bug 457487 one is that that one uses cut+paste, and this one uses inheritance. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-02 06:48 Message: Logged In: YES user_id=6380 Hm, I just checked in yet another contributed patch that added Listbox.itemconfigure, but without refactoring and without itemcget. Would you mind integrating that into your patch? See bug #457487. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=457713&group_id=5470 From noreply@sourceforge.net Sun Sep 2 23:48:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Sep 2001 15:48:31 -0700 Subject: [Patches] [ python-Patches-455176 ] sys module feature patch - modify_argv() Message-ID: Patches item #455176, was opened at 2001-08-24 18:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455176&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: sys module feature patch - modify_argv() Initial Comment: Feature enhancment patch to sys module. (Python/sysmodule.c) modify_argv(string,[start],[amount]) Modify the absolute argv (process listing) elements of the python process. Element values are set to zero, then refilled if a replacement value is present. Note: sys.argv will not be changed. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-02 15:48 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455176&group_id=5470 From noreply@sourceforge.net Mon Sep 3 03:15:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Sep 2001 19:15:50 -0700 Subject: [Patches] [ python-Patches-457892 ] sys module feature patch - modify_argv() Message-ID: Patches item #457892, was opened at 2001-09-02 19:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=457892&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dave Cinege (dcinege) Assigned to: Nobody/Anonymous (nobody) Summary: sys module feature patch - modify_argv() Initial Comment: sys module feature patch - modify_argv() Feature enhancment patch to sys module. (Python/sysmodule.c) modify_argv(string,[start],[amount]) Modify the absolute argv (process listing) elements of the python process. NOTE: You may wish view the thread of the python mailing list below. It's been mentioned a more appropreate place for this might be the posix module. (However I still think sys is the right place) I'm willing to implement this as the core team desires, if it is to be included. Subject: [PATCH] sys.modify_argv() Date: Fri, 24 Aug 2001 22:19:34 -0400 To: Python keywords: modify argv change process listing argv[0] ps output This patch adds a new feature to the sys module, modify_argv(). As you might have guessed this allows one to change to absolute argv values of the python process itself. (It is of great wonder to me why this functionality is not already available...) I have intentionally left the patch with minimal sanity checking. Ignorance of detail could lead to dangerous results. Stronger bountries may be desirable in a final implementation. The patch is against Python 2.1.1. Adding this function to another module or placing it in your own module should be a trvial task. It is self contained using Py_GetArgcArgv() to grab the location of argv, already present in the python core. This patch has been submitted for inclusion into core python. Documentation on it's use is in the patch itself. I hereby place this code into the public domain. 'Diesel' Dave 'Kill a Cop' Cinege ----------------------------------------------------- Subject: Re: [PATCH] sys.modify_argv() Date: Fri, 24 Aug 2001 23:53:04 -0400 To: Ignacio Vazquez-Abrams CC: Python > Instead of making a whole new function for this, why not add write capability > to sys.argv? Why I didn't do this: 1) From what I've looked at, the current sys code would change dramatically as it's already dealing in copies of argv initialized at python startup, and not by accessing Py_GetArgcArgv() dynamically. What I did is less intrusive and portable outside of sys. 2) Even though one clears the absolute argv, you probably still want it's values available internally. Thus clearing the sys.argv copies adds a layer of complexity that is really unneeded and probably undesirable. 3) It's not yet exactly clear (to me) to what extent you can alter argv and not impeed portability. This is probably reason enough to segregate this functionality. (On linux it stacks argv elements concurrently in memory and it's safe to use that total space anyway you want. Who knows how other OS's deal with it...) 4) sys.argv[0] == argv[1]. How do we get to the real argv[0] in a sane way? sys.argv[-1] Might break old code as the current implementation ignores negatives and uses absolute values. Also making process listing follow sys.agrv assignment might break old code. And then we have to deal with the lengths of the orginial argv elements again... This is the first time I've ever even looked at the python source, and am hardly close to being a python guru myself. There might be a better solution then what I've done, though I've tried to put a bit of thought into it. At least this patch is usable by people now and will hopefully lead to SOME sort of standard argv modification support in the near future. Dave ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=457892&group_id=5470 From noreply@sourceforge.net Mon Sep 3 15:52:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Sep 2001 07:52:56 -0700 Subject: [Patches] [ python-Patches-450702 ] zlibmodule ALLOW_THREADS update Message-ID: Patches item #450702, was opened at 2001-08-13 22:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450702&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Titus Brown (titus) >Assigned to: Martin v. Lцwis (loewis) Summary: zlibmodule ALLOW_THREADS update Initial Comment: When using e.g. the gzip module in a threaded Python embedding (PyWX, pywx.idyll.org) all other Python threads halt, because no thread interleaving is done by the time-intensive commands in zlib.so. This leads to serious lags when compressing 5 MB files... I have wrapped all of the inflate and deflate commands in Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS, which fixes this problem. Note that this fix is backwards compatible to 2.1, at least, as zlibmodule.c has not changed since then. As requested, a _context_ diff from the head of the current CVS tree is attached ;). ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-20 23:55 Message: Logged In: YES user_id=23486 One last patch: Alex Martelli pointed out that C functions do not automatically take on ownership of passed-in strings, and, under circumstances where multiple threads have access to the same namespace, thread A might be involved in a time-consuming command and thread B (now allowed to execute) could then delete the input string out from under it. Attached is the complete patch, this time including the appropriate INCREF and DECREF of the input string. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-17 10:10 Message: Logged In: YES user_id=23486 This new patch makes the zlibmodule reentrant by using a global zlib_lock. Also included is the addition of BEGIN/END_ALLOW_THREADS macros around the actual calls to compress/decompress data, which significantly improves the thread-friendliness of this module. Most of the code changes are simple rearrangements of the same old code to adapt it to the requirements of the ENTER and LEAVE_ZLIB macros, which create new blocks; thus, any code from which a 'return' was done had to be changed to exit only after LEAVE_ZLIB was called. Note that because zlib itself is re-entrant, we really only had to worry about making methods on de/compress objects reentrant. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-14 12:13 Message: Logged In: YES user_id=23486 N.B. I've found that zlib _is_ threadsafe. I still need to determine if the way in which objects are passed around in the zlibmodule.c can potentially cause problems; it seems like it can. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-14 09:06 Message: Logged In: YES user_id=23486 I think there may be a 2nd problem: I have to look into some of the Python calls used to transfer data around, but it may be possible for threads with access to the compression objects to retrieve data in an indeterminate state, i.e. mid-compression. Luckily a module-wide lock should take care of both this problem AND resolve threadsafety issues with zlib! I'll look into this & fix it. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-14 07:21 Message: Logged In: YES user_id=21627 The patch looks good, however there is a major problem with the approach taken: zlib itself might not be threadsafe. Please try to find out whether zlib indeed is thread-safe; if it isn't, I think you need to add another lock to prevent multiple Python threads from accessing zlib simultaneously. You may want to take a look at _tkinter, which has similar code to prevent multiple Python threads from accessing Tk simultaneously. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450702&group_id=5470 From noreply@sourceforge.net Mon Sep 3 16:26:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Sep 2001 08:26:26 -0700 Subject: [Patches] [ python-Patches-430706 ] Persistent connections in BaseHTTPServer Message-ID: Patches item #430706, was opened at 2001-06-06 08:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=430706&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Lawrence (lordsutch) >Assigned to: Martin v. Lцwis (loewis) Summary: Persistent connections in BaseHTTPServer Initial Comment: This patch provides HTTP/1.1 persistent connection support in BaseHTTPServer.py. It is not enabled by default (for backwards compatibility) because Content-Length headers must be supplied for persistent connections to work correctly. ---------------------------------------------------------------------- Comment By: Chris Lawrence (lordsutch) Date: 2001-08-29 20:21 Message: Logged In: YES user_id=6757 I have updated the patch against current CVS and have added documentation. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-08 13:43 Message: Logged In: YES user_id=21627 I haven't studied the patch in detail, yet, but I have a few comments on the style: - there is no need to quote all authors of the RFC. Also, the reference to long-ago expired HTTP draft should go; just replace it with a single reference to the RFC number (giving an URL for the RFC might be convenient) - Where is the documentation? A patch to Doc/lib/libbasehttp.tex would be appreciated. If you don't speak TeX, don't worry: Just write plain text, we'll do the mark-up. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=430706&group_id=5470 From noreply@sourceforge.net Tue Sep 4 03:55:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Sep 2001 19:55:36 -0700 Subject: [Patches] [ python-Patches-458245 ] Reduce import time for xmlrpclib Message-ID: Patches item #458245, was opened at 2001-09-03 19:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458245&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cesar Eduardo Barros (cesarb) Assigned to: Nobody/Anonymous (nobody) Summary: Reduce import time for xmlrpclib Initial Comment: This patch reduces the load time for xmlrpclib.py (my tests show it's about half the load time with the patch) by not loading xmllib when it's not needed. It also simplifies getparser() (by chosing the parser/unmarshaller statically) and avoids declaring slower parsers/unmarshallers when a faster version is available. The indentation is a bit odd, to avoid touching a large amount of code because of indentation changes (to improve the readability of the patch). If it is to be accepted, it might be a good idea to reindent the affected blocks of code. The only test made was the trivial one in the module (getStateName). The patch is against CVS revision 1.4 of xmlrpclib.py ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458245&group_id=5470 From noreply@sourceforge.net Tue Sep 4 04:03:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Sep 2001 20:03:58 -0700 Subject: [Patches] [ python-Patches-458245 ] Reduce import time for xmlrpclib Message-ID: Patches item #458245, was opened at 2001-09-03 19:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458245&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cesar Eduardo Barros (cesarb) >Assigned to: Fredrik Lundh (effbot) Summary: Reduce import time for xmlrpclib Initial Comment: This patch reduces the load time for xmlrpclib.py (my tests show it's about half the load time with the patch) by not loading xmllib when it's not needed. It also simplifies getparser() (by chosing the parser/unmarshaller statically) and avoids declaring slower parsers/unmarshallers when a faster version is available. The indentation is a bit odd, to avoid touching a large amount of code because of indentation changes (to improve the readability of the patch). If it is to be accepted, it might be a good idea to reindent the affected blocks of code. The only test made was the trivial one in the module (getStateName). The patch is against CVS revision 1.4 of xmlrpclib.py ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458245&group_id=5470 From noreply@sourceforge.net Tue Sep 4 12:40:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Sep 2001 04:40:44 -0700 Subject: [Patches] [ python-Patches-430706 ] Persistent connections in BaseHTTPServer Message-ID: Patches item #430706, was opened at 2001-06-06 08:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=430706&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Lawrence (lordsutch) Assigned to: Martin v. Lцwis (loewis) Summary: Persistent connections in BaseHTTPServer Initial Comment: This patch provides HTTP/1.1 persistent connection support in BaseHTTPServer.py. It is not enabled by default (for backwards compatibility) because Content-Length headers must be supplied for persistent connections to work correctly. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-04 04:40 Message: Logged In: YES user_id=21627 The patch in its current form seems to be broken. To see the problem, please run SimpleHTTPServer on some directory, then access it with a HTTP/1.1 client (e.g. Netscape 4.7). The server will use the protocol version HTTP/1.0, but the client will initially send 1.1, and send a Connection: Keep-alive header. As a result, self.close_connection is set to 0, despite using HTTP/1.0. In turn, the HTTP server won't send a content length, and won't close the connection either. Netscape waits forever from some completion which never occurs, since the server waits for the next request on the same connection. It might be useful to enhance the SimpleHTTPServer test() function to optionally operate in HTTP/1.1 mode (including sending a proper ContentLength). Doing the same for the CGI HTTP server is probably less useful. ---------------------------------------------------------------------- Comment By: Chris Lawrence (lordsutch) Date: 2001-08-29 20:21 Message: Logged In: YES user_id=6757 I have updated the patch against current CVS and have added documentation. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-08 13:43 Message: Logged In: YES user_id=21627 I haven't studied the patch in detail, yet, but I have a few comments on the style: - there is no need to quote all authors of the RFC. Also, the reference to long-ago expired HTTP draft should go; just replace it with a single reference to the RFC number (giving an URL for the RFC might be convenient) - Where is the documentation? A patch to Doc/lib/libbasehttp.tex would be appreciated. If you don't speak TeX, don't worry: Just write plain text, we'll do the mark-up. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=430706&group_id=5470 From noreply@sourceforge.net Tue Sep 4 14:37:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Sep 2001 06:37:16 -0700 Subject: [Patches] [ python-Patches-458383 ] Start of a bgen tutorial Message-ID: Patches item #458383, was opened at 2001-09-04 06:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458383&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Jack Jansen (jackjansen) Summary: Start of a bgen tutorial Initial Comment: Jack, this is (maybe) a start of a bgen tutorial. It explains some of the things I understand now from bgen. It is not finished, also it uses windows specific examples. I'm requesting comments on the general approach. I have also sent it to you via email, but probably you have not seen it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458383&group_id=5470 From noreply@sourceforge.net Tue Sep 4 15:49:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Sep 2001 07:49:31 -0700 Subject: [Patches] [ python-Patches-428326 ] Timer class for threading Message-ID: Patches item #428326, was opened at 2001-05-29 08:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428326&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Itamar Shtull-Trauring (itamar) Assigned to: Nobody/Anonymous (nobody) Summary: Timer class for threading Initial Comment: The Timer class allows you to schedule an action to happen at some time in the future, using a thread. For example: def f(): print "30 seconds have passed" t = Timer(30.0, f) t.start() # after 30 seconds f will be called try: # .... other stuff except SystemExit: t.cancel() # cancel the timer since we are shutting down It allows passing arguments and keyword arguments to the function that is called. It also allows *cancelling* the timer. That is, if the timer is still waiting, we can tell it to stop its operation. Why should this be in the standard library? 1. Timers are a standard, useful programming idiom. 2. It can be used as an example of how to: a. create subclasses of threading.Thread b. make threads that can be "stopped" If this patch is approved I will then write documentation. I'm not sure how to go about writing tests for it. ---------------------------------------------------------------------- >Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-09-04 07:49 Message: Logged In: YES user_id=32065 I've attached a patch to the documentation. I don't know LaTex so there may be some errors (although the HTML output seems OK). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 06:51 Message: Logged In: YES user_id=6380 OK. Let's do a one-short timer only. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-10 01:21 Message: Logged In: YES user_id=21627 A quick poll among colleagues shows that shoot-once timers are far more common than repeated intervall timers. You also can quite easily implement the intervall timer on top of a shoot-once timer, by restarting it in the timeout handler (although care is needed if you need exact intervalls: between last scheduled time-out and the handler invocation, time may pass, so the restart may need to be smaller than the intervall). In short, I think the API as you provide it is excellent; if people find it useful and require more, they will provide patches. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 14:45 Message: Logged In: YES user_id=6380 Good! I don't think there's a standard definition of timers -- I've seen both. A more general timer that can go off N times, defaulting to once, sounds like a nice API. Hm, I can actually only think of two usage scenarios: either you want it to go off once, or you want it to repeat until you cancel it. Think about it. There's also the msg from Aahz in the python-dev list where he claims he doesn't like something about this without saying what. I hope he clarifies that in this SF tracker item. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-08-09 14:23 Message: Logged In: YES user_id=32065 1) license can be python's and copyright PSF's 2) I will write docs and tests 3) not sure when, maybe this weekend One question - timers actually seem to be a task that happens repeatedly every X seconds (e.g. in wxWindows). Should I add that functionality (do a task every X seconds, N times, N is either >= 1 or infinite) or just rename the class? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 13:53 Message: Logged In: YES user_id=6380 I like it too. But I don't want itamar's license anywhere in the distribution -- too wordy. I agree that the PSF should clear up the licensing situation; we're working on that but it's slow going (nobody likes this work :-( ). ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-08 13:32 Message: Logged In: YES user_id=21627 I'm in favour of approving this patch, as an extension to the threading module. Are you willing to draft a patch to the documentation (libthreading.tex) as well? Ideally, there would also be a set of regression tests in a test_threading file; it would be acceptable if this only tests your feature for the moment. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-05-30 09:40 Message: Logged In: YES user_id=32065 There was a licensing discussion on python-dev which no one bothered to CC me on :). Yes, this can be relicensed under the PSF license. I suggest someone write up some sort of guidelines for submitted patches and improvement explain the whole licensing and copyright issues. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-05-30 02:16 Message: Logged In: YES user_id=32065 OK, I'm un-withdrawing this patch. Just had to get things straight with our lawyer. The patch is released under the following license (the X11 license with 4 extra paragraphs of disclaimers :): http://www.zoteca.com/opensource/LICENSE.txt ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-05-29 09:45 Message: Logged In: YES user_id=32065 I'm withdrawing this patch for a short period of time for non-technical reasons, hopefully I can put it back soon. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428326&group_id=5470 From noreply@sourceforge.net Tue Sep 4 16:01:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Sep 2001 08:01:01 -0700 Subject: [Patches] [ python-Patches-450702 ] zlibmodule ALLOW_THREADS update Message-ID: Patches item #450702, was opened at 2001-08-13 22:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450702&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Titus Brown (titus) Assigned to: Martin v. Lцwis (loewis) Summary: zlibmodule ALLOW_THREADS update Initial Comment: When using e.g. the gzip module in a threaded Python embedding (PyWX, pywx.idyll.org) all other Python threads halt, because no thread interleaving is done by the time-intensive commands in zlib.so. This leads to serious lags when compressing 5 MB files... I have wrapped all of the inflate and deflate commands in Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS, which fixes this problem. Note that this fix is backwards compatible to 2.1, at least, as zlibmodule.c has not changed since then. As requested, a _context_ diff from the head of the current CVS tree is attached ;). ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-04 08:01 Message: Logged In: YES user_id=21627 I fail to see the issue with the string being released from under the compression invocation: The string is definitely referenced from the argument tuple, and the argument tuple is guaranteed to live as long as the function is running, even if a thread switch occurs within the function. This is no showstopper issue, though: the code looks correct even with the extra incref. Unless you indicate that you'll want to study the refcount issue in more detail and potentially revise the patch, I'm willing to commit it as-is. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-20 23:55 Message: Logged In: YES user_id=23486 One last patch: Alex Martelli pointed out that C functions do not automatically take on ownership of passed-in strings, and, under circumstances where multiple threads have access to the same namespace, thread A might be involved in a time-consuming command and thread B (now allowed to execute) could then delete the input string out from under it. Attached is the complete patch, this time including the appropriate INCREF and DECREF of the input string. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-17 10:10 Message: Logged In: YES user_id=23486 This new patch makes the zlibmodule reentrant by using a global zlib_lock. Also included is the addition of BEGIN/END_ALLOW_THREADS macros around the actual calls to compress/decompress data, which significantly improves the thread-friendliness of this module. Most of the code changes are simple rearrangements of the same old code to adapt it to the requirements of the ENTER and LEAVE_ZLIB macros, which create new blocks; thus, any code from which a 'return' was done had to be changed to exit only after LEAVE_ZLIB was called. Note that because zlib itself is re-entrant, we really only had to worry about making methods on de/compress objects reentrant. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-14 12:13 Message: Logged In: YES user_id=23486 N.B. I've found that zlib _is_ threadsafe. I still need to determine if the way in which objects are passed around in the zlibmodule.c can potentially cause problems; it seems like it can. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-14 09:06 Message: Logged In: YES user_id=23486 I think there may be a 2nd problem: I have to look into some of the Python calls used to transfer data around, but it may be possible for threads with access to the compression objects to retrieve data in an indeterminate state, i.e. mid-compression. Luckily a module-wide lock should take care of both this problem AND resolve threadsafety issues with zlib! I'll look into this & fix it. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-14 07:21 Message: Logged In: YES user_id=21627 The patch looks good, however there is a major problem with the approach taken: zlib itself might not be threadsafe. Please try to find out whether zlib indeed is thread-safe; if it isn't, I think you need to add another lock to prevent multiple Python threads from accessing zlib simultaneously. You may want to take a look at _tkinter, which has similar code to prevent multiple Python threads from accessing Tk simultaneously. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450702&group_id=5470 From noreply@sourceforge.net Tue Sep 4 18:22:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Sep 2001 10:22:57 -0700 Subject: [Patches] [ python-Patches-458459 ] fix profiling of generators Message-ID: Patches item #458459, was opened at 2001-09-04 10:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458459&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: fix profiling of generators Initial Comment: The profile module doesn't understand functions that get called once but return multiple times. This patch moves call_trace(..., PyTrace_CALL, ...) to the top of eval_frame. That way the profile trace function gets notified each time a generator resumes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458459&group_id=5470 From noreply@sourceforge.net Tue Sep 4 19:34:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Sep 2001 11:34:20 -0700 Subject: [Patches] [ python-Patches-458459 ] fix profiling of generators Message-ID: Patches item #458459, was opened at 2001-09-04 10:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458459&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: fix profiling of generators Initial Comment: The profile module doesn't understand functions that get called once but return multiple times. This patch moves call_trace(..., PyTrace_CALL, ...) to the top of eval_frame. That way the profile trace function gets notified each time a generator resumes. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-09-04 11:34 Message: Logged In: YES user_id=3066 I agree; please check this in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458459&group_id=5470 From noreply@sourceforge.net Tue Sep 4 19:40:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Sep 2001 11:40:15 -0700 Subject: [Patches] [ python-Patches-450979 ] Add module docstring - imputil Message-ID: Patches item #450979, was opened at 2001-08-14 15:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450979&group_id=5470 Category: documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Add module docstring - imputil Initial Comment: Add module docstring - imputil ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-09-04 11:40 Message: Logged In: YES user_id=3066 Checked in as Lib/imputil.py revision 1.22. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450979&group_id=5470 From noreply@sourceforge.net Tue Sep 4 19:55:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Sep 2001 11:55:40 -0700 Subject: [Patches] [ python-Patches-450981 ] Add module docstring - xmlrpc Message-ID: Patches item #450981, was opened at 2001-08-14 15:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450981&group_id=5470 Category: documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Add module docstring - xmlrpc Initial Comment: Add module docstring - xmlrpc ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-09-04 11:55 Message: Logged In: YES user_id=3066 Checked in with modifications as Lib/xmlrpclib.py revision 1.5. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450981&group_id=5470 From noreply@sourceforge.net Tue Sep 4 20:04:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Sep 2001 12:04:17 -0700 Subject: [Patches] [ python-Patches-458459 ] fix profiling of generators Message-ID: Patches item #458459, was opened at 2001-09-04 10:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458459&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: fix profiling of generators Initial Comment: The profile module doesn't understand functions that get called once but return multiple times. This patch moves call_trace(..., PyTrace_CALL, ...) to the top of eval_frame. That way the profile trace function gets notified each time a generator resumes. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-09-04 12:04 Message: Logged In: YES user_id=35752 Commited as 2.273 of ceval.c. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-09-04 11:34 Message: Logged In: YES user_id=3066 I agree; please check this in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458459&group_id=5470 From noreply@sourceforge.net Tue Sep 4 20:20:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Sep 2001 12:20:26 -0700 Subject: [Patches] [ python-Patches-450980 ] Add module docstring - sre*, re Message-ID: Patches item #450980, was opened at 2001-08-14 15:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450980&group_id=5470 Category: documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Add module docstring - sre*, re Initial Comment: Add module docstring - sre*, re ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-09-04 12:20 Message: Logged In: YES user_id=3066 Checked into Lib: re.py 1.41, sre.py 1.35 (converted to a raw string in 1.36), sre_compile.py 1.41, sre_constants.py 1.30, sre_parse.py 1.47. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450980&group_id=5470 From noreply@sourceforge.net Tue Sep 4 20:44:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Sep 2001 12:44:00 -0700 Subject: [Patches] [ python-Patches-451538 ] L10n of pprint Message-ID: Patches item #451538, was opened at 2001-08-16 05:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=451538&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Denis S. Otkidach (ods) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: L10n of pprint Initial Comment: Representation of strings with non-latin national characters is quite unreadable. Although we can use current locale to determine full set of printable character. This patch in combination with dysplay_hook allows to get native representation for 8-bit strings, including ones in dictionaries, lists and tuples. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-09-04 12:44 Message: Logged In: YES user_id=3066 This doesn't appear to break things, but I don't know how to really test that this solves the cited problem (locales are just not something I know much about). I made a small performance-related change and checked it in as Lib/pprint.py revision 1.15. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-27 12:30 Message: Logged In: YES user_id=3066 I think this is OK; will think about it a little more tomorrow and make a decision. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=451538&group_id=5470 From noreply@sourceforge.net Tue Sep 4 22:15:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Sep 2001 14:15:50 -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: Pending Resolution: Accepted 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-09-04 14:15 Message: Logged In: YES user_id=3066 Could you please try to enumerate just what's left to be done here? Thanks! ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-08-14 17:39 Message: Logged In: YES user_id=93657 When you say 'windows/cygwin', I don't know if you mean 'cygwin on windows', or 'cygwin' and 'windows'... So, here are some precisions: The changes in the doc makefile are first meant to make it compatible with the Win2K command line shell, and using VC++'s nmake. As a rule, I try not to mix up Win32 and Cygwin environments together (the bundling of python and some Tetex/Latex in the standard cygwin distribution does not help at all). Since MikTek is easy to install and works fine (in contrast to cygwin's tetex), I build the doc in a 'win32' environment; and to put most chances on my side: - I don't use cygwin bash for the builds - if cygwin make is used, I run it as 'make --win32'. In what I have installed to compile the docs, cygwin is only required for building some 3rd party graphic library required for installing properly latex2html (I could not work it around). Frederic Giacometti ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-10 13:22 Message: Logged In: YES user_id=3066 Added fancyhdr.sty in Doc/texinputs/. Doc/perl/l2hinit.perl no longer needs "cat" (revision 1.55), so the adjustment to support CygWin cat is no longer needed in mkhowto. Doc/tools/mkhowto revision 1.29 contains changes to be portable to Windows/CygWin, based on the attached patch. Still not closed ;-( -- I need to try to actually understand what's going on with \pdfendlink, and the README probably needs a little work. Frederic, have I missed anything else? (Sorry to take so long getting this in!) Marked "Pending" waiting for feedback. ---------------------------------------------------------------------- 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 Sep 4 22:23:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Sep 2001 14:23:08 -0700 Subject: [Patches] [ python-Patches-458534 ] ncurses form module Message-ID: Patches item #458534, was opened at 2001-09-04 14:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458534&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: A.M. Kuchling (akuchling) Summary: ncurses form module Initial Comment: >From an e-mail sent to me privately: hello. i written extension for curses module this is not 100% jet Lambach Bartosz lda@lupa.pl ps. sorry, english is not my favorit ;) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458534&group_id=5470 From noreply@sourceforge.net Wed Sep 5 13:37:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 05:37:07 -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(). ---------------------------------------------------------------------- Comment By: James C. Ahlstrom (ahlstromjc) Date: 2001-09-05 05:37 Message: Logged In: YES user_id=64929 Currently, zipfile.py writes flag 0x08 to indicate that the CRC and file sizes follow the file data. It writes the file header with zero CRC and file sizes, writes the file data, and then writes three longs. Java seems to require a 4 byte header, then three longs. The pkware appnote.txt document requires just three longs with no header. I am unable to find a justification for the header, and I do not want to be inconsistent with the zip specification. Therefore I oppose this patch. Instead I propose a new patch. Zipfile.py will write flags 0x00, the file header, then the file data. Then it will seek backwards and write the correct CRC and file sizes in the file header, and then seek to the end of the file data. Flag 0x08 is NOT set, and the correct CRC and file sizes are in the header. This satisfies the zip specification and Java at the minor cost of two seek()'s and a tell(). I will submit this as a new patch as I can't seem to attach it to this one. Jim Ahlstrom ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442128&group_id=5470 From noreply@sourceforge.net Wed Sep 5 13:52:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 05:52:39 -0700 Subject: [Patches] [ python-Patches-458701 ] Patch to zipfile.py for Java Message-ID: Patches item #458701, was opened at 2001-09-05 05:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458701&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: James C. Ahlstrom (ahlstromjc) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to zipfile.py for Java Initial Comment: This is an alternative to the zipfile.py patch 442128 by Finn Bock (bckfnn). Java fails to read zip files created by zipfile.py because it requires a 4 byte header for the CRC and file sizes which are written after the file data, and the zip specification does not have this header. This patch will unset flag 0x08 (flags will be zero) to indicate the CRC and file sizes do NOT follow the file data, and will seek() backwards to write them in the file header. This is consistent with the zip format and eliminates the problem with Java. The patch has been tested with WinZip.exe on Windows, is very simple, and hopefully will make it into 2.2. Jim Ahlstrom ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458701&group_id=5470 From noreply@sourceforge.net Wed Sep 5 13:59:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 05:59:52 -0700 Subject: [Patches] [ python-Patches-458701 ] Patch to zipfile.py for Java Message-ID: Patches item #458701, was opened at 2001-09-05 05:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458701&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: James C. Ahlstrom (ahlstromjc) >Assigned to: Finn Bock (bckfnn) Summary: Patch to zipfile.py for Java Initial Comment: This is an alternative to the zipfile.py patch 442128 by Finn Bock (bckfnn). Java fails to read zip files created by zipfile.py because it requires a 4 byte header for the CRC and file sizes which are written after the file data, and the zip specification does not have this header. This patch will unset flag 0x08 (flags will be zero) to indicate the CRC and file sizes do NOT follow the file data, and will seek() backwards to write them in the file header. This is consistent with the zip format and eliminates the problem with Java. The patch has been tested with WinZip.exe on Windows, is very simple, and hopefully will make it into 2.2. Jim Ahlstrom ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 05:59 Message: Logged In: YES user_id=6380 Finn, if this works for you, please check it in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458701&group_id=5470 From noreply@sourceforge.net Wed Sep 5 14:46:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 06:46:03 -0700 Subject: [Patches] [ python-Patches-428326 ] Timer class for threading Message-ID: Patches item #428326, was opened at 2001-05-29 08:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428326&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Itamar Shtull-Trauring (itamar) Assigned to: Nobody/Anonymous (nobody) Summary: Timer class for threading Initial Comment: The Timer class allows you to schedule an action to happen at some time in the future, using a thread. For example: def f(): print "30 seconds have passed" t = Timer(30.0, f) t.start() # after 30 seconds f will be called try: # .... other stuff except SystemExit: t.cancel() # cancel the timer since we are shutting down It allows passing arguments and keyword arguments to the function that is called. It also allows *cancelling* the timer. That is, if the timer is still waiting, we can tell it to stop its operation. Why should this be in the standard library? 1. Timers are a standard, useful programming idiom. 2. It can be used as an example of how to: a. create subclasses of threading.Thread b. make threads that can be "stopped" If this patch is approved I will then write documentation. I'm not sure how to go about writing tests for it. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 06:46 Message: Logged In: YES user_id=21627 Thanks for the patch; it is committed as threading.py 1.18, libthreading.tex 1.11, NEWS 1.230. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-09-04 07:49 Message: Logged In: YES user_id=32065 I've attached a patch to the documentation. I don't know LaTex so there may be some errors (although the HTML output seems OK). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 06:51 Message: Logged In: YES user_id=6380 OK. Let's do a one-short timer only. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-10 01:21 Message: Logged In: YES user_id=21627 A quick poll among colleagues shows that shoot-once timers are far more common than repeated intervall timers. You also can quite easily implement the intervall timer on top of a shoot-once timer, by restarting it in the timeout handler (although care is needed if you need exact intervalls: between last scheduled time-out and the handler invocation, time may pass, so the restart may need to be smaller than the intervall). In short, I think the API as you provide it is excellent; if people find it useful and require more, they will provide patches. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 14:45 Message: Logged In: YES user_id=6380 Good! I don't think there's a standard definition of timers -- I've seen both. A more general timer that can go off N times, defaulting to once, sounds like a nice API. Hm, I can actually only think of two usage scenarios: either you want it to go off once, or you want it to repeat until you cancel it. Think about it. There's also the msg from Aahz in the python-dev list where he claims he doesn't like something about this without saying what. I hope he clarifies that in this SF tracker item. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-08-09 14:23 Message: Logged In: YES user_id=32065 1) license can be python's and copyright PSF's 2) I will write docs and tests 3) not sure when, maybe this weekend One question - timers actually seem to be a task that happens repeatedly every X seconds (e.g. in wxWindows). Should I add that functionality (do a task every X seconds, N times, N is either >= 1 or infinite) or just rename the class? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 13:53 Message: Logged In: YES user_id=6380 I like it too. But I don't want itamar's license anywhere in the distribution -- too wordy. I agree that the PSF should clear up the licensing situation; we're working on that but it's slow going (nobody likes this work :-( ). ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-08 13:32 Message: Logged In: YES user_id=21627 I'm in favour of approving this patch, as an extension to the threading module. Are you willing to draft a patch to the documentation (libthreading.tex) as well? Ideally, there would also be a set of regression tests in a test_threading file; it would be acceptable if this only tests your feature for the moment. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-05-30 09:40 Message: Logged In: YES user_id=32065 There was a licensing discussion on python-dev which no one bothered to CC me on :). Yes, this can be relicensed under the PSF license. I suggest someone write up some sort of guidelines for submitted patches and improvement explain the whole licensing and copyright issues. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-05-30 02:16 Message: Logged In: YES user_id=32065 OK, I'm un-withdrawing this patch. Just had to get things straight with our lawyer. The patch is released under the following license (the X11 license with 4 extra paragraphs of disclaimers :): http://www.zoteca.com/opensource/LICENSE.txt ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-05-29 09:45 Message: Logged In: YES user_id=32065 I'm withdrawing this patch for a short period of time for non-technical reasons, hopefully I can put it back soon. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428326&group_id=5470 From noreply@sourceforge.net Wed Sep 5 14:58:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 06:58:01 -0700 Subject: [Patches] [ python-Patches-449757 ] digestsize variable for the md5 module Message-ID: Patches item #449757, was opened at 2001-08-10 02:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449757&group_id=5470 Category: None Group: None >Status: Closed Resolution: Rejected Priority: 3 Submitted By: Martin Sjцgren (msjogren) Assigned to: Nobody/Anonymous (nobody) Summary: digestsize variable for the md5 module Initial Comment: The sha module has a digestsize constant (which is 20) which makes it easy to know how large space to use (e.g. in a database), while the md5 module doesn't. Yes I know that it IS 16, but ideally, the two modules would have the same interface and you could do tricks like this: insize = globals()[digestname].digestsize So, I included a patch to md5module.c that adds a digestsize constant both to the md5 objects and to the module dictionary, as in the sha module. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 06:58 Message: Logged In: YES user_id=21627 Since there where no further voices in favour of the patch, it seems it can be closed (as Rejected). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 08:41 Message: Logged In: YES user_id=6380 I'm for leaving well enough alone, and against code bloat. I would not have added those constants to sha, but I didn't write it. Your examples don't convince me -- they don't seem very robust coding practices anyway. Also, how often do we grow new digest algorithms? ---------------------------------------------------------------------- Comment By: Martin Sjцgren (msjogren) Date: 2001-08-10 08:27 Message: Logged In: YES user_id=80762 Yes, Python is a dynamic language. I think you missed my 'e.g. in a database'. In SQL you'd want create a column "digest CHAR(nn)" and it would be nice to have the flexibility of which digest algorithm to use. It is also nice to know when you send a digest over a socket. I'm not saying that this constant is vitally important to my health! I'm saying that the sha module has it, and it would be nice if the md5 module had it too! I'm quite aware that the size of the digests are well-known, but instead of having to do digestsizes = { 'md5': 16, 'sha': 20 } myself, I don't see why Python can't provide those constants. They are after all properties of the digest algorithms! Example: I get a message on a socket. All I know is that the characters up to the first '\0' is the name of the digest function used. I would like to do this: import md5, sha digests = { 'md5': md5, 'sha': sha } # using globals() is ugly digest = sock.recv(digests[mdalg].digestsize) I really don't see your problem with adding this constant. With your argument you could as well remove the constant from the sha module, but that would break backwards compatability, so why not just add this constant and they'd have more similar APIs? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 06:27 Message: Logged In: YES user_id=6380 Sorry, I fail to understand why knowing the return size in advance is useful. Python is a dynamic language -- why would you have to allocate a fixed-size buffer? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449757&group_id=5470 From noreply@sourceforge.net Wed Sep 5 15:03:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 07:03:50 -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: Martin v. Lцwis (loewis) 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 Wed Sep 5 15:15:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 07:15:44 -0700 Subject: [Patches] [ python-Patches-449815 ] Set filesystemencoding based on CODESET Message-ID: Patches item #449815, was opened at 2001-08-10 07:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449815&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: Set filesystemencoding based on CODESET Initial Comment: This patch sets the Py_FileSystemDefaultEncoding in each setlocale call if nl_langinfo(CODESET) is available and returns a well-known codec name. This is closest to the windows approach, which uses the "mbcs" encoding. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 07:15 Message: Logged In: YES user_id=6380 If you think this is how it should be done, go for it -- it's only an alpha release. (Famous last words. :-) Question: are the intricate semantics of Py_FileSystemDefaultEncoding sufficiently documented (e.g. the fact that it must be malloc()'ed storage)? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449815&group_id=5470 From noreply@sourceforge.net Wed Sep 5 15:16:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 07:16:13 -0700 Subject: [Patches] [ python-Patches-458534 ] ncurses form module Message-ID: Patches item #458534, was opened at 2001-09-04 14:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458534&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: A.M. Kuchling (akuchling) Summary: ncurses form module Initial Comment: >From an e-mail sent to me privately: hello. i written extension for curses module this is not 100% jet Lambach Bartosz lda@lupa.pl ps. sorry, english is not my favorit ;) ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:16 Message: Logged In: YES user_id=21627 In the current form, the module seems to be unacceptable. It comes with no documentation, and no examples. I'd strongly encourage the author to provide a sample application. If he's willing to write some documentation, that would be also good. If he can write only Polish, I could help finding somebody who translates that into English afterwards. Note that there is also a complete interface to forms, and the rest of ncurses, in http://pyncurses.sourceforge.net/ ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458534&group_id=5470 From noreply@sourceforge.net Wed Sep 5 15:18:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 07:18:09 -0700 Subject: [Patches] [ python-Patches-455176 ] sys module feature patch - modify_argv() Message-ID: Patches item #455176, was opened at 2001-08-24 18:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455176&group_id=5470 Category: core (C code) Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: sys module feature patch - modify_argv() Initial Comment: Feature enhancment patch to sys module. (Python/sysmodule.c) modify_argv(string,[start],[amount]) Modify the absolute argv (process listing) elements of the python process. Element values are set to zero, then refilled if a replacement value is present. Note: sys.argv will not be changed. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:18 Message: Logged In: YES user_id=21627 Resubmitted as http://sourceforge.net/tracker/index.php?func=detail&aid=457892&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-02 15:48 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455176&group_id=5470 From noreply@sourceforge.net Wed Sep 5 15:25:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 07:25:43 -0700 Subject: [Patches] [ python-Patches-455231 ] Python 2.2a2 -- OpenBSD a.out and ELF build fixes. Message-ID: Patches item #455231, was opened at 2001-08-25 04:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455231&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Alexander Guy (a7r) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.2a2 -- OpenBSD a.out and ELF build fixes. Initial Comment: Changes to configure.in and friends to support building on both a.out and ELF OpenBSD platforms (tested on i386 and PowerPC, respectively). Pretty straight forward; more of a cleanup than anything. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:25 Message: Logged In: YES user_id=21627 Thanks for the patch. It looks ok to me, so I have applied it as configure.in 1.252, configure 1.244, dynload_shlib.c 2.10. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455231&group_id=5470 From noreply@sourceforge.net Wed Sep 5 15:39:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 07:39:22 -0700 Subject: [Patches] [ python-Patches-453627 ] UnixWare 7.x port for Python 2.2 Message-ID: Patches item #453627, was opened at 2001-08-20 22:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: UnixWare 7.x port for Python 2.2 Initial Comment: The attached set of patches provide work-a-rounds for two know UnixWare 7.x bugs and fixes other problems related to the UnixWare 7.x port of Python. The patch file names and a description of the patches are: 1. uw7_pyconfig.patch This patch changes pyconfig.h.in to define the following macros when compiling on a UnixWare 7.x system: SCO_ATAN2_BUG, SCO_ACCEPT_BUG, and STRICT_SYSV_CURSES. 2. uw7_math.patch This patch adds code to Modules/mathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 3. uw7_cmath.patch This patch adds code to Modules/cmathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 4. uw7_complex.patch This patch adds code to Objects/complexobject.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 5. uw7_socket.patch This patch adds code to Modules/socketmodule.c to work around a bug in the SCO UnixWare 7.X accept() imple- mentation. This code is only compiled if the macro, SCO_ACCEPT_BUG, is defined. The patch also changed the code so that the accept call is restarted if it was interrupted. 6. uw7_regrtest.patch This patch adds a list of tests that are expected to be skipped for UnixWare 7.x systems. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:39 Message: Logged In: YES user_id=21627 Accepted uw7_regrtest.patch as regrtest.py 1.46. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-21 15:51 Message: Logged In: YES user_id=8500 I have uploaded an updated patch for Modules/socketmodule.py named uw7_socket_2.patch. Please use this instead of uw7_socket..patch. The original patch backed out 2 changes made to socketmodule.c since I got my copy from the CVS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 From noreply@sourceforge.net Wed Sep 5 15:40:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 07:40:28 -0700 Subject: [Patches] [ python-Patches-453627 ] UnixWare 7.x port for Python 2.2 Message-ID: Patches item #453627, was opened at 2001-08-20 22:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Billy G. Allie (ballie01) >Assigned to: Martin v. Lцwis (loewis) Summary: UnixWare 7.x port for Python 2.2 Initial Comment: The attached set of patches provide work-a-rounds for two know UnixWare 7.x bugs and fixes other problems related to the UnixWare 7.x port of Python. The patch file names and a description of the patches are: 1. uw7_pyconfig.patch This patch changes pyconfig.h.in to define the following macros when compiling on a UnixWare 7.x system: SCO_ATAN2_BUG, SCO_ACCEPT_BUG, and STRICT_SYSV_CURSES. 2. uw7_math.patch This patch adds code to Modules/mathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 3. uw7_cmath.patch This patch adds code to Modules/cmathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 4. uw7_complex.patch This patch adds code to Objects/complexobject.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 5. uw7_socket.patch This patch adds code to Modules/socketmodule.c to work around a bug in the SCO UnixWare 7.X accept() imple- mentation. This code is only compiled if the macro, SCO_ACCEPT_BUG, is defined. The patch also changed the code so that the accept call is restarted if it was interrupted. 6. uw7_regrtest.patch This patch adds a list of tests that are expected to be skipped for UnixWare 7.x systems. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:39 Message: Logged In: YES user_id=21627 Accepted uw7_regrtest.patch as regrtest.py 1.46. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-21 15:51 Message: Logged In: YES user_id=8500 I have uploaded an updated patch for Modules/socketmodule.py named uw7_socket_2.patch. Please use this instead of uw7_socket..patch. The original patch backed out 2 changes made to socketmodule.c since I got my copy from the CVS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 From noreply@sourceforge.net Wed Sep 5 15:46:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 07:46:57 -0700 Subject: [Patches] [ python-Patches-453627 ] UnixWare 7.x port for Python 2.2 Message-ID: Patches item #453627, was opened at 2001-08-20 22:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Martin v. Lцwis (loewis) Summary: UnixWare 7.x port for Python 2.2 Initial Comment: The attached set of patches provide work-a-rounds for two know UnixWare 7.x bugs and fixes other problems related to the UnixWare 7.x port of Python. The patch file names and a description of the patches are: 1. uw7_pyconfig.patch This patch changes pyconfig.h.in to define the following macros when compiling on a UnixWare 7.x system: SCO_ATAN2_BUG, SCO_ACCEPT_BUG, and STRICT_SYSV_CURSES. 2. uw7_math.patch This patch adds code to Modules/mathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 3. uw7_cmath.patch This patch adds code to Modules/cmathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 4. uw7_complex.patch This patch adds code to Objects/complexobject.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 5. uw7_socket.patch This patch adds code to Modules/socketmodule.c to work around a bug in the SCO UnixWare 7.X accept() imple- mentation. This code is only compiled if the macro, SCO_ACCEPT_BUG, is defined. The patch also changed the code so that the accept call is restarted if it was interrupted. 6. uw7_regrtest.patch This patch adds a list of tests that are expected to be skipped for UnixWare 7.x systems. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:46 Message: Logged In: YES user_id=21627 Accepted uw7_cmath.patch, uw7_complex.patch, uw7_math.patch, uw7_pyconfig.patch as cmathmodule.c 2.25, mathmodule.c 2.64, complexobject.c 2.43, and pyconfig.h.in 1.6. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:39 Message: Logged In: YES user_id=21627 Accepted uw7_regrtest.patch as regrtest.py 1.46. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-21 15:51 Message: Logged In: YES user_id=8500 I have uploaded an updated patch for Modules/socketmodule.py named uw7_socket_2.patch. Please use this instead of uw7_socket..patch. The original patch backed out 2 changes made to socketmodule.c since I got my copy from the CVS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 From noreply@sourceforge.net Wed Sep 5 15:55:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 07:55:39 -0700 Subject: [Patches] [ python-Patches-453627 ] UnixWare 7.x port for Python 2.2 Message-ID: Patches item #453627, was opened at 2001-08-20 22:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Martin v. Lцwis (loewis) Summary: UnixWare 7.x port for Python 2.2 Initial Comment: The attached set of patches provide work-a-rounds for two know UnixWare 7.x bugs and fixes other problems related to the UnixWare 7.x port of Python. The patch file names and a description of the patches are: 1. uw7_pyconfig.patch This patch changes pyconfig.h.in to define the following macros when compiling on a UnixWare 7.x system: SCO_ATAN2_BUG, SCO_ACCEPT_BUG, and STRICT_SYSV_CURSES. 2. uw7_math.patch This patch adds code to Modules/mathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 3. uw7_cmath.patch This patch adds code to Modules/cmathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 4. uw7_complex.patch This patch adds code to Objects/complexobject.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 5. uw7_socket.patch This patch adds code to Modules/socketmodule.c to work around a bug in the SCO UnixWare 7.X accept() imple- mentation. This code is only compiled if the macro, SCO_ACCEPT_BUG, is defined. The patch also changed the code so that the accept call is restarted if it was interrupted. 6. uw7_regrtest.patch This patch adds a list of tests that are expected to be skipped for UnixWare 7.x systems. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:55 Message: Logged In: YES user_id=21627 Thanks for your patches. I've applied all of them except for uw7_socket_2.patch. Why do you add an again loop around the accept(2) call? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:46 Message: Logged In: YES user_id=21627 Accepted uw7_cmath.patch, uw7_complex.patch, uw7_math.patch, uw7_pyconfig.patch as cmathmodule.c 2.25, mathmodule.c 2.64, complexobject.c 2.43, and pyconfig.h.in 1.6. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:39 Message: Logged In: YES user_id=21627 Accepted uw7_regrtest.patch as regrtest.py 1.46. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-21 15:51 Message: Logged In: YES user_id=8500 I have uploaded an updated patch for Modules/socketmodule.py named uw7_socket_2.patch. Please use this instead of uw7_socket..patch. The original patch backed out 2 changes made to socketmodule.c since I got my copy from the CVS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 From noreply@sourceforge.net Wed Sep 5 16:49:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 08:49:36 -0700 Subject: [Patches] [ python-Patches-453627 ] UnixWare 7.x port for Python 2.2 Message-ID: Patches item #453627, was opened at 2001-08-20 22:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Martin v. Lцwis (loewis) Summary: UnixWare 7.x port for Python 2.2 Initial Comment: The attached set of patches provide work-a-rounds for two know UnixWare 7.x bugs and fixes other problems related to the UnixWare 7.x port of Python. The patch file names and a description of the patches are: 1. uw7_pyconfig.patch This patch changes pyconfig.h.in to define the following macros when compiling on a UnixWare 7.x system: SCO_ATAN2_BUG, SCO_ACCEPT_BUG, and STRICT_SYSV_CURSES. 2. uw7_math.patch This patch adds code to Modules/mathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 3. uw7_cmath.patch This patch adds code to Modules/cmathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 4. uw7_complex.patch This patch adds code to Objects/complexobject.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 5. uw7_socket.patch This patch adds code to Modules/socketmodule.c to work around a bug in the SCO UnixWare 7.X accept() imple- mentation. This code is only compiled if the macro, SCO_ACCEPT_BUG, is defined. The patch also changed the code so that the accept call is restarted if it was interrupted. 6. uw7_regrtest.patch This patch adds a list of tests that are expected to be skipped for UnixWare 7.x systems. ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2001-09-05 08:49 Message: Logged In: YES user_id=8500 Any blocking I/O call is subject to being interruped by a signal. In particular, on Unixware when running threads, the first call to accept immediately returns because of an interrupted call. Therefore the loop to retry the interrupted call. On a side note, (IMHO) the code that calls an I/O operation that can block should check for an error code of EINTR and retry the operation if it was interrupted instead of returning an exception because of the interruption. That is, of course, my own opinion. BTW: is anyone looking at the distutils and setup.py changes I submitted [Patch # 454041] ? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:55 Message: Logged In: YES user_id=21627 Thanks for your patches. I've applied all of them except for uw7_socket_2.patch. Why do you add an again loop around the accept(2) call? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:46 Message: Logged In: YES user_id=21627 Accepted uw7_cmath.patch, uw7_complex.patch, uw7_math.patch, uw7_pyconfig.patch as cmathmodule.c 2.25, mathmodule.c 2.64, complexobject.c 2.43, and pyconfig.h.in 1.6. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:39 Message: Logged In: YES user_id=21627 Accepted uw7_regrtest.patch as regrtest.py 1.46. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-21 15:51 Message: Logged In: YES user_id=8500 I have uploaded an updated patch for Modules/socketmodule.py named uw7_socket_2.patch. Please use this instead of uw7_socket..patch. The original patch backed out 2 changes made to socketmodule.c since I got my copy from the CVS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 From noreply@sourceforge.net Wed Sep 5 16:50:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 08:50:13 -0700 Subject: [Patches] [ python-Patches-416704 ] More robust freeze Message-ID: Patches item #416704, was opened at 2001-04-17 07:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416704&group_id=5470 Category: None Group: None Status: Open >Resolution: Out of Date Priority: 5 Submitted By: Toby Dickenson (htrd) >Assigned to: Guido van Rossum (gvanrossum) Summary: More robust freeze Initial Comment: This patch addresses three issues, all relating to robustness of frozen programs. Specifically, this patch allows explicit and complete control over which modules may be loaded from source on the filesystem of the host system where the frozen program is run, and which may not. Without this patch it is impossible to create a non- trivial frozen program which will *never* load a module from source on the filesystem. 1. A patch to correct bug #404545 (frozen package import uses wrong files). Under this change, submodules of a frozen package must themselves be frozen modules. Previously, the import machinery may also try to import submodules from curiously named files (packagename.modulename.py) from directories in sys.path 2. A patch to add an extra command line option -E to freeze.py, which forces freeze to terminate with an error message if there are modules that it can not locate. If this switch is not specified then the default behaviour is unchanged: modules which can not be found by freeze will not be included in the frozen program, and the import machinery will try to load them from source on sys.path when the frozen program is run. In practice we have found that a missing module is probably an error (and it is a fairly frequent error too!). The -E switch can be used to detect this error; any missing modules will cause freeze.py to fail. In the rare case of a frozen module importing a non- frozen one (ie one which should be loaded from source when the program is run), the non-frozen module must be excluded from the freeze using the -x option. 3. A patch to add an extra command line option -X to freeze.py, which indicates that a specified module is excluded from the freeze, and also that the frozen program should not try to load the module from sys.path when it is imported. Importing the specified module will always trigger an ImportError. This is useful if a module used by a frozen program can optionally use a submodule... try: import optional_submodule except ImportError: pass It may be preferable for the frozen program's behaviour to not depend on whether optional_submodule happens to be installed on the host system, and that the 'import optional_submodule' should always fail with an ImportError. This can be achieved using the '- X optional_submodule' command line switch to freeze.py This is implemented by including the excluded module in the frozen imports table (_PyImport_FrozenModules), with the code pointer set to NULL. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 08:50 Message: Logged In: YES user_id=6380 I'm willing to look at this, but right now the patch doesn't apply cleanly. From the headers in the diff file it looks like you're patching an early beta for 2.0. If you can rework this for current CVS or Python 2.2a2 or 2.2a3, that would be great. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-06-07 15:26 Message: Logged In: YES user_id=21627 Why is this assigned to Mark? I cannot see anything windows-specific in it. Mark, if you are not interested in reviewing this patch, I recommend to unassign this from yourself. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416704&group_id=5470 From noreply@sourceforge.net Wed Sep 5 18:04:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 10:04:47 -0700 Subject: [Patches] [ python-Patches-453627 ] UnixWare 7.x port for Python 2.2 Message-ID: Patches item #453627, was opened at 2001-08-20 22:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Martin v. Lцwis (loewis) Summary: UnixWare 7.x port for Python 2.2 Initial Comment: The attached set of patches provide work-a-rounds for two know UnixWare 7.x bugs and fixes other problems related to the UnixWare 7.x port of Python. The patch file names and a description of the patches are: 1. uw7_pyconfig.patch This patch changes pyconfig.h.in to define the following macros when compiling on a UnixWare 7.x system: SCO_ATAN2_BUG, SCO_ACCEPT_BUG, and STRICT_SYSV_CURSES. 2. uw7_math.patch This patch adds code to Modules/mathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 3. uw7_cmath.patch This patch adds code to Modules/cmathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 4. uw7_complex.patch This patch adds code to Objects/complexobject.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 5. uw7_socket.patch This patch adds code to Modules/socketmodule.c to work around a bug in the SCO UnixWare 7.X accept() imple- mentation. This code is only compiled if the macro, SCO_ACCEPT_BUG, is defined. The patch also changed the code so that the accept call is restarted if it was interrupted. 6. uw7_regrtest.patch This patch adds a list of tests that are expected to be skipped for UnixWare 7.x systems. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 10:04 Message: Logged In: YES user_id=21627 Of course: blocking calls are interupted by signals. That is the sole purpose of SIGINT: To interrupt what the program currently does. Python must not ignore this, but immediately return to the caller - most likely, the user meant to interrupt the Python program. If the application then choses to retry on EINTR - that's a different story. Are you saying that on UnixWare, a call to accept immediately returns even without any signals being sent, in the presence of threads? That sounds broken. Where is that documented? On the distutils patches: I'm no distutils expert, so I don't feel qualified to review the patches (IOW, it would take some considerable time to review them which I don't have). Since all distutils experts have loads of patches to review, it may take some time to find a reviewer. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-09-05 08:49 Message: Logged In: YES user_id=8500 Any blocking I/O call is subject to being interruped by a signal. In particular, on Unixware when running threads, the first call to accept immediately returns because of an interrupted call. Therefore the loop to retry the interrupted call. On a side note, (IMHO) the code that calls an I/O operation that can block should check for an error code of EINTR and retry the operation if it was interrupted instead of returning an exception because of the interruption. That is, of course, my own opinion. BTW: is anyone looking at the distutils and setup.py changes I submitted [Patch # 454041] ? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:55 Message: Logged In: YES user_id=21627 Thanks for your patches. I've applied all of them except for uw7_socket_2.patch. Why do you add an again loop around the accept(2) call? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:46 Message: Logged In: YES user_id=21627 Accepted uw7_cmath.patch, uw7_complex.patch, uw7_math.patch, uw7_pyconfig.patch as cmathmodule.c 2.25, mathmodule.c 2.64, complexobject.c 2.43, and pyconfig.h.in 1.6. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:39 Message: Logged In: YES user_id=21627 Accepted uw7_regrtest.patch as regrtest.py 1.46. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-21 15:51 Message: Logged In: YES user_id=8500 I have uploaded an updated patch for Modules/socketmodule.py named uw7_socket_2.patch. Please use this instead of uw7_socket..patch. The original patch backed out 2 changes made to socketmodule.c since I got my copy from the CVS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 From noreply@sourceforge.net Wed Sep 5 18:13:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 10:13:15 -0700 Subject: [Patches] [ python-Patches-449815 ] Set filesystemencoding based on CODESET Message-ID: Patches item #449815, was opened at 2001-08-10 07:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449815&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Martin v. Lцwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Set filesystemencoding based on CODESET Initial Comment: This patch sets the Py_FileSystemDefaultEncoding in each setlocale call if nl_langinfo(CODESET) is available and returns a well-known codec name. This is closest to the windows approach, which uses the "mbcs" encoding. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 10:13 Message: Logged In: YES user_id=21627 I've documented Py_FileSystemDefaultEncoding in api.tex 1.145, as read-only: on Windows, it is a static string with the value "mbcs". Setting this is only allowed for platform code, and all assigners must coordinate tightly (which currently is Windows and Unix only). The code itself is in _localemodule.c 2.23. I also added a test case, which relies on support for the en_US locale; this is in test_unicode_file.py 1.2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 07:15 Message: Logged In: YES user_id=6380 If you think this is how it should be done, go for it -- it's only an alpha release. (Famous last words. :-) Question: are the intricate semantics of Py_FileSystemDefaultEncoding sufficiently documented (e.g. the fact that it must be malloc()'ed storage)? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449815&group_id=5470 From noreply@sourceforge.net Wed Sep 5 18:28:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 10:28:14 -0700 Subject: [Patches] [ python-Patches-453627 ] UnixWare 7.x port for Python 2.2 Message-ID: Patches item #453627, was opened at 2001-08-20 22:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Martin v. Lцwis (loewis) Summary: UnixWare 7.x port for Python 2.2 Initial Comment: The attached set of patches provide work-a-rounds for two know UnixWare 7.x bugs and fixes other problems related to the UnixWare 7.x port of Python. The patch file names and a description of the patches are: 1. uw7_pyconfig.patch This patch changes pyconfig.h.in to define the following macros when compiling on a UnixWare 7.x system: SCO_ATAN2_BUG, SCO_ACCEPT_BUG, and STRICT_SYSV_CURSES. 2. uw7_math.patch This patch adds code to Modules/mathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 3. uw7_cmath.patch This patch adds code to Modules/cmathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 4. uw7_complex.patch This patch adds code to Objects/complexobject.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 5. uw7_socket.patch This patch adds code to Modules/socketmodule.c to work around a bug in the SCO UnixWare 7.X accept() imple- mentation. This code is only compiled if the macro, SCO_ACCEPT_BUG, is defined. The patch also changed the code so that the accept call is restarted if it was interrupted. 6. uw7_regrtest.patch This patch adds a list of tests that are expected to be skipped for UnixWare 7.x systems. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 10:28 Message: Logged In: YES user_id=6380 Excuse me for butting in. I'm guessing that, indeed, somehow starting threads runs a signal handler that interrupts system calls on UW. I would like to note that to a C programmer, it makes sense to always retry after a SIGINT: if the signal doesn't kill the program outright, the EINTR means that the signal handler ran and returned, and this typically means that it decided *not* to kill the program (the C convention is to longjmp out). It would really be better if the system call continued on its own accord, but for various reasons (the "80%" argument has been mentioned) it doesn't. But in the context of Python, a SIGINT that is intended to "kill" (well, raise an asynchronous KeyboardInterrupt exception) cannot use longjmp(), and our convention is that interrupted system calls must call PyOS_InterruptOccurred() before restarting. Unfortunately, this isn't done consistently. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 10:04 Message: Logged In: YES user_id=21627 Of course: blocking calls are interupted by signals. That is the sole purpose of SIGINT: To interrupt what the program currently does. Python must not ignore this, but immediately return to the caller - most likely, the user meant to interrupt the Python program. If the application then choses to retry on EINTR - that's a different story. Are you saying that on UnixWare, a call to accept immediately returns even without any signals being sent, in the presence of threads? That sounds broken. Where is that documented? On the distutils patches: I'm no distutils expert, so I don't feel qualified to review the patches (IOW, it would take some considerable time to review them which I don't have). Since all distutils experts have loads of patches to review, it may take some time to find a reviewer. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-09-05 08:49 Message: Logged In: YES user_id=8500 Any blocking I/O call is subject to being interruped by a signal. In particular, on Unixware when running threads, the first call to accept immediately returns because of an interrupted call. Therefore the loop to retry the interrupted call. On a side note, (IMHO) the code that calls an I/O operation that can block should check for an error code of EINTR and retry the operation if it was interrupted instead of returning an exception because of the interruption. That is, of course, my own opinion. BTW: is anyone looking at the distutils and setup.py changes I submitted [Patch # 454041] ? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:55 Message: Logged In: YES user_id=21627 Thanks for your patches. I've applied all of them except for uw7_socket_2.patch. Why do you add an again loop around the accept(2) call? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:46 Message: Logged In: YES user_id=21627 Accepted uw7_cmath.patch, uw7_complex.patch, uw7_math.patch, uw7_pyconfig.patch as cmathmodule.c 2.25, mathmodule.c 2.64, complexobject.c 2.43, and pyconfig.h.in 1.6. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:39 Message: Logged In: YES user_id=21627 Accepted uw7_regrtest.patch as regrtest.py 1.46. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-21 15:51 Message: Logged In: YES user_id=8500 I have uploaded an updated patch for Modules/socketmodule.py named uw7_socket_2.patch. Please use this instead of uw7_socket..patch. The original patch backed out 2 changes made to socketmodule.c since I got my copy from the CVS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 From noreply@sourceforge.net Wed Sep 5 19:44:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 11:44:43 -0700 Subject: [Patches] [ python-Patches-458701 ] Patch to zipfile.py for Java Message-ID: Patches item #458701, was opened at 2001-09-05 05:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458701&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: James C. Ahlstrom (ahlstromjc) Assigned to: Finn Bock (bckfnn) Summary: Patch to zipfile.py for Java Initial Comment: This is an alternative to the zipfile.py patch 442128 by Finn Bock (bckfnn). Java fails to read zip files created by zipfile.py because it requires a 4 byte header for the CRC and file sizes which are written after the file data, and the zip specification does not have this header. This patch will unset flag 0x08 (flags will be zero) to indicate the CRC and file sizes do NOT follow the file data, and will seek() backwards to write them in the file header. This is consistent with the zip format and eliminates the problem with Java. The patch has been tested with WinZip.exe on Windows, is very simple, and hopefully will make it into 2.2. Jim Ahlstrom ---------------------------------------------------------------------- >Comment By: Finn Bock (bckfnn) Date: 2001-09-05 11:44 Message: Logged In: YES user_id=4201 Zipfiles created by this patch can also read by java and the solution is far better than #442128. Checking in zipfile.py revision: 1.16; ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 05:59 Message: Logged In: YES user_id=6380 Finn, if this works for you, please check it in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458701&group_id=5470 From noreply@sourceforge.net Wed Sep 5 19:48:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 11:48:24 -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: Closed >Resolution: Rejected 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(). ---------------------------------------------------------------------- >Comment By: Finn Bock (bckfnn) Date: 2001-09-05 11:48 Message: Logged In: YES user_id=4201 This patch is rejected in favor of Jim's patch (#458701), which is far better. ---------------------------------------------------------------------- Comment By: James C. Ahlstrom (ahlstromjc) Date: 2001-09-05 05:37 Message: Logged In: YES user_id=64929 Currently, zipfile.py writes flag 0x08 to indicate that the CRC and file sizes follow the file data. It writes the file header with zero CRC and file sizes, writes the file data, and then writes three longs. Java seems to require a 4 byte header, then three longs. The pkware appnote.txt document requires just three longs with no header. I am unable to find a justification for the header, and I do not want to be inconsistent with the zip specification. Therefore I oppose this patch. Instead I propose a new patch. Zipfile.py will write flags 0x00, the file header, then the file data. Then it will seek backwards and write the correct CRC and file sizes in the file header, and then seek to the end of the file data. Flag 0x08 is NOT set, and the correct CRC and file sizes are in the header. This satisfies the zip specification and Java at the minor cost of two seek()'s and a tell(). I will submit this as a new patch as I can't seem to attach it to this one. Jim Ahlstrom ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=442128&group_id=5470 From noreply@sourceforge.net Wed Sep 5 20:20:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 12:20:08 -0700 Subject: [Patches] [ python-Patches-454041 ] Setup and distutils changes. Message-ID: Patches item #454041, was opened at 2001-08-21 18:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454041&group_id=5470 Category: distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Billy G. Allie (ballie01) >Assigned to: A.M. Kuchling (akuchling) Summary: Setup and distutils changes. Initial Comment: The attached patches change setup.py and the distutils compiler modules to allow dynamically loaded modules that are built against shared libraries to be built with the appropriate runtime library search directories set as needed. The attached patches and a description of what they do follows: 1. uw7_setup.patch This patch modifies setup.py to: * have find_library_file() search for the directory where a given library file is lo- cated, and returns a tuple '(dirs, rt_dirs)' where 'dirs' is a possibly-empty list of additional directories and 'rt_dirs' is a possibly-empty list of directories to be searched at runtime. If the file couldn't be found at all, None is returned. * use the modified find_library_file() to set the runtime_library_dirs parameter to Extension() method so that the appropriate linker option to embed the runtime library directory search path in the dynamically load module will be gener- ated. Whether or not the option is generated is controlled by the distutils compiler class. * add the curses and terminfo library to the libraries searched when the readline module is built. 2. uw7_ccompiler.patch This patch modifies Lib/distutils/ccompiler.py as follows: * The runtime_library_dir_option() method was change so that it returns an empty list instead of raising the NotImplemented exception. This was done so that a reasonable default will be used for those systems that do not need to specify a runtime search path for libraries. It is possible that setup.py will determine that a directory will be needed to be searched at runtime, even if a particular system or compiler do not support or need to have a runtime directory search patch defined. In this case, the compiler class should return an empty list when runtime_library_dir_option() is called. * Changed how runtime_library_dir_option() is called. Instead of calling it once for each directory in the runtime_library_dirs list, it is called once, passing it the entire list of directories to be searched at runtime. This pushes the decision of how to format the option to the system specific compiler class. Some systems (UnixWare, for example) only allow a single -R option to be specified, followed by a colon (:) separated list of directories to search. * Added support for a new compiler class, USLCcompiler. This compiler class supports Unix System Labs style C compilers. UnixWare uses this compiler class. Sun's native compiler for Solaris use to be based on the Unix System Lab's C compiler. I don't know if this is still the case. 3. uw7_unixccompiler.patch This patch modifies Lib/distutils/unixccompier.py so that is no longer defines it's own version of runtime_library_dir_option(). Most system's that used this compiler do not need to specify a runtime directory search path via an ld option. 4. uw7_msvccompiler.patch and uw7_mwerkscompiler.patch These patches update Lib/distutils/msvccompiler.py and Lib/distutils/mwerkscompiler.py so that being passed something in runtime_library_dirs does not raise an exception. They will now print a warning message if runtime_library_dirs is not empty or None. They will return an empty list if runtime_library_dir_option() is called. 5. uw7_uslccompiler.patch This patch adds the USLCCompiler class. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-22 21:46 Message: Logged In: YES user_id=8500 A new version of the setup.py patch, uw7_setup_2.patch has been uploaded. This takes info account the recent change to setup.py in regards to the bsddb module. Please use this patch in place of uw7_setup_2.patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454041&group_id=5470 From noreply@sourceforge.net Wed Sep 5 20:20:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 12:20:37 -0700 Subject: [Patches] [ python-Patches-453914 ] bad example in pickle documentation Message-ID: Patches item #453914, was opened at 2001-08-21 12:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453914&group_id=5470 Category: documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tomas Styblo (tripiecz) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: bad example in pickle documentation Initial Comment: There's a bad example of pickle usage in the library reference. Some very hard to find bugs could emerge from that code. Here is the __getstate__() method from the example: 
def __getstate__(self):
    odict = self.__dict__
    del odict['fh']
    return odict
This code corrupts data of the instance that is being pickled, making it silently no longer usable. There's no warranty that pickled instances will not be used after they are pickled. The code should rather make a shallow copy of the self.__dict__ and then delete the filehandle from the copy. This makes the instance usable even after it's pickled. The appended patch modifies 'Doc/lib/libpickle.tex'. It's based on current CVS version of that file. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453914&group_id=5470 From noreply@sourceforge.net Wed Sep 5 20:24:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 12:24:22 -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 (Lib) Group: None Status: Open Resolution: None Priority: 3 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: Guido van Rossum (gvanrossum) Date: 2001-09-05 12:24 Message: Logged In: YES user_id=6380 OK, let's reject it. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-13 14:10 Message: Logged In: YES user_id=21627 In the current form, the patch looks much better, although I'm still somewhat concerned about the cheating. The obvious difference is that it will always return PATH_MAX but there may be slight differences in the interpretations of the other fields as well. Most people probably would not care and would prefer to have a unified interface over one that exposes the differences, so I'm +0 on this patch. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-13 14:03 Message: Logged In: YES user_id=21627 In a private message, Thomas writes: ,---- | There's a past-o in the patch I sent which may have | caused your confusion. I use statfs() to emulate statvfs() | and fstatfs() to emulate fstatvfs(). You will have realized | that the POSIX functions statvfs() and fstatvfs() take | precedence if they are available, the other calls will not | be used then. I think that's a reasonable compromise; in | fact, /F does something similar for MS Windows (patch | #410547). | | How can I update the patch in this database? `---- The new patch was attached with this comment. ---------------------------------------------------------------------- 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 Wed Sep 5 20:30:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 12:30:12 -0700 Subject: [Patches] [ python-Patches-457713 ] Allow "itemconfigure" for Listboxes. Message-ID: Patches item #457713, was opened at 2001-09-02 03:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=457713&group_id=5470 Category: Tkinter Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Joseph A Knapka (jknapka) Assigned to: Guido van Rossum (gvanrossum) >Summary: Allow "itemconfigure" for Listboxes. Initial Comment: This patch allows foreground and background colors to be configured for individual items in a Listbox. The "itemconfigure" and "itemcget" code from Canvas is pulled out into a new mixin class which is inherited by Canvas and Listbox. It seems to "just work", unless I am neglecting some subtle aspect of Tkinter code. The patch is against the Python 2.1.1 Tkinter.py file. (Note: this patch addresses #426880, for which someone neglected to provide code. I am not, incidentally, the individual who submitted the earlier patch :-) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 12:30 Message: Logged In: YES user_id=6380 OK, I've copied itemconfig from Canvas to Listbox. Enjoy! ---------------------------------------------------------------------- Comment By: Joseph A Knapka (jknapka) Date: 2001-09-02 15:15 Message: Logged In: YES user_id=118570 Well, in that case the easy thing would be to just copy the definition of the "itemcget" method out of Canvas and paste it into Listbox. Hardly worth producing a patch file for that. I think it is desirable to have both itemconfig and itemcget, because not doing so violates the expectations of those familiar with Tk. It's a small detail, but attention to detail is what makes Python great, right? (OK, among other things :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-02 14:24 Message: Logged In: YES user_id=6380 No, I just meant that I hate doing double work myself, and unless your patch provides something extra, I'm reluctant to put more effort in. Given the sheer size of Tkinter.py, one little bit of code sharing doesn't make much of a difference. ---------------------------------------------------------------------- Comment By: Joseph A Knapka (jknapka) Date: 2001-09-02 09:25 Message: Logged In: YES user_id=118570 Err... are you saying you'd prefer to have the item configuration code duplicated in Canvas and Listbox? The only difference between this patch and the bug 457487 one is that that one uses cut+paste, and this one uses inheritance. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-02 06:48 Message: Logged In: YES user_id=6380 Hm, I just checked in yet another contributed patch that added Listbox.itemconfigure, but without refactoring and without itemcget. Would you mind integrating that into your patch? See bug #457487. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=457713&group_id=5470 From noreply@sourceforge.net Wed Sep 5 20:36:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 12:36:29 -0700 Subject: [Patches] [ python-Patches-453691 ] CGI: NEW: methods getfirst(), getlist() Message-ID: Patches item #453691, was opened at 2001-08-21 04:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453691&group_id=5470 Category: Library (Lib) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Tomas Styblo (tripiecz) Assigned to: Guido van Rossum (gvanrossum) Summary: CGI: NEW: methods getfirst(), getlist() Initial Comment: This is updated version of my cgi.py patch #452174. The attached file 'pycgi.patch' modifies 'Doc/lib/libcgi.tex' and 'Lib/cgi.py'. It's based on current CVS. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 12:36 Message: Logged In: YES user_id=6380 Accepted. Waiting for SF CVS to come back online. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453691&group_id=5470 From noreply@sourceforge.net Wed Sep 5 20:46:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 12:46:14 -0700 Subject: [Patches] [ python-Patches-453691 ] CGI: NEW: methods getfirst(), getlist() Message-ID: Patches item #453691, was opened at 2001-08-21 04:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453691&group_id=5470 >Category: Documentation Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Tomas Styblo (tripiecz) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: CGI: NEW: methods getfirst(), getlist() Initial Comment: This is updated version of my cgi.py patch #452174. The attached file 'pycgi.patch' modifies 'Doc/lib/libcgi.tex' and 'Lib/cgi.py'. It's based on current CVS. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 12:46 Message: Logged In: YES user_id=6380 Checked in as cgi.py rev 1.67. Assigned to Fred for documentation review and checkin. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 12:36 Message: Logged In: YES user_id=6380 Accepted. Waiting for SF CVS to come back online. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453691&group_id=5470 From noreply@sourceforge.net Wed Sep 5 21:58:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 13:58:47 -0700 Subject: [Patches] [ python-Patches-458898 ] --python-build for install Message-ID: Patches item #458898, was opened at 2001-09-05 13:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458898&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: A.M. Kuchling (akuchling) Summary: --python-build for install Initial Comment: Sometimes, being able to install python tools without having python installed is desirable. When building an RPM package of python, for example, one may want to build/install IDLE as well, including it in a subpackage. Indeed, we're doing this with a couple of python tools here at Conectiva. Unfortunately, we have a egg-chicken problem when doing this. You need python installed in your system before you install tools. This limitation may be observed in the file Lib/distutils/sysconfig.py. It looks for Makefile in the final installation directory, for example. This patch adds a new option to dist-utils' install command: --python-build. When used, python will look for these files in the python build directory specified trough the option. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458898&group_id=5470 From noreply@sourceforge.net Wed Sep 5 22:33:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 14:33:23 -0700 Subject: [Patches] [ python-Patches-453627 ] UnixWare 7.x port for Python 2.2 Message-ID: Patches item #453627, was opened at 2001-08-20 22:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Martin v. Lцwis (loewis) Summary: UnixWare 7.x port for Python 2.2 Initial Comment: The attached set of patches provide work-a-rounds for two know UnixWare 7.x bugs and fixes other problems related to the UnixWare 7.x port of Python. The patch file names and a description of the patches are: 1. uw7_pyconfig.patch This patch changes pyconfig.h.in to define the following macros when compiling on a UnixWare 7.x system: SCO_ATAN2_BUG, SCO_ACCEPT_BUG, and STRICT_SYSV_CURSES. 2. uw7_math.patch This patch adds code to Modules/mathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 3. uw7_cmath.patch This patch adds code to Modules/cmathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 4. uw7_complex.patch This patch adds code to Objects/complexobject.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 5. uw7_socket.patch This patch adds code to Modules/socketmodule.c to work around a bug in the SCO UnixWare 7.X accept() imple- mentation. This code is only compiled if the macro, SCO_ACCEPT_BUG, is defined. The patch also changed the code so that the accept call is restarted if it was interrupted. 6. uw7_regrtest.patch This patch adds a list of tests that are expected to be skipped for UnixWare 7.x systems. ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2001-09-05 14:33 Message: Logged In: YES user_id=8500 What I am saying that without the patch the thread test fails because accept() returns with an error number of EINTR. What is probably happening (guesswork here) is that one thread started an accept() call and the main program forked to create another process to act as a client to the main program's server. A signal was generated during this process that interrupted the accept() call, which returned to the caller with errno set to EINTR. The following text comes from fork(2) manual page: ----------------------- Notices Considerations for threads programming Threads in the creating process are unaffected by these system calls except possibly for the error indication EINTR in the creating process. ------------------------ I forget what the exact test that failed is, but I can replicate the failure easily enough. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 10:28 Message: Logged In: YES user_id=6380 Excuse me for butting in. I'm guessing that, indeed, somehow starting threads runs a signal handler that interrupts system calls on UW. I would like to note that to a C programmer, it makes sense to always retry after a SIGINT: if the signal doesn't kill the program outright, the EINTR means that the signal handler ran and returned, and this typically means that it decided *not* to kill the program (the C convention is to longjmp out). It would really be better if the system call continued on its own accord, but for various reasons (the "80%" argument has been mentioned) it doesn't. But in the context of Python, a SIGINT that is intended to "kill" (well, raise an asynchronous KeyboardInterrupt exception) cannot use longjmp(), and our convention is that interrupted system calls must call PyOS_InterruptOccurred() before restarting. Unfortunately, this isn't done consistently. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 10:04 Message: Logged In: YES user_id=21627 Of course: blocking calls are interupted by signals. That is the sole purpose of SIGINT: To interrupt what the program currently does. Python must not ignore this, but immediately return to the caller - most likely, the user meant to interrupt the Python program. If the application then choses to retry on EINTR - that's a different story. Are you saying that on UnixWare, a call to accept immediately returns even without any signals being sent, in the presence of threads? That sounds broken. Where is that documented? On the distutils patches: I'm no distutils expert, so I don't feel qualified to review the patches (IOW, it would take some considerable time to review them which I don't have). Since all distutils experts have loads of patches to review, it may take some time to find a reviewer. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-09-05 08:49 Message: Logged In: YES user_id=8500 Any blocking I/O call is subject to being interruped by a signal. In particular, on Unixware when running threads, the first call to accept immediately returns because of an interrupted call. Therefore the loop to retry the interrupted call. On a side note, (IMHO) the code that calls an I/O operation that can block should check for an error code of EINTR and retry the operation if it was interrupted instead of returning an exception because of the interruption. That is, of course, my own opinion. BTW: is anyone looking at the distutils and setup.py changes I submitted [Patch # 454041] ? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:55 Message: Logged In: YES user_id=21627 Thanks for your patches. I've applied all of them except for uw7_socket_2.patch. Why do you add an again loop around the accept(2) call? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:46 Message: Logged In: YES user_id=21627 Accepted uw7_cmath.patch, uw7_complex.patch, uw7_math.patch, uw7_pyconfig.patch as cmathmodule.c 2.25, mathmodule.c 2.64, complexobject.c 2.43, and pyconfig.h.in 1.6. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:39 Message: Logged In: YES user_id=21627 Accepted uw7_regrtest.patch as regrtest.py 1.46. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-21 15:51 Message: Logged In: YES user_id=8500 I have uploaded an updated patch for Modules/socketmodule.py named uw7_socket_2.patch. Please use this instead of uw7_socket..patch. The original patch backed out 2 changes made to socketmodule.c since I got my copy from the CVS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 From noreply@sourceforge.net Wed Sep 5 22:36:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 14:36:44 -0700 Subject: [Patches] [ python-Patches-453627 ] UnixWare 7.x port for Python 2.2 Message-ID: Patches item #453627, was opened at 2001-08-20 22:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Martin v. Lцwis (loewis) Summary: UnixWare 7.x port for Python 2.2 Initial Comment: The attached set of patches provide work-a-rounds for two know UnixWare 7.x bugs and fixes other problems related to the UnixWare 7.x port of Python. The patch file names and a description of the patches are: 1. uw7_pyconfig.patch This patch changes pyconfig.h.in to define the following macros when compiling on a UnixWare 7.x system: SCO_ATAN2_BUG, SCO_ACCEPT_BUG, and STRICT_SYSV_CURSES. 2. uw7_math.patch This patch adds code to Modules/mathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 3. uw7_cmath.patch This patch adds code to Modules/cmathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 4. uw7_complex.patch This patch adds code to Objects/complexobject.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 5. uw7_socket.patch This patch adds code to Modules/socketmodule.c to work around a bug in the SCO UnixWare 7.X accept() imple- mentation. This code is only compiled if the macro, SCO_ACCEPT_BUG, is defined. The patch also changed the code so that the accept call is restarted if it was interrupted. 6. uw7_regrtest.patch This patch adds a list of tests that are expected to be skipped for UnixWare 7.x systems. ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2001-09-05 14:36 Message: Logged In: YES user_id=8500 What I am saying that without the patch the thread test fails because accept() returns with an error number of EINTR. What is probably happening (guesswork here) is that one thread started an accept() call and the main program forked to create another process to act as a client to the main program's server. A signal was generated during this process that interrupted the accept() call, which returned to the caller with errno set to EINTR. The following text comes from fork(2) manual page: ----------------------- Notices Considerations for threads programming Threads in the creating process are unaffected by these system calls except possibly for the error indication EINTR in the creating process. ------------------------ I forget what the exact test that failed is, but I can replicate the failure easily enough. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-09-05 14:33 Message: Logged In: YES user_id=8500 What I am saying that without the patch the thread test fails because accept() returns with an error number of EINTR. What is probably happening (guesswork here) is that one thread started an accept() call and the main program forked to create another process to act as a client to the main program's server. A signal was generated during this process that interrupted the accept() call, which returned to the caller with errno set to EINTR. The following text comes from fork(2) manual page: ----------------------- Notices Considerations for threads programming Threads in the creating process are unaffected by these system calls except possibly for the error indication EINTR in the creating process. ------------------------ I forget what the exact test that failed is, but I can replicate the failure easily enough. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 10:28 Message: Logged In: YES user_id=6380 Excuse me for butting in. I'm guessing that, indeed, somehow starting threads runs a signal handler that interrupts system calls on UW. I would like to note that to a C programmer, it makes sense to always retry after a SIGINT: if the signal doesn't kill the program outright, the EINTR means that the signal handler ran and returned, and this typically means that it decided *not* to kill the program (the C convention is to longjmp out). It would really be better if the system call continued on its own accord, but for various reasons (the "80%" argument has been mentioned) it doesn't. But in the context of Python, a SIGINT that is intended to "kill" (well, raise an asynchronous KeyboardInterrupt exception) cannot use longjmp(), and our convention is that interrupted system calls must call PyOS_InterruptOccurred() before restarting. Unfortunately, this isn't done consistently. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 10:04 Message: Logged In: YES user_id=21627 Of course: blocking calls are interupted by signals. That is the sole purpose of SIGINT: To interrupt what the program currently does. Python must not ignore this, but immediately return to the caller - most likely, the user meant to interrupt the Python program. If the application then choses to retry on EINTR - that's a different story. Are you saying that on UnixWare, a call to accept immediately returns even without any signals being sent, in the presence of threads? That sounds broken. Where is that documented? On the distutils patches: I'm no distutils expert, so I don't feel qualified to review the patches (IOW, it would take some considerable time to review them which I don't have). Since all distutils experts have loads of patches to review, it may take some time to find a reviewer. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-09-05 08:49 Message: Logged In: YES user_id=8500 Any blocking I/O call is subject to being interruped by a signal. In particular, on Unixware when running threads, the first call to accept immediately returns because of an interrupted call. Therefore the loop to retry the interrupted call. On a side note, (IMHO) the code that calls an I/O operation that can block should check for an error code of EINTR and retry the operation if it was interrupted instead of returning an exception because of the interruption. That is, of course, my own opinion. BTW: is anyone looking at the distutils and setup.py changes I submitted [Patch # 454041] ? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:55 Message: Logged In: YES user_id=21627 Thanks for your patches. I've applied all of them except for uw7_socket_2.patch. Why do you add an again loop around the accept(2) call? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:46 Message: Logged In: YES user_id=21627 Accepted uw7_cmath.patch, uw7_complex.patch, uw7_math.patch, uw7_pyconfig.patch as cmathmodule.c 2.25, mathmodule.c 2.64, complexobject.c 2.43, and pyconfig.h.in 1.6. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:39 Message: Logged In: YES user_id=21627 Accepted uw7_regrtest.patch as regrtest.py 1.46. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-21 15:51 Message: Logged In: YES user_id=8500 I have uploaded an updated patch for Modules/socketmodule.py named uw7_socket_2.patch. Please use this instead of uw7_socket..patch. The original patch backed out 2 changes made to socketmodule.c since I got my copy from the CVS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 From noreply@sourceforge.net Wed Sep 5 22:40:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 14:40:44 -0700 Subject: [Patches] [ python-Patches-453627 ] UnixWare 7.x port for Python 2.2 Message-ID: Patches item #453627, was opened at 2001-08-20 22:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Martin v. Lцwis (loewis) Summary: UnixWare 7.x port for Python 2.2 Initial Comment: The attached set of patches provide work-a-rounds for two know UnixWare 7.x bugs and fixes other problems related to the UnixWare 7.x port of Python. The patch file names and a description of the patches are: 1. uw7_pyconfig.patch This patch changes pyconfig.h.in to define the following macros when compiling on a UnixWare 7.x system: SCO_ATAN2_BUG, SCO_ACCEPT_BUG, and STRICT_SYSV_CURSES. 2. uw7_math.patch This patch adds code to Modules/mathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 3. uw7_cmath.patch This patch adds code to Modules/cmathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 4. uw7_complex.patch This patch adds code to Objects/complexobject.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 5. uw7_socket.patch This patch adds code to Modules/socketmodule.c to work around a bug in the SCO UnixWare 7.X accept() imple- mentation. This code is only compiled if the macro, SCO_ACCEPT_BUG, is defined. The patch also changed the code so that the accept call is restarted if it was interrupted. 6. uw7_regrtest.patch This patch adds a list of tests that are expected to be skipped for UnixWare 7.x systems. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 14:40 Message: Logged In: YES user_id=6380 OK, so it looks like they are using signal() as a communications mechanism. Then I'm not sure if it's worth fixing the thread test: the accept() call just happens to be the call that's being interrupted by thread creation in the test, but in a real application, *any* I/O system call can return an error with EINTR set, and in general this will cause Python application failures. Maybe it's better to disable threads on UW... ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-09-05 14:36 Message: Logged In: YES user_id=8500 What I am saying that without the patch the thread test fails because accept() returns with an error number of EINTR. What is probably happening (guesswork here) is that one thread started an accept() call and the main program forked to create another process to act as a client to the main program's server. A signal was generated during this process that interrupted the accept() call, which returned to the caller with errno set to EINTR. The following text comes from fork(2) manual page: ----------------------- Notices Considerations for threads programming Threads in the creating process are unaffected by these system calls except possibly for the error indication EINTR in the creating process. ------------------------ I forget what the exact test that failed is, but I can replicate the failure easily enough. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-09-05 14:33 Message: Logged In: YES user_id=8500 What I am saying that without the patch the thread test fails because accept() returns with an error number of EINTR. What is probably happening (guesswork here) is that one thread started an accept() call and the main program forked to create another process to act as a client to the main program's server. A signal was generated during this process that interrupted the accept() call, which returned to the caller with errno set to EINTR. The following text comes from fork(2) manual page: ----------------------- Notices Considerations for threads programming Threads in the creating process are unaffected by these system calls except possibly for the error indication EINTR in the creating process. ------------------------ I forget what the exact test that failed is, but I can replicate the failure easily enough. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 10:28 Message: Logged In: YES user_id=6380 Excuse me for butting in. I'm guessing that, indeed, somehow starting threads runs a signal handler that interrupts system calls on UW. I would like to note that to a C programmer, it makes sense to always retry after a SIGINT: if the signal doesn't kill the program outright, the EINTR means that the signal handler ran and returned, and this typically means that it decided *not* to kill the program (the C convention is to longjmp out). It would really be better if the system call continued on its own accord, but for various reasons (the "80%" argument has been mentioned) it doesn't. But in the context of Python, a SIGINT that is intended to "kill" (well, raise an asynchronous KeyboardInterrupt exception) cannot use longjmp(), and our convention is that interrupted system calls must call PyOS_InterruptOccurred() before restarting. Unfortunately, this isn't done consistently. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 10:04 Message: Logged In: YES user_id=21627 Of course: blocking calls are interupted by signals. That is the sole purpose of SIGINT: To interrupt what the program currently does. Python must not ignore this, but immediately return to the caller - most likely, the user meant to interrupt the Python program. If the application then choses to retry on EINTR - that's a different story. Are you saying that on UnixWare, a call to accept immediately returns even without any signals being sent, in the presence of threads? That sounds broken. Where is that documented? On the distutils patches: I'm no distutils expert, so I don't feel qualified to review the patches (IOW, it would take some considerable time to review them which I don't have). Since all distutils experts have loads of patches to review, it may take some time to find a reviewer. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-09-05 08:49 Message: Logged In: YES user_id=8500 Any blocking I/O call is subject to being interruped by a signal. In particular, on Unixware when running threads, the first call to accept immediately returns because of an interrupted call. Therefore the loop to retry the interrupted call. On a side note, (IMHO) the code that calls an I/O operation that can block should check for an error code of EINTR and retry the operation if it was interrupted instead of returning an exception because of the interruption. That is, of course, my own opinion. BTW: is anyone looking at the distutils and setup.py changes I submitted [Patch # 454041] ? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:55 Message: Logged In: YES user_id=21627 Thanks for your patches. I've applied all of them except for uw7_socket_2.patch. Why do you add an again loop around the accept(2) call? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:46 Message: Logged In: YES user_id=21627 Accepted uw7_cmath.patch, uw7_complex.patch, uw7_math.patch, uw7_pyconfig.patch as cmathmodule.c 2.25, mathmodule.c 2.64, complexobject.c 2.43, and pyconfig.h.in 1.6. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:39 Message: Logged In: YES user_id=21627 Accepted uw7_regrtest.patch as regrtest.py 1.46. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-21 15:51 Message: Logged In: YES user_id=8500 I have uploaded an updated patch for Modules/socketmodule.py named uw7_socket_2.patch. Please use this instead of uw7_socket..patch. The original patch backed out 2 changes made to socketmodule.c since I got my copy from the CVS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 From noreply@sourceforge.net Thu Sep 6 04:30:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 20:30:12 -0700 Subject: [Patches] [ python-Patches-453627 ] UnixWare 7.x port for Python 2.2 Message-ID: Patches item #453627, was opened at 2001-08-20 22:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Martin v. Lцwis (loewis) Summary: UnixWare 7.x port for Python 2.2 Initial Comment: The attached set of patches provide work-a-rounds for two know UnixWare 7.x bugs and fixes other problems related to the UnixWare 7.x port of Python. The patch file names and a description of the patches are: 1. uw7_pyconfig.patch This patch changes pyconfig.h.in to define the following macros when compiling on a UnixWare 7.x system: SCO_ATAN2_BUG, SCO_ACCEPT_BUG, and STRICT_SYSV_CURSES. 2. uw7_math.patch This patch adds code to Modules/mathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 3. uw7_cmath.patch This patch adds code to Modules/cmathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 4. uw7_complex.patch This patch adds code to Objects/complexobject.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 5. uw7_socket.patch This patch adds code to Modules/socketmodule.c to work around a bug in the SCO UnixWare 7.X accept() imple- mentation. This code is only compiled if the macro, SCO_ACCEPT_BUG, is defined. The patch also changed the code so that the accept call is restarted if it was interrupted. 6. uw7_regrtest.patch This patch adds a list of tests that are expected to be skipped for UnixWare 7.x systems. ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2001-09-05 20:30 Message: Logged In: YES user_id=8500 I have uploaded a new patch, uw7_atan2fix.patch, that changes the sco_atan2() routine so that negitive zero as the first argument is handled correctly. The previous version did not handle -0 correctly (as pointed out by Tim Peters). This patch assumes that the previous patches have been applied. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 14:40 Message: Logged In: YES user_id=6380 OK, so it looks like they are using signal() as a communications mechanism. Then I'm not sure if it's worth fixing the thread test: the accept() call just happens to be the call that's being interrupted by thread creation in the test, but in a real application, *any* I/O system call can return an error with EINTR set, and in general this will cause Python application failures. Maybe it's better to disable threads on UW... ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-09-05 14:36 Message: Logged In: YES user_id=8500 What I am saying that without the patch the thread test fails because accept() returns with an error number of EINTR. What is probably happening (guesswork here) is that one thread started an accept() call and the main program forked to create another process to act as a client to the main program's server. A signal was generated during this process that interrupted the accept() call, which returned to the caller with errno set to EINTR. The following text comes from fork(2) manual page: ----------------------- Notices Considerations for threads programming Threads in the creating process are unaffected by these system calls except possibly for the error indication EINTR in the creating process. ------------------------ I forget what the exact test that failed is, but I can replicate the failure easily enough. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-09-05 14:33 Message: Logged In: YES user_id=8500 What I am saying that without the patch the thread test fails because accept() returns with an error number of EINTR. What is probably happening (guesswork here) is that one thread started an accept() call and the main program forked to create another process to act as a client to the main program's server. A signal was generated during this process that interrupted the accept() call, which returned to the caller with errno set to EINTR. The following text comes from fork(2) manual page: ----------------------- Notices Considerations for threads programming Threads in the creating process are unaffected by these system calls except possibly for the error indication EINTR in the creating process. ------------------------ I forget what the exact test that failed is, but I can replicate the failure easily enough. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 10:28 Message: Logged In: YES user_id=6380 Excuse me for butting in. I'm guessing that, indeed, somehow starting threads runs a signal handler that interrupts system calls on UW. I would like to note that to a C programmer, it makes sense to always retry after a SIGINT: if the signal doesn't kill the program outright, the EINTR means that the signal handler ran and returned, and this typically means that it decided *not* to kill the program (the C convention is to longjmp out). It would really be better if the system call continued on its own accord, but for various reasons (the "80%" argument has been mentioned) it doesn't. But in the context of Python, a SIGINT that is intended to "kill" (well, raise an asynchronous KeyboardInterrupt exception) cannot use longjmp(), and our convention is that interrupted system calls must call PyOS_InterruptOccurred() before restarting. Unfortunately, this isn't done consistently. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 10:04 Message: Logged In: YES user_id=21627 Of course: blocking calls are interupted by signals. That is the sole purpose of SIGINT: To interrupt what the program currently does. Python must not ignore this, but immediately return to the caller - most likely, the user meant to interrupt the Python program. If the application then choses to retry on EINTR - that's a different story. Are you saying that on UnixWare, a call to accept immediately returns even without any signals being sent, in the presence of threads? That sounds broken. Where is that documented? On the distutils patches: I'm no distutils expert, so I don't feel qualified to review the patches (IOW, it would take some considerable time to review them which I don't have). Since all distutils experts have loads of patches to review, it may take some time to find a reviewer. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-09-05 08:49 Message: Logged In: YES user_id=8500 Any blocking I/O call is subject to being interruped by a signal. In particular, on Unixware when running threads, the first call to accept immediately returns because of an interrupted call. Therefore the loop to retry the interrupted call. On a side note, (IMHO) the code that calls an I/O operation that can block should check for an error code of EINTR and retry the operation if it was interrupted instead of returning an exception because of the interruption. That is, of course, my own opinion. BTW: is anyone looking at the distutils and setup.py changes I submitted [Patch # 454041] ? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:55 Message: Logged In: YES user_id=21627 Thanks for your patches. I've applied all of them except for uw7_socket_2.patch. Why do you add an again loop around the accept(2) call? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:46 Message: Logged In: YES user_id=21627 Accepted uw7_cmath.patch, uw7_complex.patch, uw7_math.patch, uw7_pyconfig.patch as cmathmodule.c 2.25, mathmodule.c 2.64, complexobject.c 2.43, and pyconfig.h.in 1.6. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:39 Message: Logged In: YES user_id=21627 Accepted uw7_regrtest.patch as regrtest.py 1.46. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-21 15:51 Message: Logged In: YES user_id=8500 I have uploaded an updated patch for Modules/socketmodule.py named uw7_socket_2.patch. Please use this instead of uw7_socket..patch. The original patch backed out 2 changes made to socketmodule.c since I got my copy from the CVS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 From noreply@sourceforge.net Thu Sep 6 05:15:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Sep 2001 21:15:50 -0700 Subject: [Patches] [ python-Patches-453627 ] UnixWare 7.x port for Python 2.2 Message-ID: Patches item #453627, was opened at 2001-08-20 22:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Martin v. Lцwis (loewis) Summary: UnixWare 7.x port for Python 2.2 Initial Comment: The attached set of patches provide work-a-rounds for two know UnixWare 7.x bugs and fixes other problems related to the UnixWare 7.x port of Python. The patch file names and a description of the patches are: 1. uw7_pyconfig.patch This patch changes pyconfig.h.in to define the following macros when compiling on a UnixWare 7.x system: SCO_ATAN2_BUG, SCO_ACCEPT_BUG, and STRICT_SYSV_CURSES. 2. uw7_math.patch This patch adds code to Modules/mathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 3. uw7_cmath.patch This patch adds code to Modules/cmathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 4. uw7_complex.patch This patch adds code to Objects/complexobject.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 5. uw7_socket.patch This patch adds code to Modules/socketmodule.c to work around a bug in the SCO UnixWare 7.X accept() imple- mentation. This code is only compiled if the macro, SCO_ACCEPT_BUG, is defined. The patch also changed the code so that the accept call is restarted if it was interrupted. 6. uw7_regrtest.patch This patch adds a list of tests that are expected to be skipped for UnixWare 7.x systems. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-09-05 21:15 Message: Logged In: YES user_id=31435 I suggest instead reverting all changes to atan2 and simply documenting that this platform has some libm bugs. Detailed review of math patches takes intense effort and I don't have time for that; and that's bad, because you're unlikely to get this right unless you're a libm expert (for example, atan2() applied to two minus zeroes should return minus pi, not a minus 0 as in the new patch -- if writing correct libm functions were easy, UnixWare wouldn't have screwed it up to begin with ). ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-09-05 20:30 Message: Logged In: YES user_id=8500 I have uploaded a new patch, uw7_atan2fix.patch, that changes the sco_atan2() routine so that negitive zero as the first argument is handled correctly. The previous version did not handle -0 correctly (as pointed out by Tim Peters). This patch assumes that the previous patches have been applied. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 14:40 Message: Logged In: YES user_id=6380 OK, so it looks like they are using signal() as a communications mechanism. Then I'm not sure if it's worth fixing the thread test: the accept() call just happens to be the call that's being interrupted by thread creation in the test, but in a real application, *any* I/O system call can return an error with EINTR set, and in general this will cause Python application failures. Maybe it's better to disable threads on UW... ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-09-05 14:36 Message: Logged In: YES user_id=8500 What I am saying that without the patch the thread test fails because accept() returns with an error number of EINTR. What is probably happening (guesswork here) is that one thread started an accept() call and the main program forked to create another process to act as a client to the main program's server. A signal was generated during this process that interrupted the accept() call, which returned to the caller with errno set to EINTR. The following text comes from fork(2) manual page: ----------------------- Notices Considerations for threads programming Threads in the creating process are unaffected by these system calls except possibly for the error indication EINTR in the creating process. ------------------------ I forget what the exact test that failed is, but I can replicate the failure easily enough. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-09-05 14:33 Message: Logged In: YES user_id=8500 What I am saying that without the patch the thread test fails because accept() returns with an error number of EINTR. What is probably happening (guesswork here) is that one thread started an accept() call and the main program forked to create another process to act as a client to the main program's server. A signal was generated during this process that interrupted the accept() call, which returned to the caller with errno set to EINTR. The following text comes from fork(2) manual page: ----------------------- Notices Considerations for threads programming Threads in the creating process are unaffected by these system calls except possibly for the error indication EINTR in the creating process. ------------------------ I forget what the exact test that failed is, but I can replicate the failure easily enough. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 10:28 Message: Logged In: YES user_id=6380 Excuse me for butting in. I'm guessing that, indeed, somehow starting threads runs a signal handler that interrupts system calls on UW. I would like to note that to a C programmer, it makes sense to always retry after a SIGINT: if the signal doesn't kill the program outright, the EINTR means that the signal handler ran and returned, and this typically means that it decided *not* to kill the program (the C convention is to longjmp out). It would really be better if the system call continued on its own accord, but for various reasons (the "80%" argument has been mentioned) it doesn't. But in the context of Python, a SIGINT that is intended to "kill" (well, raise an asynchronous KeyboardInterrupt exception) cannot use longjmp(), and our convention is that interrupted system calls must call PyOS_InterruptOccurred() before restarting. Unfortunately, this isn't done consistently. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 10:04 Message: Logged In: YES user_id=21627 Of course: blocking calls are interupted by signals. That is the sole purpose of SIGINT: To interrupt what the program currently does. Python must not ignore this, but immediately return to the caller - most likely, the user meant to interrupt the Python program. If the application then choses to retry on EINTR - that's a different story. Are you saying that on UnixWare, a call to accept immediately returns even without any signals being sent, in the presence of threads? That sounds broken. Where is that documented? On the distutils patches: I'm no distutils expert, so I don't feel qualified to review the patches (IOW, it would take some considerable time to review them which I don't have). Since all distutils experts have loads of patches to review, it may take some time to find a reviewer. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-09-05 08:49 Message: Logged In: YES user_id=8500 Any blocking I/O call is subject to being interruped by a signal. In particular, on Unixware when running threads, the first call to accept immediately returns because of an interrupted call. Therefore the loop to retry the interrupted call. On a side note, (IMHO) the code that calls an I/O operation that can block should check for an error code of EINTR and retry the operation if it was interrupted instead of returning an exception because of the interruption. That is, of course, my own opinion. BTW: is anyone looking at the distutils and setup.py changes I submitted [Patch # 454041] ? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:55 Message: Logged In: YES user_id=21627 Thanks for your patches. I've applied all of them except for uw7_socket_2.patch. Why do you add an again loop around the accept(2) call? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:46 Message: Logged In: YES user_id=21627 Accepted uw7_cmath.patch, uw7_complex.patch, uw7_math.patch, uw7_pyconfig.patch as cmathmodule.c 2.25, mathmodule.c 2.64, complexobject.c 2.43, and pyconfig.h.in 1.6. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:39 Message: Logged In: YES user_id=21627 Accepted uw7_regrtest.patch as regrtest.py 1.46. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-21 15:51 Message: Logged In: YES user_id=8500 I have uploaded an updated patch for Modules/socketmodule.py named uw7_socket_2.patch. Please use this instead of uw7_socket..patch. The original patch backed out 2 changes made to socketmodule.c since I got my copy from the CVS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 From noreply@sourceforge.net Thu Sep 6 08:44:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Sep 2001 00:44:01 -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 (Lib) Group: None >Status: Closed >Resolution: Rejected Priority: 3 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: Guido van Rossum (gvanrossum) Date: 2001-09-05 12:24 Message: Logged In: YES user_id=6380 OK, let's reject it. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-13 14:10 Message: Logged In: YES user_id=21627 In the current form, the patch looks much better, although I'm still somewhat concerned about the cheating. The obvious difference is that it will always return PATH_MAX but there may be slight differences in the interpretations of the other fields as well. Most people probably would not care and would prefer to have a unified interface over one that exposes the differences, so I'm +0 on this patch. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-13 14:03 Message: Logged In: YES user_id=21627 In a private message, Thomas writes: ,---- | There's a past-o in the patch I sent which may have | caused your confusion. I use statfs() to emulate statvfs() | and fstatfs() to emulate fstatvfs(). You will have realized | that the POSIX functions statvfs() and fstatvfs() take | precedence if they are available, the other calls will not | be used then. I think that's a reasonable compromise; in | fact, /F does something similar for MS Windows (patch | #410547). | | How can I update the patch in this database? `---- The new patch was attached with this comment. ---------------------------------------------------------------------- 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 Thu Sep 6 09:18:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Sep 2001 01:18:44 -0700 Subject: [Patches] [ python-Patches-453627 ] UnixWare 7.x port for Python 2.2 Message-ID: Patches item #453627, was opened at 2001-08-20 22:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Martin v. Lцwis (loewis) Summary: UnixWare 7.x port for Python 2.2 Initial Comment: The attached set of patches provide work-a-rounds for two know UnixWare 7.x bugs and fixes other problems related to the UnixWare 7.x port of Python. The patch file names and a description of the patches are: 1. uw7_pyconfig.patch This patch changes pyconfig.h.in to define the following macros when compiling on a UnixWare 7.x system: SCO_ATAN2_BUG, SCO_ACCEPT_BUG, and STRICT_SYSV_CURSES. 2. uw7_math.patch This patch adds code to Modules/mathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 3. uw7_cmath.patch This patch adds code to Modules/cmathmodule.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 4. uw7_complex.patch This patch adds code to Objects/complexobject.c to work around a bug in the SCO UnixWare atan2() implementation. This code is only compiled if the macro, SCO_ATAN2_BUG, is defined. 5. uw7_socket.patch This patch adds code to Modules/socketmodule.c to work around a bug in the SCO UnixWare 7.X accept() imple- mentation. This code is only compiled if the macro, SCO_ACCEPT_BUG, is defined. The patch also changed the code so that the accept call is restarted if it was interrupted. 6. uw7_regrtest.patch This patch adds a list of tests that are expected to be skipped for UnixWare 7.x systems. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-06 01:18 Message: Logged In: YES user_id=21627 I have reverted the atan2 changes, and added a note to README explaining the problem. Since both parts of the socket patch have been questioned, I reject it also. If you think anything needs to be done here, please submit a new patch. Closing this patch, as partially-accepted-partially-rejected. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-05 21:15 Message: Logged In: YES user_id=31435 I suggest instead reverting all changes to atan2 and simply documenting that this platform has some libm bugs. Detailed review of math patches takes intense effort and I don't have time for that; and that's bad, because you're unlikely to get this right unless you're a libm expert (for example, atan2() applied to two minus zeroes should return minus pi, not a minus 0 as in the new patch -- if writing correct libm functions were easy, UnixWare wouldn't have screwed it up to begin with ). ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-09-05 20:30 Message: Logged In: YES user_id=8500 I have uploaded a new patch, uw7_atan2fix.patch, that changes the sco_atan2() routine so that negitive zero as the first argument is handled correctly. The previous version did not handle -0 correctly (as pointed out by Tim Peters). This patch assumes that the previous patches have been applied. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 14:40 Message: Logged In: YES user_id=6380 OK, so it looks like they are using signal() as a communications mechanism. Then I'm not sure if it's worth fixing the thread test: the accept() call just happens to be the call that's being interrupted by thread creation in the test, but in a real application, *any* I/O system call can return an error with EINTR set, and in general this will cause Python application failures. Maybe it's better to disable threads on UW... ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-09-05 14:36 Message: Logged In: YES user_id=8500 What I am saying that without the patch the thread test fails because accept() returns with an error number of EINTR. What is probably happening (guesswork here) is that one thread started an accept() call and the main program forked to create another process to act as a client to the main program's server. A signal was generated during this process that interrupted the accept() call, which returned to the caller with errno set to EINTR. The following text comes from fork(2) manual page: ----------------------- Notices Considerations for threads programming Threads in the creating process are unaffected by these system calls except possibly for the error indication EINTR in the creating process. ------------------------ I forget what the exact test that failed is, but I can replicate the failure easily enough. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-09-05 14:33 Message: Logged In: YES user_id=8500 What I am saying that without the patch the thread test fails because accept() returns with an error number of EINTR. What is probably happening (guesswork here) is that one thread started an accept() call and the main program forked to create another process to act as a client to the main program's server. A signal was generated during this process that interrupted the accept() call, which returned to the caller with errno set to EINTR. The following text comes from fork(2) manual page: ----------------------- Notices Considerations for threads programming Threads in the creating process are unaffected by these system calls except possibly for the error indication EINTR in the creating process. ------------------------ I forget what the exact test that failed is, but I can replicate the failure easily enough. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 10:28 Message: Logged In: YES user_id=6380 Excuse me for butting in. I'm guessing that, indeed, somehow starting threads runs a signal handler that interrupts system calls on UW. I would like to note that to a C programmer, it makes sense to always retry after a SIGINT: if the signal doesn't kill the program outright, the EINTR means that the signal handler ran and returned, and this typically means that it decided *not* to kill the program (the C convention is to longjmp out). It would really be better if the system call continued on its own accord, but for various reasons (the "80%" argument has been mentioned) it doesn't. But in the context of Python, a SIGINT that is intended to "kill" (well, raise an asynchronous KeyboardInterrupt exception) cannot use longjmp(), and our convention is that interrupted system calls must call PyOS_InterruptOccurred() before restarting. Unfortunately, this isn't done consistently. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 10:04 Message: Logged In: YES user_id=21627 Of course: blocking calls are interupted by signals. That is the sole purpose of SIGINT: To interrupt what the program currently does. Python must not ignore this, but immediately return to the caller - most likely, the user meant to interrupt the Python program. If the application then choses to retry on EINTR - that's a different story. Are you saying that on UnixWare, a call to accept immediately returns even without any signals being sent, in the presence of threads? That sounds broken. Where is that documented? On the distutils patches: I'm no distutils expert, so I don't feel qualified to review the patches (IOW, it would take some considerable time to review them which I don't have). Since all distutils experts have loads of patches to review, it may take some time to find a reviewer. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-09-05 08:49 Message: Logged In: YES user_id=8500 Any blocking I/O call is subject to being interruped by a signal. In particular, on Unixware when running threads, the first call to accept immediately returns because of an interrupted call. Therefore the loop to retry the interrupted call. On a side note, (IMHO) the code that calls an I/O operation that can block should check for an error code of EINTR and retry the operation if it was interrupted instead of returning an exception because of the interruption. That is, of course, my own opinion. BTW: is anyone looking at the distutils and setup.py changes I submitted [Patch # 454041] ? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:55 Message: Logged In: YES user_id=21627 Thanks for your patches. I've applied all of them except for uw7_socket_2.patch. Why do you add an again loop around the accept(2) call? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:46 Message: Logged In: YES user_id=21627 Accepted uw7_cmath.patch, uw7_complex.patch, uw7_math.patch, uw7_pyconfig.patch as cmathmodule.c 2.25, mathmodule.c 2.64, complexobject.c 2.43, and pyconfig.h.in 1.6. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-05 07:39 Message: Logged In: YES user_id=21627 Accepted uw7_regrtest.patch as regrtest.py 1.46. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-21 15:51 Message: Logged In: YES user_id=8500 I have uploaded an updated patch for Modules/socketmodule.py named uw7_socket_2.patch. Please use this instead of uw7_socket..patch. The original patch backed out 2 changes made to socketmodule.c since I got my copy from the CVS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470 From noreply@sourceforge.net Thu Sep 6 09:54:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Sep 2001 01:54:44 -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 (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Lionel Ulmer (bbrox) Assigned to: Martin v. Lцwis (loewis) 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-09-06 01:54 Message: Logged In: YES user_id=21627 Thanks for the patch. I've added the additional IANA-registered options; if there is any interest, suboptions may be added to the module as well. Committed as telnetlib.py 1.15, libtelnetlib.tex 1.8, NEWS 1.234. ---------------------------------------------------------------------- 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 Thu Sep 6 09:58:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Sep 2001 01:58:55 -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 (Lib) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Andreas Jung (ajung) >Assigned to: Martin v. Lцwis (loewis) 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-08-09 23:22 Message: Logged In: YES user_id=21627 Just that Microsoft uses them should not cause us to violate internet standards. RFC 2045 specifies that the syntax of a subtype is subtype := extension-token / iana-token iana-token := x-token := Since text/xsl and text/xul are not registered as specified in RFC 2048, they are not valid types. So our choice is to either follow Microsoft, or follow the Internet Standards. If the inclusion of text/xsl in the patch was intentional (rather than a mistake), I recommend to reject this patch. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2001-08-09 18:22 Message: Logged In: YES user_id=11084 the mimetypes for .xsl and xul are also in common usage. Andreas ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-09 14:10 Message: Logged In: YES user_id=21627 I wasn't complaining about the x- types (application/x-javascript); they are fine. I was complaining about using unregistered types without an x- prefix, specifically + '.xsl': 'text/xsl', + '.xul': 'text/xul' These are not valid MIME types, unless I'm missing something. More generally, I was requesting that the IANA registry is analysed and this patch is brought in sync with it. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2001-08-09 11:14 Message: Logged In: YES user_id=11084 The x-* mimetypes are common used although they might not be officially assigned. I would not remove these from the list. This patch also relates to bug #439710 for better support of user-defined mime-types. Andreas ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 10:54 Message: Logged In: YES user_id=6380 Still waiting for feedback... ---------------------------------------------------------------------- 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 Sep 6 11:02:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Sep 2001 03:02:15 -0700 Subject: [Patches] [ python-Patches-449054 ] PEP 250 Implementation Message-ID: Patches item #449054, was opened at 2001-08-08 02:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: Accepted Priority: 9 Submitted By: Paul Moore (pmoore) Assigned to: Greg Ward (gward) Summary: PEP 250 Implementation Initial Comment: (Second try - on the first one, the patch itself got missed, and I couldn't log in, so it went in as 'nobody' :-(. Sorry) 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. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2001-09-06 03:02 Message: Logged In: YES user_id=11105 I've checked in the changes to bdist_wininst. Whoever is responsible to close this patch can probably close it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-23 14:54 Message: Logged In: YES user_id=31435 No violation of policy, but since you're leaving a Priority 9 patch Open, I'm assigning it to you so it doesn't show up as a high-priority nag in AMK's mailbox. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2001-08-23 13:57 Message: Logged In: YES user_id=14422 OK, I've checked in the patch. Thanks Paul, sorry for the delay. Because of the changes to wininst waiting on Thomas Heller, I'm NOT closing this patch yet. If this violates policy (patch applied means close it?), howl at me and I'll close it. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2001-08-21 07:17 Message: Logged In: YES user_id=113328 Thomas seems to be unavailable - I've had no response from him since before I submitted this patch. Can someone please apply this patch. Once this patch is in, there's a patch required to the bdist_wininst installer, which Thomas has promised. But until he reappears, this isn't going to happen. But this patch does *not* depend on Thomas' - so there is no reason to miss the 2.2 deadline because of that. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-20 22:05 Message: Logged In: YES user_id=31435 I'm not checking this in: I don't understand it, and it's been assigned to two distutils folks who declined to check it in for unrecorded reasons. Assigning to Andrew: please check it in or explain why not? ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-20 21:04 Message: Logged In: YES user_id=12800 Assigning to Tim. Isn't this already in the Py2.2 tree? Can't we close this patch now? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-08-16 07:01 Message: Logged In: YES user_id=11375 Thomas, do you want to apply this patch or shall I do it? ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2001-08-10 12:25 Message: Logged In: YES user_id=14422 The patch looks just fine to me. Since it's associated with a patch by Thomas Heller, I'll Thomas apply this and check it in. Assigning to Thomas so he sees this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 06:34 Message: Logged In: YES user_id=6380 Assigned to Greg Ward. Greg, if you can't review this patch, reassign to someone who can, or to Nobody. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-10 01:23 Message: Logged In: YES user_id=21627 Since the feature is requested for 2.2, I've raised the priority of the patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 From noreply@sourceforge.net Thu Sep 6 11:03:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Sep 2001 03:03:51 -0700 Subject: [Patches] [ python-Patches-449054 ] PEP 250 Implementation Message-ID: Patches item #449054, was opened at 2001-08-08 02:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: Accepted Priority: 9 Submitted By: Paul Moore (pmoore) Assigned to: Greg Ward (gward) Summary: PEP 250 Implementation Initial Comment: (Second try - on the first one, the patch itself got missed, and I couldn't log in, so it went in as 'nobody' :-(. Sorry) 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. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2001-09-06 03:03 Message: Logged In: YES user_id=11105 I've checked in the changes to bdist_wininst. Whoever is responsible to close this patch can probably close it. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-09-06 03:02 Message: Logged In: YES user_id=11105 I've checked in the changes to bdist_wininst. Whoever is responsible to close this patch can probably close it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-23 14:54 Message: Logged In: YES user_id=31435 No violation of policy, but since you're leaving a Priority 9 patch Open, I'm assigning it to you so it doesn't show up as a high-priority nag in AMK's mailbox. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2001-08-23 13:57 Message: Logged In: YES user_id=14422 OK, I've checked in the patch. Thanks Paul, sorry for the delay. Because of the changes to wininst waiting on Thomas Heller, I'm NOT closing this patch yet. If this violates policy (patch applied means close it?), howl at me and I'll close it. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2001-08-21 07:17 Message: Logged In: YES user_id=113328 Thomas seems to be unavailable - I've had no response from him since before I submitted this patch. Can someone please apply this patch. Once this patch is in, there's a patch required to the bdist_wininst installer, which Thomas has promised. But until he reappears, this isn't going to happen. But this patch does *not* depend on Thomas' - so there is no reason to miss the 2.2 deadline because of that. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-20 22:05 Message: Logged In: YES user_id=31435 I'm not checking this in: I don't understand it, and it's been assigned to two distutils folks who declined to check it in for unrecorded reasons. Assigning to Andrew: please check it in or explain why not? ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-20 21:04 Message: Logged In: YES user_id=12800 Assigning to Tim. Isn't this already in the Py2.2 tree? Can't we close this patch now? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-08-16 07:01 Message: Logged In: YES user_id=11375 Thomas, do you want to apply this patch or shall I do it? ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2001-08-10 12:25 Message: Logged In: YES user_id=14422 The patch looks just fine to me. Since it's associated with a patch by Thomas Heller, I'll Thomas apply this and check it in. Assigning to Thomas so he sees this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 06:34 Message: Logged In: YES user_id=6380 Assigned to Greg Ward. Greg, if you can't review this patch, reassign to someone who can, or to Nobody. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-10 01:23 Message: Logged In: YES user_id=21627 Since the feature is requested for 2.2, I've raised the priority of the patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 From noreply@sourceforge.net Fri Sep 7 02:01:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Sep 2001 18:01:52 -0700 Subject: [Patches] [ python-Patches-459381 ] Unambiguous import for encodings Message-ID: Patches item #459381, was opened at 2001-09-06 18:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459381&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: Unambiguous import for encodings Initial Comment: The __import__ call in encodings/__init__.py does not specify module hierarchy explicitly. This results in misleading error tracebacks (try "codecs.lookup('codecs')"). Worse, it results in an error when one is trying to lookup a codec and the encoding's name fires some top-level module, e.g 'base64', despite that a codec for this encoding may actually be registered in the system. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459381&group_id=5470 From noreply@sourceforge.net Fri Sep 7 02:27:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Sep 2001 18:27:44 -0700 Subject: [Patches] [ python-Patches-459385 ] 2.1.1 time.timezone fix for Cygwin Message-ID: Patches item #459385, was opened at 2001-09-06 18:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459385&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Norman Vine (nhv) Assigned to: Nobody/Anonymous (nobody) Summary: 2.1.1 time.timezone fix for Cygwin Initial Comment: *** timemodule.bak Wed Jun 27 09:01:54 2001 --- timemodule.c Thu Sep 6 20:29:28 2001 *************** *** 599,605 **** /* Squirrel away the module's dictionary for the y2k check */ Py_INCREF(d); moddict = d; ! #if defined(HAVE_TZNAME) && !defined(__GLIBC__) tzset(); #ifdef PYOS_OS2 ins(d, "timezone", PyInt_FromLong((long) _timezone)); --- 599,605 ---- /* Squirrel away the module's dictionary for the y2k check */ Py_INCREF(d); moddict = d; ! #if defined(HAVE_TZNAME) && !defined(__GLIBC__) &&! defined(__CYGWIN__) tzset(); #ifdef PYOS_OS2 ins(d, "timezone", PyInt_FromLong((long) _timezone)); ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459385&group_id=5470 From noreply@sourceforge.net Fri Sep 7 08:31:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Sep 2001 00:31:04 -0700 Subject: [Patches] [ python-Patches-459441 ] URL correction in distutils docu Message-ID: Patches item #459441, was opened at 2001-09-07 00:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459441&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rene Liebscher (rliebscher) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: URL correction in distutils docu Initial Comment: This patches fixes a URL in the distutils documentation file inst.tex. This URL points to my website, but it will become unavailable in the next months. So I moved the files to the sourceforge project (PyOpenGL) for which I originally needed them. You may probably want to remove this paragraph as whole because there are currently only files for Python 2.0 to find. (I might put there also the files for Python 2.1 and 2.2, when I needed them.) It would be probably better, if such files would maintained somewhere at python.org for all versions of Python. (I don't think it will be a problem to find someone who is testing all new Python releases and provides these files.) Kind regards Rene Liebscher ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459441&group_id=5470 From noreply@sourceforge.net Fri Sep 7 08:32:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Sep 2001 00:32:34 -0700 Subject: [Patches] [ python-Patches-459442 ] Fix small problems Message-ID: Patches item #459442, was opened at 2001-09-07 00:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459442&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Fix small problems Initial Comment: Fix some small problems with bgen: Remove some (debugging?) print statements. Fix the initialization code for generated types. They are initialized twice, which does not harm, but the code doesn't compile with MSVC 6 in C source code. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459442&group_id=5470 From noreply@sourceforge.net Fri Sep 7 08:33:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Sep 2001 00:33:03 -0700 Subject: [Patches] [ python-Patches-459442 ] Fix small Tools/bgen problems Message-ID: Patches item #459442, was opened at 2001-09-07 00:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459442&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) >Summary: Fix small Tools/bgen problems Initial Comment: Fix some small problems with bgen: Remove some (debugging?) print statements. Fix the initialization code for generated types. They are initialized twice, which does not harm, but the code doesn't compile with MSVC 6 in C source code. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459442&group_id=5470 From noreply@sourceforge.net Fri Sep 7 08:33:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Sep 2001 00:33:45 -0700 Subject: [Patches] [ python-Patches-459442 ] Fix small Tools/bgen problems Message-ID: Patches item #459442, was opened at 2001-09-07 00:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459442&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) >Assigned to: Jack Jansen (jackjansen) Summary: Fix small Tools/bgen problems Initial Comment: Fix some small problems with bgen: Remove some (debugging?) print statements. Fix the initialization code for generated types. They are initialized twice, which does not harm, but the code doesn't compile with MSVC 6 in C source code. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459442&group_id=5470 From noreply@sourceforge.net Fri Sep 7 16:46:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Sep 2001 08:46:41 -0700 Subject: [Patches] [ python-Patches-449054 ] PEP 250 Implementation Message-ID: Patches item #449054, was opened at 2001-08-08 02:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 Category: Distutils and setup.py Group: None >Status: Closed Resolution: Accepted Priority: 9 Submitted By: Paul Moore (pmoore) Assigned to: Greg Ward (gward) Summary: PEP 250 Implementation Initial Comment: (Second try - on the first one, the patch itself got missed, and I couldn't log in, so it went in as 'nobody' :-(. Sorry) 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. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-09-06 03:03 Message: Logged In: YES user_id=11105 I've checked in the changes to bdist_wininst. Whoever is responsible to close this patch can probably close it. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-09-06 03:02 Message: Logged In: YES user_id=11105 I've checked in the changes to bdist_wininst. Whoever is responsible to close this patch can probably close it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-23 14:54 Message: Logged In: YES user_id=31435 No violation of policy, but since you're leaving a Priority 9 patch Open, I'm assigning it to you so it doesn't show up as a high-priority nag in AMK's mailbox. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2001-08-23 13:57 Message: Logged In: YES user_id=14422 OK, I've checked in the patch. Thanks Paul, sorry for the delay. Because of the changes to wininst waiting on Thomas Heller, I'm NOT closing this patch yet. If this violates policy (patch applied means close it?), howl at me and I'll close it. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2001-08-21 07:17 Message: Logged In: YES user_id=113328 Thomas seems to be unavailable - I've had no response from him since before I submitted this patch. Can someone please apply this patch. Once this patch is in, there's a patch required to the bdist_wininst installer, which Thomas has promised. But until he reappears, this isn't going to happen. But this patch does *not* depend on Thomas' - so there is no reason to miss the 2.2 deadline because of that. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-20 22:05 Message: Logged In: YES user_id=31435 I'm not checking this in: I don't understand it, and it's been assigned to two distutils folks who declined to check it in for unrecorded reasons. Assigning to Andrew: please check it in or explain why not? ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-20 21:04 Message: Logged In: YES user_id=12800 Assigning to Tim. Isn't this already in the Py2.2 tree? Can't we close this patch now? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-08-16 07:01 Message: Logged In: YES user_id=11375 Thomas, do you want to apply this patch or shall I do it? ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2001-08-10 12:25 Message: Logged In: YES user_id=14422 The patch looks just fine to me. Since it's associated with a patch by Thomas Heller, I'll Thomas apply this and check it in. Assigning to Thomas so he sees this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 06:34 Message: Logged In: YES user_id=6380 Assigned to Greg Ward. Greg, if you can't review this patch, reassign to someone who can, or to Nobody. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-10 01:23 Message: Logged In: YES user_id=21627 Since the feature is requested for 2.2, I've raised the priority of the patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 From noreply@sourceforge.net Fri Sep 7 16:47:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Sep 2001 08:47:12 -0700 Subject: [Patches] [ python-Patches-449054 ] PEP 250 Implementation Message-ID: Patches item #449054, was opened at 2001-08-08 02:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 Category: Distutils and setup.py Group: None Status: Closed Resolution: Accepted Priority: 9 Submitted By: Paul Moore (pmoore) Assigned to: Greg Ward (gward) Summary: PEP 250 Implementation Initial Comment: (Second try - on the first one, the patch itself got missed, and I couldn't log in, so it went in as 'nobody' :-(. Sorry) 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. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-09-06 03:03 Message: Logged In: YES user_id=11105 I've checked in the changes to bdist_wininst. Whoever is responsible to close this patch can probably close it. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-09-06 03:02 Message: Logged In: YES user_id=11105 I've checked in the changes to bdist_wininst. Whoever is responsible to close this patch can probably close it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-23 14:54 Message: Logged In: YES user_id=31435 No violation of policy, but since you're leaving a Priority 9 patch Open, I'm assigning it to you so it doesn't show up as a high-priority nag in AMK's mailbox. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2001-08-23 13:57 Message: Logged In: YES user_id=14422 OK, I've checked in the patch. Thanks Paul, sorry for the delay. Because of the changes to wininst waiting on Thomas Heller, I'm NOT closing this patch yet. If this violates policy (patch applied means close it?), howl at me and I'll close it. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2001-08-21 07:17 Message: Logged In: YES user_id=113328 Thomas seems to be unavailable - I've had no response from him since before I submitted this patch. Can someone please apply this patch. Once this patch is in, there's a patch required to the bdist_wininst installer, which Thomas has promised. But until he reappears, this isn't going to happen. But this patch does *not* depend on Thomas' - so there is no reason to miss the 2.2 deadline because of that. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-20 22:05 Message: Logged In: YES user_id=31435 I'm not checking this in: I don't understand it, and it's been assigned to two distutils folks who declined to check it in for unrecorded reasons. Assigning to Andrew: please check it in or explain why not? ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-20 21:04 Message: Logged In: YES user_id=12800 Assigning to Tim. Isn't this already in the Py2.2 tree? Can't we close this patch now? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-08-16 07:01 Message: Logged In: YES user_id=11375 Thomas, do you want to apply this patch or shall I do it? ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2001-08-10 12:25 Message: Logged In: YES user_id=14422 The patch looks just fine to me. Since it's associated with a patch by Thomas Heller, I'll Thomas apply this and check it in. Assigning to Thomas so he sees this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 06:34 Message: Logged In: YES user_id=6380 Assigned to Greg Ward. Greg, if you can't review this patch, reassign to someone who can, or to Nobody. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-10 01:23 Message: Logged In: YES user_id=21627 Since the feature is requested for 2.2, I've raised the priority of the patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 From noreply@sourceforge.net Fri Sep 7 17:28:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Sep 2001 09:28:01 -0700 Subject: [Patches] [ python-Patches-450702 ] zlibmodule ALLOW_THREADS update Message-ID: Patches item #450702, was opened at 2001-08-13 22:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450702&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Titus Brown (titus) Assigned to: Martin v. Lцwis (loewis) Summary: zlibmodule ALLOW_THREADS update Initial Comment: When using e.g. the gzip module in a threaded Python embedding (PyWX, pywx.idyll.org) all other Python threads halt, because no thread interleaving is done by the time-intensive commands in zlib.so. This leads to serious lags when compressing 5 MB files... I have wrapped all of the inflate and deflate commands in Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS, which fixes this problem. Note that this fix is backwards compatible to 2.1, at least, as zlibmodule.c has not changed since then. As requested, a _context_ diff from the head of the current CVS tree is attached ;). ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-07 09:28 Message: Logged In: YES user_id=21627 Committed as zlibmodule.c 2.41 ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-04 08:01 Message: Logged In: YES user_id=21627 I fail to see the issue with the string being released from under the compression invocation: The string is definitely referenced from the argument tuple, and the argument tuple is guaranteed to live as long as the function is running, even if a thread switch occurs within the function. This is no showstopper issue, though: the code looks correct even with the extra incref. Unless you indicate that you'll want to study the refcount issue in more detail and potentially revise the patch, I'm willing to commit it as-is. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-20 23:55 Message: Logged In: YES user_id=23486 One last patch: Alex Martelli pointed out that C functions do not automatically take on ownership of passed-in strings, and, under circumstances where multiple threads have access to the same namespace, thread A might be involved in a time-consuming command and thread B (now allowed to execute) could then delete the input string out from under it. Attached is the complete patch, this time including the appropriate INCREF and DECREF of the input string. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-17 10:10 Message: Logged In: YES user_id=23486 This new patch makes the zlibmodule reentrant by using a global zlib_lock. Also included is the addition of BEGIN/END_ALLOW_THREADS macros around the actual calls to compress/decompress data, which significantly improves the thread-friendliness of this module. Most of the code changes are simple rearrangements of the same old code to adapt it to the requirements of the ENTER and LEAVE_ZLIB macros, which create new blocks; thus, any code from which a 'return' was done had to be changed to exit only after LEAVE_ZLIB was called. Note that because zlib itself is re-entrant, we really only had to worry about making methods on de/compress objects reentrant. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-14 12:13 Message: Logged In: YES user_id=23486 N.B. I've found that zlib _is_ threadsafe. I still need to determine if the way in which objects are passed around in the zlibmodule.c can potentially cause problems; it seems like it can. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-14 09:06 Message: Logged In: YES user_id=23486 I think there may be a 2nd problem: I have to look into some of the Python calls used to transfer data around, but it may be possible for threads with access to the compression objects to retrieve data in an indeterminate state, i.e. mid-compression. Luckily a module-wide lock should take care of both this problem AND resolve threadsafety issues with zlib! I'll look into this & fix it. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-14 07:21 Message: Logged In: YES user_id=21627 The patch looks good, however there is a major problem with the approach taken: zlib itself might not be threadsafe. Please try to find out whether zlib indeed is thread-safe; if it isn't, I think you need to add another lock to prevent multiple Python threads from accessing zlib simultaneously. You may want to take a look at _tkinter, which has similar code to prevent multiple Python threads from accessing Tk simultaneously. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450702&group_id=5470 From noreply@sourceforge.net Fri Sep 7 17:50:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Sep 2001 09:50:02 -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 (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Andreas Jung (ajung) Assigned to: Martin v. Lцwis (loewis) 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-09-07 09:50 Message: Logged In: YES user_id=21627 I've now applied this patch as mimetypes.py 1.19, removing all the types that were not registered. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-09 23:22 Message: Logged In: YES user_id=21627 Just that Microsoft uses them should not cause us to violate internet standards. RFC 2045 specifies that the syntax of a subtype is subtype := extension-token / iana-token iana-token := x-token := Since text/xsl and text/xul are not registered as specified in RFC 2048, they are not valid types. So our choice is to either follow Microsoft, or follow the Internet Standards. If the inclusion of text/xsl in the patch was intentional (rather than a mistake), I recommend to reject this patch. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2001-08-09 18:22 Message: Logged In: YES user_id=11084 the mimetypes for .xsl and xul are also in common usage. Andreas ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-09 14:10 Message: Logged In: YES user_id=21627 I wasn't complaining about the x- types (application/x-javascript); they are fine. I was complaining about using unregistered types without an x- prefix, specifically + '.xsl': 'text/xsl', + '.xul': 'text/xul' These are not valid MIME types, unless I'm missing something. More generally, I was requesting that the IANA registry is analysed and this patch is brought in sync with it. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2001-08-09 11:14 Message: Logged In: YES user_id=11084 The x-* mimetypes are common used although they might not be officially assigned. I would not remove these from the list. This patch also relates to bug #439710 for better support of user-defined mime-types. Andreas ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 10:54 Message: Logged In: YES user_id=6380 Still waiting for feedback... ---------------------------------------------------------------------- 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 Fri Sep 7 17:58:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Sep 2001 09:58:30 -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: Accepted Priority: 3 Submitted By: Moshe Zadka (moshez) >Assigned to: Moshe Zadka (moshez) 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. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-07 09:58 Message: Logged In: YES user_id=21627 This patch looks perfect to me. Please check it in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443759&group_id=5470 From noreply@sourceforge.net Fri Sep 7 18:03:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Sep 2001 10:03:15 -0700 Subject: [Patches] [ python-Patches-403753 ] zlib decompress; uncontrollable memory usage Message-ID: Patches item #403753, was opened at 2001-02-12 08:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403753&group_id=5470 Category: Modules Group: None Status: Open >Resolution: Out of Date Priority: 5 Submitted By: Toby Dickenson (htrd) Assigned to: Jeremy Hylton (jhylton) Summary: zlib decompress; uncontrollable memory usage Initial Comment: zlib's decompress method will allocate as much memory as is needed to hold the decompressed output. The length of the output buffer may be very much larger than the length of the input buffer, and the python code calling the decompress method has no other way to control how much memory is allocated. In experimentation, I seen decompress generate output that is 1000 times larger than its input These characteristics may make the decompress method unsuitable for handling data obtained from untrusted sources (for example, in a http proxy which implements gzip encoding) since it may be vulnerable to a denial of service attack. A malicious user could construct a moderately sized input which forces 'decompress' to try to allocate too much memory. This patch adds a new method, decompress_incremental, which allows the caller to specify the maximum size of the output. This method returns the excess input, in addition to the decompressed output. It is possible to solve this problem without a patch: If input is fed to the decompressor a few tens of bytes at a time, memory usage will surge by (at most) a few tens of kilobytes. Such a process is a kludge, and much less efficient that the approach used in this patch. (Ive not been able to test the documentation patch; I hope its ok) (This patch also includes the change from Patch #103748) ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-07 10:03 Message: Logged In: YES user_id=21627 Since this patch has been sitting around for such a long time, it eventually got outdated, due to the conflicting MT patch. Any volunteers to update it? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-06-04 13:55 Message: Logged In: YES user_id=21627 The patch looks good to me; I recommend to approve it. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-04-10 10:52 Message: Logged In: YES user_id=11375 I've let this patch gather dust long enough. Unassigning so that someone else can review it. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2001-04-07 00:20 Message: Logged In: YES user_id=413 as a side note. I believe I implemented a python workaround for this problem by just decompressing data in small chunks (4k at a time) using a decompressor object. see the mojonation project on sourceforge if you're curious. (specifically, in the mojonation evil module, look at common/mojoutil.py for function named safe_zlib_decompress). Regardless, I like thie idea of this patch. It would be good to have that in the main API and documentation for simplicity. (and because there are too many programmers out there who don't realize potential denial of service issues on their own...) ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-22 04:50 Message: New patch implementing a new optional parameter to .decompress, and a new attribute .unconsumed_tail ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-22 03:42 Message: Waaah - that last comment should be 'cant' not 'can' ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-22 03:40 Message: We can reuse .unused_data without introducing an ambiguity. I will prepare a patch that uses a new attribute .unconsumed_tail ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-02-21 11:32 Message: Doesn't .unused_data serve much the same purpose, though? So that even with a maximum size, .decompress() always returns a string, and .unused_data would contain the unprocessed data. ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-21 06:00 Message: I did consider that.... An extra change that you didnt mention is the need for a different return value. Currently .decompress() always returns a string. The new method in my patch returns a tuple containing the same string, and an integer specifying how many bytes were consumed from the input. Overloading return values based on an optional parameter seems a little hairy to me, but I would be happy to change the patch if that is your preferred option. I also considered (and rejected) the possibility of adding an optional max-size argument to .decompress() as you suggest, but raising an exception if this limit is exceeded. This avoids the need for an extra return value, but looses out on flexibility. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-02-20 18:48 Message: Rather than introducing a new method, why not just add an optional maxlen argument to .decompress(). I think the changes would be: * add 'int maxlen=-1;' * add "...|i" ... ,&maxlen to the argument parsing * if maxlen != -1, length = maxlen else length = DEFAULTALLOC; * Add '&& maxlen==-1' to the while loop. (Use the current CVS; I just checked in a patch rearranging the zlib module a bit.) Do you want to make those changes and resubmit the patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403753&group_id=5470 From noreply@sourceforge.net Fri Sep 7 21:59:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Sep 2001 13:59:59 -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: Open 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: Frederic Giacometti (giacometti) Date: 2001-09-07 13:59 Message: Logged In: YES user_id=93657 I'm getting back on the issue - Three months after submitting the patch, and one month after writing the PEP proposal, Barry W. still hasn't assigned a PEP number -. I have been working on the Python 2.1.1 build lately, and I stumble into this in the Makefile: There are 8 occurences of Make shell commands of the kind PYTHONPATH= $(PYTHON) ... This is the kind of thing that could be replaced a lot more clearly (and portably) with: $(PYTHON) -p "" ... if the patch were applied. If still think a PEP discussion is not necessary for this; especially since the PEP process seems frozen in this regard. In any event, it is desirable that the feature be included before the final 2.2 release. Thanks, Frederic Giacometti ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-08-05 20:37 Message: Logged In: YES user_id=93657 I apologize for the delay, but I have been travelling a lot for the last 2 months, and I could not have followed up a PEP. I'm now stabilized, so here is the PEP proposal I just mailed to Barry. Regards, Frederic Giacometti -------------------------------------- PEP XXX: Addition of an option for completing sys.path from the commandline fred@arakne.com (Frederic Giacometti) Abstract At present, the PYTHONPATH environment variable is the only method for defining additional Python module directories. This PEP introduce the '-P' valued option to the python command as an alternative to PYTHONPATH. Copyright: This document is published under the Open Publication License. Specification: On Unix: python -P $SOMEVALUE will be equivalent to env PYTHONPATH=$SOMEVALUE python On Windows 2K: python -P $SOMEVALUE will (almost, humm) be equivalent to set __PYTHONPATH=%PYTHONPATH% && set PYTHONPATH=%SOMEVALUE% && python && set PYTHONPATH=__%PYTHONPATH% Reference Implementation and PEP pre-history: See patch http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429614&group_id=5470 ---------------------------------------------------------------------- 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 Fri Sep 7 23:18:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Sep 2001 15:18:41 -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: Open 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: Frederic Giacometti (giacometti) Date: 2001-09-07 15:18 Message: Logged In: YES user_id=93657 I'm getting back on the issue - Three months after submitting the patch, and one month after writing the PEP proposal, Barry W. still hasn't assigned a PEP number -. I have been working on the Python 2.1.1 build lately, and I stumble into this in the Makefile: There are 8 occurences of Make shell commands of the kind PYTHONPATH= $(PYTHON) ... This is the kind of thing that could be replaced a lot more clearly (and portably) with: $(PYTHON) -p "" ... if the patch were applied. If still think a PEP discussion is not necessary for this; especially since the PEP process seems frozen in this regard. In any event, it is desirable that the feature be included before the final 2.2 release. Thanks, Frederic Giacometti ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-07 13:59 Message: Logged In: YES user_id=93657 I'm getting back on the issue - Three months after submitting the patch, and one month after writing the PEP proposal, Barry W. still hasn't assigned a PEP number -. I have been working on the Python 2.1.1 build lately, and I stumble into this in the Makefile: There are 8 occurences of Make shell commands of the kind PYTHONPATH= $(PYTHON) ... This is the kind of thing that could be replaced a lot more clearly (and portably) with: $(PYTHON) -p "" ... if the patch were applied. If still think a PEP discussion is not necessary for this; especially since the PEP process seems frozen in this regard. In any event, it is desirable that the feature be included before the final 2.2 release. Thanks, Frederic Giacometti ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-08-05 20:37 Message: Logged In: YES user_id=93657 I apologize for the delay, but I have been travelling a lot for the last 2 months, and I could not have followed up a PEP. I'm now stabilized, so here is the PEP proposal I just mailed to Barry. Regards, Frederic Giacometti -------------------------------------- PEP XXX: Addition of an option for completing sys.path from the commandline fred@arakne.com (Frederic Giacometti) Abstract At present, the PYTHONPATH environment variable is the only method for defining additional Python module directories. This PEP introduce the '-P' valued option to the python command as an alternative to PYTHONPATH. Copyright: This document is published under the Open Publication License. Specification: On Unix: python -P $SOMEVALUE will be equivalent to env PYTHONPATH=$SOMEVALUE python On Windows 2K: python -P $SOMEVALUE will (almost, humm) be equivalent to set __PYTHONPATH=%PYTHONPATH% && set PYTHONPATH=%SOMEVALUE% && python && set PYTHONPATH=__%PYTHONPATH% Reference Implementation and PEP pre-history: See patch http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429614&group_id=5470 ---------------------------------------------------------------------- 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 Fri Sep 7 23:25:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Sep 2001 15:25:56 -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: Open 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: Frederic Giacometti (giacometti) Date: 2001-09-07 15:25 Message: Logged In: YES user_id=93657 Since I'm still battling in Python's configure and Makefile.pre.in files, here are some more occurences: WIth the patch: PYTHONPATH=$(LIBDEST) \ ./$(PYTHON) -tt $(LIBDEST)/compileall.py $(LIBDEST) PYTHONPATH=$(LIBDEST) \ ./$(PYTHON) -O $(LIBDEST)/compileall.py $(LIBDEST) would be replaced by: ./$(PYTHON) -p $(LIBDEST) -tt $(LIBDEST)/compileall.py $(LIBDEST) ./$(PYTHON) -p $(LIBDEST) -O $(LIBDEST)/compileall.py $(LIBDEST) Some more can be found... FG ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-07 15:18 Message: Logged In: YES user_id=93657 I'm getting back on the issue - Three months after submitting the patch, and one month after writing the PEP proposal, Barry W. still hasn't assigned a PEP number -. I have been working on the Python 2.1.1 build lately, and I stumble into this in the Makefile: There are 8 occurences of Make shell commands of the kind PYTHONPATH= $(PYTHON) ... This is the kind of thing that could be replaced a lot more clearly (and portably) with: $(PYTHON) -p "" ... if the patch were applied. If still think a PEP discussion is not necessary for this; especially since the PEP process seems frozen in this regard. In any event, it is desirable that the feature be included before the final 2.2 release. Thanks, Frederic Giacometti ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-07 13:59 Message: Logged In: YES user_id=93657 I'm getting back on the issue - Three months after submitting the patch, and one month after writing the PEP proposal, Barry W. still hasn't assigned a PEP number -. I have been working on the Python 2.1.1 build lately, and I stumble into this in the Makefile: There are 8 occurences of Make shell commands of the kind PYTHONPATH= $(PYTHON) ... This is the kind of thing that could be replaced a lot more clearly (and portably) with: $(PYTHON) -p "" ... if the patch were applied. If still think a PEP discussion is not necessary for this; especially since the PEP process seems frozen in this regard. In any event, it is desirable that the feature be included before the final 2.2 release. Thanks, Frederic Giacometti ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-08-05 20:37 Message: Logged In: YES user_id=93657 I apologize for the delay, but I have been travelling a lot for the last 2 months, and I could not have followed up a PEP. I'm now stabilized, so here is the PEP proposal I just mailed to Barry. Regards, Frederic Giacometti -------------------------------------- PEP XXX: Addition of an option for completing sys.path from the commandline fred@arakne.com (Frederic Giacometti) Abstract At present, the PYTHONPATH environment variable is the only method for defining additional Python module directories. This PEP introduce the '-P' valued option to the python command as an alternative to PYTHONPATH. Copyright: This document is published under the Open Publication License. Specification: On Unix: python -P $SOMEVALUE will be equivalent to env PYTHONPATH=$SOMEVALUE python On Windows 2K: python -P $SOMEVALUE will (almost, humm) be equivalent to set __PYTHONPATH=%PYTHONPATH% && set PYTHONPATH=%SOMEVALUE% && python && set PYTHONPATH=__%PYTHONPATH% Reference Implementation and PEP pre-history: See patch http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429614&group_id=5470 ---------------------------------------------------------------------- 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 Sat Sep 8 00:38:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Sep 2001 16:38:12 -0700 Subject: [Patches] [ python-Patches-453199 ] Cosmetic changes to libframework.tex Message-ID: Patches item #453199, was opened at 2001-08-19 21:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453199&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Cosmetic changes to libframework.tex Initial Comment: Most changes here are grammatical or cosmetic, to fit more in line with the documentation guidelines. In a few cases, parameter names were changed to match the source code (important for keyword argument passing). ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-07 16:38 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453199&group_id=5470 From noreply@sourceforge.net Sat Sep 8 02:57:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Sep 2001 18:57:16 -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: Open 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: Guido van Rossum (gvanrossum) Date: 2001-09-07 18:57 Message: Logged In: YES user_id=6380 (A) You will hear from Barry soon. (B) I don't see the advantage of using -p or -P. I don't understand the motivation you are giving; can you explain it better? If you want control over the path without setting PYTHONPATH, you can write a small script that sets sys.path directly. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-07 15:25 Message: Logged In: YES user_id=93657 Since I'm still battling in Python's configure and Makefile.pre.in files, here are some more occurences: WIth the patch: PYTHONPATH=$(LIBDEST) \ ./$(PYTHON) -tt $(LIBDEST)/compileall.py $(LIBDEST) PYTHONPATH=$(LIBDEST) \ ./$(PYTHON) -O $(LIBDEST)/compileall.py $(LIBDEST) would be replaced by: ./$(PYTHON) -p $(LIBDEST) -tt $(LIBDEST)/compileall.py $(LIBDEST) ./$(PYTHON) -p $(LIBDEST) -O $(LIBDEST)/compileall.py $(LIBDEST) Some more can be found... FG ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-07 15:18 Message: Logged In: YES user_id=93657 I'm getting back on the issue - Three months after submitting the patch, and one month after writing the PEP proposal, Barry W. still hasn't assigned a PEP number -. I have been working on the Python 2.1.1 build lately, and I stumble into this in the Makefile: There are 8 occurences of Make shell commands of the kind PYTHONPATH= $(PYTHON) ... This is the kind of thing that could be replaced a lot more clearly (and portably) with: $(PYTHON) -p "" ... if the patch were applied. If still think a PEP discussion is not necessary for this; especially since the PEP process seems frozen in this regard. In any event, it is desirable that the feature be included before the final 2.2 release. Thanks, Frederic Giacometti ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-07 13:59 Message: Logged In: YES user_id=93657 I'm getting back on the issue - Three months after submitting the patch, and one month after writing the PEP proposal, Barry W. still hasn't assigned a PEP number -. I have been working on the Python 2.1.1 build lately, and I stumble into this in the Makefile: There are 8 occurences of Make shell commands of the kind PYTHONPATH= $(PYTHON) ... This is the kind of thing that could be replaced a lot more clearly (and portably) with: $(PYTHON) -p "" ... if the patch were applied. If still think a PEP discussion is not necessary for this; especially since the PEP process seems frozen in this regard. In any event, it is desirable that the feature be included before the final 2.2 release. Thanks, Frederic Giacometti ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-08-05 20:37 Message: Logged In: YES user_id=93657 I apologize for the delay, but I have been travelling a lot for the last 2 months, and I could not have followed up a PEP. I'm now stabilized, so here is the PEP proposal I just mailed to Barry. Regards, Frederic Giacometti -------------------------------------- PEP XXX: Addition of an option for completing sys.path from the commandline fred@arakne.com (Frederic Giacometti) Abstract At present, the PYTHONPATH environment variable is the only method for defining additional Python module directories. This PEP introduce the '-P' valued option to the python command as an alternative to PYTHONPATH. Copyright: This document is published under the Open Publication License. Specification: On Unix: python -P $SOMEVALUE will be equivalent to env PYTHONPATH=$SOMEVALUE python On Windows 2K: python -P $SOMEVALUE will (almost, humm) be equivalent to set __PYTHONPATH=%PYTHONPATH% && set PYTHONPATH=%SOMEVALUE% && python && set PYTHONPATH=__%PYTHONPATH% Reference Implementation and PEP pre-history: See patch http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429614&group_id=5470 ---------------------------------------------------------------------- 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 oio_oiuu_ww_ll@yandex.ru Sat Sep 8 15:00:51 2001 From: oio_oiuu_ww_ll@yandex.ru (MailBase) Date: Sat, 8 Sep 2001 18:00:51 +0400 Subject: [Patches] =?windows-1251?Q?=C1=E0=E7=FB_=E4=E0=ED=ED=FB=F5_=EF=F0=E5=E4=EF=F0=E8=FF=F2=E8=E9_=E4=EB=FF_=EA=EE=ED=F2=E0=EA=F2=EE=E2_=EF=EE_=FD=EB=E5=EA=F2=F0=EE=ED=ED=EE=E9_=EF=EE=F7=F2=E5?= Message-ID: <693200196814051915@yandex.ru> Здравствуйте! В этом письме: - базы данных предприятий для контактов по электронной почте; - программа для автоматической рассылки электронной почты; - базы данных крупнейших предприятий. Когда необходимо быстро и с минимальными затратами сообщить определенной целевой группе предприятий какую-либо информацию, нет ничего лучше, чем сделать это по электронной почте. Наши базы данных для контактов по электронной почте предназначены специально для этих целей. Многие отрицательно относятся к массовым электронным рассылки, печально известным как spam. Однако мы считаем, нет ничего плохого в том, что фирма, выбрав из базы ограниченный круг предприятий (и только предприятий, а не частных лиц!) лишь определенного рода деятельности, рассылает по ним соответствующее предложение небольшого объема, которое действительно реально может их заинтересовать. Такие рассылки можно использовать не только для рекламных целей. Например, вам нужно узнать стоимость определенного товара, производимого или продаваемого определенной группой организаций. Обзвонить 500, а то и 1000 фирм - занятие, требующее значительного времени. А если сделать рассылку с соответствующим запросом по данной группе организаций, можно быстро получить полную информацию по интересующему вопросу. Предлагаем Вам два комплекта для контактов по электронной почте: Комплект "Организации Москвы" - 38000 предприятий (все с электронными адресами); Комплект "Организации СНГ" - 30000 предприятий (все с электронными адресами) Каждый комплект включает в себя: - соответствующую базу данных для контактов по электронной почте; - программу GroupMail для автоматической рассылки электронной почты. База данных "38000 организаций Москвы". Кроме электронного адреса (e-mail имеется у каждой организации) по каждой компании представлены: - название, - род деятельности, - телефоны, - факс, - почтовый адрес, - адрес сайта. База оформлена в виде стандартной таблицы Excel, что позволяет работать с нею пользователю с любым уровнем знания компьютера, и дает возможность сортировки строк по любому из параметров, например, по роду деятельности. В базу вошли все компании, которые сами публикуют свой e-mail в различных бизнес-справочниках по Москве. Возвратов с несуществующих адресов при рассылках: 15%. Обновление базы происходит каждый квартал. База с программой предоставляется на компакт-диске или высылается электронной почтой. СТОИМОСТЬ данной базы в комплекте с программой GroupMail (см. ниже) - $300. Стоимость обновления $60. Форма оплаты любая. Заказы и вопросы направляйте на адрес mailbase@post.com. База данных "30000 предприятий СНГ". Кроме электронного адреса (e-mail имеется у каждой организации) по каждой компании представлены: - название, - форма собственности, - телефоны, - факс, - почтовый адрес, - адрес сайта, - Ф.И.О. и должность руководителя (!), - численность штата, - список производимых товаров и услуг. База оформлена в виде стандартной таблицы Excel, что позволяет работать с нею пользователю с любым уровнем знания компьютера. Возвратов с несуществующих адресов при рассылках: 20%. Обновление базы происходит каждый квартал. База с программой предоставляется на компакт-диске или высылается электронной почтой. СТОИМОСТЬ данной базы в комплекте с программой GroupMail (см. ниже) - $200. Стоимость обновления $40. Форма оплаты любая. Заказы и вопросы направляйте на адрес mailbase@post.com. Программа "Group Mail" предназначена для осуществления электронных рассылок. Во время рассылки "Group Mail" генерирует и отсылает письма для каждого получателя в отдельности. При этом в текстах (как в теме, так и в теле письма) может использоваться подстановка информации из различных ячеек базы, соответствующих конкретному адресу. Это позволяет обращаться к каждому получателю по имени в рассылках по базе Ваших клиентов или партнеров, а также любым другим образом персонифицировать Вашу рассылку. Например, тема письма может быть такой: "Предложение для компании (название_компании)". "Group Mail" имеет широкие возможности по ведению баз данных. Вы можете импортировать в программу свои базы. Их может быть неограниченное количество. Базы можно создавать, дополнять, редактировать. Письма в рассылках могут составляться как в формате txt, так и html. Реализована возможность прикрепления файлов любого формата. Group Mail работает без участия какой-либо другой почтовой программы. Программа "Group Mail" бесплатно прилагается к каждой из вышеописанных баз данных. Но ее можно приобрести и отдельно для рассылки по своим базам. В этом случае стоимость ее предоставления $25. Форма оплаты любая. Программа предоставляется на компакт-диске или высылается электронной почтой. Заказы и вопросы направляйте на адрес mailbase@post.com. Внимание! При одновременном приобретении обеих баз данных предоставляется скидка: $100! Выполняем электронные рассылки по Вашему заказу. Заказы и вопросы направляйте на адрес mailbase@post.com. Имеются также маркетинговые базы данных КРУПНЕЙШИХ ПРЕДПРИЯТИЙ: "Предприятия Москвы/России/СНГ с численностью штата более 50/500/1000 человек". Стоимости этх баз данных от $100 до $300. Форма оплаты любая. Базы предоставляется на компакт диске или высылается электронной почтой. Заказы и вопросы направляйте на адрес mailbase@post.com. Базы региональных промышленных предприятий. mailbase@post.com. Компания MailBase, E-mail: mailbase@post.com From noreply@sourceforge.net Sun Sep 9 18:59:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Sep 2001 10:59:25 -0700 Subject: [Patches] [ python-Patches-401335 ] Adds login to auth-type servers (smtplib.py) Message-ID: Patches item #401335, was opened at 2000-08-29 01:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401335&group_id=5470 Category: Library (Lib) Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Ulf Engstrшm (alexisjuh) Assigned to: Jeremy Hylton (jhylton) Summary: Adds login to auth-type servers (smtplib.py) Initial Comment: ---------------------------------------------------------------------- Comment By: Gerhard Hдring (ghaering) Date: 2001-09-09 10:59 Message: Logged In: YES user_id=163326 I'd also recommend to reject this particular patch. No offense, but it seems more like a quick hack for a particular problem than something belonging into the Python standard library to me. I'm working on SMTP AUTH support for smtplib and have a working prototype for the AUTH methods "PLAIN" and "CRAM-MD5". This still needs a lot of cleaning up and some serious testing. Would you prefer this as a new patch or submitted here to keep things in one place? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-08-09 07:52 Message: Logged In: YES user_id=31392 I've never looked at this patch , so I'll defer to Martin who has given it some serious attention. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-06-04 00:37 Message: Logged In: YES user_id=21627 I've transformed this into a patch into a diff-style patch. I've left out the self.authenticated attribute, since it appears never to be set, and since its purpose is unclear. Applying the patch seems harmless, since it just adds another method to the SMTP class. I still recommend rejecting it, since it has no apparent relationship to RFC 2554. In that RFC, the AUTH line of the EHLO response will contain a list of SASL authentication mechanisms, as defined in RFC 2222, and listed in http://www.iana.org/assignments/sasl-mechanisms So a valid AUTH request would be "AUTH CRAM-MD5", as the example in RFC 2554 shows. "AUTH login", as implemented in this patch, does not conform to the RFC. Therefore, I recommend to reject this patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-04 07:44 Message: Jeremy, can you look at this again? ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2000-08-29 02:22 Message: Postponed -- we're in feature freeze. Assigned to Jeremy in case he disagrees. Note also that it's preferable to submit patches in diff format, not as human-readable summaries. Try "diff -c". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401335&group_id=5470 From noreply@sourceforge.net Sun Sep 9 19:03:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Sep 2001 11:03:18 -0700 Subject: [Patches] [ python-Patches-401335 ] Adds login to auth-type servers (smtplib.py) Message-ID: Patches item #401335, was opened at 2000-08-29 01:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401335&group_id=5470 Category: Library (Lib) Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Ulf Engstrшm (alexisjuh) Assigned to: Jeremy Hylton (jhylton) Summary: Adds login to auth-type servers (smtplib.py) Initial Comment: ---------------------------------------------------------------------- Comment By: Gerhard Hдring (ghaering) Date: 2001-09-09 11:03 Message: Logged In: YES user_id=163326 Stupid me. This patch is already rejected, so I'll submit a new one, once I'm ready. ---------------------------------------------------------------------- Comment By: Gerhard Hдring (ghaering) Date: 2001-09-09 10:59 Message: Logged In: YES user_id=163326 I'd also recommend to reject this particular patch. No offense, but it seems more like a quick hack for a particular problem than something belonging into the Python standard library to me. I'm working on SMTP AUTH support for smtplib and have a working prototype for the AUTH methods "PLAIN" and "CRAM-MD5". This still needs a lot of cleaning up and some serious testing. Would you prefer this as a new patch or submitted here to keep things in one place? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-08-09 07:52 Message: Logged In: YES user_id=31392 I've never looked at this patch , so I'll defer to Martin who has given it some serious attention. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-06-04 00:37 Message: Logged In: YES user_id=21627 I've transformed this into a patch into a diff-style patch. I've left out the self.authenticated attribute, since it appears never to be set, and since its purpose is unclear. Applying the patch seems harmless, since it just adds another method to the SMTP class. I still recommend rejecting it, since it has no apparent relationship to RFC 2554. In that RFC, the AUTH line of the EHLO response will contain a list of SASL authentication mechanisms, as defined in RFC 2222, and listed in http://www.iana.org/assignments/sasl-mechanisms So a valid AUTH request would be "AUTH CRAM-MD5", as the example in RFC 2554 shows. "AUTH login", as implemented in this patch, does not conform to the RFC. Therefore, I recommend to reject this patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-04 07:44 Message: Jeremy, can you look at this again? ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2000-08-29 02:22 Message: Postponed -- we're in feature freeze. Assigned to Jeremy in case he disagrees. Note also that it's preferable to submit patches in diff format, not as human-readable summaries. Try "diff -c". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401335&group_id=5470 From mailgrabber-feedback-1@lb.bcentral.com Sun Sep 9 22:46:44 2001 From: mailgrabber-feedback-1@lb.bcentral.com (Anonymouse) Date: 9 Sep 2001 21:46:44 -0000 Subject: [Patches] Продажа,покупка продукции,поиск партнеров. Message-ID: <1000072004.54276.qmail@ech> Уважаемые господа! Что такое Информация ? Информация – это власть, богатство, успех, процветание. Кто владеет информацией, тот управляет. ООО «ВИЭЛЬ-М» предлагает Вам воспользоваться такой информацией и взять на себя проблему поиска необходимого Вам оборудования, сырья, приборов, материалов и т. д., словом всего того, без чего не может существовать Ваше производство, успешно процветать Ваш бизнес. Благодаря обширным связям с ведущими производителями и поставщиками не только в России, но и за рубежом, мы имеем возможность выполнять Ваши заказы наиболее полно и в кратчайшие сроки. Спектр нашей деятельности довольно широк. Это область электроники, причем не только поставки приборов, аппаратуры, но и различные комплектующие как отечественных, так и зарубежных производителей электронной техники. Это такие фирмы как International Rectifier, Epcos, Bourns, Metex, unit-t и др. Это область металловедения- сварочные электроды, металл-лист, уголок, швеллер, лента, трубы и т.д. Это поставки станков, оборудования для производства, аппараты газводы, светильники для офисов и промышленных предприятий, люстры, сварочное оборудование и т.д. Это область медицины- в настоящее время мы представляем уникальное изобретение русского ученого-люстру Чижевского. С полным перечнем продукции, поставляемой нашей фирмой,Вы сможете ознакомиться на нашем сайте в интернет: vielm.narod.ru Информация на данном сайте будет постоянно обновляться и совершенствоваться. Мы не просто предоставляем информацию, где можно достать нужную Вам продукцию, мы сами поставим Вам заказанный товар по выгодным для Вас ценам и в оптимально короткие сроки. Вашу потребность в продукции представленной на нашем сайте, Вы можете отправить на наш факс: (095) 275-89-94, или по электронной почте: tandiv@mail.ru . Мы ждем Вас и выражаем уверенность в том, что обратившись к нам, Вы получите квалифицированную помощь, внимательное отношение к Вашим потребностям, оперативную обработку Вашего заказа. По всем вопросам вы можете обращаться по телефонам: 275-89-94, 746-68-78. _______________________________________________________________________ Powered by List Builder To unsubscribe follow the link: http://lb.bcentral.com/ex/manage/subscriberprefs?customerid=15131&subid=8FC25C37CA314057&msgnum=1 From noreply@sourceforge.net Mon Sep 10 02:29:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Sep 2001 18:29:52 -0700 Subject: [Patches] [ python-Patches-460112 ] SMTP AUTH patch Message-ID: Patches item #460112, was opened at 2001-09-09 18:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460112&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Hдring (ghaering) Assigned to: Nobody/Anonymous (nobody) Summary: SMTP AUTH patch Initial Comment: This patch adds SMTP authentication support to Python's smtplib module. The methods supported by this patch are "CRAM-MD5" and "PLAIN". It also adds a new module hmac for a keyed hash (PEP 247 compatible) to the standard library. The hmac module is needed for the CRAM-MD5 authentication method, but could also be useful for IMAP authentication, for example. I tested this patch against the authenticated SMTP MTA's Postfix (on my own machine) and qmail (on the german Freemail provider GMX). It has one known weakness that I currently don't know how to fix: the return code in case of a failed authentication is always 500 "Bad syntax". Especially the changes to smtlib, but also the new hmac module would like to be reviewed by experienced RFC readers, SMTP and/or Python wizards. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460112&group_id=5470 From noreply@sourceforge.net Mon Sep 10 07:39:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Sep 2001 23:39:13 -0700 Subject: [Patches] [ python-Patches-460112 ] SMTP AUTH patch Message-ID: Patches item #460112, was opened at 2001-09-09 18:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460112&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Hдring (ghaering) Assigned to: Nobody/Anonymous (nobody) Summary: SMTP AUTH patch Initial Comment: This patch adds SMTP authentication support to Python's smtplib module. The methods supported by this patch are "CRAM-MD5" and "PLAIN". It also adds a new module hmac for a keyed hash (PEP 247 compatible) to the standard library. The hmac module is needed for the CRAM-MD5 authentication method, but could also be useful for IMAP authentication, for example. I tested this patch against the authenticated SMTP MTA's Postfix (on my own machine) and qmail (on the german Freemail provider GMX). It has one known weakness that I currently don't know how to fix: the return code in case of a failed authentication is always 500 "Bad syntax". Especially the changes to smtlib, but also the new hmac module would like to be reviewed by experienced RFC readers, SMTP and/or Python wizards. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-09 23:39 Message: Logged In: YES user_id=21627 >From a shallow inspection, the code itself looks ok, structurally and from the proposed new features. Please indicate whether you are willing to write patches to the documentation, since the current patch includes none. In particular, the new module deserves a documentation entry; copying the doc strings is fine. You may also consider writing a Misc/NEWS entry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460112&group_id=5470 From noreply@sourceforge.net Mon Sep 10 14:00:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Sep 2001 06:00:27 -0700 Subject: [Patches] [ python-Patches-458245 ] Reduce import time for xmlrpclib Message-ID: Patches item #458245, was opened at 2001-09-03 19:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458245&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Cesar Eduardo Barros (cesarb) Assigned to: Fredrik Lundh (effbot) Summary: Reduce import time for xmlrpclib Initial Comment: This patch reduces the load time for xmlrpclib.py (my tests show it's about half the load time with the patch) by not loading xmllib when it's not needed. It also simplifies getparser() (by chosing the parser/unmarshaller statically) and avoids declaring slower parsers/unmarshallers when a faster version is available. The indentation is a bit odd, to avoid touching a large amount of code because of indentation changes (to improve the readability of the patch). If it is to be accepted, it might be a good idea to reindent the affected blocks of code. The only test made was the trivial one in the module (getStateName). The patch is against CVS revision 1.4 of xmlrpclib.py ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2001-09-10 06:00 Message: Logged In: YES user_id=38376 The statical binding breaks existing user code (some applications depend on being able to plug in a sloppier parser than the default). I've implemented another variant of lazy loading, which gives a 20x speedup in my test setup. YMMV, as usual. Will appear in a repository near you real soon now. Thanks /F ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458245&group_id=5470 From noreply@sourceforge.net Mon Sep 10 14:30:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Sep 2001 06:30:23 -0700 Subject: [Patches] [ python-Patches-460269 ] Improve threading on Solaris platform. Message-ID: Patches item #460269, was opened at 2001-09-10 06:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460269&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Improve threading on Solaris platform. Initial Comment: To have threading working 'as expected' (i.e. threads that are preempted by the OS and NOT threads that need to have explicit yields), they need to have the 'SYSTEM_SCOPE' attribute set at thread creation on the Solaris platform (at least on SPARC, did not check on x86). This patch adds : - a configure check to see if threads can be created with this attribute without returning an error - the setting of this attribute in the 'standard' case (all draft versions are ignored). This patch NEEDS to be tested on more than one Unices using POSIX threads to be sure that it does not break anything (I only tested it on Solaris). The configure check is a bit awkward as I wanted to actually run some threading programs, so I needed to have all the parameters (CC and LIBS) set properly. Maybe a better way could be found. The attached patch is against version 2.2.a3. Should a patch also be sent for 2.0 or 2.1 releases as a bug fix ? (see comp.langage.python discussion for more details) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460269&group_id=5470 From noreply@sourceforge.net Mon Sep 10 14:34:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Sep 2001 06:34:54 -0700 Subject: [Patches] [ python-Patches-460269 ] Improve threading on Solaris platform. Message-ID: Patches item #460269, was opened at 2001-09-10 06:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460269&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Improve threading on Solaris platform. Initial Comment: To have threading working 'as expected' (i.e. threads that are preempted by the OS and NOT threads that need to have explicit yields), they need to have the 'SYSTEM_SCOPE' attribute set at thread creation on the Solaris platform (at least on SPARC, did not check on x86). This patch adds : - a configure check to see if threads can be created with this attribute without returning an error - the setting of this attribute in the 'standard' case (all draft versions are ignored). This patch NEEDS to be tested on more than one Unices using POSIX threads to be sure that it does not break anything (I only tested it on Solaris). The configure check is a bit awkward as I wanted to actually run some threading programs, so I needed to have all the parameters (CC and LIBS) set properly. Maybe a better way could be found. The attached patch is against version 2.2.a3. Should a patch also be sent for 2.0 or 2.1 releases as a bug fix ? (see comp.langage.python discussion for more details) ---------------------------------------------------------------------- Comment By: Lionel Ulmer (bbrox) Date: 2001-09-10 06:34 Message: Logged In: YES user_id=1344 Just to say that I somewhat screwed up and posted this patch as 'nobody' whereas I have an SF account... So for any comments, please send mail to bbrox@bbrox.org or lionel.ulmer@free.fr. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460269&group_id=5470 From noreply@sourceforge.net Mon Sep 10 15:10:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Sep 2001 07:10:57 -0700 Subject: [Patches] [ python-Patches-460269 ] Improve threading on Solaris platform. Message-ID: Patches item #460269, was opened at 2001-09-10 06:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460269&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Guido van Rossum (gvanrossum) Summary: Improve threading on Solaris platform. Initial Comment: To have threading working 'as expected' (i.e. threads that are preempted by the OS and NOT threads that need to have explicit yields), they need to have the 'SYSTEM_SCOPE' attribute set at thread creation on the Solaris platform (at least on SPARC, did not check on x86). This patch adds : - a configure check to see if threads can be created with this attribute without returning an error - the setting of this attribute in the 'standard' case (all draft versions are ignored). This patch NEEDS to be tested on more than one Unices using POSIX threads to be sure that it does not break anything (I only tested it on Solaris). The configure check is a bit awkward as I wanted to actually run some threading programs, so I needed to have all the parameters (CC and LIBS) set properly. Maybe a better way could be found. The attached patch is against version 2.2.a3. Should a patch also be sent for 2.0 or 2.1 releases as a bug fix ? (see comp.langage.python discussion for more details) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-10 07:10 Message: Logged In: YES user_id=6380 Looks good to me, and checked in. Do you know of any reason why we couldn't always declare the 'attrs' variable, initialize it, and pass it to pthread_create()? That would save a lot of #ifdef mess in PyThread_start_new_thread(). ---------------------------------------------------------------------- Comment By: Lionel Ulmer (bbrox) Date: 2001-09-10 06:34 Message: Logged In: YES user_id=1344 Just to say that I somewhat screwed up and posted this patch as 'nobody' whereas I have an SF account... So for any comments, please send mail to bbrox@bbrox.org or lionel.ulmer@free.fr. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460269&group_id=5470 From noreply@sourceforge.net Mon Sep 10 15:18:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Sep 2001 07:18:50 -0700 Subject: [Patches] [ python-Patches-403753 ] zlib decompress; uncontrollable memory usage Message-ID: Patches item #403753, was opened at 2001-02-12 08:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403753&group_id=5470 Category: Modules Group: None Status: Open Resolution: Out of Date Priority: 5 Submitted By: Toby Dickenson (htrd) Assigned to: Jeremy Hylton (jhylton) Summary: zlib decompress; uncontrollable memory usage Initial Comment: zlib's decompress method will allocate as much memory as is needed to hold the decompressed output. The length of the output buffer may be very much larger than the length of the input buffer, and the python code calling the decompress method has no other way to control how much memory is allocated. In experimentation, I seen decompress generate output that is 1000 times larger than its input These characteristics may make the decompress method unsuitable for handling data obtained from untrusted sources (for example, in a http proxy which implements gzip encoding) since it may be vulnerable to a denial of service attack. A malicious user could construct a moderately sized input which forces 'decompress' to try to allocate too much memory. This patch adds a new method, decompress_incremental, which allows the caller to specify the maximum size of the output. This method returns the excess input, in addition to the decompressed output. It is possible to solve this problem without a patch: If input is fed to the decompressor a few tens of bytes at a time, memory usage will surge by (at most) a few tens of kilobytes. Such a process is a kludge, and much less efficient that the approach used in this patch. (Ive not been able to test the documentation patch; I hope its ok) (This patch also includes the change from Patch #103748) ---------------------------------------------------------------------- >Comment By: Toby Dickenson (htrd) Date: 2001-09-10 07:18 Message: Logged In: YES user_id=46460 I volunteer to update it ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-07 10:03 Message: Logged In: YES user_id=21627 Since this patch has been sitting around for such a long time, it eventually got outdated, due to the conflicting MT patch. Any volunteers to update it? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-06-04 13:55 Message: Logged In: YES user_id=21627 The patch looks good to me; I recommend to approve it. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-04-10 10:52 Message: Logged In: YES user_id=11375 I've let this patch gather dust long enough. Unassigning so that someone else can review it. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2001-04-07 00:20 Message: Logged In: YES user_id=413 as a side note. I believe I implemented a python workaround for this problem by just decompressing data in small chunks (4k at a time) using a decompressor object. see the mojonation project on sourceforge if you're curious. (specifically, in the mojonation evil module, look at common/mojoutil.py for function named safe_zlib_decompress). Regardless, I like thie idea of this patch. It would be good to have that in the main API and documentation for simplicity. (and because there are too many programmers out there who don't realize potential denial of service issues on their own...) ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-22 04:50 Message: New patch implementing a new optional parameter to .decompress, and a new attribute .unconsumed_tail ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-22 03:42 Message: Waaah - that last comment should be 'cant' not 'can' ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-22 03:40 Message: We can reuse .unused_data without introducing an ambiguity. I will prepare a patch that uses a new attribute .unconsumed_tail ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-02-21 11:32 Message: Doesn't .unused_data serve much the same purpose, though? So that even with a maximum size, .decompress() always returns a string, and .unused_data would contain the unprocessed data. ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-21 06:00 Message: I did consider that.... An extra change that you didnt mention is the need for a different return value. Currently .decompress() always returns a string. The new method in my patch returns a tuple containing the same string, and an integer specifying how many bytes were consumed from the input. Overloading return values based on an optional parameter seems a little hairy to me, but I would be happy to change the patch if that is your preferred option. I also considered (and rejected) the possibility of adding an optional max-size argument to .decompress() as you suggest, but raising an exception if this limit is exceeded. This avoids the need for an extra return value, but looses out on flexibility. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-02-20 18:48 Message: Rather than introducing a new method, why not just add an optional maxlen argument to .decompress(). I think the changes would be: * add 'int maxlen=-1;' * add "...|i" ... ,&maxlen to the argument parsing * if maxlen != -1, length = maxlen else length = DEFAULTALLOC; * Add '&& maxlen==-1' to the while loop. (Use the current CVS; I just checked in a patch rearranging the zlib module a bit.) Do you want to make those changes and resubmit the patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403753&group_id=5470 From noreply@sourceforge.net Mon Sep 10 15:20:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Sep 2001 07:20:04 -0700 Subject: [Patches] [ python-Patches-416704 ] More robust freeze Message-ID: Patches item #416704, was opened at 2001-04-17 07:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416704&group_id=5470 Category: None Group: None Status: Open Resolution: Out of Date Priority: 5 Submitted By: Toby Dickenson (htrd) Assigned to: Guido van Rossum (gvanrossum) Summary: More robust freeze Initial Comment: This patch addresses three issues, all relating to robustness of frozen programs. Specifically, this patch allows explicit and complete control over which modules may be loaded from source on the filesystem of the host system where the frozen program is run, and which may not. Without this patch it is impossible to create a non- trivial frozen program which will *never* load a module from source on the filesystem. 1. A patch to correct bug #404545 (frozen package import uses wrong files). Under this change, submodules of a frozen package must themselves be frozen modules. Previously, the import machinery may also try to import submodules from curiously named files (packagename.modulename.py) from directories in sys.path 2. A patch to add an extra command line option -E to freeze.py, which forces freeze to terminate with an error message if there are modules that it can not locate. If this switch is not specified then the default behaviour is unchanged: modules which can not be found by freeze will not be included in the frozen program, and the import machinery will try to load them from source on sys.path when the frozen program is run. In practice we have found that a missing module is probably an error (and it is a fairly frequent error too!). The -E switch can be used to detect this error; any missing modules will cause freeze.py to fail. In the rare case of a frozen module importing a non- frozen one (ie one which should be loaded from source when the program is run), the non-frozen module must be excluded from the freeze using the -x option. 3. A patch to add an extra command line option -X to freeze.py, which indicates that a specified module is excluded from the freeze, and also that the frozen program should not try to load the module from sys.path when it is imported. Importing the specified module will always trigger an ImportError. This is useful if a module used by a frozen program can optionally use a submodule... try: import optional_submodule except ImportError: pass It may be preferable for the frozen program's behaviour to not depend on whether optional_submodule happens to be installed on the host system, and that the 'import optional_submodule' should always fail with an ImportError. This can be achieved using the '- X optional_submodule' command line switch to freeze.py This is implemented by including the excluded module in the frozen imports table (_PyImport_FrozenModules), with the code pointer set to NULL. ---------------------------------------------------------------------- >Comment By: Toby Dickenson (htrd) Date: 2001-09-10 07:20 Message: Logged In: YES user_id=46460 OK, I should get round to this soon. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 08:50 Message: Logged In: YES user_id=6380 I'm willing to look at this, but right now the patch doesn't apply cleanly. From the headers in the diff file it looks like you're patching an early beta for 2.0. If you can rework this for current CVS or Python 2.2a2 or 2.2a3, that would be great. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-06-07 15:26 Message: Logged In: YES user_id=21627 Why is this assigned to Mark? I cannot see anything windows-specific in it. Mark, if you are not interested in reviewing this patch, I recommend to unassign this from yourself. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416704&group_id=5470 From noreply@sourceforge.net Mon Sep 10 19:48:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Sep 2001 11:48:35 -0700 Subject: [Patches] [ python-Patches-460402 ] PEP 270: uniq() method for list objects Message-ID: Patches item #460402, was opened at 2001-09-10 11:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460402&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Petrone (jpetrone) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 270: uniq() method for list objects Initial Comment: Remove duplicate elements from a list object. 3 Patches: uniq.doc.patch - Documentation changes in libstdtypes.tex uniq.ordered.patch - Changes to listmodule.c for brute force duplicate removal with uniq(). Maintains list order. uniq.unordered.patch - Changes to listmodule.c for duplicate removal with uniq() First tries using a mapping object. If the list elements aren't mapable, tries sorted removal. If the list isn't sortable, finally falls back on brute force removal. Does not maintain list order. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460402&group_id=5470 From noreply@sourceforge.net Mon Sep 10 19:51:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Sep 2001 11:51:54 -0700 Subject: [Patches] [ python-Patches-401022 ] Removal of SET_LINENO (experimental) Message-ID: Patches item #401022, was opened at 2000-07-30 16:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401022&group_id=5470 Category: Core (C code) Group: None >Status: Open >Resolution: Out of Date Priority: 5 Submitted By: Vladimir Marangozov (marangoz) >Assigned to: Tim Peters (tim_one) Summary: Removal of SET_LINENO (experimental) Initial Comment: ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-10 11:51 Message: Logged In: YES user_id=6380 Tim wants to revisit this. It could be the quickest way to a 7% speedup in pystone that we can think of... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-11-13 11:42 Message: Rejected. It's in the archives for reference, but for now, I don't think it's worth spending cycles worrying about this kind of stuff. I'll eventually redesign the entire VM. ---------------------------------------------------------------------- Comment By: Vladimir Marangozov (marangoz) Date: 2000-10-27 04:08 Message: Oops, the last patch update does not contain the f.f_lineno computation in frame_getattr. This is necessary, cf. the following messages: http://www.python.org/pipermail/python-dev/2000-July/014395.html http://www.python.org/pipermail/python-dev/2000-July/014401.html Patch assigned to Guido, for review or further assignment. ---------------------------------------------------------------------- Comment By: Vladimir Marangozov (marangoz) Date: 2000-10-25 17:42 Message: noreply@sourceforge.net wrote: > > Date: 2000-Oct-25 13:56 > By: gvanrossum > > Comment: > Vladimir, are you there? So-so :) I'm a moving target, checking my mail occasionally these days. Luckily, today is one of these days. > > The patch doesn't apply cleanly to the current CVS tree any more... Ah, this one's easy. Here's an update relative to 2.0 final, not CVS. I got some r/w access error trying to update my CVS copy from SF that I have no time to investigate right now... The Web interface still works though :) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-25 13:56 Message: Vladimir, are you there? The patch doesn't apply cleanly to the current CVS tree any more... ---------------------------------------------------------------------- Comment By: Vladimir Marangozov (marangoz) Date: 2000-08-03 12:22 Message: Fix missing DECREF on error condition in start_tracing() + some renaming. ---------------------------------------------------------------------- Comment By: Vladimir Marangozov (marangoz) Date: 2000-07-31 10:50 Message: A last tiny fix of the SET_LINENO opcode for better b/w compatibility. Stopping here and entering standby mode for reactions & feedback. PS: the last idea about not duplicating co_code and tweaking the original with CALL_TRACE is a bad one. I remember Guido being against it because co_code could be used elsewhere (copied, written to disk, whatever) and he's right! Better operate on an internal copy created in ceval. ---------------------------------------------------------------------- Comment By: Vladimir Marangozov (marangoz) Date: 2000-07-31 07:57 Message: Another rewrite, making this whole strategy b/w compatible according to the 1st incompatibility point a) described in: http://www.python.org/pipermail/python-dev/2000-July/014364.html Changes: 1. f.f_lineno is computed and updated on f_lineno attribute requests for f, given f.f_lasti. Correctness is ensured because f.f_lasti is updated on *all* attribute accesses (in LOAD_ATTR in the main loop). 2. The standard setup does not generate SET_LINENO, but uses co_lnotab for computing the source line number (e.g. tracebacks) This is equivalent to the actual "python -O". 3. With "python -d", we fall back to the current version of the interpreter (with SET_LINENO) thus making it easy to test whether this patch fully replaces SET_LINENO's behavior. (modulo f->f_lineno accesses from legacy C code, but this is insane). IMO, this version already worths the pain to be truly tested and improved. One improvement is to define a nicer public C API for breakpoints: - PyCode_SetBreakPointAtLine(line) - PyCode_SetBreakPointAtAddr(addr) or similar, which would install a CALL_TRACE opcode in the appropriate location of the copy of co_code. Another idea is to avoid duplicating the entire co_code just for storing the CALL_TRACE opcodes. We can store them in the original and keep a table of breakpoints. Setting the breakpoints would occur whenever the sys.settrace hook is set. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-07-31 06:40 Message: Status set to postponed to indicate that this is still experimental. ---------------------------------------------------------------------- Comment By: Vladimir Marangozov (marangoz) Date: 2000-07-30 18:16 Message: A nit: inline the argfetch in CALL_TRACE and goto the switch, instead of jumping to get_oparg which splits the sequence [fetch opcode, fetch oparg] -- this can slow things down. ---------------------------------------------------------------------- Comment By: Vladimir Marangozov (marangoz) Date: 2000-07-30 16:12 Message: For testing, as discussed on python-dev. For a gentle summary, see: http://www.python.org/pipermail/python-dev/2000-July/014364.html ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401022&group_id=5470 From noreply@sourceforge.net Mon Sep 10 19:53:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Sep 2001 11:53:41 -0700 Subject: [Patches] [ python-Patches-460269 ] Improve threading on Solaris platform. Message-ID: Patches item #460269, was opened at 2001-09-10 06:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460269&group_id=5470 Category: Core (C code) Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: Improve threading on Solaris platform. Initial Comment: To have threading working 'as expected' (i.e. threads that are preempted by the OS and NOT threads that need to have explicit yields), they need to have the 'SYSTEM_SCOPE' attribute set at thread creation on the Solaris platform (at least on SPARC, did not check on x86). This patch adds : - a configure check to see if threads can be created with this attribute without returning an error - the setting of this attribute in the 'standard' case (all draft versions are ignored). This patch NEEDS to be tested on more than one Unices using POSIX threads to be sure that it does not break anything (I only tested it on Solaris). The configure check is a bit awkward as I wanted to actually run some threading programs, so I needed to have all the parameters (CC and LIBS) set properly. Maybe a better way could be found. The attached patch is against version 2.2.a3. Should a patch also be sent for 2.0 or 2.1 releases as a bug fix ? (see comp.langage.python discussion for more details) ---------------------------------------------------------------------- Comment By: Lionel Ulmer (bbrox) Date: 2001-09-10 11:53 Message: Logged In: YES user_id=1344 Thanks for the commit. As for my patch, I did the 'minimize risk' approach by changing the less code as possible. But I agree that, according to the man pages and the POSIX threads documentations that passing 'attrs' (initialized with 'pthread_attr_init') should be completely equivalent to passing NULL. So, at least in the 'PY_PTHREAD_STD' case, we could always use 'attrs' and never the NULL attributes (anyway, I think that with my patch, all of the POSIX compliant pthread libraries will support the SCOPE_SYSTEM attribute and thus the NULL case will almost never be used). By the way, once this has been tested, should I generate a patch for 2.1 / 2.0 ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-10 07:10 Message: Logged In: YES user_id=6380 Looks good to me, and checked in. Do you know of any reason why we couldn't always declare the 'attrs' variable, initialize it, and pass it to pthread_create()? That would save a lot of #ifdef mess in PyThread_start_new_thread(). ---------------------------------------------------------------------- Comment By: Lionel Ulmer (bbrox) Date: 2001-09-10 06:34 Message: Logged In: YES user_id=1344 Just to say that I somewhat screwed up and posted this patch as 'nobody' whereas I have an SF account... So for any comments, please send mail to bbrox@bbrox.org or lionel.ulmer@free.fr. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460269&group_id=5470 From noreply@sourceforge.net Mon Sep 10 19:59:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Sep 2001 11:59:59 -0700 Subject: [Patches] [ python-Patches-460269 ] Improve threading on Solaris platform. Message-ID: Patches item #460269, was opened at 2001-09-10 06:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460269&group_id=5470 Category: Core (C code) Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: Improve threading on Solaris platform. Initial Comment: To have threading working 'as expected' (i.e. threads that are preempted by the OS and NOT threads that need to have explicit yields), they need to have the 'SYSTEM_SCOPE' attribute set at thread creation on the Solaris platform (at least on SPARC, did not check on x86). This patch adds : - a configure check to see if threads can be created with this attribute without returning an error - the setting of this attribute in the 'standard' case (all draft versions are ignored). This patch NEEDS to be tested on more than one Unices using POSIX threads to be sure that it does not break anything (I only tested it on Solaris). The configure check is a bit awkward as I wanted to actually run some threading programs, so I needed to have all the parameters (CC and LIBS) set properly. Maybe a better way could be found. The attached patch is against version 2.2.a3. Should a patch also be sent for 2.0 or 2.1 releases as a bug fix ? (see comp.langage.python discussion for more details) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-10 11:59 Message: Logged In: YES user_id=6380 Well, the rub is in PY_PTHREAD_STD. :-) No need for 2.0/2.1 patches -- development on those has effectively stopped. ---------------------------------------------------------------------- Comment By: Lionel Ulmer (bbrox) Date: 2001-09-10 11:53 Message: Logged In: YES user_id=1344 Thanks for the commit. As for my patch, I did the 'minimize risk' approach by changing the less code as possible. But I agree that, according to the man pages and the POSIX threads documentations that passing 'attrs' (initialized with 'pthread_attr_init') should be completely equivalent to passing NULL. So, at least in the 'PY_PTHREAD_STD' case, we could always use 'attrs' and never the NULL attributes (anyway, I think that with my patch, all of the POSIX compliant pthread libraries will support the SCOPE_SYSTEM attribute and thus the NULL case will almost never be used). By the way, once this has been tested, should I generate a patch for 2.1 / 2.0 ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-10 07:10 Message: Logged In: YES user_id=6380 Looks good to me, and checked in. Do you know of any reason why we couldn't always declare the 'attrs' variable, initialize it, and pass it to pthread_create()? That would save a lot of #ifdef mess in PyThread_start_new_thread(). ---------------------------------------------------------------------- Comment By: Lionel Ulmer (bbrox) Date: 2001-09-10 06:34 Message: Logged In: YES user_id=1344 Just to say that I somewhat screwed up and posted this patch as 'nobody' whereas I have an SF account... So for any comments, please send mail to bbrox@bbrox.org or lionel.ulmer@free.fr. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460269&group_id=5470 From noreply@sourceforge.net Tue Sep 11 02:07:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Sep 2001 18:07:31 -0700 Subject: [Patches] [ python-Patches-460532 ] minidom.Node.text(), per TODO Message-ID: Patches item #460532, was opened at 2001-09-10 18:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460532&group_id=5470 Category: XML Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chip Salzenberg (chip) Assigned to: Nobody/Anonymous (nobody) Summary: minidom.Node.text(), per TODO Initial Comment: The TODO list for the minidom includes "more convenience methods for text and entities". Well, here's a text() method I've found helpful. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460532&group_id=5470 From noreply@sourceforge.net Tue Sep 11 03:46:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Sep 2001 19:46:28 -0700 Subject: [Patches] [ python-Patches-460554 ] Fix asyncore.dispatcher.__repr__ Message-ID: Patches item #460554, was opened at 2001-09-10 19:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460554&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cesar Eduardo Barros (cesarb) Assigned to: Nobody/Anonymous (nobody) Summary: Fix asyncore.dispatcher.__repr__ Initial Comment: This patch fixes a bug that caused the __repr__ method in asyncore.dispatcher to fail when self.addr was a tuple. If it is accepted, you might also think of removing the "import types" line and using type(()) instead of types.TupleType; the types module is used only in that line. The patch is relative to version 1.17 of asyncore.py ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460554&group_id=5470 From noreply@sourceforge.net Tue Sep 11 03:52:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Sep 2001 19:52:39 -0700 Subject: [Patches] [ python-Patches-460112 ] SMTP AUTH patch Message-ID: Patches item #460112, was opened at 2001-09-09 18:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460112&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Hдring (ghaering) Assigned to: Nobody/Anonymous (nobody) Summary: SMTP AUTH patch Initial Comment: This patch adds SMTP authentication support to Python's smtplib module. The methods supported by this patch are "CRAM-MD5" and "PLAIN". It also adds a new module hmac for a keyed hash (PEP 247 compatible) to the standard library. The hmac module is needed for the CRAM-MD5 authentication method, but could also be useful for IMAP authentication, for example. I tested this patch against the authenticated SMTP MTA's Postfix (on my own machine) and qmail (on the german Freemail provider GMX). It has one known weakness that I currently don't know how to fix: the return code in case of a failed authentication is always 500 "Bad syntax". Especially the changes to smtlib, but also the new hmac module would like to be reviewed by experienced RFC readers, SMTP and/or Python wizards. ---------------------------------------------------------------------- >Comment By: Gerhard Hдring (ghaering) Date: 2001-09-10 19:52 Message: Logged In: YES user_id=163326 I meanwhile fixed the "syntax error" problem. The cause was base64.encodestring() adding an extra newline character. I've updated the patch with documentation and a Misc/NEWS entry. With this patch, the documentation doesn't correctly build. I think the cause is the new hmac module. Would somebody please take a look at it? I've never used the Python doc system before, so I'm a bit lost at the moment. The error message when building the docs is: """ +++ latex dist +++ latex2html -init_file dist.l2h -dir /mnt/data1/src/python/dist/src/Doc/html/dist /mnt/data1/src/python/dist/src/Doc/dist/dist.tex +++ perl /mnt/data1/src/python/dist/src/Doc/tools/node2label.pl *.html python tools/rewrite.py texinputs/boilerplate.tex RELEASE=2.2a3 \ html/index.html cd html && \ python ../tools/mkmodindex --columns 4 \ --output modindex.html --address "See About this document... for information on suggesting changes." \ lib/modindex.html mac/modindex.html Traceback (most recent call last): File "../tools/mkmodindex", line 139, in ? main() File "../tools/mkmodindex", line 94, in main ifp = open(ifn) IOError: [Errno 2] No such file or directory: 'lib/modindex.html' make: *** [html/modindex.html] Error 1 """ Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-09 23:39 Message: Logged In: YES user_id=21627 >From a shallow inspection, the code itself looks ok, structurally and from the proposed new features. Please indicate whether you are willing to write patches to the documentation, since the current patch includes none. In particular, the new module deserves a documentation entry; copying the doc strings is fine. You may also consider writing a Misc/NEWS entry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460112&group_id=5470 From noreply@sourceforge.net Tue Sep 11 16:04:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Sep 2001 08:04:43 -0700 Subject: [Patches] [ python-Patches-460532 ] minidom.Node.text(), per TODO Message-ID: Patches item #460532, was opened at 2001-09-10 18:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460532&group_id=5470 Category: XML Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chip Salzenberg (chip) Assigned to: Nobody/Anonymous (nobody) Summary: minidom.Node.text(), per TODO Initial Comment: The TODO list for the minidom includes "more convenience methods for text and entities". Well, here's a text() method I've found helpful. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-11 08:04 Message: Logged In: YES user_id=21627 I'm tempted to reject this, since it is not in the DOM specification. I believe the remark in the TODO list referred to convenience functions defined in DOM level 2, most of which have been implemented already. If a text function was implemented, I feel it should have the semantics of the XPath text() node test. If you want to see this patch integrated, I recommend discussing it on xml-sig first. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460532&group_id=5470 From noreply@sourceforge.net Tue Sep 11 16:11:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Sep 2001 08:11:56 -0700 Subject: [Patches] [ python-Patches-459441 ] URL correction in distutils docu Message-ID: Patches item #459441, was opened at 2001-09-07 00:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459441&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Rene Liebscher (rliebscher) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: URL correction in distutils docu Initial Comment: This patches fixes a URL in the distutils documentation file inst.tex. This URL points to my website, but it will become unavailable in the next months. So I moved the files to the sourceforge project (PyOpenGL) for which I originally needed them. You may probably want to remove this paragraph as whole because there are currently only files for Python 2.0 to find. (I might put there also the files for Python 2.1 and 2.2, when I needed them.) It would be probably better, if such files would maintained somewhere at python.org for all versions of Python. (I don't think it will be a problem to find someone who is testing all new Python releases and provides these files.) Kind regards Rene Liebscher ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-09-11 08:11 Message: Logged In: YES user_id=3066 Checked in as Doc/inst/inst.tex revision 1.35. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459441&group_id=5470 From noreply@sourceforge.net Tue Sep 11 16:14:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Sep 2001 08:14:54 -0700 Subject: [Patches] [ python-Patches-460554 ] Fix asyncore.dispatcher.__repr__ Message-ID: Patches item #460554, was opened at 2001-09-10 19:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460554&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cesar Eduardo Barros (cesarb) Assigned to: Nobody/Anonymous (nobody) Summary: Fix asyncore.dispatcher.__repr__ Initial Comment: This patch fixes a bug that caused the __repr__ method in asyncore.dispatcher to fail when self.addr was a tuple. If it is accepted, you might also think of removing the "import types" line and using type(()) instead of types.TupleType; the types module is used only in that line. The patch is relative to version 1.17 of asyncore.py ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-11 08:14 Message: Logged In: YES user_id=21627 Thanks for the patch, I have committed it as asyncore.py 1.18. Using type(()) is not recommended, since types.TupleType is more explicit. If anything, this could be changed to if type(self.addr) == tuple: or isinstance(self.addr, tuple). However, such a change, if desirable, should be made throughout the library. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460554&group_id=5470 From noreply@sourceforge.net Tue Sep 11 16:15:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Sep 2001 08:15:31 -0700 Subject: [Patches] [ python-Patches-460554 ] Fix asyncore.dispatcher.__repr__ Message-ID: Patches item #460554, was opened at 2001-09-10 19:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460554&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Cesar Eduardo Barros (cesarb) Assigned to: Nobody/Anonymous (nobody) Summary: Fix asyncore.dispatcher.__repr__ Initial Comment: This patch fixes a bug that caused the __repr__ method in asyncore.dispatcher to fail when self.addr was a tuple. If it is accepted, you might also think of removing the "import types" line and using type(()) instead of types.TupleType; the types module is used only in that line. The patch is relative to version 1.17 of asyncore.py ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-11 08:14 Message: Logged In: YES user_id=21627 Thanks for the patch, I have committed it as asyncore.py 1.18. Using type(()) is not recommended, since types.TupleType is more explicit. If anything, this could be changed to if type(self.addr) == tuple: or isinstance(self.addr, tuple). However, such a change, if desirable, should be made throughout the library. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460554&group_id=5470 From noreply@sourceforge.net Tue Sep 11 16:51:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Sep 2001 08:51:11 -0700 Subject: [Patches] [ python-Patches-460112 ] SMTP AUTH patch Message-ID: Patches item #460112, was opened at 2001-09-09 18:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460112&group_id=5470 Category: Library (Lib) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Gerhard Hдring (ghaering) >Assigned to: Guido van Rossum (gvanrossum) Summary: SMTP AUTH patch Initial Comment: This patch adds SMTP authentication support to Python's smtplib module. The methods supported by this patch are "CRAM-MD5" and "PLAIN". It also adds a new module hmac for a keyed hash (PEP 247 compatible) to the standard library. The hmac module is needed for the CRAM-MD5 authentication method, but could also be useful for IMAP authentication, for example. I tested this patch against the authenticated SMTP MTA's Postfix (on my own machine) and qmail (on the german Freemail provider GMX). It has one known weakness that I currently don't know how to fix: the return code in case of a failed authentication is always 500 "Bad syntax". Especially the changes to smtlib, but also the new hmac module would like to be reviewed by experienced RFC readers, SMTP and/or Python wizards. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-11 08:51 Message: Logged In: YES user_id=6380 The patch and new module look good. I successfully sent a message using Zope.com's secure SMTP service, but this only uses plaintext passwords, so I've not tested hmac.py. That module looks good too though, so I'll check it in and let additional review happen while in CVS. ---------------------------------------------------------------------- Comment By: Gerhard Hдring (ghaering) Date: 2001-09-10 19:52 Message: Logged In: YES user_id=163326 I meanwhile fixed the "syntax error" problem. The cause was base64.encodestring() adding an extra newline character. I've updated the patch with documentation and a Misc/NEWS entry. With this patch, the documentation doesn't correctly build. I think the cause is the new hmac module. Would somebody please take a look at it? I've never used the Python doc system before, so I'm a bit lost at the moment. The error message when building the docs is: """ +++ latex dist +++ latex2html -init_file dist.l2h -dir /mnt/data1/src/python/dist/src/Doc/html/dist /mnt/data1/src/python/dist/src/Doc/dist/dist.tex +++ perl /mnt/data1/src/python/dist/src/Doc/tools/node2label.pl *.html python tools/rewrite.py texinputs/boilerplate.tex RELEASE=2.2a3 \ html/index.html cd html && \ python ../tools/mkmodindex --columns 4 \ --output modindex.html --address "See About this document... for information on suggesting changes." \ lib/modindex.html mac/modindex.html Traceback (most recent call last): File "../tools/mkmodindex", line 139, in ? main() File "../tools/mkmodindex", line 94, in main ifp = open(ifn) IOError: [Errno 2] No such file or directory: 'lib/modindex.html' make: *** [html/modindex.html] Error 1 """ Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-09 23:39 Message: Logged In: YES user_id=21627 >From a shallow inspection, the code itself looks ok, structurally and from the proposed new features. Please indicate whether you are willing to write patches to the documentation, since the current patch includes none. In particular, the new module deserves a documentation entry; copying the doc strings is fine. You may also consider writing a Misc/NEWS entry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460112&group_id=5470 From noreply@sourceforge.net Tue Sep 11 17:00:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Sep 2001 09:00:12 -0700 Subject: [Patches] [ python-Patches-460112 ] SMTP AUTH patch Message-ID: Patches item #460112, was opened at 2001-09-09 18:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460112&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Gerhard Hдring (ghaering) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: SMTP AUTH patch Initial Comment: This patch adds SMTP authentication support to Python's smtplib module. The methods supported by this patch are "CRAM-MD5" and "PLAIN". It also adds a new module hmac for a keyed hash (PEP 247 compatible) to the standard library. The hmac module is needed for the CRAM-MD5 authentication method, but could also be useful for IMAP authentication, for example. I tested this patch against the authenticated SMTP MTA's Postfix (on my own machine) and qmail (on the german Freemail provider GMX). It has one known weakness that I currently don't know how to fix: the return code in case of a failed authentication is always 500 "Bad syntax". Especially the changes to smtlib, but also the new hmac module would like to be reviewed by experienced RFC readers, SMTP and/or Python wizards. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-11 09:00 Message: Logged In: YES user_id=6380 Assigned to Fred for doc review and checkin. (Use the 3rd file download.) Thanks, Gerhard! One remark on docstrings: please don't start docstrings with """ on a line by itself, and please insert a blank line between the first line of the docstring (the summary line) and the body of the docstring, if there is a body. See PEP 257. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-11 08:51 Message: Logged In: YES user_id=6380 The patch and new module look good. I successfully sent a message using Zope.com's secure SMTP service, but this only uses plaintext passwords, so I've not tested hmac.py. That module looks good too though, so I'll check it in and let additional review happen while in CVS. ---------------------------------------------------------------------- Comment By: Gerhard Hдring (ghaering) Date: 2001-09-10 19:52 Message: Logged In: YES user_id=163326 I meanwhile fixed the "syntax error" problem. The cause was base64.encodestring() adding an extra newline character. I've updated the patch with documentation and a Misc/NEWS entry. With this patch, the documentation doesn't correctly build. I think the cause is the new hmac module. Would somebody please take a look at it? I've never used the Python doc system before, so I'm a bit lost at the moment. The error message when building the docs is: """ +++ latex dist +++ latex2html -init_file dist.l2h -dir /mnt/data1/src/python/dist/src/Doc/html/dist /mnt/data1/src/python/dist/src/Doc/dist/dist.tex +++ perl /mnt/data1/src/python/dist/src/Doc/tools/node2label.pl *.html python tools/rewrite.py texinputs/boilerplate.tex RELEASE=2.2a3 \ html/index.html cd html && \ python ../tools/mkmodindex --columns 4 \ --output modindex.html --address "See About this document... for information on suggesting changes." \ lib/modindex.html mac/modindex.html Traceback (most recent call last): File "../tools/mkmodindex", line 139, in ? main() File "../tools/mkmodindex", line 94, in main ifp = open(ifn) IOError: [Errno 2] No such file or directory: 'lib/modindex.html' make: *** [html/modindex.html] Error 1 """ Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-09 23:39 Message: Logged In: YES user_id=21627 >From a shallow inspection, the code itself looks ok, structurally and from the proposed new features. Please indicate whether you are willing to write patches to the documentation, since the current patch includes none. In particular, the new module deserves a documentation entry; copying the doc strings is fine. You may also consider writing a Misc/NEWS entry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460112&group_id=5470 From noreply@sourceforge.net Tue Sep 11 17:27:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Sep 2001 09:27:25 -0700 Subject: [Patches] [ python-Patches-453691 ] CGI: NEW: methods getfirst(), getlist() Message-ID: Patches item #453691, was opened at 2001-08-21 04:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453691&group_id=5470 Category: Documentation Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Tomas Styblo (tripiecz) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: CGI: NEW: methods getfirst(), getlist() Initial Comment: This is updated version of my cgi.py patch #452174. The attached file 'pycgi.patch' modifies 'Doc/lib/libcgi.tex' and 'Lib/cgi.py'. It's based on current CVS. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-09-11 09:27 Message: Logged In: YES user_id=3066 Checked in a modified documentation patch as Doc/lib/libcgi.tex revision 1.33. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 12:46 Message: Logged In: YES user_id=6380 Checked in as cgi.py rev 1.67. Assigned to Fred for documentation review and checkin. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 12:36 Message: Logged In: YES user_id=6380 Accepted. Waiting for SF CVS to come back online. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453691&group_id=5470 From noreply@sourceforge.net Tue Sep 11 18:00:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Sep 2001 10:00:24 -0700 Subject: [Patches] [ python-Patches-460112 ] SMTP AUTH patch Message-ID: Patches item #460112, was opened at 2001-09-09 18:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460112&group_id=5470 Category: Library (Lib) Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Gerhard Hдring (ghaering) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: SMTP AUTH patch Initial Comment: This patch adds SMTP authentication support to Python's smtplib module. The methods supported by this patch are "CRAM-MD5" and "PLAIN". It also adds a new module hmac for a keyed hash (PEP 247 compatible) to the standard library. The hmac module is needed for the CRAM-MD5 authentication method, but could also be useful for IMAP authentication, for example. I tested this patch against the authenticated SMTP MTA's Postfix (on my own machine) and qmail (on the german Freemail provider GMX). It has one known weakness that I currently don't know how to fix: the return code in case of a failed authentication is always 500 "Bad syntax". Especially the changes to smtlib, but also the new hmac module would like to be reviewed by experienced RFC readers, SMTP and/or Python wizards. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-09-11 10:00 Message: Logged In: YES user_id=3066 Documentation checked in with slight modifications as Doc/lib/libhmac.tex 1.1, Doc/lib/libsmtplib.tex 1.18, Doc/lib/lib.tex 1.191, Doc/Makefile.deps 1.73. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-11 09:00 Message: Logged In: YES user_id=6380 Assigned to Fred for doc review and checkin. (Use the 3rd file download.) Thanks, Gerhard! One remark on docstrings: please don't start docstrings with """ on a line by itself, and please insert a blank line between the first line of the docstring (the summary line) and the body of the docstring, if there is a body. See PEP 257. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-11 08:51 Message: Logged In: YES user_id=6380 The patch and new module look good. I successfully sent a message using Zope.com's secure SMTP service, but this only uses plaintext passwords, so I've not tested hmac.py. That module looks good too though, so I'll check it in and let additional review happen while in CVS. ---------------------------------------------------------------------- Comment By: Gerhard Hдring (ghaering) Date: 2001-09-10 19:52 Message: Logged In: YES user_id=163326 I meanwhile fixed the "syntax error" problem. The cause was base64.encodestring() adding an extra newline character. I've updated the patch with documentation and a Misc/NEWS entry. With this patch, the documentation doesn't correctly build. I think the cause is the new hmac module. Would somebody please take a look at it? I've never used the Python doc system before, so I'm a bit lost at the moment. The error message when building the docs is: """ +++ latex dist +++ latex2html -init_file dist.l2h -dir /mnt/data1/src/python/dist/src/Doc/html/dist /mnt/data1/src/python/dist/src/Doc/dist/dist.tex +++ perl /mnt/data1/src/python/dist/src/Doc/tools/node2label.pl *.html python tools/rewrite.py texinputs/boilerplate.tex RELEASE=2.2a3 \ html/index.html cd html && \ python ../tools/mkmodindex --columns 4 \ --output modindex.html --address "See About this document... for information on suggesting changes." \ lib/modindex.html mac/modindex.html Traceback (most recent call last): File "../tools/mkmodindex", line 139, in ? main() File "../tools/mkmodindex", line 94, in main ifp = open(ifn) IOError: [Errno 2] No such file or directory: 'lib/modindex.html' make: *** [html/modindex.html] Error 1 """ Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-09 23:39 Message: Logged In: YES user_id=21627 >From a shallow inspection, the code itself looks ok, structurally and from the proposed new features. Please indicate whether you are willing to write patches to the documentation, since the current patch includes none. In particular, the new module deserves a documentation entry; copying the doc strings is fine. You may also consider writing a Misc/NEWS entry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460112&group_id=5470 From noreply@sourceforge.net Tue Sep 11 21:10:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Sep 2001 13:10:37 -0700 Subject: [Patches] [ python-Patches-460737 ] Some mac modules should go Message-ID: Patches item #460737, was opened at 2001-09-11 13:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460737&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Some mac modules should go Initial Comment: Some of the Macintosh modules are so outdated that they should probably not even be listen in the depraceted section but be removed altogether: libmactcp libmacdnr libmacconsole I'll leave removing them to you, I have no idea whether more needs to be done than taking them out of mac.tex and removing them. I'll check in some other fixes directly. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460737&group_id=5470 From noreply@sourceforge.net Tue Sep 11 22:29:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Sep 2001 14:29:47 -0700 Subject: [Patches] [ python-Patches-460751 ] --with-shared: python with shared lib Message-ID: Patches item #460751, was opened at 2001-09-11 14:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Nobody/Anonymous (nobody) Summary: --with-shared: python with shared lib Initial Comment: As a follow up to patch 400938 (https://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=400938), here is an implementation of the --with-shared configure option for building python on Posix systems as a shared library. Building python as shared library is activated with the --with-shared option on ./configure The following points are drawn to particular attention: - A configbuild.py module is generated and placed in the machine-dependent directory. It records most Python/Makefile variables (CC, CFLAG, LDSHARED...), and make them available in Python. - The build has been tested on: Linux2: OK SunOS5: OK IRIX64: Build OK, crash on test (bus error) - Inference with distutils: I found it very difficult understanding the distutil architecture and finding the right points of change; I minimized my interaction there. Furthermore, the availability of the 'configbuild' module overlaps some of the distutils; but 'configbuild' is very easy to use ... - Unresolved symbols: I turned on the symbol checking flags whenever possible, on behalf the its better generating the error on build than at runtime. - configure.in: I only edited the configure Bourne script, and did not bother with configure.in (actually, I deleted it) and its autoconfig/m4 macro comparses. Frederic Giacometti ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 From noreply@sourceforge.net Tue Sep 11 22:32:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Sep 2001 14:32:06 -0700 Subject: [Patches] [ python-Patches-456736 ] Remember __future__ imports in IDE Message-ID: Patches item #456736, was opened at 2001-08-29 19:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=456736&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jack Jansen (jackjansen) Summary: Remember __future__ imports in IDE Initial Comment: Changes the MacPython IDE's interactive mode to use a codeop.Compile object instead of the builtin compile. Maintains the compiler's flags between statements, so that "from __future__ import" applies to further statements (just like in the interpretter). ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-09-11 14:32 Message: Logged In: YES user_id=45365 The patches have been installed as of Python 2.2a3. ---------------------------------------------------------------------- Comment By: Mark Day (markday) Date: 2001-08-30 08:56 Message: Logged In: YES user_id=312024 I don't see a way to attach the patch to the existing report. In the meantime, I'll mail it directly to Jack Jansen. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-30 07:44 Message: Logged In: YES user_id=6656 There ain't no patch here! You have to check the "Check to Upload & Attach File:" box (this is infuriating, yes). Maybe this should be a canned response... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=456736&group_id=5470 From noreply@sourceforge.net Tue Sep 11 22:33:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Sep 2001 14:33:21 -0700 Subject: [Patches] [ python-Patches-455675 ] PyConsole raw_input improvements Message-ID: Patches item #455675, was opened at 2001-08-26 23:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455675&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jack Jansen (jackjansen) Summary: PyConsole raw_input improvements Initial Comment: This patch addresses two drawbacks of the current behavior of raw_input() when running in the IDE: * The prompt string doesn't appear in the AskString dialog. * The result string isn't printed to stdout (it should, so that the session "looks like" it would when run under the Interpreter. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-09-11 14:33 Message: Logged In: YES user_id=45365 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-09-11 14:33 Message: Logged In: YES user_id=45365 ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-08-27 02:21 Message: Logged In: YES user_id=45365 Just in case the original poster is still tracking this patch: you forgot to attach the patch itself! (There's a nasty checkbox you have to check, just browsing to the file isn't good enough). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=455675&group_id=5470 From noreply@sourceforge.net Wed Sep 12 03:03:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Sep 2001 19:03:32 -0700 Subject: [Patches] [ python-Patches-460751 ] --with-shared: python with shared lib Message-ID: Patches item #460751, was opened at 2001-09-11 14:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Nobody/Anonymous (nobody) Summary: --with-shared: python with shared lib Initial Comment: As a follow up to patch 400938 (https://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=400938), here is an implementation of the --with-shared configure option for building python on Posix systems as a shared library. Building python as shared library is activated with the --with-shared option on ./configure The following points are drawn to particular attention: - A configbuild.py module is generated and placed in the machine-dependent directory. It records most Python/Makefile variables (CC, CFLAG, LDSHARED...), and make them available in Python. - The build has been tested on: Linux2: OK SunOS5: OK IRIX64: Build OK, crash on test (bus error) - Inference with distutils: I found it very difficult understanding the distutil architecture and finding the right points of change; I minimized my interaction there. Furthermore, the availability of the 'configbuild' module overlaps some of the distutils; but 'configbuild' is very easy to use ... - Unresolved symbols: I turned on the symbol checking flags whenever possible, on behalf the its better generating the error on build than at runtime. - configure.in: I only edited the configure Bourne script, and did not bother with configure.in (actually, I deleted it) and its autoconfig/m4 macro comparses. Frederic Giacometti ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-11 19:03 Message: Logged In: YES user_id=6380 Haven't seen the patch yet, but I like the idea -- the command line option suggests that it shouldn't hurt platforms where it can't be done or has to be done differently. Alternative: we could also consider using libtool. I didn't like that much in the past, but maybe it would work. Dunno. Anybody know about it? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 From noreply@sourceforge.net Wed Sep 12 05:25:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Sep 2001 21:25:29 -0700 Subject: [Patches] [ python-Patches-460805 ] Support for unsetenv() Message-ID: Patches item #460805, was opened at 2001-09-11 21:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Gonnerman (solomoriah) Assigned to: Nobody/Anonymous (nobody) Summary: Support for unsetenv() Initial Comment: The attached patch files implement os.unsetenv() for Python 2.1 and 2.2a3. os.py is extended to call unsetenv() when _Environ.__delitem__ is called. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 From noreply@sourceforge.net Wed Sep 12 08:18:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Sep 2001 00:18:35 -0700 Subject: [Patches] [ python-Patches-460751 ] --with-shared: python with shared lib Message-ID: Patches item #460751, was opened at 2001-09-11 14:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Nobody/Anonymous (nobody) Summary: --with-shared: python with shared lib Initial Comment: As a follow up to patch 400938 (https://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=400938), here is an implementation of the --with-shared configure option for building python on Posix systems as a shared library. Building python as shared library is activated with the --with-shared option on ./configure The following points are drawn to particular attention: - A configbuild.py module is generated and placed in the machine-dependent directory. It records most Python/Makefile variables (CC, CFLAG, LDSHARED...), and make them available in Python. - The build has been tested on: Linux2: OK SunOS5: OK IRIX64: Build OK, crash on test (bus error) - Inference with distutils: I found it very difficult understanding the distutil architecture and finding the right points of change; I minimized my interaction there. Furthermore, the availability of the 'configbuild' module overlaps some of the distutils; but 'configbuild' is very easy to use ... - Unresolved symbols: I turned on the symbol checking flags whenever possible, on behalf the its better generating the error on build than at runtime. - configure.in: I only edited the configure Bourne script, and did not bother with configure.in (actually, I deleted it) and its autoconfig/m4 macro comparses. Frederic Giacometti ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-12 00:18 Message: Logged In: YES user_id=21627 I recommend to rework this patch to get rid of configbuild. I cannot see what you achieve with the configbuild module that you couldn't do with distutils.sysconfig.get_config_vars (which is capable of parsing the Makefile directly). I also recommend to go through the patch chunk by chunk, asking yourself whether this chunk *really* is needed to achieve the desired functionality. E.g. I cannot see the relationship of the .cvsignore chunk; I also believe that removal of .purify is incorrect. Likewise, while I sympathize with the unresolved symbols change, I believe it is unrelated to the main objective of this patch (building Python shared). What is the rationale for not changing configure.in? As-is, this patch is useless: configure will be overwritten everytime you run autoconf. Please get a copy of autoconf on one of your systems, change configure.in, run autoconf, and then provide us with a patch that only changes configure.in: everybody reviewing this patch should be capable of running autoconf. configure is a generated file and should not be edited manually. What is the rationale for the introduction of the THREADOBJ variable? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-11 19:03 Message: Logged In: YES user_id=6380 Haven't seen the patch yet, but I like the idea -- the command line option suggests that it shouldn't hurt platforms where it can't be done or has to be done differently. Alternative: we could also consider using libtool. I didn't like that much in the past, but maybe it would work. Dunno. Anybody know about it? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 From noreply@sourceforge.net Wed Sep 12 09:06:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Sep 2001 01:06:17 -0700 Subject: [Patches] [ python-Patches-460751 ] --with-shared: python with shared lib Message-ID: Patches item #460751, was opened at 2001-09-11 14:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Nobody/Anonymous (nobody) Summary: --with-shared: python with shared lib Initial Comment: As a follow up to patch 400938 (https://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=400938), here is an implementation of the --with-shared configure option for building python on Posix systems as a shared library. Building python as shared library is activated with the --with-shared option on ./configure The following points are drawn to particular attention: - A configbuild.py module is generated and placed in the machine-dependent directory. It records most Python/Makefile variables (CC, CFLAG, LDSHARED...), and make them available in Python. - The build has been tested on: Linux2: OK SunOS5: OK IRIX64: Build OK, crash on test (bus error) - Inference with distutils: I found it very difficult understanding the distutil architecture and finding the right points of change; I minimized my interaction there. Furthermore, the availability of the 'configbuild' module overlaps some of the distutils; but 'configbuild' is very easy to use ... - Unresolved symbols: I turned on the symbol checking flags whenever possible, on behalf the its better generating the error on build than at runtime. - configure.in: I only edited the configure Bourne script, and did not bother with configure.in (actually, I deleted it) and its autoconfig/m4 macro comparses. Frederic Giacometti ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-12 01:06 Message: Logged In: YES user_id=21627 As for libtool: I strongly advise not to use it. It is broken in too many ways to enumerate. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-12 00:18 Message: Logged In: YES user_id=21627 I recommend to rework this patch to get rid of configbuild. I cannot see what you achieve with the configbuild module that you couldn't do with distutils.sysconfig.get_config_vars (which is capable of parsing the Makefile directly). I also recommend to go through the patch chunk by chunk, asking yourself whether this chunk *really* is needed to achieve the desired functionality. E.g. I cannot see the relationship of the .cvsignore chunk; I also believe that removal of .purify is incorrect. Likewise, while I sympathize with the unresolved symbols change, I believe it is unrelated to the main objective of this patch (building Python shared). What is the rationale for not changing configure.in? As-is, this patch is useless: configure will be overwritten everytime you run autoconf. Please get a copy of autoconf on one of your systems, change configure.in, run autoconf, and then provide us with a patch that only changes configure.in: everybody reviewing this patch should be capable of running autoconf. configure is a generated file and should not be edited manually. What is the rationale for the introduction of the THREADOBJ variable? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-11 19:03 Message: Logged In: YES user_id=6380 Haven't seen the patch yet, but I like the idea -- the command line option suggests that it shouldn't hurt platforms where it can't be done or has to be done differently. Alternative: we could also consider using libtool. I didn't like that much in the past, but maybe it would work. Dunno. Anybody know about it? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 From noreply@sourceforge.net Wed Sep 12 14:38:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Sep 2001 06:38:54 -0700 Subject: [Patches] [ python-Patches-460805 ] Support for unsetenv() Message-ID: Patches item #460805, was opened at 2001-09-11 21:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Gonnerman (solomoriah) Assigned to: Nobody/Anonymous (nobody) Summary: Support for unsetenv() Initial Comment: The attached patch files implement os.unsetenv() for Python 2.1 and 2.2a3. os.py is extended to call unsetenv() when _Environ.__delitem__ is called. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 06:38 Message: Logged In: YES user_id=6380 Can you point to where unsetenv is standardized? I'm worried that it's not available on standard-conforming Unix systems, and since it's of marginal utility at best, I'm not sure what the point is to add it -- unless there's a clear standard that ensures its existence. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 From noreply@sourceforge.net Wed Sep 12 18:32:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Sep 2001 10:32:40 -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: Open 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: Frederic Giacometti (giacometti) Date: 2001-09-12 10:32 Message: Logged In: YES user_id=93657 The motivation seems fairly clear to me: python -p is easy to understand, to use, and to implement. The present syntax (PYTHONPATH= python ...) depends upon the shell being used (won't work in C shell), has side effects (redefine locally the shell variable...). It's a convenience feature, for use especially when integrating python with other script-based tools (Make, ksh, csh, bash), especially in non-regression and build scripts. As to what you propose (small script directly setting sys.path), this is not feasible in the context above; a context in which the 'python -c' command would be used, typically. On can live without it, but there will be no revolution adding it either; not does it really cost anything. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-07 18:57 Message: Logged In: YES user_id=6380 (A) You will hear from Barry soon. (B) I don't see the advantage of using -p or -P. I don't understand the motivation you are giving; can you explain it better? If you want control over the path without setting PYTHONPATH, you can write a small script that sets sys.path directly. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-07 15:25 Message: Logged In: YES user_id=93657 Since I'm still battling in Python's configure and Makefile.pre.in files, here are some more occurences: WIth the patch: PYTHONPATH=$(LIBDEST) \ ./$(PYTHON) -tt $(LIBDEST)/compileall.py $(LIBDEST) PYTHONPATH=$(LIBDEST) \ ./$(PYTHON) -O $(LIBDEST)/compileall.py $(LIBDEST) would be replaced by: ./$(PYTHON) -p $(LIBDEST) -tt $(LIBDEST)/compileall.py $(LIBDEST) ./$(PYTHON) -p $(LIBDEST) -O $(LIBDEST)/compileall.py $(LIBDEST) Some more can be found... FG ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-07 15:18 Message: Logged In: YES user_id=93657 I'm getting back on the issue - Three months after submitting the patch, and one month after writing the PEP proposal, Barry W. still hasn't assigned a PEP number -. I have been working on the Python 2.1.1 build lately, and I stumble into this in the Makefile: There are 8 occurences of Make shell commands of the kind PYTHONPATH= $(PYTHON) ... This is the kind of thing that could be replaced a lot more clearly (and portably) with: $(PYTHON) -p "" ... if the patch were applied. If still think a PEP discussion is not necessary for this; especially since the PEP process seems frozen in this regard. In any event, it is desirable that the feature be included before the final 2.2 release. Thanks, Frederic Giacometti ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-07 13:59 Message: Logged In: YES user_id=93657 I'm getting back on the issue - Three months after submitting the patch, and one month after writing the PEP proposal, Barry W. still hasn't assigned a PEP number -. I have been working on the Python 2.1.1 build lately, and I stumble into this in the Makefile: There are 8 occurences of Make shell commands of the kind PYTHONPATH= $(PYTHON) ... This is the kind of thing that could be replaced a lot more clearly (and portably) with: $(PYTHON) -p "" ... if the patch were applied. If still think a PEP discussion is not necessary for this; especially since the PEP process seems frozen in this regard. In any event, it is desirable that the feature be included before the final 2.2 release. Thanks, Frederic Giacometti ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-08-05 20:37 Message: Logged In: YES user_id=93657 I apologize for the delay, but I have been travelling a lot for the last 2 months, and I could not have followed up a PEP. I'm now stabilized, so here is the PEP proposal I just mailed to Barry. Regards, Frederic Giacometti -------------------------------------- PEP XXX: Addition of an option for completing sys.path from the commandline fred@arakne.com (Frederic Giacometti) Abstract At present, the PYTHONPATH environment variable is the only method for defining additional Python module directories. This PEP introduce the '-P' valued option to the python command as an alternative to PYTHONPATH. Copyright: This document is published under the Open Publication License. Specification: On Unix: python -P $SOMEVALUE will be equivalent to env PYTHONPATH=$SOMEVALUE python On Windows 2K: python -P $SOMEVALUE will (almost, humm) be equivalent to set __PYTHONPATH=%PYTHONPATH% && set PYTHONPATH=%SOMEVALUE% && python && set PYTHONPATH=__%PYTHONPATH% Reference Implementation and PEP pre-history: See patch http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429614&group_id=5470 ---------------------------------------------------------------------- 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 Sep 12 18:36:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Sep 2001 10:36:09 -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: Open >Resolution: Rejected 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: Guido van Rossum (gvanrossum) Date: 2001-09-12 10:36 Message: Logged In: YES user_id=6380 It may be easy to implement, but it's still code bloat. It may be easy to use, but it seems only useful in uncommon situations, where another way of accomplishing the same thing is already possible. I'm rejecting this now. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-12 10:32 Message: Logged In: YES user_id=93657 The motivation seems fairly clear to me: python -p is easy to understand, to use, and to implement. The present syntax (PYTHONPATH= python ...) depends upon the shell being used (won't work in C shell), has side effects (redefine locally the shell variable...). It's a convenience feature, for use especially when integrating python with other script-based tools (Make, ksh, csh, bash), especially in non-regression and build scripts. As to what you propose (small script directly setting sys.path), this is not feasible in the context above; a context in which the 'python -c' command would be used, typically. On can live without it, but there will be no revolution adding it either; not does it really cost anything. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-07 18:57 Message: Logged In: YES user_id=6380 (A) You will hear from Barry soon. (B) I don't see the advantage of using -p or -P. I don't understand the motivation you are giving; can you explain it better? If you want control over the path without setting PYTHONPATH, you can write a small script that sets sys.path directly. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-07 15:25 Message: Logged In: YES user_id=93657 Since I'm still battling in Python's configure and Makefile.pre.in files, here are some more occurences: WIth the patch: PYTHONPATH=$(LIBDEST) \ ./$(PYTHON) -tt $(LIBDEST)/compileall.py $(LIBDEST) PYTHONPATH=$(LIBDEST) \ ./$(PYTHON) -O $(LIBDEST)/compileall.py $(LIBDEST) would be replaced by: ./$(PYTHON) -p $(LIBDEST) -tt $(LIBDEST)/compileall.py $(LIBDEST) ./$(PYTHON) -p $(LIBDEST) -O $(LIBDEST)/compileall.py $(LIBDEST) Some more can be found... FG ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-07 15:18 Message: Logged In: YES user_id=93657 I'm getting back on the issue - Three months after submitting the patch, and one month after writing the PEP proposal, Barry W. still hasn't assigned a PEP number -. I have been working on the Python 2.1.1 build lately, and I stumble into this in the Makefile: There are 8 occurences of Make shell commands of the kind PYTHONPATH= $(PYTHON) ... This is the kind of thing that could be replaced a lot more clearly (and portably) with: $(PYTHON) -p "" ... if the patch were applied. If still think a PEP discussion is not necessary for this; especially since the PEP process seems frozen in this regard. In any event, it is desirable that the feature be included before the final 2.2 release. Thanks, Frederic Giacometti ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-07 13:59 Message: Logged In: YES user_id=93657 I'm getting back on the issue - Three months after submitting the patch, and one month after writing the PEP proposal, Barry W. still hasn't assigned a PEP number -. I have been working on the Python 2.1.1 build lately, and I stumble into this in the Makefile: There are 8 occurences of Make shell commands of the kind PYTHONPATH= $(PYTHON) ... This is the kind of thing that could be replaced a lot more clearly (and portably) with: $(PYTHON) -p "" ... if the patch were applied. If still think a PEP discussion is not necessary for this; especially since the PEP process seems frozen in this regard. In any event, it is desirable that the feature be included before the final 2.2 release. Thanks, Frederic Giacometti ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-08-05 20:37 Message: Logged In: YES user_id=93657 I apologize for the delay, but I have been travelling a lot for the last 2 months, and I could not have followed up a PEP. I'm now stabilized, so here is the PEP proposal I just mailed to Barry. Regards, Frederic Giacometti -------------------------------------- PEP XXX: Addition of an option for completing sys.path from the commandline fred@arakne.com (Frederic Giacometti) Abstract At present, the PYTHONPATH environment variable is the only method for defining additional Python module directories. This PEP introduce the '-P' valued option to the python command as an alternative to PYTHONPATH. Copyright: This document is published under the Open Publication License. Specification: On Unix: python -P $SOMEVALUE will be equivalent to env PYTHONPATH=$SOMEVALUE python On Windows 2K: python -P $SOMEVALUE will (almost, humm) be equivalent to set __PYTHONPATH=%PYTHONPATH% && set PYTHONPATH=%SOMEVALUE% && python && set PYTHONPATH=__%PYTHONPATH% Reference Implementation and PEP pre-history: See patch http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429614&group_id=5470 ---------------------------------------------------------------------- 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 Sep 12 18:36:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Sep 2001 10:36:19 -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: Closed Resolution: Rejected 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: Guido van Rossum (gvanrossum) Date: 2001-09-12 10:36 Message: Logged In: YES user_id=6380 It may be easy to implement, but it's still code bloat. It may be easy to use, but it seems only useful in uncommon situations, where another way of accomplishing the same thing is already possible. I'm rejecting this now. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-12 10:32 Message: Logged In: YES user_id=93657 The motivation seems fairly clear to me: python -p is easy to understand, to use, and to implement. The present syntax (PYTHONPATH= python ...) depends upon the shell being used (won't work in C shell), has side effects (redefine locally the shell variable...). It's a convenience feature, for use especially when integrating python with other script-based tools (Make, ksh, csh, bash), especially in non-regression and build scripts. As to what you propose (small script directly setting sys.path), this is not feasible in the context above; a context in which the 'python -c' command would be used, typically. On can live without it, but there will be no revolution adding it either; not does it really cost anything. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-07 18:57 Message: Logged In: YES user_id=6380 (A) You will hear from Barry soon. (B) I don't see the advantage of using -p or -P. I don't understand the motivation you are giving; can you explain it better? If you want control over the path without setting PYTHONPATH, you can write a small script that sets sys.path directly. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-07 15:25 Message: Logged In: YES user_id=93657 Since I'm still battling in Python's configure and Makefile.pre.in files, here are some more occurences: WIth the patch: PYTHONPATH=$(LIBDEST) \ ./$(PYTHON) -tt $(LIBDEST)/compileall.py $(LIBDEST) PYTHONPATH=$(LIBDEST) \ ./$(PYTHON) -O $(LIBDEST)/compileall.py $(LIBDEST) would be replaced by: ./$(PYTHON) -p $(LIBDEST) -tt $(LIBDEST)/compileall.py $(LIBDEST) ./$(PYTHON) -p $(LIBDEST) -O $(LIBDEST)/compileall.py $(LIBDEST) Some more can be found... FG ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-07 15:18 Message: Logged In: YES user_id=93657 I'm getting back on the issue - Three months after submitting the patch, and one month after writing the PEP proposal, Barry W. still hasn't assigned a PEP number -. I have been working on the Python 2.1.1 build lately, and I stumble into this in the Makefile: There are 8 occurences of Make shell commands of the kind PYTHONPATH= $(PYTHON) ... This is the kind of thing that could be replaced a lot more clearly (and portably) with: $(PYTHON) -p "" ... if the patch were applied. If still think a PEP discussion is not necessary for this; especially since the PEP process seems frozen in this regard. In any event, it is desirable that the feature be included before the final 2.2 release. Thanks, Frederic Giacometti ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-07 13:59 Message: Logged In: YES user_id=93657 I'm getting back on the issue - Three months after submitting the patch, and one month after writing the PEP proposal, Barry W. still hasn't assigned a PEP number -. I have been working on the Python 2.1.1 build lately, and I stumble into this in the Makefile: There are 8 occurences of Make shell commands of the kind PYTHONPATH= $(PYTHON) ... This is the kind of thing that could be replaced a lot more clearly (and portably) with: $(PYTHON) -p "" ... if the patch were applied. If still think a PEP discussion is not necessary for this; especially since the PEP process seems frozen in this regard. In any event, it is desirable that the feature be included before the final 2.2 release. Thanks, Frederic Giacometti ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-08-05 20:37 Message: Logged In: YES user_id=93657 I apologize for the delay, but I have been travelling a lot for the last 2 months, and I could not have followed up a PEP. I'm now stabilized, so here is the PEP proposal I just mailed to Barry. Regards, Frederic Giacometti -------------------------------------- PEP XXX: Addition of an option for completing sys.path from the commandline fred@arakne.com (Frederic Giacometti) Abstract At present, the PYTHONPATH environment variable is the only method for defining additional Python module directories. This PEP introduce the '-P' valued option to the python command as an alternative to PYTHONPATH. Copyright: This document is published under the Open Publication License. Specification: On Unix: python -P $SOMEVALUE will be equivalent to env PYTHONPATH=$SOMEVALUE python On Windows 2K: python -P $SOMEVALUE will (almost, humm) be equivalent to set __PYTHONPATH=%PYTHONPATH% && set PYTHONPATH=%SOMEVALUE% && python && set PYTHONPATH=__%PYTHONPATH% Reference Implementation and PEP pre-history: See patch http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429614&group_id=5470 ---------------------------------------------------------------------- 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 Sep 12 19:12:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Sep 2001 11:12:50 -0700 Subject: [Patches] [ python-Patches-460751 ] --with-shared: python with shared lib Message-ID: Patches item #460751, was opened at 2001-09-11 14:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Nobody/Anonymous (nobody) Summary: --with-shared: python with shared lib Initial Comment: As a follow up to patch 400938 (https://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=400938), here is an implementation of the --with-shared configure option for building python on Posix systems as a shared library. Building python as shared library is activated with the --with-shared option on ./configure The following points are drawn to particular attention: - A configbuild.py module is generated and placed in the machine-dependent directory. It records most Python/Makefile variables (CC, CFLAG, LDSHARED...), and make them available in Python. - The build has been tested on: Linux2: OK SunOS5: OK IRIX64: Build OK, crash on test (bus error) - Inference with distutils: I found it very difficult understanding the distutil architecture and finding the right points of change; I minimized my interaction there. Furthermore, the availability of the 'configbuild' module overlaps some of the distutils; but 'configbuild' is very easy to use ... - Unresolved symbols: I turned on the symbol checking flags whenever possible, on behalf the its better generating the error on build than at runtime. - configure.in: I only edited the configure Bourne script, and did not bother with configure.in (actually, I deleted it) and its autoconfig/m4 macro comparses. Frederic Giacometti ---------------------------------------------------------------------- >Comment By: Frederic Giacometti (giacometti) Date: 2001-09-12 11:12 Message: Logged In: YES user_id=93657 - I will remove the configbuild; since Martin pointed to me the existence of distutils.sysconfig.get_config_vars(). I did not know about this function... Thanks! On the fly, you'll also note the following potential problem with using get_config_vars() instead of configbuild: configbuild will report the actual values used for the build, whereas get_config_vars() will report erroneous values whenever the Makefile internal variables were overriden at build time (by either the environment, or by commandline assignment of the type 'make CC=gxx ...'); not to mention that configbuild does not need to find and parse the original Makefile (with all the potential problems associated). - The .purify line should be in the CVSROOT/cvsignore CVS admin file, not in .cvsignore in the root directory of the source distribution... - Autoconf is not installed on the commercial Unix platforms, it is useless for me to learn it, and I was better off directly editing ./configure. However, if others are familiar with the tool, it should be straightforward for them to retrocede the changes from configure to configure.in - I had to introduce THREADOBJ because you will note that, in the present implementation, Modules/thread.o appears multiple times in LIBOBJS, which causes warning at link time. Now, Modules/thread.o appears only once ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-12 01:06 Message: Logged In: YES user_id=21627 As for libtool: I strongly advise not to use it. It is broken in too many ways to enumerate. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-12 00:18 Message: Logged In: YES user_id=21627 I recommend to rework this patch to get rid of configbuild. I cannot see what you achieve with the configbuild module that you couldn't do with distutils.sysconfig.get_config_vars (which is capable of parsing the Makefile directly). I also recommend to go through the patch chunk by chunk, asking yourself whether this chunk *really* is needed to achieve the desired functionality. E.g. I cannot see the relationship of the .cvsignore chunk; I also believe that removal of .purify is incorrect. Likewise, while I sympathize with the unresolved symbols change, I believe it is unrelated to the main objective of this patch (building Python shared). What is the rationale for not changing configure.in? As-is, this patch is useless: configure will be overwritten everytime you run autoconf. Please get a copy of autoconf on one of your systems, change configure.in, run autoconf, and then provide us with a patch that only changes configure.in: everybody reviewing this patch should be capable of running autoconf. configure is a generated file and should not be edited manually. What is the rationale for the introduction of the THREADOBJ variable? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-11 19:03 Message: Logged In: YES user_id=6380 Haven't seen the patch yet, but I like the idea -- the command line option suggests that it shouldn't hurt platforms where it can't be done or has to be done differently. Alternative: we could also consider using libtool. I didn't like that much in the past, but maybe it would work. Dunno. Anybody know about it? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 From noreply@sourceforge.net Wed Sep 12 19:37:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Sep 2001 11:37:31 -0700 Subject: [Patches] [ python-Patches-460751 ] --with-shared: python with shared lib Message-ID: Patches item #460751, was opened at 2001-09-11 14:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Nobody/Anonymous (nobody) Summary: --with-shared: python with shared lib Initial Comment: As a follow up to patch 400938 (https://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=400938), here is an implementation of the --with-shared configure option for building python on Posix systems as a shared library. Building python as shared library is activated with the --with-shared option on ./configure The following points are drawn to particular attention: - A configbuild.py module is generated and placed in the machine-dependent directory. It records most Python/Makefile variables (CC, CFLAG, LDSHARED...), and make them available in Python. - The build has been tested on: Linux2: OK SunOS5: OK IRIX64: Build OK, crash on test (bus error) - Inference with distutils: I found it very difficult understanding the distutil architecture and finding the right points of change; I minimized my interaction there. Furthermore, the availability of the 'configbuild' module overlaps some of the distutils; but 'configbuild' is very easy to use ... - Unresolved symbols: I turned on the symbol checking flags whenever possible, on behalf the its better generating the error on build than at runtime. - configure.in: I only edited the configure Bourne script, and did not bother with configure.in (actually, I deleted it) and its autoconfig/m4 macro comparses. Frederic Giacometti ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 11:37 Message: Logged In: YES user_id=6380 > Autoconf is not installed on the commercial Unix > platforms, it is useless for me to learn it, and I was > better off directly editing ./configure. However, if others > are familiar with the tool, it should be straightforward for > them to retrocede the changes from configure to configure.in Sure. You'll just have to wait until we have time for that. You can make it easy for us to integrate your changes, or you can make it difficult. Your choice. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-12 11:12 Message: Logged In: YES user_id=93657 - I will remove the configbuild; since Martin pointed to me the existence of distutils.sysconfig.get_config_vars(). I did not know about this function... Thanks! On the fly, you'll also note the following potential problem with using get_config_vars() instead of configbuild: configbuild will report the actual values used for the build, whereas get_config_vars() will report erroneous values whenever the Makefile internal variables were overriden at build time (by either the environment, or by commandline assignment of the type 'make CC=gxx ...'); not to mention that configbuild does not need to find and parse the original Makefile (with all the potential problems associated). - The .purify line should be in the CVSROOT/cvsignore CVS admin file, not in .cvsignore in the root directory of the source distribution... - Autoconf is not installed on the commercial Unix platforms, it is useless for me to learn it, and I was better off directly editing ./configure. However, if others are familiar with the tool, it should be straightforward for them to retrocede the changes from configure to configure.in - I had to introduce THREADOBJ because you will note that, in the present implementation, Modules/thread.o appears multiple times in LIBOBJS, which causes warning at link time. Now, Modules/thread.o appears only once ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-12 01:06 Message: Logged In: YES user_id=21627 As for libtool: I strongly advise not to use it. It is broken in too many ways to enumerate. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-12 00:18 Message: Logged In: YES user_id=21627 I recommend to rework this patch to get rid of configbuild. I cannot see what you achieve with the configbuild module that you couldn't do with distutils.sysconfig.get_config_vars (which is capable of parsing the Makefile directly). I also recommend to go through the patch chunk by chunk, asking yourself whether this chunk *really* is needed to achieve the desired functionality. E.g. I cannot see the relationship of the .cvsignore chunk; I also believe that removal of .purify is incorrect. Likewise, while I sympathize with the unresolved symbols change, I believe it is unrelated to the main objective of this patch (building Python shared). What is the rationale for not changing configure.in? As-is, this patch is useless: configure will be overwritten everytime you run autoconf. Please get a copy of autoconf on one of your systems, change configure.in, run autoconf, and then provide us with a patch that only changes configure.in: everybody reviewing this patch should be capable of running autoconf. configure is a generated file and should not be edited manually. What is the rationale for the introduction of the THREADOBJ variable? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-11 19:03 Message: Logged In: YES user_id=6380 Haven't seen the patch yet, but I like the idea -- the command line option suggests that it shouldn't hurt platforms where it can't be done or has to be done differently. Alternative: we could also consider using libtool. I didn't like that much in the past, but maybe it would work. Dunno. Anybody know about it? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 From noreply@sourceforge.net Wed Sep 12 22:18:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Sep 2001 14:18:52 -0700 Subject: [Patches] [ python-Patches-460402 ] PEP 270: uniq() method for list objects Message-ID: Patches item #460402, was opened at 2001-09-10 11:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460402&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Petrone (jpetrone) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 270: uniq() method for list objects Initial Comment: Remove duplicate elements from a list object. 3 Patches: uniq.doc.patch - Documentation changes in libstdtypes.tex uniq.ordered.patch - Changes to listmodule.c for brute force duplicate removal with uniq(). Maintains list order. uniq.unordered.patch - Changes to listmodule.c for duplicate removal with uniq() First tries using a mapping object. If the list elements aren't mapable, tries sorted removal. If the list isn't sortable, finally falls back on brute force removal. Does not maintain list order. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 14:18 Message: Logged In: YES user_id=6380 Hm. The unix uniq(1) program only removes *consecutive* duplicates. That's an O(N) algorithm and only requires equality to be defined, and leaves the sorting to the caller. Would it make sense to support only that? I guess I'm looking for a use case here... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460402&group_id=5470 From noreply@sourceforge.net Thu Sep 13 00:06:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Sep 2001 16:06:00 -0700 Subject: [Patches] [ python-Patches-460751 ] --with-shared: python with shared lib Message-ID: Patches item #460751, was opened at 2001-09-11 14:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Nobody/Anonymous (nobody) Summary: --with-shared: python with shared lib Initial Comment: As a follow up to patch 400938 (https://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=400938), here is an implementation of the --with-shared configure option for building python on Posix systems as a shared library. Building python as shared library is activated with the --with-shared option on ./configure The following points are drawn to particular attention: - A configbuild.py module is generated and placed in the machine-dependent directory. It records most Python/Makefile variables (CC, CFLAG, LDSHARED...), and make them available in Python. - The build has been tested on: Linux2: OK SunOS5: OK IRIX64: Build OK, crash on test (bus error) - Inference with distutils: I found it very difficult understanding the distutil architecture and finding the right points of change; I minimized my interaction there. Furthermore, the availability of the 'configbuild' module overlaps some of the distutils; but 'configbuild' is very easy to use ... - Unresolved symbols: I turned on the symbol checking flags whenever possible, on behalf the its better generating the error on build than at runtime. - configure.in: I only edited the configure Bourne script, and did not bother with configure.in (actually, I deleted it) and its autoconfig/m4 macro comparses. Frederic Giacometti ---------------------------------------------------------------------- >Comment By: Frederic Giacometti (giacometti) Date: 2001-09-12 16:06 Message: Logged In: YES user_id=93657 I am not willing to make anything difficult for anybody, but: What is the point of keeping using the autoconf thing when it is easier to maintain configure directly, than going through configure.in ? After configure has been generated once, it makes more sense to me to work directly on configure, and forget about configure.in. configure (pure Bourne shell) is a easier to understand, to troubleshoot, and to maintain that configure.in (a mixture of Bourne shell and autoconf m4 macros). I'll have a second look at the autoconf thing latter on - at present I hardly understand anything to configure.in, and got 'configure --with-shared' working with satisfaction across multiple platforms without undue difficulties. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 11:37 Message: Logged In: YES user_id=6380 > Autoconf is not installed on the commercial Unix > platforms, it is useless for me to learn it, and I was > better off directly editing ./configure. However, if others > are familiar with the tool, it should be straightforward for > them to retrocede the changes from configure to configure.in Sure. You'll just have to wait until we have time for that. You can make it easy for us to integrate your changes, or you can make it difficult. Your choice. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-12 11:12 Message: Logged In: YES user_id=93657 - I will remove the configbuild; since Martin pointed to me the existence of distutils.sysconfig.get_config_vars(). I did not know about this function... Thanks! On the fly, you'll also note the following potential problem with using get_config_vars() instead of configbuild: configbuild will report the actual values used for the build, whereas get_config_vars() will report erroneous values whenever the Makefile internal variables were overriden at build time (by either the environment, or by commandline assignment of the type 'make CC=gxx ...'); not to mention that configbuild does not need to find and parse the original Makefile (with all the potential problems associated). - The .purify line should be in the CVSROOT/cvsignore CVS admin file, not in .cvsignore in the root directory of the source distribution... - Autoconf is not installed on the commercial Unix platforms, it is useless for me to learn it, and I was better off directly editing ./configure. However, if others are familiar with the tool, it should be straightforward for them to retrocede the changes from configure to configure.in - I had to introduce THREADOBJ because you will note that, in the present implementation, Modules/thread.o appears multiple times in LIBOBJS, which causes warning at link time. Now, Modules/thread.o appears only once ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-12 01:06 Message: Logged In: YES user_id=21627 As for libtool: I strongly advise not to use it. It is broken in too many ways to enumerate. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-12 00:18 Message: Logged In: YES user_id=21627 I recommend to rework this patch to get rid of configbuild. I cannot see what you achieve with the configbuild module that you couldn't do with distutils.sysconfig.get_config_vars (which is capable of parsing the Makefile directly). I also recommend to go through the patch chunk by chunk, asking yourself whether this chunk *really* is needed to achieve the desired functionality. E.g. I cannot see the relationship of the .cvsignore chunk; I also believe that removal of .purify is incorrect. Likewise, while I sympathize with the unresolved symbols change, I believe it is unrelated to the main objective of this patch (building Python shared). What is the rationale for not changing configure.in? As-is, this patch is useless: configure will be overwritten everytime you run autoconf. Please get a copy of autoconf on one of your systems, change configure.in, run autoconf, and then provide us with a patch that only changes configure.in: everybody reviewing this patch should be capable of running autoconf. configure is a generated file and should not be edited manually. What is the rationale for the introduction of the THREADOBJ variable? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-11 19:03 Message: Logged In: YES user_id=6380 Haven't seen the patch yet, but I like the idea -- the command line option suggests that it shouldn't hurt platforms where it can't be done or has to be done differently. Alternative: we could also consider using libtool. I didn't like that much in the past, but maybe it would work. Dunno. Anybody know about it? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 From noreply@sourceforge.net Thu Sep 13 02:14:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Sep 2001 18:14:18 -0700 Subject: [Patches] [ python-Patches-460805 ] Support for unsetenv() Message-ID: Patches item #460805, was opened at 2001-09-11 21:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Gonnerman (solomoriah) Assigned to: Nobody/Anonymous (nobody) Summary: Support for unsetenv() Initial Comment: The attached patch files implement os.unsetenv() for Python 2.1 and 2.2a3. os.py is extended to call unsetenv() when _Environ.__delitem__ is called. ---------------------------------------------------------------------- >Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 18:14 Message: Logged In: YES user_id=321948 Well, the only place I know of that it is standardized is in GNU libc. That's not entirely the point, though. 1) If you do 'del os.environ["SOMEVAR"]' you remove SOMEVAR from the copy of the environment but not from the real environment. This behavior IMHO is broken. 2) It's true, many OS's don't have unsetenv(). However, my patch falls back to the *current* behavior if unsetenv() is not available. In other words, this doesn't break Python any more than it's already broken, and it's a net gain for operating systems that *do* have unsetenv(). I figure if some gain and none lose, why not do it? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 06:38 Message: Logged In: YES user_id=6380 Can you point to where unsetenv is standardized? I'm worried that it's not available on standard-conforming Unix systems, and since it's of marginal utility at best, I'm not sure what the point is to add it -- unless there's a clear standard that ensures its existence. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 From noreply@sourceforge.net Thu Sep 13 02:20:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Sep 2001 18:20:01 -0700 Subject: [Patches] [ python-Patches-460805 ] Support for unsetenv() Message-ID: Patches item #460805, was opened at 2001-09-11 21:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Gonnerman (solomoriah) Assigned to: Nobody/Anonymous (nobody) Summary: Support for unsetenv() Initial Comment: The attached patch files implement os.unsetenv() for Python 2.1 and 2.2a3. os.py is extended to call unsetenv() when _Environ.__delitem__ is called. ---------------------------------------------------------------------- >Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 18:20 Message: Logged In: YES user_id=321948 By the way, I found the following note in the man pages for NetBSD: The functions setenv() and unsetenv() appeared in Version 7 AT&T UNIX. so it appears, standard or not, that most real Unix systems should have it. Regarding the minimal utility argument, I don't currently have a use for it, but it came up on the mailing list so I wrote it. It's recommended, when writing sysadmin tools which call other programs, to "clean up" the environment so that only known-safe values are in there before calling the externals. ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 18:14 Message: Logged In: YES user_id=321948 Well, the only place I know of that it is standardized is in GNU libc. That's not entirely the point, though. 1) If you do 'del os.environ["SOMEVAR"]' you remove SOMEVAR from the copy of the environment but not from the real environment. This behavior IMHO is broken. 2) It's true, many OS's don't have unsetenv(). However, my patch falls back to the *current* behavior if unsetenv() is not available. In other words, this doesn't break Python any more than it's already broken, and it's a net gain for operating systems that *do* have unsetenv(). I figure if some gain and none lose, why not do it? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 06:38 Message: Logged In: YES user_id=6380 Can you point to where unsetenv is standardized? I'm worried that it's not available on standard-conforming Unix systems, and since it's of marginal utility at best, I'm not sure what the point is to add it -- unless there's a clear standard that ensures its existence. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 From noreply@sourceforge.net Thu Sep 13 02:31:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Sep 2001 18:31:59 -0700 Subject: [Patches] [ python-Patches-460805 ] Support for unsetenv() Message-ID: Patches item #460805, was opened at 2001-09-11 21:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Gonnerman (solomoriah) Assigned to: Nobody/Anonymous (nobody) Summary: Support for unsetenv() Initial Comment: The attached patch files implement os.unsetenv() for Python 2.1 and 2.2a3. os.py is extended to call unsetenv() when _Environ.__delitem__ is called. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 18:31 Message: Logged In: YES user_id=6380 Code bloat. If it's not important enough to standardize in POSIX (or one of the other standards), why should we add it? GNU code is infamous for always including more features, needed or not. If you're cynical, this is part of a Microsoft-like "buy-in" strategy (code developed for GNU libc doesn't work anywhere else). ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 18:20 Message: Logged In: YES user_id=321948 By the way, I found the following note in the man pages for NetBSD: The functions setenv() and unsetenv() appeared in Version 7 AT&T UNIX. so it appears, standard or not, that most real Unix systems should have it. Regarding the minimal utility argument, I don't currently have a use for it, but it came up on the mailing list so I wrote it. It's recommended, when writing sysadmin tools which call other programs, to "clean up" the environment so that only known-safe values are in there before calling the externals. ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 18:14 Message: Logged In: YES user_id=321948 Well, the only place I know of that it is standardized is in GNU libc. That's not entirely the point, though. 1) If you do 'del os.environ["SOMEVAR"]' you remove SOMEVAR from the copy of the environment but not from the real environment. This behavior IMHO is broken. 2) It's true, many OS's don't have unsetenv(). However, my patch falls back to the *current* behavior if unsetenv() is not available. In other words, this doesn't break Python any more than it's already broken, and it's a net gain for operating systems that *do* have unsetenv(). I figure if some gain and none lose, why not do it? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 06:38 Message: Logged In: YES user_id=6380 Can you point to where unsetenv is standardized? I'm worried that it's not available on standard-conforming Unix systems, and since it's of marginal utility at best, I'm not sure what the point is to add it -- unless there's a clear standard that ensures its existence. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 From noreply@sourceforge.net Thu Sep 13 02:36:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Sep 2001 18:36:51 -0700 Subject: [Patches] [ python-Patches-460751 ] --with-shared: python with shared lib Message-ID: Patches item #460751, was opened at 2001-09-11 14:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Nobody/Anonymous (nobody) Summary: --with-shared: python with shared lib Initial Comment: As a follow up to patch 400938 (https://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=400938), here is an implementation of the --with-shared configure option for building python on Posix systems as a shared library. Building python as shared library is activated with the --with-shared option on ./configure The following points are drawn to particular attention: - A configbuild.py module is generated and placed in the machine-dependent directory. It records most Python/Makefile variables (CC, CFLAG, LDSHARED...), and make them available in Python. - The build has been tested on: Linux2: OK SunOS5: OK IRIX64: Build OK, crash on test (bus error) - Inference with distutils: I found it very difficult understanding the distutil architecture and finding the right points of change; I minimized my interaction there. Furthermore, the availability of the 'configbuild' module overlaps some of the distutils; but 'configbuild' is very easy to use ... - Unresolved symbols: I turned on the symbol checking flags whenever possible, on behalf the its better generating the error on build than at runtime. - configure.in: I only edited the configure Bourne script, and did not bother with configure.in (actually, I deleted it) and its autoconfig/m4 macro comparses. Frederic Giacometti ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 18:36 Message: Logged In: YES user_id=6380 > What is the point of keeping using the autoconf thing when > it is easier to maintain configure directly, than going > through configure.in ? But it's not. One line of configure.in often expands to dozens (occasionally hundreds) of lines of configure. autoconf has arcane knowledge that gets updated with new autoconf releases. You are entitled to your opinion, but in this case, it's wrong. Go fork your own version of Python if you don't want to learn autoconf. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-12 16:06 Message: Logged In: YES user_id=93657 I am not willing to make anything difficult for anybody, but: What is the point of keeping using the autoconf thing when it is easier to maintain configure directly, than going through configure.in ? After configure has been generated once, it makes more sense to me to work directly on configure, and forget about configure.in. configure (pure Bourne shell) is a easier to understand, to troubleshoot, and to maintain that configure.in (a mixture of Bourne shell and autoconf m4 macros). I'll have a second look at the autoconf thing latter on - at present I hardly understand anything to configure.in, and got 'configure --with-shared' working with satisfaction across multiple platforms without undue difficulties. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 11:37 Message: Logged In: YES user_id=6380 > Autoconf is not installed on the commercial Unix > platforms, it is useless for me to learn it, and I was > better off directly editing ./configure. However, if others > are familiar with the tool, it should be straightforward for > them to retrocede the changes from configure to configure.in Sure. You'll just have to wait until we have time for that. You can make it easy for us to integrate your changes, or you can make it difficult. Your choice. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-12 11:12 Message: Logged In: YES user_id=93657 - I will remove the configbuild; since Martin pointed to me the existence of distutils.sysconfig.get_config_vars(). I did not know about this function... Thanks! On the fly, you'll also note the following potential problem with using get_config_vars() instead of configbuild: configbuild will report the actual values used for the build, whereas get_config_vars() will report erroneous values whenever the Makefile internal variables were overriden at build time (by either the environment, or by commandline assignment of the type 'make CC=gxx ...'); not to mention that configbuild does not need to find and parse the original Makefile (with all the potential problems associated). - The .purify line should be in the CVSROOT/cvsignore CVS admin file, not in .cvsignore in the root directory of the source distribution... - Autoconf is not installed on the commercial Unix platforms, it is useless for me to learn it, and I was better off directly editing ./configure. However, if others are familiar with the tool, it should be straightforward for them to retrocede the changes from configure to configure.in - I had to introduce THREADOBJ because you will note that, in the present implementation, Modules/thread.o appears multiple times in LIBOBJS, which causes warning at link time. Now, Modules/thread.o appears only once ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-12 01:06 Message: Logged In: YES user_id=21627 As for libtool: I strongly advise not to use it. It is broken in too many ways to enumerate. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-12 00:18 Message: Logged In: YES user_id=21627 I recommend to rework this patch to get rid of configbuild. I cannot see what you achieve with the configbuild module that you couldn't do with distutils.sysconfig.get_config_vars (which is capable of parsing the Makefile directly). I also recommend to go through the patch chunk by chunk, asking yourself whether this chunk *really* is needed to achieve the desired functionality. E.g. I cannot see the relationship of the .cvsignore chunk; I also believe that removal of .purify is incorrect. Likewise, while I sympathize with the unresolved symbols change, I believe it is unrelated to the main objective of this patch (building Python shared). What is the rationale for not changing configure.in? As-is, this patch is useless: configure will be overwritten everytime you run autoconf. Please get a copy of autoconf on one of your systems, change configure.in, run autoconf, and then provide us with a patch that only changes configure.in: everybody reviewing this patch should be capable of running autoconf. configure is a generated file and should not be edited manually. What is the rationale for the introduction of the THREADOBJ variable? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-11 19:03 Message: Logged In: YES user_id=6380 Haven't seen the patch yet, but I like the idea -- the command line option suggests that it shouldn't hurt platforms where it can't be done or has to be done differently. Alternative: we could also consider using libtool. I didn't like that much in the past, but maybe it would work. Dunno. Anybody know about it? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 From noreply@sourceforge.net Thu Sep 13 05:08:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Sep 2001 21:08:17 -0700 Subject: [Patches] [ python-Patches-460805 ] Support for unsetenv() Message-ID: Patches item #460805, was opened at 2001-09-11 21:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Gonnerman (solomoriah) Assigned to: Nobody/Anonymous (nobody) Summary: Support for unsetenv() Initial Comment: The attached patch files implement os.unsetenv() for Python 2.1 and 2.2a3. os.py is extended to call unsetenv() when _Environ.__delitem__ is called. ---------------------------------------------------------------------- >Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 21:08 Message: Logged In: YES user_id=321948 Ouch. It's in AT&T/USL/SCO Unix AFAIK, it's in NetBSD and GNU libc for sure, and the other BSD's also I believe; Win32 provides a different way to do it, but there is a way. I think Solaris has it also but I can't easily check. De facto standards are important too. As for the bloat argument, my patch adds a tiny function to posixmodule and a tiny method to os._Environ (in the Unix version only at this point); my Python 2.1 interpreter gained a couple hundred bytes. Code bloat is when you add unnecessary features to a module. Python has *no other way* to remove an environment variable so that child processes don't see it, so Python's behavior is broken. It is IMHO not Pythonic to have del os.environ["HOME"] (for instance) not work correctly. From the perspective of the calling module, there is no longer a HOME variable, but called processes will still see it. It's true, you can set the variable to a null string, but this isn't the same thing and might not satisfy some secure programming requirements. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 18:31 Message: Logged In: YES user_id=6380 Code bloat. If it's not important enough to standardize in POSIX (or one of the other standards), why should we add it? GNU code is infamous for always including more features, needed or not. If you're cynical, this is part of a Microsoft-like "buy-in" strategy (code developed for GNU libc doesn't work anywhere else). ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 18:20 Message: Logged In: YES user_id=321948 By the way, I found the following note in the man pages for NetBSD: The functions setenv() and unsetenv() appeared in Version 7 AT&T UNIX. so it appears, standard or not, that most real Unix systems should have it. Regarding the minimal utility argument, I don't currently have a use for it, but it came up on the mailing list so I wrote it. It's recommended, when writing sysadmin tools which call other programs, to "clean up" the environment so that only known-safe values are in there before calling the externals. ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 18:14 Message: Logged In: YES user_id=321948 Well, the only place I know of that it is standardized is in GNU libc. That's not entirely the point, though. 1) If you do 'del os.environ["SOMEVAR"]' you remove SOMEVAR from the copy of the environment but not from the real environment. This behavior IMHO is broken. 2) It's true, many OS's don't have unsetenv(). However, my patch falls back to the *current* behavior if unsetenv() is not available. In other words, this doesn't break Python any more than it's already broken, and it's a net gain for operating systems that *do* have unsetenv(). I figure if some gain and none lose, why not do it? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 06:38 Message: Logged In: YES user_id=6380 Can you point to where unsetenv is standardized? I'm worried that it's not available on standard-conforming Unix systems, and since it's of marginal utility at best, I'm not sure what the point is to add it -- unless there's a clear standard that ensures its existence. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 From noreply@sourceforge.net Thu Sep 13 15:54:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Sep 2001 07:54:54 -0700 Subject: [Patches] [ python-Patches-460402 ] PEP 270: uniq() method for list objects Message-ID: Patches item #460402, was opened at 2001-09-10 11:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460402&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Petrone (jpetrone) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 270: uniq() method for list objects Initial Comment: Remove duplicate elements from a list object. 3 Patches: uniq.doc.patch - Documentation changes in libstdtypes.tex uniq.ordered.patch - Changes to listmodule.c for brute force duplicate removal with uniq(). Maintains list order. uniq.unordered.patch - Changes to listmodule.c for duplicate removal with uniq() First tries using a mapping object. If the list elements aren't mapable, tries sorted removal. If the list isn't sortable, finally falls back on brute force removal. Does not maintain list order. ---------------------------------------------------------------------- >Comment By: Jason Petrone (jpetrone) Date: 2001-09-13 07:54 Message: Logged In: YES user_id=71210 I've always assumed the unix uniq(1) program only removes consecutive duplicates so it may operate on very large files without buffering them entirely into memory. In Python, buffering the data in memory isn't an issue since it is already there. Also, in most cases a hash table can be used instead of sorting for slightly better performance than pre-sorting and removing consecutive duplicates. My main reason for not wanting to mimic unix uniq's functionality is that I've never really been in a situation where I've only needed consecutive duplicates removed. I think achieving global uniqueness in a list is a much more common task. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 14:18 Message: Logged In: YES user_id=6380 Hm. The unix uniq(1) program only removes *consecutive* duplicates. That's an O(N) algorithm and only requires equality to be defined, and leaves the sorting to the caller. Would it make sense to support only that? I guess I'm looking for a use case here... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460402&group_id=5470 From noreply@sourceforge.net Thu Sep 13 16:34:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Sep 2001 08:34:49 -0700 Subject: [Patches] [ python-Patches-460402 ] PEP 270: uniq() method for list objects Message-ID: Patches item #460402, was opened at 2001-09-10 11:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460402&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Petrone (jpetrone) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 270: uniq() method for list objects Initial Comment: Remove duplicate elements from a list object. 3 Patches: uniq.doc.patch - Documentation changes in libstdtypes.tex uniq.ordered.patch - Changes to listmodule.c for brute force duplicate removal with uniq(). Maintains list order. uniq.unordered.patch - Changes to listmodule.c for duplicate removal with uniq() First tries using a mapping object. If the list elements aren't mapable, tries sorted removal. If the list isn't sortable, finally falls back on brute force removal. Does not maintain list order. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 08:34 Message: Logged In: YES user_id=6380 I've always assumed that the reason uniq(1) only removed consecutive duplicates would be so that it doesn't have to use a O(N**2) algorithm where an O(N log N) algorithm will do. If you need all duplicates removed, you can do it as follows: L.sort() L.uniq() In many cases, you can ensure uniqueness by simply choosing the right data structures. The keys of a dictionary can be used to represent a set; there's also talk of adding a set data type (see PEP 218). I still haven't seen a good motivation for this addition. If you don't post it here, I'll reject this. ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-09-13 07:54 Message: Logged In: YES user_id=71210 I've always assumed the unix uniq(1) program only removes consecutive duplicates so it may operate on very large files without buffering them entirely into memory. In Python, buffering the data in memory isn't an issue since it is already there. Also, in most cases a hash table can be used instead of sorting for slightly better performance than pre-sorting and removing consecutive duplicates. My main reason for not wanting to mimic unix uniq's functionality is that I've never really been in a situation where I've only needed consecutive duplicates removed. I think achieving global uniqueness in a list is a much more common task. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 14:18 Message: Logged In: YES user_id=6380 Hm. The unix uniq(1) program only removes *consecutive* duplicates. That's an O(N) algorithm and only requires equality to be defined, and leaves the sorting to the caller. Would it make sense to support only that? I guess I'm looking for a use case here... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460402&group_id=5470 From noreply@sourceforge.net Thu Sep 13 16:36:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Sep 2001 08:36:51 -0700 Subject: [Patches] [ python-Patches-460805 ] Support for unsetenv() Message-ID: Patches item #460805, was opened at 2001-09-11 21:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Gonnerman (solomoriah) Assigned to: Nobody/Anonymous (nobody) Summary: Support for unsetenv() Initial Comment: The attached patch files implement os.unsetenv() for Python 2.1 and 2.2a3. os.py is extended to call unsetenv() when _Environ.__delitem__ is called. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 08:36 Message: Logged In: YES user_id=6380 Lots of speculation there, but no motivation beyond "it's not Pythonic". IMO it's very Pythonic not to provide features that are rarely needed and can easily be done without. But who am I to judge. :-) If you give me a patch that implemens "del os.environ[key]" by calling os.putenv(key, ""), I'll accept it in a jiffy. ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 21:08 Message: Logged In: YES user_id=321948 Ouch. It's in AT&T/USL/SCO Unix AFAIK, it's in NetBSD and GNU libc for sure, and the other BSD's also I believe; Win32 provides a different way to do it, but there is a way. I think Solaris has it also but I can't easily check. De facto standards are important too. As for the bloat argument, my patch adds a tiny function to posixmodule and a tiny method to os._Environ (in the Unix version only at this point); my Python 2.1 interpreter gained a couple hundred bytes. Code bloat is when you add unnecessary features to a module. Python has *no other way* to remove an environment variable so that child processes don't see it, so Python's behavior is broken. It is IMHO not Pythonic to have del os.environ["HOME"] (for instance) not work correctly. From the perspective of the calling module, there is no longer a HOME variable, but called processes will still see it. It's true, you can set the variable to a null string, but this isn't the same thing and might not satisfy some secure programming requirements. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 18:31 Message: Logged In: YES user_id=6380 Code bloat. If it's not important enough to standardize in POSIX (or one of the other standards), why should we add it? GNU code is infamous for always including more features, needed or not. If you're cynical, this is part of a Microsoft-like "buy-in" strategy (code developed for GNU libc doesn't work anywhere else). ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 18:20 Message: Logged In: YES user_id=321948 By the way, I found the following note in the man pages for NetBSD: The functions setenv() and unsetenv() appeared in Version 7 AT&T UNIX. so it appears, standard or not, that most real Unix systems should have it. Regarding the minimal utility argument, I don't currently have a use for it, but it came up on the mailing list so I wrote it. It's recommended, when writing sysadmin tools which call other programs, to "clean up" the environment so that only known-safe values are in there before calling the externals. ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 18:14 Message: Logged In: YES user_id=321948 Well, the only place I know of that it is standardized is in GNU libc. That's not entirely the point, though. 1) If you do 'del os.environ["SOMEVAR"]' you remove SOMEVAR from the copy of the environment but not from the real environment. This behavior IMHO is broken. 2) It's true, many OS's don't have unsetenv(). However, my patch falls back to the *current* behavior if unsetenv() is not available. In other words, this doesn't break Python any more than it's already broken, and it's a net gain for operating systems that *do* have unsetenv(). I figure if some gain and none lose, why not do it? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 06:38 Message: Logged In: YES user_id=6380 Can you point to where unsetenv is standardized? I'm worried that it's not available on standard-conforming Unix systems, and since it's of marginal utility at best, I'm not sure what the point is to add it -- unless there's a clear standard that ensures its existence. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 From noreply@sourceforge.net Thu Sep 13 16:50:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Sep 2001 08:50:48 -0700 Subject: [Patches] [ python-Patches-460805 ] Support for unsetenv() Message-ID: Patches item #460805, was opened at 2001-09-11 21:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Gonnerman (solomoriah) Assigned to: Nobody/Anonymous (nobody) Summary: Support for unsetenv() Initial Comment: The attached patch files implement os.unsetenv() for Python 2.1 and 2.2a3. os.py is extended to call unsetenv() when _Environ.__delitem__ is called. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-09-13 08:50 Message: Logged In: YES user_id=34209 Sorry, Guido, but I have to agree with Chris here. You *can't* do without unsetenv. Setting the environment variable to an empty string is not the same as removing it. unsetenv() appeared in BSD4.3, so it is a lot more standard than, say, LFS support, or some of the other functions we define in the posix module. It's easy to test for, it introduces no problems wrt. prototypes or such, and it provides functionality that's not available otherwise. Unsetting environment variables can't be done portably, but we can't do it *at all* right now. Making 'del' work the expected way (by using unsetenv, or faking it using os.putenv(key, "") seems very useful to me -- in fact, I was suprised os.environ didn't already do that! I definately do not see this as code bloat. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 08:36 Message: Logged In: YES user_id=6380 Lots of speculation there, but no motivation beyond "it's not Pythonic". IMO it's very Pythonic not to provide features that are rarely needed and can easily be done without. But who am I to judge. :-) If you give me a patch that implemens "del os.environ[key]" by calling os.putenv(key, ""), I'll accept it in a jiffy. ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 21:08 Message: Logged In: YES user_id=321948 Ouch. It's in AT&T/USL/SCO Unix AFAIK, it's in NetBSD and GNU libc for sure, and the other BSD's also I believe; Win32 provides a different way to do it, but there is a way. I think Solaris has it also but I can't easily check. De facto standards are important too. As for the bloat argument, my patch adds a tiny function to posixmodule and a tiny method to os._Environ (in the Unix version only at this point); my Python 2.1 interpreter gained a couple hundred bytes. Code bloat is when you add unnecessary features to a module. Python has *no other way* to remove an environment variable so that child processes don't see it, so Python's behavior is broken. It is IMHO not Pythonic to have del os.environ["HOME"] (for instance) not work correctly. From the perspective of the calling module, there is no longer a HOME variable, but called processes will still see it. It's true, you can set the variable to a null string, but this isn't the same thing and might not satisfy some secure programming requirements. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 18:31 Message: Logged In: YES user_id=6380 Code bloat. If it's not important enough to standardize in POSIX (or one of the other standards), why should we add it? GNU code is infamous for always including more features, needed or not. If you're cynical, this is part of a Microsoft-like "buy-in" strategy (code developed for GNU libc doesn't work anywhere else). ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 18:20 Message: Logged In: YES user_id=321948 By the way, I found the following note in the man pages for NetBSD: The functions setenv() and unsetenv() appeared in Version 7 AT&T UNIX. so it appears, standard or not, that most real Unix systems should have it. Regarding the minimal utility argument, I don't currently have a use for it, but it came up on the mailing list so I wrote it. It's recommended, when writing sysadmin tools which call other programs, to "clean up" the environment so that only known-safe values are in there before calling the externals. ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 18:14 Message: Logged In: YES user_id=321948 Well, the only place I know of that it is standardized is in GNU libc. That's not entirely the point, though. 1) If you do 'del os.environ["SOMEVAR"]' you remove SOMEVAR from the copy of the environment but not from the real environment. This behavior IMHO is broken. 2) It's true, many OS's don't have unsetenv(). However, my patch falls back to the *current* behavior if unsetenv() is not available. In other words, this doesn't break Python any more than it's already broken, and it's a net gain for operating systems that *do* have unsetenv(). I figure if some gain and none lose, why not do it? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 06:38 Message: Logged In: YES user_id=6380 Can you point to where unsetenv is standardized? I'm worried that it's not available on standard-conforming Unix systems, and since it's of marginal utility at best, I'm not sure what the point is to add it -- unless there's a clear standard that ensures its existence. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 From noreply@sourceforge.net Thu Sep 13 16:56:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Sep 2001 08:56:21 -0700 Subject: [Patches] [ python-Patches-460402 ] PEP 270: uniq() method for list objects Message-ID: Patches item #460402, was opened at 2001-09-10 11:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460402&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Petrone (jpetrone) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 270: uniq() method for list objects Initial Comment: Remove duplicate elements from a list object. 3 Patches: uniq.doc.patch - Documentation changes in libstdtypes.tex uniq.ordered.patch - Changes to listmodule.c for brute force duplicate removal with uniq(). Maintains list order. uniq.unordered.patch - Changes to listmodule.c for duplicate removal with uniq() First tries using a mapping object. If the list elements aren't mapable, tries sorted removal. If the list isn't sortable, finally falls back on brute force removal. Does not maintain list order. ---------------------------------------------------------------------- >Comment By: Jason Petrone (jpetrone) Date: 2001-09-13 08:56 Message: Logged In: YES user_id=71210 I don't really have any motivations for this which aren't apparent. If you don't immediately see this as useful it probably should be rejected. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 08:34 Message: Logged In: YES user_id=6380 I've always assumed that the reason uniq(1) only removed consecutive duplicates would be so that it doesn't have to use a O(N**2) algorithm where an O(N log N) algorithm will do. If you need all duplicates removed, you can do it as follows: L.sort() L.uniq() In many cases, you can ensure uniqueness by simply choosing the right data structures. The keys of a dictionary can be used to represent a set; there's also talk of adding a set data type (see PEP 218). I still haven't seen a good motivation for this addition. If you don't post it here, I'll reject this. ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-09-13 07:54 Message: Logged In: YES user_id=71210 I've always assumed the unix uniq(1) program only removes consecutive duplicates so it may operate on very large files without buffering them entirely into memory. In Python, buffering the data in memory isn't an issue since it is already there. Also, in most cases a hash table can be used instead of sorting for slightly better performance than pre-sorting and removing consecutive duplicates. My main reason for not wanting to mimic unix uniq's functionality is that I've never really been in a situation where I've only needed consecutive duplicates removed. I think achieving global uniqueness in a list is a much more common task. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 14:18 Message: Logged In: YES user_id=6380 Hm. The unix uniq(1) program only removes *consecutive* duplicates. That's an O(N) algorithm and only requires equality to be defined, and leaves the sorting to the caller. Would it make sense to support only that? I guess I'm looking for a use case here... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460402&group_id=5470 From noreply@sourceforge.net Thu Sep 13 17:33:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Sep 2001 09:33:44 -0700 Subject: [Patches] [ python-Patches-460805 ] Support for unsetenv() Message-ID: Patches item #460805, was opened at 2001-09-11 21:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Gonnerman (solomoriah) >Assigned to: Thomas Wouters (twouters) Summary: Support for unsetenv() Initial Comment: The attached patch files implement os.unsetenv() for Python 2.1 and 2.2a3. os.py is extended to call unsetenv() when _Environ.__delitem__ is called. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 09:33 Message: Logged In: YES user_id=6380 Excellent, Thomas. I was waiting for someone to champion this. I hope you don't mind that I assigned it to you. Go ahead and review the code and decide what to do! ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-09-13 08:50 Message: Logged In: YES user_id=34209 Sorry, Guido, but I have to agree with Chris here. You *can't* do without unsetenv. Setting the environment variable to an empty string is not the same as removing it. unsetenv() appeared in BSD4.3, so it is a lot more standard than, say, LFS support, or some of the other functions we define in the posix module. It's easy to test for, it introduces no problems wrt. prototypes or such, and it provides functionality that's not available otherwise. Unsetting environment variables can't be done portably, but we can't do it *at all* right now. Making 'del' work the expected way (by using unsetenv, or faking it using os.putenv(key, "") seems very useful to me -- in fact, I was suprised os.environ didn't already do that! I definately do not see this as code bloat. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 08:36 Message: Logged In: YES user_id=6380 Lots of speculation there, but no motivation beyond "it's not Pythonic". IMO it's very Pythonic not to provide features that are rarely needed and can easily be done without. But who am I to judge. :-) If you give me a patch that implemens "del os.environ[key]" by calling os.putenv(key, ""), I'll accept it in a jiffy. ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 21:08 Message: Logged In: YES user_id=321948 Ouch. It's in AT&T/USL/SCO Unix AFAIK, it's in NetBSD and GNU libc for sure, and the other BSD's also I believe; Win32 provides a different way to do it, but there is a way. I think Solaris has it also but I can't easily check. De facto standards are important too. As for the bloat argument, my patch adds a tiny function to posixmodule and a tiny method to os._Environ (in the Unix version only at this point); my Python 2.1 interpreter gained a couple hundred bytes. Code bloat is when you add unnecessary features to a module. Python has *no other way* to remove an environment variable so that child processes don't see it, so Python's behavior is broken. It is IMHO not Pythonic to have del os.environ["HOME"] (for instance) not work correctly. From the perspective of the calling module, there is no longer a HOME variable, but called processes will still see it. It's true, you can set the variable to a null string, but this isn't the same thing and might not satisfy some secure programming requirements. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 18:31 Message: Logged In: YES user_id=6380 Code bloat. If it's not important enough to standardize in POSIX (or one of the other standards), why should we add it? GNU code is infamous for always including more features, needed or not. If you're cynical, this is part of a Microsoft-like "buy-in" strategy (code developed for GNU libc doesn't work anywhere else). ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 18:20 Message: Logged In: YES user_id=321948 By the way, I found the following note in the man pages for NetBSD: The functions setenv() and unsetenv() appeared in Version 7 AT&T UNIX. so it appears, standard or not, that most real Unix systems should have it. Regarding the minimal utility argument, I don't currently have a use for it, but it came up on the mailing list so I wrote it. It's recommended, when writing sysadmin tools which call other programs, to "clean up" the environment so that only known-safe values are in there before calling the externals. ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 18:14 Message: Logged In: YES user_id=321948 Well, the only place I know of that it is standardized is in GNU libc. That's not entirely the point, though. 1) If you do 'del os.environ["SOMEVAR"]' you remove SOMEVAR from the copy of the environment but not from the real environment. This behavior IMHO is broken. 2) It's true, many OS's don't have unsetenv(). However, my patch falls back to the *current* behavior if unsetenv() is not available. In other words, this doesn't break Python any more than it's already broken, and it's a net gain for operating systems that *do* have unsetenv(). I figure if some gain and none lose, why not do it? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 06:38 Message: Logged In: YES user_id=6380 Can you point to where unsetenv is standardized? I'm worried that it's not available on standard-conforming Unix systems, and since it's of marginal utility at best, I'm not sure what the point is to add it -- unless there's a clear standard that ensures its existence. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 From noreply@sourceforge.net Thu Sep 13 17:59:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Sep 2001 09:59:47 -0700 Subject: [Patches] [ python-Patches-460402 ] PEP 270: uniq() method for list objects Message-ID: Patches item #460402, was opened at 2001-09-10 11:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460402&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Jason Petrone (jpetrone) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 270: uniq() method for list objects Initial Comment: Remove duplicate elements from a list object. 3 Patches: uniq.doc.patch - Documentation changes in libstdtypes.tex uniq.ordered.patch - Changes to listmodule.c for brute force duplicate removal with uniq(). Maintains list order. uniq.unordered.patch - Changes to listmodule.c for duplicate removal with uniq() First tries using a mapping object. If the list elements aren't mapable, tries sorted removal. If the list isn't sortable, finally falls back on brute force removal. Does not maintain list order. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 09:59 Message: Logged In: YES user_id=6380 I talked this over with Tim Peters (whose Cookbook entry is the source of your original code, we presume). He doesn't want a Unix-style uniq(), because usually the dict approach is fastest, and it is O(N). But he also thinks there is little reason to make this a built-in, given that the cookbook example exists and is easy enough to follow. The only reason to make this a built-in would be if it can be done much faster in Python, which we doubt since most of the time goes in the dictionary implementation anyway. Finally, this is the realm of sets, which (if Greg V Wilson ever finishes his work for PEP 218) will eventually become a standard Python datatype. So, I'm rejecting this patch. Sorry! ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-09-13 08:56 Message: Logged In: YES user_id=71210 I don't really have any motivations for this which aren't apparent. If you don't immediately see this as useful it probably should be rejected. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 08:34 Message: Logged In: YES user_id=6380 I've always assumed that the reason uniq(1) only removed consecutive duplicates would be so that it doesn't have to use a O(N**2) algorithm where an O(N log N) algorithm will do. If you need all duplicates removed, you can do it as follows: L.sort() L.uniq() In many cases, you can ensure uniqueness by simply choosing the right data structures. The keys of a dictionary can be used to represent a set; there's also talk of adding a set data type (see PEP 218). I still haven't seen a good motivation for this addition. If you don't post it here, I'll reject this. ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-09-13 07:54 Message: Logged In: YES user_id=71210 I've always assumed the unix uniq(1) program only removes consecutive duplicates so it may operate on very large files without buffering them entirely into memory. In Python, buffering the data in memory isn't an issue since it is already there. Also, in most cases a hash table can be used instead of sorting for slightly better performance than pre-sorting and removing consecutive duplicates. My main reason for not wanting to mimic unix uniq's functionality is that I've never really been in a situation where I've only needed consecutive duplicates removed. I think achieving global uniqueness in a list is a much more common task. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 14:18 Message: Logged In: YES user_id=6380 Hm. The unix uniq(1) program only removes *consecutive* duplicates. That's an O(N) algorithm and only requires equality to be defined, and leaves the sorting to the caller. Would it make sense to support only that? I guess I'm looking for a use case here... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460402&group_id=5470 From noreply@sourceforge.net Thu Sep 13 21:08:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Sep 2001 13:08:46 -0700 Subject: [Patches] [ python-Patches-461321 ] Fix timeout=None in asyncore.py Message-ID: Patches item #461321, was opened at 2001-09-13 13:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461321&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cesar Eduardo Barros (cesarb) Assigned to: Nobody/Anonymous (nobody) Summary: Fix timeout=None in asyncore.py Initial Comment: This patch makes poll2 and poll3 in asyncore.py work when the timeout argument is None instead of a number. The patch is against CVS 1.18 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461321&group_id=5470 From noreply@sourceforge.net Thu Sep 13 21:33:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Sep 2001 13:33:06 -0700 Subject: [Patches] [ python-Patches-461337 ] Docs for SSL methods and objects Message-ID: Patches item #461337, was opened at 2001-09-13 13:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461337&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Hдring (ghaering) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Docs for SSL methods and objects Initial Comment: This is my try to fix bug #215026. Perhaps a link to the OpenSSL homepage should be added somewhere (so we don't have to explain all that private key and certificate stuff in the docs ourselves). I also think it should be indicated somewhere, that Python's SSL implementation is incomplete, not to be considered secure (certificates aren't checked) and thus (at least I hope so :-), likely to be changed in the future. Did I already say that the SSL stuff looks quite broken? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461337&group_id=5470 From noreply@sourceforge.net Thu Sep 13 21:39:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Sep 2001 13:39:12 -0700 Subject: [Patches] [ python-Patches-461337 ] Docs for SSL methods and objects Message-ID: Patches item #461337, was opened at 2001-09-13 13:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461337&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Hдring (ghaering) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Docs for SSL methods and objects Initial Comment: This is my try to fix bug #215026. Perhaps a link to the OpenSSL homepage should be added somewhere (so we don't have to explain all that private key and certificate stuff in the docs ourselves). I also think it should be indicated somewhere, that Python's SSL implementation is incomplete, not to be considered secure (certificates aren't checked) and thus (at least I hope so :-), likely to be changed in the future. Did I already say that the SSL stuff looks quite broken? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 13:39 Message: Logged In: YES user_id=6380 Thanks for the feedback, Gerhard. Unfortunately this code was donated and nobody at PythonLabs understands it enough to fix it. Do you want to help? At least tell us what you think "looks quite broken". If you know how to fix it, that would be great! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461337&group_id=5470 From noreply@sourceforge.net Thu Sep 13 22:17:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Sep 2001 14:17:37 -0700 Subject: [Patches] [ python-Patches-461337 ] Docs for SSL methods and objects Message-ID: Patches item #461337, was opened at 2001-09-13 13:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461337&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Hдring (ghaering) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Docs for SSL methods and objects Initial Comment: This is my try to fix bug #215026. Perhaps a link to the OpenSSL homepage should be added somewhere (so we don't have to explain all that private key and certificate stuff in the docs ourselves). I also think it should be indicated somewhere, that Python's SSL implementation is incomplete, not to be considered secure (certificates aren't checked) and thus (at least I hope so :-), likely to be changed in the future. Did I already say that the SSL stuff looks quite broken? ---------------------------------------------------------------------- >Comment By: Gerhard Hдring (ghaering) Date: 2001-09-13 14:17 Message: Logged In: YES user_id=163326 Well, I don't fully understand the code either (and just know the basics about sockets and OpenSSL). With incomplete, I mean that it would be nice if the SSLObject were compatible to a socket object and thus interchangeable. This is currently not the case. Sockets have send() and recv() while the SSLObject has read() and write(). Another possibility would be to make the SSLObject a "file-like object". As for why I think it's broken: The ssl() method requires that you provide it with a private key file and a certficate key store (that contains known certifictates of Certificate Authorities (Verisign, ...) and server certificates). But it looks like the code doesn't check the certificates at all, and a forged certificate is silently ignored, even if it could be detected. I'm mainly drawing my conclusion from this line of code and the OpenSSL documentation for this function (socketmodule.c; newSSLObject()): SSL_CTX_set_verify(self->ctx, SSL_VERIFY_NONE, NULL); /* set verify lvl */ I'll try to look further into this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 13:39 Message: Logged In: YES user_id=6380 Thanks for the feedback, Gerhard. Unfortunately this code was donated and nobody at PythonLabs understands it enough to fix it. Do you want to help? At least tell us what you think "looks quite broken". If you know how to fix it, that would be great! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461337&group_id=5470 From noreply@sourceforge.net Fri Sep 14 01:11:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Sep 2001 17:11:02 -0700 Subject: [Patches] [ python-Patches-459385 ] 2.1.1 time.timezone fix for Cygwin Message-ID: Patches item #459385, was opened at 2001-09-06 18:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459385&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Norman Vine (nhv) Assigned to: Nobody/Anonymous (nobody) Summary: 2.1.1 time.timezone fix for Cygwin Initial Comment: *** timemodule.bak Wed Jun 27 09:01:54 2001 --- timemodule.c Thu Sep 6 20:29:28 2001 *************** *** 599,605 **** /* Squirrel away the module's dictionary for the y2k check */ Py_INCREF(d); moddict = d; ! #if defined(HAVE_TZNAME) && !defined(__GLIBC__) tzset(); #ifdef PYOS_OS2 ins(d, "timezone", PyInt_FromLong((long) _timezone)); --- 599,605 ---- /* Squirrel away the module's dictionary for the y2k check */ Py_INCREF(d); moddict = d; ! #if defined(HAVE_TZNAME) && !defined(__GLIBC__) &&! defined(__CYGWIN__) tzset(); #ifdef PYOS_OS2 ins(d, "timezone", PyInt_FromLong((long) _timezone)); ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-09-13 17:11 Message: Logged In: YES user_id=86216 [I guess that there is not a way to upload a patch if you are not the submitter?] I concur that this patch should be accepted. However, I offer the following slightly more aesthetic, but otherwise functionality identical patch: Index: timemodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/timemodule.c,v retrieving revision 2.113 diff -c -r2.113 timemodule.c *** timemodule.c 2001/08/22 12:39:16 2.113 --- timemodule.c 2001/09/13 17:54:27 *************** *** 599,605 **** /* Squirrel away the module's dictionary for the y2k check */ Py_INCREF(d); moddict = d; ! #if defined(HAVE_TZNAME) && !defined(__GLIBC__) tzset(); #ifdef PYOS_OS2 ins(d, "timezone", PyInt_FromLong((long)_timezone)); --- 599,605 ---- /* Squirrel away the module's dictionary for the y2k check */ Py_INCREF(d); moddict = d; ! #if defined(HAVE_TZNAME) && !defined(__GLIBC__) && !defined(__CYGWIN__) tzset(); #ifdef PYOS_OS2 ins(d, "timezone", PyInt_FromLong((long)_timezone)); *************** *** 617,623 **** #endif ins(d, "daylight", PyInt_FromLong((long)daylight)); ins(d, "tzname", Py_BuildValue("(zz)", tzname[0], tzname[1])); ! #else /* !HAVE_TZNAME || __GLIBC__ */ #ifdef HAVE_TM_ZONE { #define YEAR ((time_t)((365 * 24 + 6) * 3600)) --- 617,623 ---- #endif ins(d, "daylight", PyInt_FromLong((long)daylight)); ins(d, "tzname", Py_BuildValue("(zz)", tzname[0], tzname[1])); ! #else /* !HAVE_TZNAME || __GLIBC__ || __CYGWIN__*/ #ifdef HAVE_TM_ZONE { #define YEAR ((time_t)((365 * 24 + 6) * 3600)) *************** *** 673,679 **** ins(d, "daylight", PyInt_FromLong(_daylight)); ins(d, "tzname", Py_BuildValue("(zz)", _tzname[0], _tzname[1])); #endif /* __CYGWIN__ */ ! #endif /* !HAVE_TZNAME || __GLIBC__ */ } --- 673,679 ---- ins(d, "daylight", PyInt_FromLong(_daylight)); ins(d, "tzname", Py_BuildValue("(zz)", _tzname[0], _tzname[1])); #endif /* __CYGWIN__ */ ! #endif /* !HAVE_TZNAME || __GLIBC__ || __CYGWIN__*/ } ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459385&group_id=5470 From noreply@sourceforge.net Fri Sep 14 01:14:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Sep 2001 17:14:55 -0700 Subject: [Patches] [ python-Patches-459385 ] 2.1.1 time.timezone fix for Cygwin Message-ID: Patches item #459385, was opened at 2001-09-06 18:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459385&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Norman Vine (nhv) Assigned to: Nobody/Anonymous (nobody) Summary: 2.1.1 time.timezone fix for Cygwin Initial Comment: *** timemodule.bak Wed Jun 27 09:01:54 2001 --- timemodule.c Thu Sep 6 20:29:28 2001 *************** *** 599,605 **** /* Squirrel away the module's dictionary for the y2k check */ Py_INCREF(d); moddict = d; ! #if defined(HAVE_TZNAME) && !defined(__GLIBC__) tzset(); #ifdef PYOS_OS2 ins(d, "timezone", PyInt_FromLong((long) _timezone)); --- 599,605 ---- /* Squirrel away the module's dictionary for the y2k check */ Py_INCREF(d); moddict = d; ! #if defined(HAVE_TZNAME) && !defined(__GLIBC__) &&! defined(__CYGWIN__) tzset(); #ifdef PYOS_OS2 ins(d, "timezone", PyInt_FromLong((long) _timezone)); ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-09-13 17:14 Message: Logged In: YES user_id=86216 Argh! I guess that I can mail the patch to Norman and then ask him to upload it... ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-09-13 17:11 Message: Logged In: YES user_id=86216 [I guess that there is not a way to upload a patch if you are not the submitter?] I concur that this patch should be accepted. However, I offer the following slightly more aesthetic, but otherwise functionality identical patch: Index: timemodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/timemodule.c,v retrieving revision 2.113 diff -c -r2.113 timemodule.c *** timemodule.c 2001/08/22 12:39:16 2.113 --- timemodule.c 2001/09/13 17:54:27 *************** *** 599,605 **** /* Squirrel away the module's dictionary for the y2k check */ Py_INCREF(d); moddict = d; ! #if defined(HAVE_TZNAME) && !defined(__GLIBC__) tzset(); #ifdef PYOS_OS2 ins(d, "timezone", PyInt_FromLong((long)_timezone)); --- 599,605 ---- /* Squirrel away the module's dictionary for the y2k check */ Py_INCREF(d); moddict = d; ! #if defined(HAVE_TZNAME) && !defined(__GLIBC__) && !defined(__CYGWIN__) tzset(); #ifdef PYOS_OS2 ins(d, "timezone", PyInt_FromLong((long)_timezone)); *************** *** 617,623 **** #endif ins(d, "daylight", PyInt_FromLong((long)daylight)); ins(d, "tzname", Py_BuildValue("(zz)", tzname[0], tzname[1])); ! #else /* !HAVE_TZNAME || __GLIBC__ */ #ifdef HAVE_TM_ZONE { #define YEAR ((time_t)((365 * 24 + 6) * 3600)) --- 617,623 ---- #endif ins(d, "daylight", PyInt_FromLong((long)daylight)); ins(d, "tzname", Py_BuildValue("(zz)", tzname[0], tzname[1])); ! #else /* !HAVE_TZNAME || __GLIBC__ || __CYGWIN__*/ #ifdef HAVE_TM_ZONE { #define YEAR ((time_t)((365 * 24 + 6) * 3600)) *************** *** 673,679 **** ins(d, "daylight", PyInt_FromLong(_daylight)); ins(d, "tzname", Py_BuildValue("(zz)", _tzname[0], _tzname[1])); #endif /* __CYGWIN__ */ ! #endif /* !HAVE_TZNAME || __GLIBC__ */ } --- 673,679 ---- ins(d, "daylight", PyInt_FromLong(_daylight)); ins(d, "tzname", Py_BuildValue("(zz)", _tzname[0], _tzname[1])); #endif /* __CYGWIN__ */ ! #endif /* !HAVE_TZNAME || __GLIBC__ || __CYGWIN__*/ } ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459385&group_id=5470 From noreply@sourceforge.net Fri Sep 14 01:38:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Sep 2001 17:38:34 -0700 Subject: [Patches] [ python-Patches-459385 ] 2.1.1 time.timezone fix for Cygwin Message-ID: Patches item #459385, was opened at 2001-09-06 18:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459385&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Norman Vine (nhv) Assigned to: Nobody/Anonymous (nobody) Summary: 2.1.1 time.timezone fix for Cygwin Initial Comment: *** timemodule.bak Wed Jun 27 09:01:54 2001 --- timemodule.c Thu Sep 6 20:29:28 2001 *************** *** 599,605 **** /* Squirrel away the module's dictionary for the y2k check */ Py_INCREF(d); moddict = d; ! #if defined(HAVE_TZNAME) && !defined(__GLIBC__) tzset(); #ifdef PYOS_OS2 ins(d, "timezone", PyInt_FromLong((long) _timezone)); --- 599,605 ---- /* Squirrel away the module's dictionary for the y2k check */ Py_INCREF(d); moddict = d; ! #if defined(HAVE_TZNAME) && !defined(__GLIBC__) &&! defined(__CYGWIN__) tzset(); #ifdef PYOS_OS2 ins(d, "timezone", PyInt_FromLong((long) _timezone)); ---------------------------------------------------------------------- >Comment By: Norman Vine (nhv) Date: 2001-09-13 17:38 Message: Logged In: YES user_id=1020 Could we please get either Jason's or my patch into the current source tree. AFAICT both work eaqually well Note AFAIK This is the last change we need for a Cygwin compiled Python running on Win2k to pass 100% of the make test regression suite :-) Thanks Norman Vine ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-09-13 17:14 Message: Logged In: YES user_id=86216 Argh! I guess that I can mail the patch to Norman and then ask him to upload it... ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-09-13 17:11 Message: Logged In: YES user_id=86216 [I guess that there is not a way to upload a patch if you are not the submitter?] I concur that this patch should be accepted. However, I offer the following slightly more aesthetic, but otherwise functionality identical patch: Index: timemodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/timemodule.c,v retrieving revision 2.113 diff -c -r2.113 timemodule.c *** timemodule.c 2001/08/22 12:39:16 2.113 --- timemodule.c 2001/09/13 17:54:27 *************** *** 599,605 **** /* Squirrel away the module's dictionary for the y2k check */ Py_INCREF(d); moddict = d; ! #if defined(HAVE_TZNAME) && !defined(__GLIBC__) tzset(); #ifdef PYOS_OS2 ins(d, "timezone", PyInt_FromLong((long)_timezone)); --- 599,605 ---- /* Squirrel away the module's dictionary for the y2k check */ Py_INCREF(d); moddict = d; ! #if defined(HAVE_TZNAME) && !defined(__GLIBC__) && !defined(__CYGWIN__) tzset(); #ifdef PYOS_OS2 ins(d, "timezone", PyInt_FromLong((long)_timezone)); *************** *** 617,623 **** #endif ins(d, "daylight", PyInt_FromLong((long)daylight)); ins(d, "tzname", Py_BuildValue("(zz)", tzname[0], tzname[1])); ! #else /* !HAVE_TZNAME || __GLIBC__ */ #ifdef HAVE_TM_ZONE { #define YEAR ((time_t)((365 * 24 + 6) * 3600)) --- 617,623 ---- #endif ins(d, "daylight", PyInt_FromLong((long)daylight)); ins(d, "tzname", Py_BuildValue("(zz)", tzname[0], tzname[1])); ! #else /* !HAVE_TZNAME || __GLIBC__ || __CYGWIN__*/ #ifdef HAVE_TM_ZONE { #define YEAR ((time_t)((365 * 24 + 6) * 3600)) *************** *** 673,679 **** ins(d, "daylight", PyInt_FromLong(_daylight)); ins(d, "tzname", Py_BuildValue("(zz)", _tzname[0], _tzname[1])); #endif /* __CYGWIN__ */ ! #endif /* !HAVE_TZNAME || __GLIBC__ */ } --- 673,679 ---- ins(d, "daylight", PyInt_FromLong(_daylight)); ins(d, "tzname", Py_BuildValue("(zz)", _tzname[0], _tzname[1])); #endif /* __CYGWIN__ */ ! #endif /* !HAVE_TZNAME || __GLIBC__ || __CYGWIN__*/ } ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459385&group_id=5470 From noreply@sourceforge.net Fri Sep 14 02:05:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Sep 2001 18:05:12 -0700 Subject: [Patches] [ python-Patches-461337 ] Docs for SSL methods and objects Message-ID: Patches item #461337, was opened at 2001-09-13 13:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461337&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Hдring (ghaering) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Docs for SSL methods and objects Initial Comment: This is my try to fix bug #215026. Perhaps a link to the OpenSSL homepage should be added somewhere (so we don't have to explain all that private key and certificate stuff in the docs ourselves). I also think it should be indicated somewhere, that Python's SSL implementation is incomplete, not to be considered secure (certificates aren't checked) and thus (at least I hope so :-), likely to be changed in the future. Did I already say that the SSL stuff looks quite broken? ---------------------------------------------------------------------- >Comment By: Gerhard Hдring (ghaering) Date: 2001-09-13 18:05 Message: Logged In: YES user_id=163326 I've updated the patch: in fact for the ssl() method the combination of (keyfile, certfile) is optional. That is, either supply both or none of these arguments. Nevertheless, a check of certificates doesn't take place in either case, that's why I added a "WARNING" to the ssl() function's documentation. ---------------------------------------------------------------------- Comment By: Gerhard Hдring (ghaering) Date: 2001-09-13 14:17 Message: Logged In: YES user_id=163326 Well, I don't fully understand the code either (and just know the basics about sockets and OpenSSL). With incomplete, I mean that it would be nice if the SSLObject were compatible to a socket object and thus interchangeable. This is currently not the case. Sockets have send() and recv() while the SSLObject has read() and write(). Another possibility would be to make the SSLObject a "file-like object". As for why I think it's broken: The ssl() method requires that you provide it with a private key file and a certficate key store (that contains known certifictates of Certificate Authorities (Verisign, ...) and server certificates). But it looks like the code doesn't check the certificates at all, and a forged certificate is silently ignored, even if it could be detected. I'm mainly drawing my conclusion from this line of code and the OpenSSL documentation for this function (socketmodule.c; newSSLObject()): SSL_CTX_set_verify(self->ctx, SSL_VERIFY_NONE, NULL); /* set verify lvl */ I'll try to look further into this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 13:39 Message: Logged In: YES user_id=6380 Thanks for the feedback, Gerhard. Unfortunately this code was donated and nobody at PythonLabs understands it enough to fix it. Do you want to help? At least tell us what you think "looks quite broken". If you know how to fix it, that would be great! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461337&group_id=5470 From noreply@sourceforge.net Fri Sep 14 03:11:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Sep 2001 19:11:53 -0700 Subject: [Patches] [ python-Patches-459385 ] 2.1.1 time.timezone fix for Cygwin Message-ID: Patches item #459385, was opened at 2001-09-06 18:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459385&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Norman Vine (nhv) >Assigned to: Tim Peters (tim_one) Summary: 2.1.1 time.timezone fix for Cygwin Initial Comment: *** timemodule.bak Wed Jun 27 09:01:54 2001 --- timemodule.c Thu Sep 6 20:29:28 2001 *************** *** 599,605 **** /* Squirrel away the module's dictionary for the y2k check */ Py_INCREF(d); moddict = d; ! #if defined(HAVE_TZNAME) && !defined(__GLIBC__) tzset(); #ifdef PYOS_OS2 ins(d, "timezone", PyInt_FromLong((long) _timezone)); --- 599,605 ---- /* Squirrel away the module's dictionary for the y2k check */ Py_INCREF(d); moddict = d; ! #if defined(HAVE_TZNAME) && !defined(__GLIBC__) &&! defined(__CYGWIN__) tzset(); #ifdef PYOS_OS2 ins(d, "timezone", PyInt_FromLong((long) _timezone)); ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 19:11 Message: Logged In: YES user_id=6380 We'll work on it. Give us some time. ---------------------------------------------------------------------- Comment By: Norman Vine (nhv) Date: 2001-09-13 17:38 Message: Logged In: YES user_id=1020 Could we please get either Jason's or my patch into the current source tree. AFAICT both work eaqually well Note AFAIK This is the last change we need for a Cygwin compiled Python running on Win2k to pass 100% of the make test regression suite :-) Thanks Norman Vine ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-09-13 17:14 Message: Logged In: YES user_id=86216 Argh! I guess that I can mail the patch to Norman and then ask him to upload it... ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-09-13 17:11 Message: Logged In: YES user_id=86216 [I guess that there is not a way to upload a patch if you are not the submitter?] I concur that this patch should be accepted. However, I offer the following slightly more aesthetic, but otherwise functionality identical patch: Index: timemodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/timemodule.c,v retrieving revision 2.113 diff -c -r2.113 timemodule.c *** timemodule.c 2001/08/22 12:39:16 2.113 --- timemodule.c 2001/09/13 17:54:27 *************** *** 599,605 **** /* Squirrel away the module's dictionary for the y2k check */ Py_INCREF(d); moddict = d; ! #if defined(HAVE_TZNAME) && !defined(__GLIBC__) tzset(); #ifdef PYOS_OS2 ins(d, "timezone", PyInt_FromLong((long)_timezone)); --- 599,605 ---- /* Squirrel away the module's dictionary for the y2k check */ Py_INCREF(d); moddict = d; ! #if defined(HAVE_TZNAME) && !defined(__GLIBC__) && !defined(__CYGWIN__) tzset(); #ifdef PYOS_OS2 ins(d, "timezone", PyInt_FromLong((long)_timezone)); *************** *** 617,623 **** #endif ins(d, "daylight", PyInt_FromLong((long)daylight)); ins(d, "tzname", Py_BuildValue("(zz)", tzname[0], tzname[1])); ! #else /* !HAVE_TZNAME || __GLIBC__ */ #ifdef HAVE_TM_ZONE { #define YEAR ((time_t)((365 * 24 + 6) * 3600)) --- 617,623 ---- #endif ins(d, "daylight", PyInt_FromLong((long)daylight)); ins(d, "tzname", Py_BuildValue("(zz)", tzname[0], tzname[1])); ! #else /* !HAVE_TZNAME || __GLIBC__ || __CYGWIN__*/ #ifdef HAVE_TM_ZONE { #define YEAR ((time_t)((365 * 24 + 6) * 3600)) *************** *** 673,679 **** ins(d, "daylight", PyInt_FromLong(_daylight)); ins(d, "tzname", Py_BuildValue("(zz)", _tzname[0], _tzname[1])); #endif /* __CYGWIN__ */ ! #endif /* !HAVE_TZNAME || __GLIBC__ */ } --- 673,679 ---- ins(d, "daylight", PyInt_FromLong(_daylight)); ins(d, "tzname", Py_BuildValue("(zz)", _tzname[0], _tzname[1])); #endif /* __CYGWIN__ */ ! #endif /* !HAVE_TZNAME || __GLIBC__ || __CYGWIN__*/ } ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459385&group_id=5470 From noreply@sourceforge.net Fri Sep 14 03:20:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Sep 2001 19:20:31 -0700 Subject: [Patches] [ python-Patches-459385 ] 2.1.1 time.timezone fix for Cygwin Message-ID: Patches item #459385, was opened at 2001-09-06 18:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459385&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Norman Vine (nhv) >Assigned to: Barry Warsaw (bwarsaw) Summary: 2.1.1 time.timezone fix for Cygwin Initial Comment: *** timemodule.bak Wed Jun 27 09:01:54 2001 --- timemodule.c Thu Sep 6 20:29:28 2001 *************** *** 599,605 **** /* Squirrel away the module's dictionary for the y2k check */ Py_INCREF(d); moddict = d; ! #if defined(HAVE_TZNAME) && !defined(__GLIBC__) tzset(); #ifdef PYOS_OS2 ins(d, "timezone", PyInt_FromLong((long) _timezone)); --- 599,605 ---- /* Squirrel away the module's dictionary for the y2k check */ Py_INCREF(d); moddict = d; ! #if defined(HAVE_TZNAME) && !defined(__GLIBC__) &&! defined(__CYGWIN__) tzset(); #ifdef PYOS_OS2 ins(d, "timezone", PyInt_FromLong((long) _timezone)); ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-09-13 19:20 Message: Logged In: YES user_id=31435 Reassigned to Barry. Cygwin patches are more likely to break the Unixish builds than the Windows build (& this one in particular appears to have nothing to do with the "win" part of "Cygwin"). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 19:11 Message: Logged In: YES user_id=6380 We'll work on it. Give us some time. ---------------------------------------------------------------------- Comment By: Norman Vine (nhv) Date: 2001-09-13 17:38 Message: Logged In: YES user_id=1020 Could we please get either Jason's or my patch into the current source tree. AFAICT both work eaqually well Note AFAIK This is the last change we need for a Cygwin compiled Python running on Win2k to pass 100% of the make test regression suite :-) Thanks Norman Vine ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-09-13 17:14 Message: Logged In: YES user_id=86216 Argh! I guess that I can mail the patch to Norman and then ask him to upload it... ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-09-13 17:11 Message: Logged In: YES user_id=86216 [I guess that there is not a way to upload a patch if you are not the submitter?] I concur that this patch should be accepted. However, I offer the following slightly more aesthetic, but otherwise functionality identical patch: Index: timemodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/timemodule.c,v retrieving revision 2.113 diff -c -r2.113 timemodule.c *** timemodule.c 2001/08/22 12:39:16 2.113 --- timemodule.c 2001/09/13 17:54:27 *************** *** 599,605 **** /* Squirrel away the module's dictionary for the y2k check */ Py_INCREF(d); moddict = d; ! #if defined(HAVE_TZNAME) && !defined(__GLIBC__) tzset(); #ifdef PYOS_OS2 ins(d, "timezone", PyInt_FromLong((long)_timezone)); --- 599,605 ---- /* Squirrel away the module's dictionary for the y2k check */ Py_INCREF(d); moddict = d; ! #if defined(HAVE_TZNAME) && !defined(__GLIBC__) && !defined(__CYGWIN__) tzset(); #ifdef PYOS_OS2 ins(d, "timezone", PyInt_FromLong((long)_timezone)); *************** *** 617,623 **** #endif ins(d, "daylight", PyInt_FromLong((long)daylight)); ins(d, "tzname", Py_BuildValue("(zz)", tzname[0], tzname[1])); ! #else /* !HAVE_TZNAME || __GLIBC__ */ #ifdef HAVE_TM_ZONE { #define YEAR ((time_t)((365 * 24 + 6) * 3600)) --- 617,623 ---- #endif ins(d, "daylight", PyInt_FromLong((long)daylight)); ins(d, "tzname", Py_BuildValue("(zz)", tzname[0], tzname[1])); ! #else /* !HAVE_TZNAME || __GLIBC__ || __CYGWIN__*/ #ifdef HAVE_TM_ZONE { #define YEAR ((time_t)((365 * 24 + 6) * 3600)) *************** *** 673,679 **** ins(d, "daylight", PyInt_FromLong(_daylight)); ins(d, "tzname", Py_BuildValue("(zz)", _tzname[0], _tzname[1])); #endif /* __CYGWIN__ */ ! #endif /* !HAVE_TZNAME || __GLIBC__ */ } --- 673,679 ---- ins(d, "daylight", PyInt_FromLong(_daylight)); ins(d, "tzname", Py_BuildValue("(zz)", _tzname[0], _tzname[1])); #endif /* __CYGWIN__ */ ! #endif /* !HAVE_TZNAME || __GLIBC__ || __CYGWIN__*/ } ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459385&group_id=5470 From noreply@sourceforge.net Fri Sep 14 03:51:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Sep 2001 19:51:50 -0700 Subject: [Patches] [ python-Patches-461413 ] Add STARTTLS feature to smtplib Message-ID: Patches item #461413, was opened at 2001-09-13 19:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461413&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Hдring (ghaering) Assigned to: Nobody/Anonymous (nobody) Summary: Add STARTTLS feature to smtplib Initial Comment: This patch adds the features from RFC 2487 (Secure SMTP over TLS) to the smtplib module: - A starttls() function - Wrapper classes that simulate enough of sockets and files for smtplib, but really wrap a SSLObject - reset the list of known SMTP extensions at each call of ehlo(). This should have been the case anyway. If Pythonlabs people want to try this out, mail.zope.com seems to support the STARTTLS extension, and btw. also the CRAM-MD5 method for my recent SMTP AUTH patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461413&group_id=5470 From noreply@sourceforge.net Fri Sep 14 04:36:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Sep 2001 20:36:02 -0700 Subject: [Patches] [ python-Patches-460805 ] Support for unsetenv() Message-ID: Patches item #460805, was opened at 2001-09-11 21:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Gonnerman (solomoriah) Assigned to: Thomas Wouters (twouters) Summary: Support for unsetenv() Initial Comment: The attached patch files implement os.unsetenv() for Python 2.1 and 2.2a3. os.py is extended to call unsetenv() when _Environ.__delitem__ is called. ---------------------------------------------------------------------- >Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-13 20:36 Message: Logged In: YES user_id=321948 You asked for it... attached now is an updated patchfile set for 2.1 and 2.2 with unsetenv() bindings for Windows; I defined unsetenv(key) in terms of putenv(key, "") if os.name is 'os2', 'nt', or 'dos' (I'm pretty sure that's right for DOS if anyone can build the rest of Python for that platform; I'm not so sure about OS/2). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 09:33 Message: Logged In: YES user_id=6380 Excellent, Thomas. I was waiting for someone to champion this. I hope you don't mind that I assigned it to you. Go ahead and review the code and decide what to do! ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-09-13 08:50 Message: Logged In: YES user_id=34209 Sorry, Guido, but I have to agree with Chris here. You *can't* do without unsetenv. Setting the environment variable to an empty string is not the same as removing it. unsetenv() appeared in BSD4.3, so it is a lot more standard than, say, LFS support, or some of the other functions we define in the posix module. It's easy to test for, it introduces no problems wrt. prototypes or such, and it provides functionality that's not available otherwise. Unsetting environment variables can't be done portably, but we can't do it *at all* right now. Making 'del' work the expected way (by using unsetenv, or faking it using os.putenv(key, "") seems very useful to me -- in fact, I was suprised os.environ didn't already do that! I definately do not see this as code bloat. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 08:36 Message: Logged In: YES user_id=6380 Lots of speculation there, but no motivation beyond "it's not Pythonic". IMO it's very Pythonic not to provide features that are rarely needed and can easily be done without. But who am I to judge. :-) If you give me a patch that implemens "del os.environ[key]" by calling os.putenv(key, ""), I'll accept it in a jiffy. ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 21:08 Message: Logged In: YES user_id=321948 Ouch. It's in AT&T/USL/SCO Unix AFAIK, it's in NetBSD and GNU libc for sure, and the other BSD's also I believe; Win32 provides a different way to do it, but there is a way. I think Solaris has it also but I can't easily check. De facto standards are important too. As for the bloat argument, my patch adds a tiny function to posixmodule and a tiny method to os._Environ (in the Unix version only at this point); my Python 2.1 interpreter gained a couple hundred bytes. Code bloat is when you add unnecessary features to a module. Python has *no other way* to remove an environment variable so that child processes don't see it, so Python's behavior is broken. It is IMHO not Pythonic to have del os.environ["HOME"] (for instance) not work correctly. From the perspective of the calling module, there is no longer a HOME variable, but called processes will still see it. It's true, you can set the variable to a null string, but this isn't the same thing and might not satisfy some secure programming requirements. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 18:31 Message: Logged In: YES user_id=6380 Code bloat. If it's not important enough to standardize in POSIX (or one of the other standards), why should we add it? GNU code is infamous for always including more features, needed or not. If you're cynical, this is part of a Microsoft-like "buy-in" strategy (code developed for GNU libc doesn't work anywhere else). ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 18:20 Message: Logged In: YES user_id=321948 By the way, I found the following note in the man pages for NetBSD: The functions setenv() and unsetenv() appeared in Version 7 AT&T UNIX. so it appears, standard or not, that most real Unix systems should have it. Regarding the minimal utility argument, I don't currently have a use for it, but it came up on the mailing list so I wrote it. It's recommended, when writing sysadmin tools which call other programs, to "clean up" the environment so that only known-safe values are in there before calling the externals. ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 18:14 Message: Logged In: YES user_id=321948 Well, the only place I know of that it is standardized is in GNU libc. That's not entirely the point, though. 1) If you do 'del os.environ["SOMEVAR"]' you remove SOMEVAR from the copy of the environment but not from the real environment. This behavior IMHO is broken. 2) It's true, many OS's don't have unsetenv(). However, my patch falls back to the *current* behavior if unsetenv() is not available. In other words, this doesn't break Python any more than it's already broken, and it's a net gain for operating systems that *do* have unsetenv(). I figure if some gain and none lose, why not do it? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 06:38 Message: Logged In: YES user_id=6380 Can you point to where unsetenv is standardized? I'm worried that it's not available on standard-conforming Unix systems, and since it's of marginal utility at best, I'm not sure what the point is to add it -- unless there's a clear standard that ensures its existence. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 From noreply@sourceforge.net Fri Sep 14 10:34:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Sep 2001 02:34:30 -0700 Subject: [Patches] [ python-Patches-460805 ] Support for unsetenv() Message-ID: Patches item #460805, was opened at 2001-09-11 21:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Gonnerman (solomoriah) Assigned to: Thomas Wouters (twouters) Summary: Support for unsetenv() Initial Comment: The attached patch files implement os.unsetenv() for Python 2.1 and 2.2a3. os.py is extended to call unsetenv() when _Environ.__delitem__ is called. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-09-14 02:34 Message: Logged In: YES user_id=34209 You don't have to submit a patch for 2.1, 2.1.1 was the final 2.1 release, and a patch like this would never make it into a patch release anyway. The unsetenv function looks good. The os.py changes don't make a whole lot of sense, however. Why not fake unsetenv on all platforms ? It's a simple matter of a 'hasattr()'. Setting the environment variable to an empty string on delete is more preferable than the current behaviour, I think. We could also fake it in C, though that means the other platform modules that aren't build from posix.c (riscos, macos, etc). ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-13 20:36 Message: Logged In: YES user_id=321948 You asked for it... attached now is an updated patchfile set for 2.1 and 2.2 with unsetenv() bindings for Windows; I defined unsetenv(key) in terms of putenv(key, "") if os.name is 'os2', 'nt', or 'dos' (I'm pretty sure that's right for DOS if anyone can build the rest of Python for that platform; I'm not so sure about OS/2). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 09:33 Message: Logged In: YES user_id=6380 Excellent, Thomas. I was waiting for someone to champion this. I hope you don't mind that I assigned it to you. Go ahead and review the code and decide what to do! ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-09-13 08:50 Message: Logged In: YES user_id=34209 Sorry, Guido, but I have to agree with Chris here. You *can't* do without unsetenv. Setting the environment variable to an empty string is not the same as removing it. unsetenv() appeared in BSD4.3, so it is a lot more standard than, say, LFS support, or some of the other functions we define in the posix module. It's easy to test for, it introduces no problems wrt. prototypes or such, and it provides functionality that's not available otherwise. Unsetting environment variables can't be done portably, but we can't do it *at all* right now. Making 'del' work the expected way (by using unsetenv, or faking it using os.putenv(key, "") seems very useful to me -- in fact, I was suprised os.environ didn't already do that! I definately do not see this as code bloat. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 08:36 Message: Logged In: YES user_id=6380 Lots of speculation there, but no motivation beyond "it's not Pythonic". IMO it's very Pythonic not to provide features that are rarely needed and can easily be done without. But who am I to judge. :-) If you give me a patch that implemens "del os.environ[key]" by calling os.putenv(key, ""), I'll accept it in a jiffy. ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 21:08 Message: Logged In: YES user_id=321948 Ouch. It's in AT&T/USL/SCO Unix AFAIK, it's in NetBSD and GNU libc for sure, and the other BSD's also I believe; Win32 provides a different way to do it, but there is a way. I think Solaris has it also but I can't easily check. De facto standards are important too. As for the bloat argument, my patch adds a tiny function to posixmodule and a tiny method to os._Environ (in the Unix version only at this point); my Python 2.1 interpreter gained a couple hundred bytes. Code bloat is when you add unnecessary features to a module. Python has *no other way* to remove an environment variable so that child processes don't see it, so Python's behavior is broken. It is IMHO not Pythonic to have del os.environ["HOME"] (for instance) not work correctly. From the perspective of the calling module, there is no longer a HOME variable, but called processes will still see it. It's true, you can set the variable to a null string, but this isn't the same thing and might not satisfy some secure programming requirements. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 18:31 Message: Logged In: YES user_id=6380 Code bloat. If it's not important enough to standardize in POSIX (or one of the other standards), why should we add it? GNU code is infamous for always including more features, needed or not. If you're cynical, this is part of a Microsoft-like "buy-in" strategy (code developed for GNU libc doesn't work anywhere else). ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 18:20 Message: Logged In: YES user_id=321948 By the way, I found the following note in the man pages for NetBSD: The functions setenv() and unsetenv() appeared in Version 7 AT&T UNIX. so it appears, standard or not, that most real Unix systems should have it. Regarding the minimal utility argument, I don't currently have a use for it, but it came up on the mailing list so I wrote it. It's recommended, when writing sysadmin tools which call other programs, to "clean up" the environment so that only known-safe values are in there before calling the externals. ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 18:14 Message: Logged In: YES user_id=321948 Well, the only place I know of that it is standardized is in GNU libc. That's not entirely the point, though. 1) If you do 'del os.environ["SOMEVAR"]' you remove SOMEVAR from the copy of the environment but not from the real environment. This behavior IMHO is broken. 2) It's true, many OS's don't have unsetenv(). However, my patch falls back to the *current* behavior if unsetenv() is not available. In other words, this doesn't break Python any more than it's already broken, and it's a net gain for operating systems that *do* have unsetenv(). I figure if some gain and none lose, why not do it? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 06:38 Message: Logged In: YES user_id=6380 Can you point to where unsetenv is standardized? I'm worried that it's not available on standard-conforming Unix systems, and since it's of marginal utility at best, I'm not sure what the point is to add it -- unless there's a clear standard that ensures its existence. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 From noreply@sourceforge.net Fri Sep 14 12:58:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Sep 2001 04:58:18 -0700 Subject: [Patches] [ python-Patches-460805 ] Support for unsetenv() Message-ID: Patches item #460805, was opened at 2001-09-11 21:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Gonnerman (solomoriah) Assigned to: Thomas Wouters (twouters) Summary: Support for unsetenv() Initial Comment: The attached patch files implement os.unsetenv() for Python 2.1 and 2.2a3. os.py is extended to call unsetenv() when _Environ.__delitem__ is called. ---------------------------------------------------------------------- >Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-14 04:58 Message: Logged In: YES user_id=321948 I didn't fake unsetenv() on all platforms because it's not really "fake". putenv(key, "") actually removes the given environment variable on Win32 ('nt') and I think on OS/2 and DOS as well. On Unix platforms it does not, and I feel it's a mistake to have unsetenv() and not have it actually work. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-09-14 02:34 Message: Logged In: YES user_id=34209 You don't have to submit a patch for 2.1, 2.1.1 was the final 2.1 release, and a patch like this would never make it into a patch release anyway. The unsetenv function looks good. The os.py changes don't make a whole lot of sense, however. Why not fake unsetenv on all platforms ? It's a simple matter of a 'hasattr()'. Setting the environment variable to an empty string on delete is more preferable than the current behaviour, I think. We could also fake it in C, though that means the other platform modules that aren't build from posix.c (riscos, macos, etc). ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-13 20:36 Message: Logged In: YES user_id=321948 You asked for it... attached now is an updated patchfile set for 2.1 and 2.2 with unsetenv() bindings for Windows; I defined unsetenv(key) in terms of putenv(key, "") if os.name is 'os2', 'nt', or 'dos' (I'm pretty sure that's right for DOS if anyone can build the rest of Python for that platform; I'm not so sure about OS/2). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 09:33 Message: Logged In: YES user_id=6380 Excellent, Thomas. I was waiting for someone to champion this. I hope you don't mind that I assigned it to you. Go ahead and review the code and decide what to do! ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-09-13 08:50 Message: Logged In: YES user_id=34209 Sorry, Guido, but I have to agree with Chris here. You *can't* do without unsetenv. Setting the environment variable to an empty string is not the same as removing it. unsetenv() appeared in BSD4.3, so it is a lot more standard than, say, LFS support, or some of the other functions we define in the posix module. It's easy to test for, it introduces no problems wrt. prototypes or such, and it provides functionality that's not available otherwise. Unsetting environment variables can't be done portably, but we can't do it *at all* right now. Making 'del' work the expected way (by using unsetenv, or faking it using os.putenv(key, "") seems very useful to me -- in fact, I was suprised os.environ didn't already do that! I definately do not see this as code bloat. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 08:36 Message: Logged In: YES user_id=6380 Lots of speculation there, but no motivation beyond "it's not Pythonic". IMO it's very Pythonic not to provide features that are rarely needed and can easily be done without. But who am I to judge. :-) If you give me a patch that implemens "del os.environ[key]" by calling os.putenv(key, ""), I'll accept it in a jiffy. ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 21:08 Message: Logged In: YES user_id=321948 Ouch. It's in AT&T/USL/SCO Unix AFAIK, it's in NetBSD and GNU libc for sure, and the other BSD's also I believe; Win32 provides a different way to do it, but there is a way. I think Solaris has it also but I can't easily check. De facto standards are important too. As for the bloat argument, my patch adds a tiny function to posixmodule and a tiny method to os._Environ (in the Unix version only at this point); my Python 2.1 interpreter gained a couple hundred bytes. Code bloat is when you add unnecessary features to a module. Python has *no other way* to remove an environment variable so that child processes don't see it, so Python's behavior is broken. It is IMHO not Pythonic to have del os.environ["HOME"] (for instance) not work correctly. From the perspective of the calling module, there is no longer a HOME variable, but called processes will still see it. It's true, you can set the variable to a null string, but this isn't the same thing and might not satisfy some secure programming requirements. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 18:31 Message: Logged In: YES user_id=6380 Code bloat. If it's not important enough to standardize in POSIX (or one of the other standards), why should we add it? GNU code is infamous for always including more features, needed or not. If you're cynical, this is part of a Microsoft-like "buy-in" strategy (code developed for GNU libc doesn't work anywhere else). ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 18:20 Message: Logged In: YES user_id=321948 By the way, I found the following note in the man pages for NetBSD: The functions setenv() and unsetenv() appeared in Version 7 AT&T UNIX. so it appears, standard or not, that most real Unix systems should have it. Regarding the minimal utility argument, I don't currently have a use for it, but it came up on the mailing list so I wrote it. It's recommended, when writing sysadmin tools which call other programs, to "clean up" the environment so that only known-safe values are in there before calling the externals. ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 18:14 Message: Logged In: YES user_id=321948 Well, the only place I know of that it is standardized is in GNU libc. That's not entirely the point, though. 1) If you do 'del os.environ["SOMEVAR"]' you remove SOMEVAR from the copy of the environment but not from the real environment. This behavior IMHO is broken. 2) It's true, many OS's don't have unsetenv(). However, my patch falls back to the *current* behavior if unsetenv() is not available. In other words, this doesn't break Python any more than it's already broken, and it's a net gain for operating systems that *do* have unsetenv(). I figure if some gain and none lose, why not do it? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 06:38 Message: Logged In: YES user_id=6380 Can you point to where unsetenv is standardized? I'm worried that it's not available on standard-conforming Unix systems, and since it's of marginal utility at best, I'm not sure what the point is to add it -- unless there's a clear standard that ensures its existence. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 From noreply@sourceforge.net Fri Sep 14 14:25:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Sep 2001 06:25:48 -0700 Subject: [Patches] [ python-Patches-460805 ] Support for unsetenv() Message-ID: Patches item #460805, was opened at 2001-09-11 21:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Gonnerman (solomoriah) Assigned to: Thomas Wouters (twouters) Summary: Support for unsetenv() Initial Comment: The attached patch files implement os.unsetenv() for Python 2.1 and 2.2a3. os.py is extended to call unsetenv() when _Environ.__delitem__ is called. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-14 06:25 Message: Logged In: YES user_id=6380 On the other hand, setting to "" is better than nothing, and I believe that (because unset isn't universally supported in shells either) defensive programming takes an empty environment variable the same as an absent one. That's certainly how I've learned to use getenv(). But maybe that qualifies me as an oldtimer. :-) ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-14 04:58 Message: Logged In: YES user_id=321948 I didn't fake unsetenv() on all platforms because it's not really "fake". putenv(key, "") actually removes the given environment variable on Win32 ('nt') and I think on OS/2 and DOS as well. On Unix platforms it does not, and I feel it's a mistake to have unsetenv() and not have it actually work. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-09-14 02:34 Message: Logged In: YES user_id=34209 You don't have to submit a patch for 2.1, 2.1.1 was the final 2.1 release, and a patch like this would never make it into a patch release anyway. The unsetenv function looks good. The os.py changes don't make a whole lot of sense, however. Why not fake unsetenv on all platforms ? It's a simple matter of a 'hasattr()'. Setting the environment variable to an empty string on delete is more preferable than the current behaviour, I think. We could also fake it in C, though that means the other platform modules that aren't build from posix.c (riscos, macos, etc). ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-13 20:36 Message: Logged In: YES user_id=321948 You asked for it... attached now is an updated patchfile set for 2.1 and 2.2 with unsetenv() bindings for Windows; I defined unsetenv(key) in terms of putenv(key, "") if os.name is 'os2', 'nt', or 'dos' (I'm pretty sure that's right for DOS if anyone can build the rest of Python for that platform; I'm not so sure about OS/2). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 09:33 Message: Logged In: YES user_id=6380 Excellent, Thomas. I was waiting for someone to champion this. I hope you don't mind that I assigned it to you. Go ahead and review the code and decide what to do! ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-09-13 08:50 Message: Logged In: YES user_id=34209 Sorry, Guido, but I have to agree with Chris here. You *can't* do without unsetenv. Setting the environment variable to an empty string is not the same as removing it. unsetenv() appeared in BSD4.3, so it is a lot more standard than, say, LFS support, or some of the other functions we define in the posix module. It's easy to test for, it introduces no problems wrt. prototypes or such, and it provides functionality that's not available otherwise. Unsetting environment variables can't be done portably, but we can't do it *at all* right now. Making 'del' work the expected way (by using unsetenv, or faking it using os.putenv(key, "") seems very useful to me -- in fact, I was suprised os.environ didn't already do that! I definately do not see this as code bloat. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 08:36 Message: Logged In: YES user_id=6380 Lots of speculation there, but no motivation beyond "it's not Pythonic". IMO it's very Pythonic not to provide features that are rarely needed and can easily be done without. But who am I to judge. :-) If you give me a patch that implemens "del os.environ[key]" by calling os.putenv(key, ""), I'll accept it in a jiffy. ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 21:08 Message: Logged In: YES user_id=321948 Ouch. It's in AT&T/USL/SCO Unix AFAIK, it's in NetBSD and GNU libc for sure, and the other BSD's also I believe; Win32 provides a different way to do it, but there is a way. I think Solaris has it also but I can't easily check. De facto standards are important too. As for the bloat argument, my patch adds a tiny function to posixmodule and a tiny method to os._Environ (in the Unix version only at this point); my Python 2.1 interpreter gained a couple hundred bytes. Code bloat is when you add unnecessary features to a module. Python has *no other way* to remove an environment variable so that child processes don't see it, so Python's behavior is broken. It is IMHO not Pythonic to have del os.environ["HOME"] (for instance) not work correctly. From the perspective of the calling module, there is no longer a HOME variable, but called processes will still see it. It's true, you can set the variable to a null string, but this isn't the same thing and might not satisfy some secure programming requirements. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 18:31 Message: Logged In: YES user_id=6380 Code bloat. If it's not important enough to standardize in POSIX (or one of the other standards), why should we add it? GNU code is infamous for always including more features, needed or not. If you're cynical, this is part of a Microsoft-like "buy-in" strategy (code developed for GNU libc doesn't work anywhere else). ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 18:20 Message: Logged In: YES user_id=321948 By the way, I found the following note in the man pages for NetBSD: The functions setenv() and unsetenv() appeared in Version 7 AT&T UNIX. so it appears, standard or not, that most real Unix systems should have it. Regarding the minimal utility argument, I don't currently have a use for it, but it came up on the mailing list so I wrote it. It's recommended, when writing sysadmin tools which call other programs, to "clean up" the environment so that only known-safe values are in there before calling the externals. ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 18:14 Message: Logged In: YES user_id=321948 Well, the only place I know of that it is standardized is in GNU libc. That's not entirely the point, though. 1) If you do 'del os.environ["SOMEVAR"]' you remove SOMEVAR from the copy of the environment but not from the real environment. This behavior IMHO is broken. 2) It's true, many OS's don't have unsetenv(). However, my patch falls back to the *current* behavior if unsetenv() is not available. In other words, this doesn't break Python any more than it's already broken, and it's a net gain for operating systems that *do* have unsetenv(). I figure if some gain and none lose, why not do it? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 06:38 Message: Logged In: YES user_id=6380 Can you point to where unsetenv is standardized? I'm worried that it's not available on standard-conforming Unix systems, and since it's of marginal utility at best, I'm not sure what the point is to add it -- unless there's a clear standard that ensures its existence. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 From noreply@sourceforge.net Fri Sep 14 14:37:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Sep 2001 06:37:39 -0700 Subject: [Patches] [ python-Patches-460805 ] Support for unsetenv() Message-ID: Patches item #460805, was opened at 2001-09-11 21:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Gonnerman (solomoriah) Assigned to: Thomas Wouters (twouters) Summary: Support for unsetenv() Initial Comment: The attached patch files implement os.unsetenv() for Python 2.1 and 2.2a3. os.py is extended to call unsetenv() when _Environ.__delitem__ is called. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-09-14 06:37 Message: Logged In: YES user_id=34209 Yes, that was my point: better clear it than leave it. It's the closest approximation we have, and it's better than nothing. I guess I'm also a certified and card-bearing old-timer :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-14 06:25 Message: Logged In: YES user_id=6380 On the other hand, setting to "" is better than nothing, and I believe that (because unset isn't universally supported in shells either) defensive programming takes an empty environment variable the same as an absent one. That's certainly how I've learned to use getenv(). But maybe that qualifies me as an oldtimer. :-) ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-14 04:58 Message: Logged In: YES user_id=321948 I didn't fake unsetenv() on all platforms because it's not really "fake". putenv(key, "") actually removes the given environment variable on Win32 ('nt') and I think on OS/2 and DOS as well. On Unix platforms it does not, and I feel it's a mistake to have unsetenv() and not have it actually work. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-09-14 02:34 Message: Logged In: YES user_id=34209 You don't have to submit a patch for 2.1, 2.1.1 was the final 2.1 release, and a patch like this would never make it into a patch release anyway. The unsetenv function looks good. The os.py changes don't make a whole lot of sense, however. Why not fake unsetenv on all platforms ? It's a simple matter of a 'hasattr()'. Setting the environment variable to an empty string on delete is more preferable than the current behaviour, I think. We could also fake it in C, though that means the other platform modules that aren't build from posix.c (riscos, macos, etc). ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-13 20:36 Message: Logged In: YES user_id=321948 You asked for it... attached now is an updated patchfile set for 2.1 and 2.2 with unsetenv() bindings for Windows; I defined unsetenv(key) in terms of putenv(key, "") if os.name is 'os2', 'nt', or 'dos' (I'm pretty sure that's right for DOS if anyone can build the rest of Python for that platform; I'm not so sure about OS/2). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 09:33 Message: Logged In: YES user_id=6380 Excellent, Thomas. I was waiting for someone to champion this. I hope you don't mind that I assigned it to you. Go ahead and review the code and decide what to do! ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-09-13 08:50 Message: Logged In: YES user_id=34209 Sorry, Guido, but I have to agree with Chris here. You *can't* do without unsetenv. Setting the environment variable to an empty string is not the same as removing it. unsetenv() appeared in BSD4.3, so it is a lot more standard than, say, LFS support, or some of the other functions we define in the posix module. It's easy to test for, it introduces no problems wrt. prototypes or such, and it provides functionality that's not available otherwise. Unsetting environment variables can't be done portably, but we can't do it *at all* right now. Making 'del' work the expected way (by using unsetenv, or faking it using os.putenv(key, "") seems very useful to me -- in fact, I was suprised os.environ didn't already do that! I definately do not see this as code bloat. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 08:36 Message: Logged In: YES user_id=6380 Lots of speculation there, but no motivation beyond "it's not Pythonic". IMO it's very Pythonic not to provide features that are rarely needed and can easily be done without. But who am I to judge. :-) If you give me a patch that implemens "del os.environ[key]" by calling os.putenv(key, ""), I'll accept it in a jiffy. ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 21:08 Message: Logged In: YES user_id=321948 Ouch. It's in AT&T/USL/SCO Unix AFAIK, it's in NetBSD and GNU libc for sure, and the other BSD's also I believe; Win32 provides a different way to do it, but there is a way. I think Solaris has it also but I can't easily check. De facto standards are important too. As for the bloat argument, my patch adds a tiny function to posixmodule and a tiny method to os._Environ (in the Unix version only at this point); my Python 2.1 interpreter gained a couple hundred bytes. Code bloat is when you add unnecessary features to a module. Python has *no other way* to remove an environment variable so that child processes don't see it, so Python's behavior is broken. It is IMHO not Pythonic to have del os.environ["HOME"] (for instance) not work correctly. From the perspective of the calling module, there is no longer a HOME variable, but called processes will still see it. It's true, you can set the variable to a null string, but this isn't the same thing and might not satisfy some secure programming requirements. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 18:31 Message: Logged In: YES user_id=6380 Code bloat. If it's not important enough to standardize in POSIX (or one of the other standards), why should we add it? GNU code is infamous for always including more features, needed or not. If you're cynical, this is part of a Microsoft-like "buy-in" strategy (code developed for GNU libc doesn't work anywhere else). ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 18:20 Message: Logged In: YES user_id=321948 By the way, I found the following note in the man pages for NetBSD: The functions setenv() and unsetenv() appeared in Version 7 AT&T UNIX. so it appears, standard or not, that most real Unix systems should have it. Regarding the minimal utility argument, I don't currently have a use for it, but it came up on the mailing list so I wrote it. It's recommended, when writing sysadmin tools which call other programs, to "clean up" the environment so that only known-safe values are in there before calling the externals. ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 18:14 Message: Logged In: YES user_id=321948 Well, the only place I know of that it is standardized is in GNU libc. That's not entirely the point, though. 1) If you do 'del os.environ["SOMEVAR"]' you remove SOMEVAR from the copy of the environment but not from the real environment. This behavior IMHO is broken. 2) It's true, many OS's don't have unsetenv(). However, my patch falls back to the *current* behavior if unsetenv() is not available. In other words, this doesn't break Python any more than it's already broken, and it's a net gain for operating systems that *do* have unsetenv(). I figure if some gain and none lose, why not do it? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 06:38 Message: Logged In: YES user_id=6380 Can you point to where unsetenv is standardized? I'm worried that it's not available on standard-conforming Unix systems, and since it's of marginal utility at best, I'm not sure what the point is to add it -- unless there's a clear standard that ensures its existence. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 From noreply@sourceforge.net Fri Sep 14 14:39:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Sep 2001 06:39:58 -0700 Subject: [Patches] [ python-Patches-461413 ] Add STARTTLS feature to smtplib Message-ID: Patches item #461413, was opened at 2001-09-13 19:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461413&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Hдring (ghaering) Assigned to: Nobody/Anonymous (nobody) Summary: Add STARTTLS feature to smtplib Initial Comment: This patch adds the features from RFC 2487 (Secure SMTP over TLS) to the smtplib module: - A starttls() function - Wrapper classes that simulate enough of sockets and files for smtplib, but really wrap a SSLObject - reset the list of known SMTP extensions at each call of ehlo(). This should have been the case anyway. If Pythonlabs people want to try this out, mail.zope.com seems to support the STARTTLS extension, and btw. also the CRAM-MD5 method for my recent SMTP AUTH patch. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-14 06:39 Message: Logged In: YES user_id=6380 Thanks. I may not understand how to use this though. When I tried this, I got a traceback: AttributeError: SSLFakeFile instance has no attribute 'close' I've included a log file that shows the script I ran, plus the session log (with debuglevel set to 1 so you can see the interaction). If I'm doing something wrong, maybe the docs could be improved? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461413&group_id=5470 From noreply@sourceforge.net Fri Sep 14 17:00:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Sep 2001 09:00:33 -0700 Subject: [Patches] [ python-Patches-461413 ] Add STARTTLS feature to smtplib Message-ID: Patches item #461413, was opened at 2001-09-13 19:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461413&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Hдring (ghaering) Assigned to: Nobody/Anonymous (nobody) Summary: Add STARTTLS feature to smtplib Initial Comment: This patch adds the features from RFC 2487 (Secure SMTP over TLS) to the smtplib module: - A starttls() function - Wrapper classes that simulate enough of sockets and files for smtplib, but really wrap a SSLObject - reset the list of known SMTP extensions at each call of ehlo(). This should have been the case anyway. If Pythonlabs people want to try this out, mail.zope.com seems to support the STARTTLS extension, and btw. also the CRAM-MD5 method for my recent SMTP AUTH patch. ---------------------------------------------------------------------- >Comment By: Gerhard Hдring (ghaering) Date: 2001-09-14 09:00 Message: Logged In: YES user_id=163326 Oops. I didn't look hard enough to include all the needed methods in the wrapper classes and forget the close() methods for socket and file. Sorry for that. The updated patch includes all methods used in the SMTP class for self.sock and self.file. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-14 06:39 Message: Logged In: YES user_id=6380 Thanks. I may not understand how to use this though. When I tried this, I got a traceback: AttributeError: SSLFakeFile instance has no attribute 'close' I've included a log file that shows the script I ran, plus the session log (with debuglevel set to 1 so you can see the interaction). If I'm doing something wrong, maybe the docs could be improved? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461413&group_id=5470 From noreply@sourceforge.net Fri Sep 14 17:09:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Sep 2001 09:09:27 -0700 Subject: [Patches] [ python-Patches-461413 ] Add STARTTLS feature to smtplib Message-ID: Patches item #461413, was opened at 2001-09-13 19:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461413&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gerhard Hдring (ghaering) Assigned to: Nobody/Anonymous (nobody) Summary: Add STARTTLS feature to smtplib Initial Comment: This patch adds the features from RFC 2487 (Secure SMTP over TLS) to the smtplib module: - A starttls() function - Wrapper classes that simulate enough of sockets and files for smtplib, but really wrap a SSLObject - reset the list of known SMTP extensions at each call of ehlo(). This should have been the case anyway. If Pythonlabs people want to try this out, mail.zope.com seems to support the STARTTLS extension, and btw. also the CRAM-MD5 method for my recent SMTP AUTH patch. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-14 09:09 Message: Logged In: YES user_id=6380 Thanks! Checked in as smtplib.py 1.42 and libsmtplib.tex 1.19. ---------------------------------------------------------------------- Comment By: Gerhard Hдring (ghaering) Date: 2001-09-14 09:00 Message: Logged In: YES user_id=163326 Oops. I didn't look hard enough to include all the needed methods in the wrapper classes and forget the close() methods for socket and file. Sorry for that. The updated patch includes all methods used in the SMTP class for self.sock and self.file. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-14 06:39 Message: Logged In: YES user_id=6380 Thanks. I may not understand how to use this though. When I tried this, I got a traceback: AttributeError: SSLFakeFile instance has no attribute 'close' I've included a log file that shows the script I ran, plus the session log (with debuglevel set to 1 so you can see the interaction). If I'm doing something wrong, maybe the docs could be improved? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461413&group_id=5470 From noreply@sourceforge.net Sat Sep 15 09:15:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Sep 2001 01:15:09 -0700 Subject: [Patches] [ python-Patches-430706 ] Persistent connections in BaseHTTPServer Message-ID: Patches item #430706, was opened at 2001-06-06 08:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=430706&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Lawrence (lordsutch) Assigned to: Martin v. Lцwis (loewis) Summary: Persistent connections in BaseHTTPServer Initial Comment: This patch provides HTTP/1.1 persistent connection support in BaseHTTPServer.py. It is not enabled by default (for backwards compatibility) because Content-Length headers must be supplied for persistent connections to work correctly. ---------------------------------------------------------------------- >Comment By: Chris Lawrence (lordsutch) Date: 2001-09-15 01:15 Message: Logged In: YES user_id=6757 I reworked the patch a bit to ensure HTTP 1.1 mode is only used if the handler class is in HTTP 1.1 mode, and modified the test() functions in the server classes to add a "protocol" option. I also modified SimpleHTTPServer to send Content-Length headers for the implemented classes. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-04 04:40 Message: Logged In: YES user_id=21627 The patch in its current form seems to be broken. To see the problem, please run SimpleHTTPServer on some directory, then access it with a HTTP/1.1 client (e.g. Netscape 4.7). The server will use the protocol version HTTP/1.0, but the client will initially send 1.1, and send a Connection: Keep-alive header. As a result, self.close_connection is set to 0, despite using HTTP/1.0. In turn, the HTTP server won't send a content length, and won't close the connection either. Netscape waits forever from some completion which never occurs, since the server waits for the next request on the same connection. It might be useful to enhance the SimpleHTTPServer test() function to optionally operate in HTTP/1.1 mode (including sending a proper ContentLength). Doing the same for the CGI HTTP server is probably less useful. ---------------------------------------------------------------------- Comment By: Chris Lawrence (lordsutch) Date: 2001-08-29 20:21 Message: Logged In: YES user_id=6757 I have updated the patch against current CVS and have added documentation. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-08 13:43 Message: Logged In: YES user_id=21627 I haven't studied the patch in detail, yet, but I have a few comments on the style: - there is no need to quote all authors of the RFC. Also, the reference to long-ago expired HTTP draft should go; just replace it with a single reference to the RFC number (giving an URL for the RFC might be convenient) - Where is the documentation? A patch to Doc/lib/libbasehttp.tex would be appreciated. If you don't speak TeX, don't worry: Just write plain text, we'll do the mark-up. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=430706&group_id=5470 From noreply@sourceforge.net Sat Sep 15 09:58:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Sep 2001 01:58:43 -0700 Subject: [Patches] [ python-Patches-461781 ] os.path.realpath - Resolve symlinks Message-ID: Patches item #461781, was opened at 2001-09-15 01:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461781&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Lawrence (lordsutch) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.realpath - Resolve symlinks Initial Comment: Once upon a time, I put together a little function that tries to find the canonical filename for a given pathname on POSIX. I've finally gotten around to turning it into a proper patch with documentation. On non-POSIX, I made it an alias for 'abspath', as that's the behavior on POSIX when no symlinks are encountered in the path. Example: >>> os.path.realpath('/usr/bin/X11/X') '/usr/X11R6/bin/X' ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461781&group_id=5470 From noreply@sourceforge.net Sat Sep 15 16:42:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Sep 2001 08:42:49 -0700 Subject: [Patches] [ python-Patches-461781 ] os.path.realpath - Resolve symlinks Message-ID: Patches item #461781, was opened at 2001-09-15 01:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461781&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Lawrence (lordsutch) >Assigned to: Guido van Rossum (gvanrossum) Summary: os.path.realpath - Resolve symlinks Initial Comment: Once upon a time, I put together a little function that tries to find the canonical filename for a given pathname on POSIX. I've finally gotten around to turning it into a proper patch with documentation. On non-POSIX, I made it an alias for 'abspath', as that's the behavior on POSIX when no symlinks are encountered in the path. Example: >>> os.path.realpath('/usr/bin/X11/X') '/usr/X11R6/bin/X' ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-15 08:42 Message: Logged In: YES user_id=6380 Cool. I'll test and apply this later. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461781&group_id=5470 From noreply@sourceforge.net Sun Sep 16 06:27:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Sep 2001 22:27:03 -0700 Subject: [Patches] [ python-Patches-461966 ] Adds an XML-RPC server module Message-ID: Patches item #461966, was opened at 2001-09-15 22:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461966&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Nobody/Anonymous (nobody) Summary: Adds an XML-RPC server module Initial Comment: This module adds XML-RPC server functionality in a manner similar to the way SimpleHTTPServer adds HTTP server functionality. The pimary motivation for creating this module is that creating XML-RPC servers in Python is more difficult that it should be and is considerably more difficult in Python than it is in other languages (http://xmlrpc- c.sourceforge.net/xmlrpc-howto/xmlrpc-howto.html). Here are the design motivations: 1. subclassing an XML-RPC or HTTP class should not be needed for simple servers 2. it should be designed in such a way that the code could be refactored to use a (hypothetical) BaseXMLRPCServer module without breaking backwards compatibility 3. it should behave in a similar manner to other Python web modules i.e. SimpleHTTPServer and soaplib ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461966&group_id=5470 From noreply@sourceforge.net Sun Sep 16 21:44:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Sep 2001 13:44:10 -0700 Subject: [Patches] [ python-Patches-461966 ] Adds an XML-RPC server module Message-ID: Patches item #461966, was opened at 2001-09-15 22:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461966&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Nobody/Anonymous (nobody) Summary: Adds an XML-RPC server module Initial Comment: This module adds XML-RPC server functionality in a manner similar to the way SimpleHTTPServer adds HTTP server functionality. The pimary motivation for creating this module is that creating XML-RPC servers in Python is more difficult that it should be and is considerably more difficult in Python than it is in other languages (http://xmlrpc- c.sourceforge.net/xmlrpc-howto/xmlrpc-howto.html). Here are the design motivations: 1. subclassing an XML-RPC or HTTP class should not be needed for simple servers 2. it should be designed in such a way that the code could be refactored to use a (hypothetical) BaseXMLRPCServer module without breaking backwards compatibility 3. it should behave in a similar manner to other Python web modules i.e. SimpleHTTPServer and soaplib ---------------------------------------------------------------------- >Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:44 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461966&group_id=5470 From noreply@sourceforge.net Sun Sep 16 21:46:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Sep 2001 13:46:01 -0700 Subject: [Patches] [ python-Patches-461966 ] Adds an XML-RPC server module Message-ID: Patches item #461966, was opened at 2001-09-15 22:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461966&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Nobody/Anonymous (nobody) Summary: Adds an XML-RPC server module Initial Comment: This module adds XML-RPC server functionality in a manner similar to the way SimpleHTTPServer adds HTTP server functionality. The pimary motivation for creating this module is that creating XML-RPC servers in Python is more difficult that it should be and is considerably more difficult in Python than it is in other languages (http://xmlrpc- c.sourceforge.net/xmlrpc-howto/xmlrpc-howto.html). Here are the design motivations: 1. subclassing an XML-RPC or HTTP class should not be needed for simple servers 2. it should be designed in such a way that the code could be refactored to use a (hypothetical) BaseXMLRPCServer module without breaking backwards compatibility 3. it should behave in a similar manner to other Python web modules i.e. SimpleHTTPServer and soaplib ---------------------------------------------------------------------- >Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:46 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:44 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461966&group_id=5470 From noreply@sourceforge.net Sun Sep 16 21:47:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Sep 2001 13:47:33 -0700 Subject: [Patches] [ python-Patches-461966 ] Adds an XML-RPC server module Message-ID: Patches item #461966, was opened at 2001-09-15 22:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461966&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Nobody/Anonymous (nobody) Summary: Adds an XML-RPC server module Initial Comment: This module adds XML-RPC server functionality in a manner similar to the way SimpleHTTPServer adds HTTP server functionality. The pimary motivation for creating this module is that creating XML-RPC servers in Python is more difficult that it should be and is considerably more difficult in Python than it is in other languages (http://xmlrpc- c.sourceforge.net/xmlrpc-howto/xmlrpc-howto.html). Here are the design motivations: 1. subclassing an XML-RPC or HTTP class should not be needed for simple servers 2. it should be designed in such a way that the code could be refactored to use a (hypothetical) BaseXMLRPCServer module without breaking backwards compatibility 3. it should behave in a similar manner to other Python web modules i.e. SimpleHTTPServer and soaplib ---------------------------------------------------------------------- >Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:47 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:46 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:44 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461966&group_id=5470 From noreply@sourceforge.net Sun Sep 16 21:51:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Sep 2001 13:51:41 -0700 Subject: [Patches] [ python-Patches-461966 ] Adds an XML-RPC server module Message-ID: Patches item #461966, was opened at 2001-09-15 22:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461966&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Nobody/Anonymous (nobody) Summary: Adds an XML-RPC server module Initial Comment: This module adds XML-RPC server functionality in a manner similar to the way SimpleHTTPServer adds HTTP server functionality. The pimary motivation for creating this module is that creating XML-RPC servers in Python is more difficult that it should be and is considerably more difficult in Python than it is in other languages (http://xmlrpc- c.sourceforge.net/xmlrpc-howto/xmlrpc-howto.html). Here are the design motivations: 1. subclassing an XML-RPC or HTTP class should not be needed for simple servers 2. it should be designed in such a way that the code could be refactored to use a (hypothetical) BaseXMLRPCServer module without breaking backwards compatibility 3. it should behave in a similar manner to other Python web modules i.e. SimpleHTTPServer and soaplib ---------------------------------------------------------------------- >Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:51 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:47 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:46 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:44 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461966&group_id=5470 From noreply@sourceforge.net Mon Sep 17 00:50:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Sep 2001 16:50:03 -0700 Subject: [Patches] [ python-Patches-462122 ] add readline startup and pre_event hooks Message-ID: Patches item #462122, was opened at 2001-09-16 16:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462122&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: add readline startup and pre_event hooks Initial Comment: Adds support for the readline rl_startup_hook and rl_pre_event_hook callbacks. For example, the startup hook can be used to insert text to begin editing rather than always starting with a blank entry. I just added the pre_event hook too since it was there. Supporting rl_event_hook could be done too, but its already set to PyOS_InputHook and I'm not sure what significance this has or if it could just be called in addition to that. In order to avoid too much code dupe I moved some stuff into a generic hook setter func. However I'm not 100% sure of the thread state stuff, if it really needs to store a seperate one per each hook or if it should only store one. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462122&group_id=5470 From noreply@sourceforge.net Mon Sep 17 03:47:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Sep 2001 19:47:25 -0700 Subject: [Patches] [ python-Patches-461966 ] Adds an XML-RPC server module Message-ID: Patches item #461966, was opened at 2001-09-15 22:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461966&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Nobody/Anonymous (nobody) Summary: Adds an XML-RPC server module Initial Comment: This module adds XML-RPC server functionality in a manner similar to the way SimpleHTTPServer adds HTTP server functionality. The pimary motivation for creating this module is that creating XML-RPC servers in Python is more difficult that it should be and is considerably more difficult in Python than it is in other languages (http://xmlrpc- c.sourceforge.net/xmlrpc-howto/xmlrpc-howto.html). Here are the design motivations: 1. subclassing an XML-RPC or HTTP class should not be needed for simple servers 2. it should be designed in such a way that the code could be refactored to use a (hypothetical) BaseXMLRPCServer module without breaking backwards compatibility 3. it should behave in a similar manner to other Python web modules i.e. SimpleHTTPServer and soaplib ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-16 19:47 Message: Logged In: YES user_id=6380 Assigned to Fredrik Lundh. Fredrik, if you don't have time for this, please assign back to me. Don't just let it sit (we're trying to give patches quick turnaround to motivate the users!). Brian, I've deleted the old patch. A good idea is to always give a second upload a different name and description that explain it's a newer version! ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:51 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:47 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:46 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:44 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461966&group_id=5470 From noreply@sourceforge.net Mon Sep 17 03:55:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Sep 2001 19:55:37 -0700 Subject: [Patches] [ python-Patches-461966 ] Adds an XML-RPC server module Message-ID: Patches item #461966, was opened at 2001-09-15 22:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461966&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) >Assigned to: Fredrik Lundh (effbot) Summary: Adds an XML-RPC server module Initial Comment: This module adds XML-RPC server functionality in a manner similar to the way SimpleHTTPServer adds HTTP server functionality. The pimary motivation for creating this module is that creating XML-RPC servers in Python is more difficult that it should be and is considerably more difficult in Python than it is in other languages (http://xmlrpc- c.sourceforge.net/xmlrpc-howto/xmlrpc-howto.html). Here are the design motivations: 1. subclassing an XML-RPC or HTTP class should not be needed for simple servers 2. it should be designed in such a way that the code could be refactored to use a (hypothetical) BaseXMLRPCServer module without breaking backwards compatibility 3. it should behave in a similar manner to other Python web modules i.e. SimpleHTTPServer and soaplib ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-16 19:47 Message: Logged In: YES user_id=6380 Assigned to Fredrik Lundh. Fredrik, if you don't have time for this, please assign back to me. Don't just let it sit (we're trying to give patches quick turnaround to motivate the users!). Brian, I've deleted the old patch. A good idea is to always give a second upload a different name and description that explain it's a newer version! ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:51 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:47 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:46 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:44 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461966&group_id=5470 From noreply@sourceforge.net Mon Sep 17 07:05:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Sep 2001 23:05:39 -0700 Subject: [Patches] [ python-Patches-461966 ] Adds an XML-RPC server module Message-ID: Patches item #461966, was opened at 2001-09-15 22:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461966&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Fredrik Lundh (effbot) Summary: Adds an XML-RPC server module Initial Comment: This module adds XML-RPC server functionality in a manner similar to the way SimpleHTTPServer adds HTTP server functionality. The pimary motivation for creating this module is that creating XML-RPC servers in Python is more difficult that it should be and is considerably more difficult in Python than it is in other languages (http://xmlrpc- c.sourceforge.net/xmlrpc-howto/xmlrpc-howto.html). Here are the design motivations: 1. subclassing an XML-RPC or HTTP class should not be needed for simple servers 2. it should be designed in such a way that the code could be refactored to use a (hypothetical) BaseXMLRPCServer module without breaking backwards compatibility 3. it should behave in a similar manner to other Python web modules i.e. SimpleHTTPServer and soaplib ---------------------------------------------------------------------- >Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 23:05 Message: Logged In: YES user_id=108973 Yes, please motivate me :-) I didn't know that I couldn't delete my patches or I would have! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-16 19:47 Message: Logged In: YES user_id=6380 Assigned to Fredrik Lundh. Fredrik, if you don't have time for this, please assign back to me. Don't just let it sit (we're trying to give patches quick turnaround to motivate the users!). Brian, I've deleted the old patch. A good idea is to always give a second upload a different name and description that explain it's a newer version! ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:51 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:47 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:46 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:44 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461966&group_id=5470 From noreply@sourceforge.net Mon Sep 17 08:39:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Sep 2001 00:39:40 -0700 Subject: [Patches] [ python-Patches-462190 ] New C module for quopri assist Message-ID: Patches item #462190, was opened at 2001-09-17 00:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462190&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brandon Long (blong42) Assigned to: Nobody/Anonymous (nobody) Summary: New C module for quopri assist Initial Comment: This patch adds a new module, quoted, and code in quopri to use this module if it exists. This module implements quoted printable encoding and decoding based on strings in C. This was required by a recent project of mine because 1MB quoted printable mail attachments (sometimes chosen to send PDF and PS data) would take 40+ minutes to encode and decode using the standard quopri python module. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462190&group_id=5470 From noreply@sourceforge.net Mon Sep 17 09:17:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Sep 2001 01:17:37 -0700 Subject: [Patches] [ python-Patches-462195 ] URL change in distutils doc/inst.tex Message-ID: Patches item #462195, was opened at 2001-09-17 01:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462195&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rene Liebscher (rliebscher) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: URL change in distutils doc/inst.tex Initial Comment: This URL was already changed some days ago, but now SourceForge announced to stop ftp services. So this URL changes a second time. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462195&group_id=5470 From noreply@sourceforge.net Mon Sep 17 15:22:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Sep 2001 07:22:40 -0700 Subject: [Patches] [ python-Patches-462190 ] New C module for quopri assist Message-ID: Patches item #462190, was opened at 2001-09-17 00:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462190&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brandon Long (blong42) Assigned to: Nobody/Anonymous (nobody) Summary: New C module for quopri assist Initial Comment: This patch adds a new module, quoted, and code in quopri to use this module if it exists. This module implements quoted printable encoding and decoding based on strings in C. This was required by a recent project of mine because 1MB quoted printable mail attachments (sometimes chosen to send PDF and PS data) would take 40+ minutes to encode and decode using the standard quopri python module. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-17 07:22 Message: Logged In: YES user_id=6380 It would make more sense to add this as another pair of encodings to the binascii module, which provides similar support for binhex, base64, and uuencode. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462190&group_id=5470 From nety-feedback-1@lb.bcentral.com Mon Sep 17 15:45:05 2001 From: nety-feedback-1@lb.bcentral.com (Oleg_atl) Date: 17 Sep 2001 14:45:05 -0000 Subject: [Patches] Коммерческое предложение. Message-ID: <1000737905.13362.qmail@ech> Вашему вниманию предлагаются цены на комплектующие. Московская фирма Атлантик Компьютерс осуществляет торговлю оптом и в розницу, так же осуществляется сборка компьютеров на заказ по конфигурации клиента, гарантия на системные блоки два года. Гибкие цены, индивидуальный подход к клиенту. Возможна доставка по Москве, в транспортные компании до вокзалов и аэропортов. С уважением, менеджер по продажам Ларин Олег. _______________________________________________________________________ Powered by List Builder To unsubscribe follow the link: http://lb.bcentral.com/ex/manage/subscriberprefs?customerid=15216&subid=75229AA26D70DB8F&msgnum=1 From noreply@sourceforge.net Mon Sep 17 16:15:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Sep 2001 08:15:23 -0700 Subject: [Patches] [ python-Patches-462255 ] Cygwin resource module patch Message-ID: Patches item #462255, was opened at 2001-09-17 08:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462255&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: A.M. Kuchling (akuchling) Summary: Cygwin resource module patch Initial Comment: This patch re-enables building the resouce module on the Cygwin platform. See the following for details (if interested): http://sources.redhat.com/ml/cygwin/2001-09/msg00855.html I also tested this patch on Red Hat 7.1 without any ill effects. Use the following procedure, to apply the patch: $ # save the patch to /tmp/pyresource.patch $ # change directory to the top of the Python source tree $ patch -p0 Patches item #461781, was opened at 2001-09-15 01:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461781&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Chris Lawrence (lordsutch) Assigned to: Guido van Rossum (gvanrossum) Summary: os.path.realpath - Resolve symlinks Initial Comment: Once upon a time, I put together a little function that tries to find the canonical filename for a given pathname on POSIX. I've finally gotten around to turning it into a proper patch with documentation. On non-POSIX, I made it an alias for 'abspath', as that's the behavior on POSIX when no symlinks are encountered in the path. Example: >>> os.path.realpath('/usr/bin/X11/X') '/usr/X11R6/bin/X' ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-17 08:16 Message: Logged In: YES user_id=6380 Thanks! Checked into CVS now. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-15 08:42 Message: Logged In: YES user_id=6380 Cool. I'll test and apply this later. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461781&group_id=5470 From noreply@sourceforge.net Mon Sep 17 16:31:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Sep 2001 08:31:28 -0700 Subject: [Patches] [ python-Patches-462258 ] tkinter without X11 patch Message-ID: Patches item #462258, was opened at 2001-09-17 08:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462258&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: A.M. Kuchling (akuchling) Summary: tkinter without X11 patch Initial Comment: This patch is a follow up to patch #443669. It prevents the attempt to build the tkinter module unless the X header files can be found. I developed this patch with Cygwin in mind but it should work for other platforms too. I tested this patch on Red Hat 7.1 without any ill effects. However, if one is concerned about breaking other Unix platforms, then the following guard: if platform == 'cygwin' can be added. I'm willing to redo the patch, if this is deemed necessary. To apply the patch, use the following procedure: $ # save the patch to /tmp/tkinter.patch $ # change directory to the top of the Python source tree $ patch Patches item #462258, was opened at 2001-09-17 08:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462258&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: A.M. Kuchling (akuchling) Summary: tkinter without X11 patch Initial Comment: This patch is a follow up to patch #443669. It prevents the attempt to build the tkinter module unless the X header files can be found. I developed this patch with Cygwin in mind but it should work for other platforms too. I tested this patch on Red Hat 7.1 without any ill effects. However, if one is concerned about breaking other Unix platforms, then the following guard: if platform == 'cygwin' can be added. I'm willing to redo the patch, if this is deemed necessary. To apply the patch, use the following procedure: $ # save the patch to /tmp/tkinter.patch $ # change directory to the top of the Python source tree $ patch Comment By: A.M. Kuchling (akuchling) Date: 2001-09-17 09:08 Message: Logged In: YES user_id=11375 I think I'd prefer this patch with the platform=='cygwin' guard. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462258&group_id=5470 From noreply@sourceforge.net Mon Sep 17 17:19:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Sep 2001 09:19:42 -0700 Subject: [Patches] [ python-Patches-462255 ] Cygwin resource module patch Message-ID: Patches item #462255, was opened at 2001-09-17 08:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462255&group_id=5470 Category: Distutils and setup.py Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: A.M. Kuchling (akuchling) Summary: Cygwin resource module patch Initial Comment: This patch re-enables building the resouce module on the Cygwin platform. See the following for details (if interested): http://sources.redhat.com/ml/cygwin/2001-09/msg00855.html I also tested this patch on Red Hat 7.1 without any ill effects. Use the following procedure, to apply the patch: $ # save the patch to /tmp/pyresource.patch $ # change directory to the top of the Python source tree $ patch -p0 Comment By: A.M. Kuchling (akuchling) Date: 2001-09-17 09:19 Message: Logged In: YES user_id=11375 Accepted and checked in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462255&group_id=5470 From noreply@sourceforge.net Mon Sep 17 17:30:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Sep 2001 09:30:20 -0700 Subject: [Patches] [ python-Patches-461966 ] Adds an XML-RPC server module Message-ID: Patches item #461966, was opened at 2001-09-15 22:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461966&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Fredrik Lundh (effbot) Summary: Adds an XML-RPC server module Initial Comment: This module adds XML-RPC server functionality in a manner similar to the way SimpleHTTPServer adds HTTP server functionality. The pimary motivation for creating this module is that creating XML-RPC servers in Python is more difficult that it should be and is considerably more difficult in Python than it is in other languages (http://xmlrpc- c.sourceforge.net/xmlrpc-howto/xmlrpc-howto.html). Here are the design motivations: 1. subclassing an XML-RPC or HTTP class should not be needed for simple servers 2. it should be designed in such a way that the code could be refactored to use a (hypothetical) BaseXMLRPCServer module without breaking backwards compatibility 3. it should behave in a similar manner to other Python web modules i.e. SimpleHTTPServer and soaplib ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2001-09-17 09:30 Message: Logged In: YES user_id=38376 (Umm. What happened to the comment I posted earlier?) >From a quick glance, this is a nicely done extension of one of the samples from the original xmlrpc samples. +1 from me. (guido: should I check it into the library at once, or should I keep it in the sandbox for a week or two?) ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 23:05 Message: Logged In: YES user_id=108973 Yes, please motivate me :-) I didn't know that I couldn't delete my patches or I would have! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-16 19:47 Message: Logged In: YES user_id=6380 Assigned to Fredrik Lundh. Fredrik, if you don't have time for this, please assign back to me. Don't just let it sit (we're trying to give patches quick turnaround to motivate the users!). Brian, I've deleted the old patch. A good idea is to always give a second upload a different name and description that explain it's a newer version! ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:51 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:47 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:46 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:44 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461966&group_id=5470 From noreply@sourceforge.net Mon Sep 17 17:48:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Sep 2001 09:48:34 -0700 Subject: [Patches] [ python-Patches-461966 ] Adds an XML-RPC server module Message-ID: Patches item #461966, was opened at 2001-09-15 22:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461966&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Fredrik Lundh (effbot) Summary: Adds an XML-RPC server module Initial Comment: This module adds XML-RPC server functionality in a manner similar to the way SimpleHTTPServer adds HTTP server functionality. The pimary motivation for creating this module is that creating XML-RPC servers in Python is more difficult that it should be and is considerably more difficult in Python than it is in other languages (http://xmlrpc- c.sourceforge.net/xmlrpc-howto/xmlrpc-howto.html). Here are the design motivations: 1. subclassing an XML-RPC or HTTP class should not be needed for simple servers 2. it should be designed in such a way that the code could be refactored to use a (hypothetical) BaseXMLRPCServer module without breaking backwards compatibility 3. it should behave in a similar manner to other Python web modules i.e. SimpleHTTPServer and soaplib ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-17 09:48 Message: Logged In: YES user_id=6380 If you check it in now, it can make the 2.2a4 release. Go for it! ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-09-17 09:30 Message: Logged In: YES user_id=38376 (Umm. What happened to the comment I posted earlier?) >From a quick glance, this is a nicely done extension of one of the samples from the original xmlrpc samples. +1 from me. (guido: should I check it into the library at once, or should I keep it in the sandbox for a week or two?) ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 23:05 Message: Logged In: YES user_id=108973 Yes, please motivate me :-) I didn't know that I couldn't delete my patches or I would have! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-16 19:47 Message: Logged In: YES user_id=6380 Assigned to Fredrik Lundh. Fredrik, if you don't have time for this, please assign back to me. Don't just let it sit (we're trying to give patches quick turnaround to motivate the users!). Brian, I've deleted the old patch. A good idea is to always give a second upload a different name and description that explain it's a newer version! ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:51 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:47 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:46 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:44 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461966&group_id=5470 From noreply@sourceforge.net Mon Sep 17 18:36:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Sep 2001 10:36:30 -0700 Subject: [Patches] [ python-Patches-460751 ] --with-shared: python with shared lib Message-ID: Patches item #460751, was opened at 2001-09-11 14:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Nobody/Anonymous (nobody) Summary: --with-shared: python with shared lib Initial Comment: As a follow up to patch 400938 (https://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=400938), here is an implementation of the --with-shared configure option for building python on Posix systems as a shared library. Building python as shared library is activated with the --with-shared option on ./configure The following points are drawn to particular attention: - A configbuild.py module is generated and placed in the machine-dependent directory. It records most Python/Makefile variables (CC, CFLAG, LDSHARED...), and make them available in Python. - The build has been tested on: Linux2: OK SunOS5: OK IRIX64: Build OK, crash on test (bus error) - Inference with distutils: I found it very difficult understanding the distutil architecture and finding the right points of change; I minimized my interaction there. Furthermore, the availability of the 'configbuild' module overlaps some of the distutils; but 'configbuild' is very easy to use ... - Unresolved symbols: I turned on the symbol checking flags whenever possible, on behalf the its better generating the error on build than at runtime. - configure.in: I only edited the configure Bourne script, and did not bother with configure.in (actually, I deleted it) and its autoconfig/m4 macro comparses. Frederic Giacometti ---------------------------------------------------------------------- >Comment By: Frederic Giacometti (giacometti) Date: 2001-09-17 10:36 Message: Logged In: YES user_id=93657 I'm attaching an updated patch where, following Martin suggestions: - I removed the configbuild thing, and replaced it with distutils.sysconfig.get_conf_var calls - I manually cleaned up the patch from unrelated changes (.cvsignore, @ Makefile modifiers...) Remains the configure.in thing. If one looks at autoconf: - it takes care of plateform idiosyncracies, for platform which do not follow posix API specs; this was of use in previous generation Unix OS's, and these legacy systems do not evolve anymore. On present Unixes, and with regard to the features used for building the core python engine, nothing moves, and autoconf updates bring nothing. Doesn't the Python 1.5.2's configure still works as it did the first day it was generated ... ? - autoconf is of use for configuring particular packages and libraries (e.g.: for configuring and building python extensions, Tkinter/Tk/TCL...); unfortunately this never worked with python, and the task is now assumed by the distutils. - In the Python core build, autoconf is of no help in anything sensible: thread, shared library, debug build, compiler options... All these were programmed manually in Bourne; and for doing the later, autoconf is a complexifying factor on something already fairly complex - i.e. a handicap -. - not to say, autoconf is of no use on non-posix plateforms (windows...) - last, and the least: autoconf now requires that perl be installed... Frederic Giacometti ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 18:36 Message: Logged In: YES user_id=6380 > What is the point of keeping using the autoconf thing when > it is easier to maintain configure directly, than going > through configure.in ? But it's not. One line of configure.in often expands to dozens (occasionally hundreds) of lines of configure. autoconf has arcane knowledge that gets updated with new autoconf releases. You are entitled to your opinion, but in this case, it's wrong. Go fork your own version of Python if you don't want to learn autoconf. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-12 16:06 Message: Logged In: YES user_id=93657 I am not willing to make anything difficult for anybody, but: What is the point of keeping using the autoconf thing when it is easier to maintain configure directly, than going through configure.in ? After configure has been generated once, it makes more sense to me to work directly on configure, and forget about configure.in. configure (pure Bourne shell) is a easier to understand, to troubleshoot, and to maintain that configure.in (a mixture of Bourne shell and autoconf m4 macros). I'll have a second look at the autoconf thing latter on - at present I hardly understand anything to configure.in, and got 'configure --with-shared' working with satisfaction across multiple platforms without undue difficulties. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 11:37 Message: Logged In: YES user_id=6380 > Autoconf is not installed on the commercial Unix > platforms, it is useless for me to learn it, and I was > better off directly editing ./configure. However, if others > are familiar with the tool, it should be straightforward for > them to retrocede the changes from configure to configure.in Sure. You'll just have to wait until we have time for that. You can make it easy for us to integrate your changes, or you can make it difficult. Your choice. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-12 11:12 Message: Logged In: YES user_id=93657 - I will remove the configbuild; since Martin pointed to me the existence of distutils.sysconfig.get_config_vars(). I did not know about this function... Thanks! On the fly, you'll also note the following potential problem with using get_config_vars() instead of configbuild: configbuild will report the actual values used for the build, whereas get_config_vars() will report erroneous values whenever the Makefile internal variables were overriden at build time (by either the environment, or by commandline assignment of the type 'make CC=gxx ...'); not to mention that configbuild does not need to find and parse the original Makefile (with all the potential problems associated). - The .purify line should be in the CVSROOT/cvsignore CVS admin file, not in .cvsignore in the root directory of the source distribution... - Autoconf is not installed on the commercial Unix platforms, it is useless for me to learn it, and I was better off directly editing ./configure. However, if others are familiar with the tool, it should be straightforward for them to retrocede the changes from configure to configure.in - I had to introduce THREADOBJ because you will note that, in the present implementation, Modules/thread.o appears multiple times in LIBOBJS, which causes warning at link time. Now, Modules/thread.o appears only once ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-12 01:06 Message: Logged In: YES user_id=21627 As for libtool: I strongly advise not to use it. It is broken in too many ways to enumerate. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-12 00:18 Message: Logged In: YES user_id=21627 I recommend to rework this patch to get rid of configbuild. I cannot see what you achieve with the configbuild module that you couldn't do with distutils.sysconfig.get_config_vars (which is capable of parsing the Makefile directly). I also recommend to go through the patch chunk by chunk, asking yourself whether this chunk *really* is needed to achieve the desired functionality. E.g. I cannot see the relationship of the .cvsignore chunk; I also believe that removal of .purify is incorrect. Likewise, while I sympathize with the unresolved symbols change, I believe it is unrelated to the main objective of this patch (building Python shared). What is the rationale for not changing configure.in? As-is, this patch is useless: configure will be overwritten everytime you run autoconf. Please get a copy of autoconf on one of your systems, change configure.in, run autoconf, and then provide us with a patch that only changes configure.in: everybody reviewing this patch should be capable of running autoconf. configure is a generated file and should not be edited manually. What is the rationale for the introduction of the THREADOBJ variable? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-11 19:03 Message: Logged In: YES user_id=6380 Haven't seen the patch yet, but I like the idea -- the command line option suggests that it shouldn't hurt platforms where it can't be done or has to be done differently. Alternative: we could also consider using libtool. I didn't like that much in the past, but maybe it would work. Dunno. Anybody know about it? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 From noreply@sourceforge.net Mon Sep 17 18:36:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Sep 2001 10:36:54 -0700 Subject: [Patches] [ python-Patches-461966 ] Adds an XML-RPC server module Message-ID: Patches item #461966, was opened at 2001-09-15 22:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461966&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Fredrik Lundh (effbot) Summary: Adds an XML-RPC server module Initial Comment: This module adds XML-RPC server functionality in a manner similar to the way SimpleHTTPServer adds HTTP server functionality. The pimary motivation for creating this module is that creating XML-RPC servers in Python is more difficult that it should be and is considerably more difficult in Python than it is in other languages (http://xmlrpc- c.sourceforge.net/xmlrpc-howto/xmlrpc-howto.html). Here are the design motivations: 1. subclassing an XML-RPC or HTTP class should not be needed for simple servers 2. it should be designed in such a way that the code could be refactored to use a (hypothetical) BaseXMLRPCServer module without breaking backwards compatibility 3. it should behave in a similar manner to other Python web modules i.e. SimpleHTTPServer and soaplib ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2001-09-17 10:36 Message: Logged In: YES user_id=38376 Done. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-17 09:48 Message: Logged In: YES user_id=6380 If you check it in now, it can make the 2.2a4 release. Go for it! ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-09-17 09:30 Message: Logged In: YES user_id=38376 (Umm. What happened to the comment I posted earlier?) >From a quick glance, this is a nicely done extension of one of the samples from the original xmlrpc samples. +1 from me. (guido: should I check it into the library at once, or should I keep it in the sandbox for a week or two?) ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 23:05 Message: Logged In: YES user_id=108973 Yes, please motivate me :-) I didn't know that I couldn't delete my patches or I would have! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-16 19:47 Message: Logged In: YES user_id=6380 Assigned to Fredrik Lundh. Fredrik, if you don't have time for this, please assign back to me. Don't just let it sit (we're trying to give patches quick turnaround to motivate the users!). Brian, I've deleted the old patch. A good idea is to always give a second upload a different name and description that explain it's a newer version! ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:51 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:47 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:46 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-16 13:44 Message: Logged In: YES user_id=108973 Ooops, there was a problem with the arguments of an Exception (that is eaten internally anyway). Attached another version. Arghhhh, I can't seem to delete the original. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461966&group_id=5470 From noreply@sourceforge.net Mon Sep 17 18:57:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Sep 2001 10:57:02 -0700 Subject: [Patches] [ python-Patches-462296 ] Add attributes to os.stat results Message-ID: Patches item #462296, was opened at 2001-09-17 10:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Add attributes to os.stat results Initial Comment: See bug #111481, and PEP 0042. Both suggest that the return values for os.{stat,lstat,statvfs,fstatvfs} ought to be struct-like objects rather than simple tuples. With this patch, the os module will modify the aformentioned functions so that their results still obey the previous tuple protocol, but now have read-only attributes as well. In other words, "os.stat('filename')[0]" is now synonymous with "os.stat('filename').st_mode. The patch also modifies test_os.py to test the new behavior. In order to prevent old code from breaking, these new return types extend tuple. They also use the new attribute descriptor interface. (Thanks for PEP-025[23], Guido!) Backward compatibility: Code will only break if it assumes that type(os.stat(...)) == TupleType, or if it assumes that os.stat(...) has no attributes beyond those defined in tuple. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 From nety-feedback-2@lb.bcentral.com Mon Sep 17 19:54:53 2001 From: nety-feedback-2@lb.bcentral.com (:-)) Date: 17 Sep 2001 18:54:53 -0000 Subject: [Patches] :-) Message-ID: <1000752893.6992.qmail@ech> --_alistboundary123 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable _______________________________________________________________________ Powered by List Builder To unsubscribe follow the link: http://lb.bcentral.com/ex/manage/subscriberprefs?customerid=3D15216&subid= =3D4BFC4A82BC9D9315&msgnum=3D2 --_alistboundary123 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

WWW.MAILGRABBER.RU



=CD=E0=E4=E5=FE=F1=FC =F2=E5=EF=E5=F0=FC =FD=F2=EE=F2 =F1=E0=E9= =F2 =E7=E0=EA=F0=EE=FE=F2! :-)


Powered by List Builde= r
Click here to change or r= emove your subscription
--_alistboundary123-- From noreply@sourceforge.net Mon Sep 17 21:58:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Sep 2001 13:58:33 -0700 Subject: [Patches] [ python-Patches-462296 ] Add attributes to os.stat results Message-ID: Patches item #462296, was opened at 2001-09-17 10:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Add attributes to os.stat results Initial Comment: See bug #111481, and PEP 0042. Both suggest that the return values for os.{stat,lstat,statvfs,fstatvfs} ought to be struct-like objects rather than simple tuples. With this patch, the os module will modify the aformentioned functions so that their results still obey the previous tuple protocol, but now have read-only attributes as well. In other words, "os.stat('filename')[0]" is now synonymous with "os.stat('filename').st_mode. The patch also modifies test_os.py to test the new behavior. In order to prevent old code from breaking, these new return types extend tuple. They also use the new attribute descriptor interface. (Thanks for PEP-025[23], Guido!) Backward compatibility: Code will only break if it assumes that type(os.stat(...)) == TupleType, or if it assumes that os.stat(...) has no attributes beyond those defined in tuple. ---------------------------------------------------------------------- >Comment By: Nick Mathewson (nickm) Date: 2001-09-17 13:58 Message: Logged In: YES user_id=499 BTW, if this gets in, I have another patch that adds support for st_blksize, st_blocks, and st_rdev on platforms that support them. It don't expose these new fields in the tuple, as that would break all the old code that tries to unpack all the fields of the tuple. Instead, these fields are only accessible as attributes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 From noreply@sourceforge.net Mon Sep 17 23:24:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Sep 2001 15:24:36 -0700 Subject: [Patches] [ python-Patches-462296 ] Add attributes to os.stat results Message-ID: Patches item #462296, was opened at 2001-09-17 10:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Add attributes to os.stat results Initial Comment: See bug #111481, and PEP 0042. Both suggest that the return values for os.{stat,lstat,statvfs,fstatvfs} ought to be struct-like objects rather than simple tuples. With this patch, the os module will modify the aformentioned functions so that their results still obey the previous tuple protocol, but now have read-only attributes as well. In other words, "os.stat('filename')[0]" is now synonymous with "os.stat('filename').st_mode. The patch also modifies test_os.py to test the new behavior. In order to prevent old code from breaking, these new return types extend tuple. They also use the new attribute descriptor interface. (Thanks for PEP-025[23], Guido!) Backward compatibility: Code will only break if it assumes that type(os.stat(...)) == TupleType, or if it assumes that os.stat(...) has no attributes beyond those defined in tuple. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-17 15:24 Message: Logged In: YES user_id=21627 I second the request for supporting additional fields where available. At the same time, it appears unimplementable using pure Python. Consequently, I'd like to see this patch redone in C. The implementation strategy could probably remain the same, i.e. inherit from tuple for best compatibility; add the remaining fields as slots. It may be reasonable to implement attribute access using a custom getattr function, though. I have also my doubts about the naming of the fields. The st_ prefix originates from the time where struct fields were living in the global namespace (i.e. across different structures), so prefixing them for uniqueness was essential. I'm not sure whether we should inherit this into Python... ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 13:58 Message: Logged In: YES user_id=499 BTW, if this gets in, I have another patch that adds support for st_blksize, st_blocks, and st_rdev on platforms that support them. It don't expose these new fields in the tuple, as that would break all the old code that tries to unpack all the fields of the tuple. Instead, these fields are only accessible as attributes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 From noreply@sourceforge.net Mon Sep 17 23:31:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Sep 2001 15:31:15 -0700 Subject: [Patches] [ python-Patches-462190 ] New C module for quopri assist Message-ID: Patches item #462190, was opened at 2001-09-17 00:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462190&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brandon Long (blong42) Assigned to: Nobody/Anonymous (nobody) Summary: New C module for quopri assist Initial Comment: This patch adds a new module, quoted, and code in quopri to use this module if it exists. This module implements quoted printable encoding and decoding based on strings in C. This was required by a recent project of mine because 1MB quoted printable mail attachments (sometimes chosen to send PDF and PS data) would take 40+ minutes to encode and decode using the standard quopri python module. ---------------------------------------------------------------------- >Comment By: Brandon Long (blong42) Date: 2001-09-17 15:31 Message: Logged In: YES user_id=325633 Ok, this new patch adds the code to binascii, b2a_qp and a2b_qp. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-17 07:22 Message: Logged In: YES user_id=6380 It would make more sense to add this as another pair of encodings to the binascii module, which provides similar support for binhex, base64, and uuencode. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462190&group_id=5470 From noreply@sourceforge.net Mon Sep 17 23:53:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Sep 2001 15:53:56 -0700 Subject: [Patches] [ python-Patches-462296 ] Add attributes to os.stat results Message-ID: Patches item #462296, was opened at 2001-09-17 10:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Add attributes to os.stat results Initial Comment: See bug #111481, and PEP 0042. Both suggest that the return values for os.{stat,lstat,statvfs,fstatvfs} ought to be struct-like objects rather than simple tuples. With this patch, the os module will modify the aformentioned functions so that their results still obey the previous tuple protocol, but now have read-only attributes as well. In other words, "os.stat('filename')[0]" is now synonymous with "os.stat('filename').st_mode. The patch also modifies test_os.py to test the new behavior. In order to prevent old code from breaking, these new return types extend tuple. They also use the new attribute descriptor interface. (Thanks for PEP-025[23], Guido!) Backward compatibility: Code will only break if it assumes that type(os.stat(...)) == TupleType, or if it assumes that os.stat(...) has no attributes beyond those defined in tuple. ---------------------------------------------------------------------- >Comment By: Nick Mathewson (nickm) Date: 2001-09-17 15:53 Message: Logged In: YES user_id=499 Martin: I'm not entirely sure what you mean here; while my patch for extra fields requires a minor chunk of C (to access the struct fields), the rest still works in pure python. I'm attaching this second version for reference. I'm not sure it makes much sense to do this with pure C; it would certainly take a lot more code, with little benefit I can descern. But you're more experienced than I; what am I missing? I agree that the field naming is suboptimal; I was taking my lead from the stat and statvfs modules. If people prefer, we can name the fields whatever we like. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-17 15:24 Message: Logged In: YES user_id=21627 I second the request for supporting additional fields where available. At the same time, it appears unimplementable using pure Python. Consequently, I'd like to see this patch redone in C. The implementation strategy could probably remain the same, i.e. inherit from tuple for best compatibility; add the remaining fields as slots. It may be reasonable to implement attribute access using a custom getattr function, though. I have also my doubts about the naming of the fields. The st_ prefix originates from the time where struct fields were living in the global namespace (i.e. across different structures), so prefixing them for uniqueness was essential. I'm not sure whether we should inherit this into Python... ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 13:58 Message: Logged In: YES user_id=499 BTW, if this gets in, I have another patch that adds support for st_blksize, st_blocks, and st_rdev on platforms that support them. It don't expose these new fields in the tuple, as that would break all the old code that tries to unpack all the fields of the tuple. Instead, these fields are only accessible as attributes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 From noreply@sourceforge.net Tue Sep 18 00:10:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Sep 2001 16:10:26 -0700 Subject: [Patches] [ python-Patches-462296 ] Add attributes to os.stat results Message-ID: Patches item #462296, was opened at 2001-09-17 10:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Add attributes to os.stat results Initial Comment: See bug #111481, and PEP 0042. Both suggest that the return values for os.{stat,lstat,statvfs,fstatvfs} ought to be struct-like objects rather than simple tuples. With this patch, the os module will modify the aformentioned functions so that their results still obey the previous tuple protocol, but now have read-only attributes as well. In other words, "os.stat('filename')[0]" is now synonymous with "os.stat('filename').st_mode. The patch also modifies test_os.py to test the new behavior. In order to prevent old code from breaking, these new return types extend tuple. They also use the new attribute descriptor interface. (Thanks for PEP-025[23], Guido!) Backward compatibility: Code will only break if it assumes that type(os.stat(...)) == TupleType, or if it assumes that os.stat(...) has no attributes beyond those defined in tuple. ---------------------------------------------------------------------- >Comment By: Nick Mathewson (nickm) Date: 2001-09-17 16:10 Message: Logged In: YES user_id=499 On further consideration, the approach taken in the second (*example only*) patch is indeed too fragile. The C code should not lengthen the tuple arbitrarily and depend on the Python code to decode it; instead, it should return a dictionary of extra fields. I think that this approach uses a minimum of C, is easily maintainable, and very extensible. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 15:53 Message: Logged In: YES user_id=499 Martin: I'm not entirely sure what you mean here; while my patch for extra fields requires a minor chunk of C (to access the struct fields), the rest still works in pure python. I'm attaching this second version for reference. I'm not sure it makes much sense to do this with pure C; it would certainly take a lot more code, with little benefit I can descern. But you're more experienced than I; what am I missing? I agree that the field naming is suboptimal; I was taking my lead from the stat and statvfs modules. If people prefer, we can name the fields whatever we like. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-17 15:24 Message: Logged In: YES user_id=21627 I second the request for supporting additional fields where available. At the same time, it appears unimplementable using pure Python. Consequently, I'd like to see this patch redone in C. The implementation strategy could probably remain the same, i.e. inherit from tuple for best compatibility; add the remaining fields as slots. It may be reasonable to implement attribute access using a custom getattr function, though. I have also my doubts about the naming of the fields. The st_ prefix originates from the time where struct fields were living in the global namespace (i.e. across different structures), so prefixing them for uniqueness was essential. I'm not sure whether we should inherit this into Python... ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 13:58 Message: Logged In: YES user_id=499 BTW, if this gets in, I have another patch that adds support for st_blksize, st_blocks, and st_rdev on platforms that support them. It don't expose these new fields in the tuple, as that would break all the old code that tries to unpack all the fields of the tuple. Instead, these fields are only accessible as attributes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 From noreply@sourceforge.net Tue Sep 18 01:32:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Sep 2001 17:32:44 -0700 Subject: [Patches] [ python-Patches-462296 ] Add attributes to os.stat results Message-ID: Patches item #462296, was opened at 2001-09-17 10:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Add attributes to os.stat results Initial Comment: See bug #111481, and PEP 0042. Both suggest that the return values for os.{stat,lstat,statvfs,fstatvfs} ought to be struct-like objects rather than simple tuples. With this patch, the os module will modify the aformentioned functions so that their results still obey the previous tuple protocol, but now have read-only attributes as well. In other words, "os.stat('filename')[0]" is now synonymous with "os.stat('filename').st_mode. The patch also modifies test_os.py to test the new behavior. In order to prevent old code from breaking, these new return types extend tuple. They also use the new attribute descriptor interface. (Thanks for PEP-025[23], Guido!) Backward compatibility: Code will only break if it assumes that type(os.stat(...)) == TupleType, or if it assumes that os.stat(...) has no attributes beyond those defined in tuple. ---------------------------------------------------------------------- >Comment By: Nick Mathewson (nickm) Date: 2001-09-17 17:32 Message: Logged In: YES user_id=499 Here's the revised (*example only*) patch that takes the more portable approach I mention below. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 16:10 Message: Logged In: YES user_id=499 On further consideration, the approach taken in the second (*example only*) patch is indeed too fragile. The C code should not lengthen the tuple arbitrarily and depend on the Python code to decode it; instead, it should return a dictionary of extra fields. I think that this approach uses a minimum of C, is easily maintainable, and very extensible. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 15:53 Message: Logged In: YES user_id=499 Martin: I'm not entirely sure what you mean here; while my patch for extra fields requires a minor chunk of C (to access the struct fields), the rest still works in pure python. I'm attaching this second version for reference. I'm not sure it makes much sense to do this with pure C; it would certainly take a lot more code, with little benefit I can descern. But you're more experienced than I; what am I missing? I agree that the field naming is suboptimal; I was taking my lead from the stat and statvfs modules. If people prefer, we can name the fields whatever we like. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-17 15:24 Message: Logged In: YES user_id=21627 I second the request for supporting additional fields where available. At the same time, it appears unimplementable using pure Python. Consequently, I'd like to see this patch redone in C. The implementation strategy could probably remain the same, i.e. inherit from tuple for best compatibility; add the remaining fields as slots. It may be reasonable to implement attribute access using a custom getattr function, though. I have also my doubts about the naming of the fields. The st_ prefix originates from the time where struct fields were living in the global namespace (i.e. across different structures), so prefixing them for uniqueness was essential. I'm not sure whether we should inherit this into Python... ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 13:58 Message: Logged In: YES user_id=499 BTW, if this gets in, I have another patch that adds support for st_blksize, st_blocks, and st_rdev on platforms that support them. It don't expose these new fields in the tuple, as that would break all the old code that tries to unpack all the fields of the tuple. Instead, these fields are only accessible as attributes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 From noreply@sourceforge.net Tue Sep 18 02:54:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Sep 2001 18:54:49 -0700 Subject: [Patches] [ python-Patches-462296 ] Add attributes to os.stat results Message-ID: Patches item #462296, was opened at 2001-09-17 10:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Add attributes to os.stat results Initial Comment: See bug #111481, and PEP 0042. Both suggest that the return values for os.{stat,lstat,statvfs,fstatvfs} ought to be struct-like objects rather than simple tuples. With this patch, the os module will modify the aformentioned functions so that their results still obey the previous tuple protocol, but now have read-only attributes as well. In other words, "os.stat('filename')[0]" is now synonymous with "os.stat('filename').st_mode. The patch also modifies test_os.py to test the new behavior. In order to prevent old code from breaking, these new return types extend tuple. They also use the new attribute descriptor interface. (Thanks for PEP-025[23], Guido!) Backward compatibility: Code will only break if it assumes that type(os.stat(...)) == TupleType, or if it assumes that os.stat(...) has no attributes beyond those defined in tuple. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-17 18:54 Message: Logged In: YES user_id=6380 Haven't had time to review the patch yet, but the idea of providing a structure with fields that doubles as a tuple is a good one. It's been tried before and can be done in pure Python as well. Regarding the field names: I think the field names should keep their st_ prefix -- IMO this makes the code more recognizable and hence readable. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 17:32 Message: Logged In: YES user_id=499 Here's the revised (*example only*) patch that takes the more portable approach I mention below. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 16:10 Message: Logged In: YES user_id=499 On further consideration, the approach taken in the second (*example only*) patch is indeed too fragile. The C code should not lengthen the tuple arbitrarily and depend on the Python code to decode it; instead, it should return a dictionary of extra fields. I think that this approach uses a minimum of C, is easily maintainable, and very extensible. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 15:53 Message: Logged In: YES user_id=499 Martin: I'm not entirely sure what you mean here; while my patch for extra fields requires a minor chunk of C (to access the struct fields), the rest still works in pure python. I'm attaching this second version for reference. I'm not sure it makes much sense to do this with pure C; it would certainly take a lot more code, with little benefit I can descern. But you're more experienced than I; what am I missing? I agree that the field naming is suboptimal; I was taking my lead from the stat and statvfs modules. If people prefer, we can name the fields whatever we like. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-17 15:24 Message: Logged In: YES user_id=21627 I second the request for supporting additional fields where available. At the same time, it appears unimplementable using pure Python. Consequently, I'd like to see this patch redone in C. The implementation strategy could probably remain the same, i.e. inherit from tuple for best compatibility; add the remaining fields as slots. It may be reasonable to implement attribute access using a custom getattr function, though. I have also my doubts about the naming of the fields. The st_ prefix originates from the time where struct fields were living in the global namespace (i.e. across different structures), so prefixing them for uniqueness was essential. I'm not sure whether we should inherit this into Python... ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 13:58 Message: Logged In: YES user_id=499 BTW, if this gets in, I have another patch that adds support for st_blksize, st_blocks, and st_rdev on platforms that support them. It don't expose these new fields in the tuple, as that would break all the old code that tries to unpack all the fields of the tuple. Instead, these fields are only accessible as attributes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 From oncol@e-mail.ru Tue Sep 18 08:09:15 2001 From: oncol@e-mail.ru (=?windows-1251?B?wOvl6vHl6Q==?=) Date: Tue, 18 Sep 2001 11:09:15 +0400 Subject: [Patches] SOS - We need help !!! Message-ID: <003a01c14010$d3a45060$4d49e9c1@rsl.ru> Здравствуйте уважаемые дамы и господа. Прошу прощения что вторгаюсь в Ваш почтовый ящик столь неблагородным способом как спам. Но у меня нет другого выхода ! Это не реклама и не предложение работы. ЭТО ПРОСЬБА О ПОМОЩИ !!! Пожалуйста потратьте 1 минуту Вашего времени и зайдите на http://www.oncol.non.ru Возможно именно Вы сможете спасти жизнь человеку. Ещё раз простите что отнимаю у Вас время . Храни Вас Бог ! С уважением Алексей. ========================================== Dear Sirs and Ladies, I beg your pardon for my intrusion into your mailbox in such an indelicate way as spam. But it is the only thing to do for me! (There is no other way out). It is neither advertisement nor offer of work. Please, spend a minute of your time and call on http://www.oncol.non.ru. It may be you who saves girl`s life. Once more I beg your pardon for taking your time. God bless you! Yours sincerely, Alexis. From nety-feedback-3@lb.bcentral.com Tue Sep 18 08:39:08 2001 From: nety-feedback-3@lb.bcentral.com (:-)) Date: 18 Sep 2001 07:39:08 -0000 Subject: [Patches] телмбнб Message-ID: <1000798748.44994.qmail@ech> рПУЕФЙФЕ ОБЫ УБКФ: http://web-business.virtualave.net/ _______________________________________________________________________ Powered by List Builder To unsubscribe follow the link: http://lb.bcentral.com/ex/manage/subscriberprefs?customerid=15216&subid=BD760F1659A80025&msgnum=3 From noreply@sourceforge.net Tue Sep 18 08:54:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Sep 2001 00:54:46 -0700 Subject: [Patches] [ python-Patches-462296 ] Add attributes to os.stat results Message-ID: Patches item #462296, was opened at 2001-09-17 10:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Add attributes to os.stat results Initial Comment: See bug #111481, and PEP 0042. Both suggest that the return values for os.{stat,lstat,statvfs,fstatvfs} ought to be struct-like objects rather than simple tuples. With this patch, the os module will modify the aformentioned functions so that their results still obey the previous tuple protocol, but now have read-only attributes as well. In other words, "os.stat('filename')[0]" is now synonymous with "os.stat('filename').st_mode. The patch also modifies test_os.py to test the new behavior. In order to prevent old code from breaking, these new return types extend tuple. They also use the new attribute descriptor interface. (Thanks for PEP-025[23], Guido!) Backward compatibility: Code will only break if it assumes that type(os.stat(...)) == TupleType, or if it assumes that os.stat(...) has no attributes beyond those defined in tuple. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-18 00:54 Message: Logged In: YES user_id=21627 The problem with your second and third patch is that it includes an incompatibility for users of posix.stat (and friends), since it changes the siye of the tuple. If you want to continue to return a tuple (as the top-level data structure), you'll break compatibility for applications using the C module directly. An example of code that would be broken is mode, ino, dev, nlink, uid, gid, size, a, c, m = posix.stat(filename) To pass the additional fields, you already need your class _StatResult available in C. You may find a way to define it in Python and use it in C, but that has proven to be very fragile in the past. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-17 18:54 Message: Logged In: YES user_id=6380 Haven't had time to review the patch yet, but the idea of providing a structure with fields that doubles as a tuple is a good one. It's been tried before and can be done in pure Python as well. Regarding the field names: I think the field names should keep their st_ prefix -- IMO this makes the code more recognizable and hence readable. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 17:32 Message: Logged In: YES user_id=499 Here's the revised (*example only*) patch that takes the more portable approach I mention below. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 16:10 Message: Logged In: YES user_id=499 On further consideration, the approach taken in the second (*example only*) patch is indeed too fragile. The C code should not lengthen the tuple arbitrarily and depend on the Python code to decode it; instead, it should return a dictionary of extra fields. I think that this approach uses a minimum of C, is easily maintainable, and very extensible. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 15:53 Message: Logged In: YES user_id=499 Martin: I'm not entirely sure what you mean here; while my patch for extra fields requires a minor chunk of C (to access the struct fields), the rest still works in pure python. I'm attaching this second version for reference. I'm not sure it makes much sense to do this with pure C; it would certainly take a lot more code, with little benefit I can descern. But you're more experienced than I; what am I missing? I agree that the field naming is suboptimal; I was taking my lead from the stat and statvfs modules. If people prefer, we can name the fields whatever we like. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-17 15:24 Message: Logged In: YES user_id=21627 I second the request for supporting additional fields where available. At the same time, it appears unimplementable using pure Python. Consequently, I'd like to see this patch redone in C. The implementation strategy could probably remain the same, i.e. inherit from tuple for best compatibility; add the remaining fields as slots. It may be reasonable to implement attribute access using a custom getattr function, though. I have also my doubts about the naming of the fields. The st_ prefix originates from the time where struct fields were living in the global namespace (i.e. across different structures), so prefixing them for uniqueness was essential. I'm not sure whether we should inherit this into Python... ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 13:58 Message: Logged In: YES user_id=499 BTW, if this gets in, I have another patch that adds support for st_blksize, st_blocks, and st_rdev on platforms that support them. It don't expose these new fields in the tuple, as that would break all the old code that tries to unpack all the fields of the tuple. Instead, these fields are only accessible as attributes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 From noreply@sourceforge.net Tue Sep 18 09:03:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Sep 2001 01:03:07 -0700 Subject: [Patches] [ python-Patches-460751 ] --with-shared: python with shared lib Message-ID: Patches item #460751, was opened at 2001-09-11 14:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) >Assigned to: Martin v. Lцwis (loewis) Summary: --with-shared: python with shared lib Initial Comment: As a follow up to patch 400938 (https://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=400938), here is an implementation of the --with-shared configure option for building python on Posix systems as a shared library. Building python as shared library is activated with the --with-shared option on ./configure The following points are drawn to particular attention: - A configbuild.py module is generated and placed in the machine-dependent directory. It records most Python/Makefile variables (CC, CFLAG, LDSHARED...), and make them available in Python. - The build has been tested on: Linux2: OK SunOS5: OK IRIX64: Build OK, crash on test (bus error) - Inference with distutils: I found it very difficult understanding the distutil architecture and finding the right points of change; I minimized my interaction there. Furthermore, the availability of the 'configbuild' module overlaps some of the distutils; but 'configbuild' is very easy to use ... - Unresolved symbols: I turned on the symbol checking flags whenever possible, on behalf the its better generating the error on build than at runtime. - configure.in: I only edited the configure Bourne script, and did not bother with configure.in (actually, I deleted it) and its autoconfig/m4 macro comparses. Frederic Giacometti ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-17 10:36 Message: Logged In: YES user_id=93657 I'm attaching an updated patch where, following Martin suggestions: - I removed the configbuild thing, and replaced it with distutils.sysconfig.get_conf_var calls - I manually cleaned up the patch from unrelated changes (.cvsignore, @ Makefile modifiers...) Remains the configure.in thing. If one looks at autoconf: - it takes care of plateform idiosyncracies, for platform which do not follow posix API specs; this was of use in previous generation Unix OS's, and these legacy systems do not evolve anymore. On present Unixes, and with regard to the features used for building the core python engine, nothing moves, and autoconf updates bring nothing. Doesn't the Python 1.5.2's configure still works as it did the first day it was generated ... ? - autoconf is of use for configuring particular packages and libraries (e.g.: for configuring and building python extensions, Tkinter/Tk/TCL...); unfortunately this never worked with python, and the task is now assumed by the distutils. - In the Python core build, autoconf is of no help in anything sensible: thread, shared library, debug build, compiler options... All these were programmed manually in Bourne; and for doing the later, autoconf is a complexifying factor on something already fairly complex - i.e. a handicap -. - not to say, autoconf is of no use on non-posix plateforms (windows...) - last, and the least: autoconf now requires that perl be installed... Frederic Giacometti ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 18:36 Message: Logged In: YES user_id=6380 > What is the point of keeping using the autoconf thing when > it is easier to maintain configure directly, than going > through configure.in ? But it's not. One line of configure.in often expands to dozens (occasionally hundreds) of lines of configure. autoconf has arcane knowledge that gets updated with new autoconf releases. You are entitled to your opinion, but in this case, it's wrong. Go fork your own version of Python if you don't want to learn autoconf. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-12 16:06 Message: Logged In: YES user_id=93657 I am not willing to make anything difficult for anybody, but: What is the point of keeping using the autoconf thing when it is easier to maintain configure directly, than going through configure.in ? After configure has been generated once, it makes more sense to me to work directly on configure, and forget about configure.in. configure (pure Bourne shell) is a easier to understand, to troubleshoot, and to maintain that configure.in (a mixture of Bourne shell and autoconf m4 macros). I'll have a second look at the autoconf thing latter on - at present I hardly understand anything to configure.in, and got 'configure --with-shared' working with satisfaction across multiple platforms without undue difficulties. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 11:37 Message: Logged In: YES user_id=6380 > Autoconf is not installed on the commercial Unix > platforms, it is useless for me to learn it, and I was > better off directly editing ./configure. However, if others > are familiar with the tool, it should be straightforward for > them to retrocede the changes from configure to configure.in Sure. You'll just have to wait until we have time for that. You can make it easy for us to integrate your changes, or you can make it difficult. Your choice. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-12 11:12 Message: Logged In: YES user_id=93657 - I will remove the configbuild; since Martin pointed to me the existence of distutils.sysconfig.get_config_vars(). I did not know about this function... Thanks! On the fly, you'll also note the following potential problem with using get_config_vars() instead of configbuild: configbuild will report the actual values used for the build, whereas get_config_vars() will report erroneous values whenever the Makefile internal variables were overriden at build time (by either the environment, or by commandline assignment of the type 'make CC=gxx ...'); not to mention that configbuild does not need to find and parse the original Makefile (with all the potential problems associated). - The .purify line should be in the CVSROOT/cvsignore CVS admin file, not in .cvsignore in the root directory of the source distribution... - Autoconf is not installed on the commercial Unix platforms, it is useless for me to learn it, and I was better off directly editing ./configure. However, if others are familiar with the tool, it should be straightforward for them to retrocede the changes from configure to configure.in - I had to introduce THREADOBJ because you will note that, in the present implementation, Modules/thread.o appears multiple times in LIBOBJS, which causes warning at link time. Now, Modules/thread.o appears only once ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-12 01:06 Message: Logged In: YES user_id=21627 As for libtool: I strongly advise not to use it. It is broken in too many ways to enumerate. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-12 00:18 Message: Logged In: YES user_id=21627 I recommend to rework this patch to get rid of configbuild. I cannot see what you achieve with the configbuild module that you couldn't do with distutils.sysconfig.get_config_vars (which is capable of parsing the Makefile directly). I also recommend to go through the patch chunk by chunk, asking yourself whether this chunk *really* is needed to achieve the desired functionality. E.g. I cannot see the relationship of the .cvsignore chunk; I also believe that removal of .purify is incorrect. Likewise, while I sympathize with the unresolved symbols change, I believe it is unrelated to the main objective of this patch (building Python shared). What is the rationale for not changing configure.in? As-is, this patch is useless: configure will be overwritten everytime you run autoconf. Please get a copy of autoconf on one of your systems, change configure.in, run autoconf, and then provide us with a patch that only changes configure.in: everybody reviewing this patch should be capable of running autoconf. configure is a generated file and should not be edited manually. What is the rationale for the introduction of the THREADOBJ variable? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-11 19:03 Message: Logged In: YES user_id=6380 Haven't seen the patch yet, but I like the idea -- the command line option suggests that it shouldn't hurt platforms where it can't be done or has to be done differently. Alternative: we could also consider using libtool. I didn't like that much in the past, but maybe it would work. Dunno. Anybody know about it? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 From noreply@sourceforge.net Tue Sep 18 12:55:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Sep 2001 04:55:08 -0700 Subject: [Patches] [ python-Patches-462522 ] code.py softspace attribute fix Message-ID: Patches item #462522, was opened at 2001-09-18 04:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462522&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Guido van Rossum (gvanrossum) Summary: code.py softspace attribute fix Initial Comment: I *think* this is required as fallout from the fact that ob.foo = 1 can raise AttributeError now. To someone who knows, this should be a no-brainer. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462522&group_id=5470 From noreply@sourceforge.net Tue Sep 18 14:34:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Sep 2001 06:34:11 -0700 Subject: [Patches] [ python-Patches-462522 ] code.py softspace attribute fix Message-ID: Patches item #462522, was opened at 2001-09-18 04:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462522&group_id=5470 Category: Modules Group: None Status: Open >Resolution: Fixed Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Guido van Rossum (gvanrossum) Summary: code.py softspace attribute fix Initial Comment: I *think* this is required as fallout from the fact that ob.foo = 1 can raise AttributeError now. To someone who knows, this should be a no-brainer. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-18 06:34 Message: Logged In: YES user_id=6380 I've checked this in, but I'm leaving it open for now: can you show me how to reproduce the problem? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462522&group_id=5470 From noreply@sourceforge.net Tue Sep 18 17:36:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Sep 2001 09:36:37 -0700 Subject: [Patches] [ python-Patches-430706 ] Persistent connections in BaseHTTPServer Message-ID: Patches item #430706, was opened at 2001-06-06 08:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=430706&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Lawrence (lordsutch) Assigned to: Martin v. Lцwis (loewis) Summary: Persistent connections in BaseHTTPServer Initial Comment: This patch provides HTTP/1.1 persistent connection support in BaseHTTPServer.py. It is not enabled by default (for backwards compatibility) because Content-Length headers must be supplied for persistent connections to work correctly. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-18 09:36 Message: Logged In: YES user_id=21627 It still doesn't work right. If I access SimpleHTTPServer from a Netscape client, I get error messages like localhost - - [18/Sep/2001 18:32:22] code 400, message Bad request syntax ('') localhost - - [18/Sep/2001 18:32:22] "" 400 - These are caused because the client closes the connection after the first request (likely, after it finds out that the document it got contains no references to the same server anymore). However, the server continues to invoke handle_one_request, which reads the empty line and fails to recognize that the client has closed the connection. ---------------------------------------------------------------------- Comment By: Chris Lawrence (lordsutch) Date: 2001-09-15 01:15 Message: Logged In: YES user_id=6757 I reworked the patch a bit to ensure HTTP 1.1 mode is only used if the handler class is in HTTP 1.1 mode, and modified the test() functions in the server classes to add a "protocol" option. I also modified SimpleHTTPServer to send Content-Length headers for the implemented classes. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-04 04:40 Message: Logged In: YES user_id=21627 The patch in its current form seems to be broken. To see the problem, please run SimpleHTTPServer on some directory, then access it with a HTTP/1.1 client (e.g. Netscape 4.7). The server will use the protocol version HTTP/1.0, but the client will initially send 1.1, and send a Connection: Keep-alive header. As a result, self.close_connection is set to 0, despite using HTTP/1.0. In turn, the HTTP server won't send a content length, and won't close the connection either. Netscape waits forever from some completion which never occurs, since the server waits for the next request on the same connection. It might be useful to enhance the SimpleHTTPServer test() function to optionally operate in HTTP/1.1 mode (including sending a proper ContentLength). Doing the same for the CGI HTTP server is probably less useful. ---------------------------------------------------------------------- Comment By: Chris Lawrence (lordsutch) Date: 2001-08-29 20:21 Message: Logged In: YES user_id=6757 I have updated the patch against current CVS and have added documentation. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-08 13:43 Message: Logged In: YES user_id=21627 I haven't studied the patch in detail, yet, but I have a few comments on the style: - there is no need to quote all authors of the RFC. Also, the reference to long-ago expired HTTP draft should go; just replace it with a single reference to the RFC number (giving an URL for the RFC might be convenient) - Where is the documentation? A patch to Doc/lib/libbasehttp.tex would be appreciated. If you don't speak TeX, don't worry: Just write plain text, we'll do the mark-up. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=430706&group_id=5470 From noreply@sourceforge.net Tue Sep 18 18:02:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Sep 2001 10:02:24 -0700 Subject: [Patches] [ python-Patches-462596 ] StringIO Enhancement Message-ID: Patches item #462596, was opened at 2001-09-18 10:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462596&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Guido van Rossum (gvanrossum) Summary: StringIO Enhancement Initial Comment: This patch allows using arbitrary read-buffer compatible objects as basis for StringIO and cStringIO objects. Previously, StringIO.py and cStringIO could only handle Python string objects as input buffer and in the .write() methods. The patch modifies the two modules in a way which automatically translates the used objects into strings (using the "s#" parser marker or str() to implement the conversion), e.g. Unicode objects, buffers, memory mapped files, etc. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462596&group_id=5470 From noreply@sourceforge.net Tue Sep 18 18:05:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Sep 2001 10:05:08 -0700 Subject: [Patches] [ python-Patches-460751 ] --with-shared: python with shared lib Message-ID: Patches item #460751, was opened at 2001-09-11 14:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Martin v. Lцwis (loewis) Summary: --with-shared: python with shared lib Initial Comment: As a follow up to patch 400938 (https://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=400938), here is an implementation of the --with-shared configure option for building python on Posix systems as a shared library. Building python as shared library is activated with the --with-shared option on ./configure The following points are drawn to particular attention: - A configbuild.py module is generated and placed in the machine-dependent directory. It records most Python/Makefile variables (CC, CFLAG, LDSHARED...), and make them available in Python. - The build has been tested on: Linux2: OK SunOS5: OK IRIX64: Build OK, crash on test (bus error) - Inference with distutils: I found it very difficult understanding the distutil architecture and finding the right points of change; I minimized my interaction there. Furthermore, the availability of the 'configbuild' module overlaps some of the distutils; but 'configbuild' is very easy to use ... - Unresolved symbols: I turned on the symbol checking flags whenever possible, on behalf the its better generating the error on build than at runtime. - configure.in: I only edited the configure Bourne script, and did not bother with configure.in (actually, I deleted it) and its autoconfig/m4 macro comparses. Frederic Giacometti ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-18 10:05 Message: Logged In: YES user_id=21627 I've tried testing your patch, but I get numerous failed chunks when applying it against the current CVS. What version does this patch apply to? To simplify the integration, it would be greatly appreciated if you could use the current source base. >From reviewing the patch, I still have a number of concerns: - it appears that you change the mechanism by which buildno is incremented. Why? - There appear to extra white space changes (e.g. in the distclean chunk); those are naturally unrelated to the patch - please remove them - it appears that configuration knowledge for some platforms is lost when applying this patch, e.g. the dguxR4 special-casing of passing -pic is gone. Please try to integrate any such knowledge faithfully into your patch, instead of restricting its applicability to just the platforms where you've tested it on. - There is something going on with dropping -lsocket from the patch. What is that, and why does it happen? Instead, it appears that you put 'socket' and 'nsl' into setup.py. According to configure.in, this is wrong on some systems: they may not have the libraries, or the libraries may be broken. - Other libraries appear to suffer as well, such as removing -lmpc. That might mean that you break thread support on some systems. - the chunk to disable fpectl if nothing is known about the systems appears to be unrelated. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-17 10:36 Message: Logged In: YES user_id=93657 I'm attaching an updated patch where, following Martin suggestions: - I removed the configbuild thing, and replaced it with distutils.sysconfig.get_conf_var calls - I manually cleaned up the patch from unrelated changes (.cvsignore, @ Makefile modifiers...) Remains the configure.in thing. If one looks at autoconf: - it takes care of plateform idiosyncracies, for platform which do not follow posix API specs; this was of use in previous generation Unix OS's, and these legacy systems do not evolve anymore. On present Unixes, and with regard to the features used for building the core python engine, nothing moves, and autoconf updates bring nothing. Doesn't the Python 1.5.2's configure still works as it did the first day it was generated ... ? - autoconf is of use for configuring particular packages and libraries (e.g.: for configuring and building python extensions, Tkinter/Tk/TCL...); unfortunately this never worked with python, and the task is now assumed by the distutils. - In the Python core build, autoconf is of no help in anything sensible: thread, shared library, debug build, compiler options... All these were programmed manually in Bourne; and for doing the later, autoconf is a complexifying factor on something already fairly complex - i.e. a handicap -. - not to say, autoconf is of no use on non-posix plateforms (windows...) - last, and the least: autoconf now requires that perl be installed... Frederic Giacometti ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 18:36 Message: Logged In: YES user_id=6380 > What is the point of keeping using the autoconf thing when > it is easier to maintain configure directly, than going > through configure.in ? But it's not. One line of configure.in often expands to dozens (occasionally hundreds) of lines of configure. autoconf has arcane knowledge that gets updated with new autoconf releases. You are entitled to your opinion, but in this case, it's wrong. Go fork your own version of Python if you don't want to learn autoconf. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-12 16:06 Message: Logged In: YES user_id=93657 I am not willing to make anything difficult for anybody, but: What is the point of keeping using the autoconf thing when it is easier to maintain configure directly, than going through configure.in ? After configure has been generated once, it makes more sense to me to work directly on configure, and forget about configure.in. configure (pure Bourne shell) is a easier to understand, to troubleshoot, and to maintain that configure.in (a mixture of Bourne shell and autoconf m4 macros). I'll have a second look at the autoconf thing latter on - at present I hardly understand anything to configure.in, and got 'configure --with-shared' working with satisfaction across multiple platforms without undue difficulties. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 11:37 Message: Logged In: YES user_id=6380 > Autoconf is not installed on the commercial Unix > platforms, it is useless for me to learn it, and I was > better off directly editing ./configure. However, if others > are familiar with the tool, it should be straightforward for > them to retrocede the changes from configure to configure.in Sure. You'll just have to wait until we have time for that. You can make it easy for us to integrate your changes, or you can make it difficult. Your choice. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-12 11:12 Message: Logged In: YES user_id=93657 - I will remove the configbuild; since Martin pointed to me the existence of distutils.sysconfig.get_config_vars(). I did not know about this function... Thanks! On the fly, you'll also note the following potential problem with using get_config_vars() instead of configbuild: configbuild will report the actual values used for the build, whereas get_config_vars() will report erroneous values whenever the Makefile internal variables were overriden at build time (by either the environment, or by commandline assignment of the type 'make CC=gxx ...'); not to mention that configbuild does not need to find and parse the original Makefile (with all the potential problems associated). - The .purify line should be in the CVSROOT/cvsignore CVS admin file, not in .cvsignore in the root directory of the source distribution... - Autoconf is not installed on the commercial Unix platforms, it is useless for me to learn it, and I was better off directly editing ./configure. However, if others are familiar with the tool, it should be straightforward for them to retrocede the changes from configure to configure.in - I had to introduce THREADOBJ because you will note that, in the present implementation, Modules/thread.o appears multiple times in LIBOBJS, which causes warning at link time. Now, Modules/thread.o appears only once ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-12 01:06 Message: Logged In: YES user_id=21627 As for libtool: I strongly advise not to use it. It is broken in too many ways to enumerate. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-12 00:18 Message: Logged In: YES user_id=21627 I recommend to rework this patch to get rid of configbuild. I cannot see what you achieve with the configbuild module that you couldn't do with distutils.sysconfig.get_config_vars (which is capable of parsing the Makefile directly). I also recommend to go through the patch chunk by chunk, asking yourself whether this chunk *really* is needed to achieve the desired functionality. E.g. I cannot see the relationship of the .cvsignore chunk; I also believe that removal of .purify is incorrect. Likewise, while I sympathize with the unresolved symbols change, I believe it is unrelated to the main objective of this patch (building Python shared). What is the rationale for not changing configure.in? As-is, this patch is useless: configure will be overwritten everytime you run autoconf. Please get a copy of autoconf on one of your systems, change configure.in, run autoconf, and then provide us with a patch that only changes configure.in: everybody reviewing this patch should be capable of running autoconf. configure is a generated file and should not be edited manually. What is the rationale for the introduction of the THREADOBJ variable? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-11 19:03 Message: Logged In: YES user_id=6380 Haven't seen the patch yet, but I like the idea -- the command line option suggests that it shouldn't hurt platforms where it can't be done or has to be done differently. Alternative: we could also consider using libtool. I didn't like that much in the past, but maybe it would work. Dunno. Anybody know about it? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 From noreply@sourceforge.net Tue Sep 18 19:46:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Sep 2001 11:46:58 -0700 Subject: [Patches] [ python-Patches-462190 ] New C module for quopri assist Message-ID: Patches item #462190, was opened at 2001-09-17 00:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462190&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brandon Long (blong42) Assigned to: Nobody/Anonymous (nobody) Summary: New C module for quopri assist Initial Comment: This patch adds a new module, quoted, and code in quopri to use this module if it exists. This module implements quoted printable encoding and decoding based on strings in C. This was required by a recent project of mine because 1MB quoted printable mail attachments (sometimes chosen to send PDF and PS data) would take 40+ minutes to encode and decode using the standard quopri python module. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-18 11:46 Message: Logged In: YES user_id=21627 The patch looks good to me. A couple of comments that may be worth consideration: - if backwards compatibility is an objective, boundary cases should be analysed in more detail. E.g. it appears that the case of invalid escape sequences (=EI) is handled differently. - the new module, when encoding one file into anothher, reads all data, whereas the old one would read line by line. Is that change desirable? - the C code could avoid copying the string if it allocated a PyString right away, and adjusted it with _Resize when it is done. ---------------------------------------------------------------------- Comment By: Brandon Long (blong42) Date: 2001-09-17 15:31 Message: Logged In: YES user_id=325633 Ok, this new patch adds the code to binascii, b2a_qp and a2b_qp. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-17 07:22 Message: Logged In: YES user_id=6380 It would make more sense to add this as another pair of encodings to the binascii module, which provides similar support for binhex, base64, and uuencode. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462190&group_id=5470 From noreply@sourceforge.net Tue Sep 18 19:56:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Sep 2001 11:56:25 -0700 Subject: [Patches] [ python-Patches-462628 ] NNTPLib supports saving BODY to a file Message-ID: Patches item #462628, was opened at 2001-09-18 11:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462628&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Travers Naran (tnaran) Assigned to: Nobody/Anonymous (nobody) Summary: NNTPLib supports saving BODY to a file Initial Comment: I modified nntplib so the body method can accept an optional second parameter pointing to a filehandle or filename (string). This way, really long body articles can be stored to disk instead of kept in memory. The way I made the modification should make it easy to extend this functionality to other extended return methods. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462628&group_id=5470 From noreply@sourceforge.net Tue Sep 18 20:13:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Sep 2001 12:13:00 -0700 Subject: [Patches] [ python-Patches-462635 ] Fix bugs in new encodings Message-ID: Patches item #462635, was opened at 2001-09-18 12:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462635&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 6 Submitted By: A.M. Kuchling (akuchling) Assigned to: M.-A. Lemburg (lemburg) Summary: Fix bugs in new encodings Initial Comment: Attempting to open a stream using the new uu/zlib/base64/etc encodings doesn't work. >>> import codecs >>> f=codecs.open('foo.gz', 'wb', encoding='zlib') >>> f.write('Output goes here. ' * 10) Traceback (most recent call last): File "", line 1, in ? File "/home/akuchlin/src/python/Lib/codecs.py", line 338, in write return self.writer.write(data) File "/home/akuchlin/src/python/Lib/codecs.py", line 137, in write data, consumed = self.encode(object, self.errors) TypeError: zlib_encode() takes at most 2 arguments (3 given) Python is returning a bound method for self.encode, so it's short by one argument. The supplied patch fixes this; there should also be a test case added to the test suite to exercise this code. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462635&group_id=5470 From noreply@sourceforge.net Tue Sep 18 21:00:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Sep 2001 13:00:14 -0700 Subject: [Patches] [ python-Patches-462258 ] tkinter without X11 patch Message-ID: Patches item #462258, was opened at 2001-09-17 08:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462258&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: A.M. Kuchling (akuchling) Summary: tkinter without X11 patch Initial Comment: This patch is a follow up to patch #443669. It prevents the attempt to build the tkinter module unless the X header files can be found. I developed this patch with Cygwin in mind but it should work for other platforms too. I tested this patch on Red Hat 7.1 without any ill effects. However, if one is concerned about breaking other Unix platforms, then the following guard: if platform == 'cygwin' can be added. I'm willing to redo the patch, if this is deemed necessary. To apply the patch, use the following procedure: $ # save the patch to /tmp/tkinter.patch $ # change directory to the top of the Python source tree $ patch Comment By: Jason Tishler (jlt63) Date: 2001-09-18 13:00 Message: Logged In: YES user_id=86216 This version of the patch includes the requested Cygwin guard. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-09-17 09:08 Message: Logged In: YES user_id=11375 I think I'd prefer this patch with the platform=='cygwin' guard. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462258&group_id=5470 From noreply@sourceforge.net Tue Sep 18 21:32:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Sep 2001 13:32:09 -0700 Subject: [Patches] [ python-Patches-462190 ] New C module for quopri assist Message-ID: Patches item #462190, was opened at 2001-09-17 00:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462190&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brandon Long (blong42) Assigned to: Nobody/Anonymous (nobody) Summary: New C module for quopri assist Initial Comment: This patch adds a new module, quoted, and code in quopri to use this module if it exists. This module implements quoted printable encoding and decoding based on strings in C. This was required by a recent project of mine because 1MB quoted printable mail attachments (sometimes chosen to send PDF and PS data) would take 40+ minutes to encode and decode using the standard quopri python module. ---------------------------------------------------------------------- >Comment By: Brandon Long (blong42) Date: 2001-09-18 13:32 Message: Logged In: YES user_id=325633 Ok, this version handles invalid escape sequences the same way, ie by leaving them as they were in the input stream. My original reason for writing this was performance, and the size of the input was already restricted to 1MB, hence the chosen in memory encode/decode. No one is likely to be using the current version for anything even approaching that size given the abysmal performance of the current version. Given that 2.2 adds the decodestring and encodestring versions, maybe we should have both, I'm not sure. The new mimelib module handles mail in memory, instead of using the file like operations of the rfc822 module. *shrug* Using PyString in that fashion I don't think will save anything... as the only external interfaces for that would do a copy on create with PyString_FromStringAndSize(), and then a realloc with the PyString_Resize() (though I could be missing something in there). ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-18 11:46 Message: Logged In: YES user_id=21627 The patch looks good to me. A couple of comments that may be worth consideration: - if backwards compatibility is an objective, boundary cases should be analysed in more detail. E.g. it appears that the case of invalid escape sequences (=EI) is handled differently. - the new module, when encoding one file into anothher, reads all data, whereas the old one would read line by line. Is that change desirable? - the C code could avoid copying the string if it allocated a PyString right away, and adjusted it with _Resize when it is done. ---------------------------------------------------------------------- Comment By: Brandon Long (blong42) Date: 2001-09-17 15:31 Message: Logged In: YES user_id=325633 Ok, this new patch adds the code to binascii, b2a_qp and a2b_qp. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-17 07:22 Message: Logged In: YES user_id=6380 It would make more sense to add this as another pair of encodings to the binascii module, which provides similar support for binhex, base64, and uuencode. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462190&group_id=5470 From noreply@sourceforge.net Tue Sep 18 21:32:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Sep 2001 13:32:35 -0700 Subject: [Patches] [ python-Patches-462258 ] tkinter without X11 patch Message-ID: Patches item #462258, was opened at 2001-09-17 08:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462258&group_id=5470 Category: Distutils and setup.py Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: A.M. Kuchling (akuchling) Summary: tkinter without X11 patch Initial Comment: This patch is a follow up to patch #443669. It prevents the attempt to build the tkinter module unless the X header files can be found. I developed this patch with Cygwin in mind but it should work for other platforms too. I tested this patch on Red Hat 7.1 without any ill effects. However, if one is concerned about breaking other Unix platforms, then the following guard: if platform == 'cygwin' can be added. I'm willing to redo the patch, if this is deemed necessary. To apply the patch, use the following procedure: $ # save the patch to /tmp/tkinter.patch $ # change directory to the top of the Python source tree $ patch Comment By: A.M. Kuchling (akuchling) Date: 2001-09-18 13:32 Message: Logged In: YES user_id=11375 Checked in to revision 1.57 of setup.py. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-09-18 13:00 Message: Logged In: YES user_id=86216 This version of the patch includes the requested Cygwin guard. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-09-17 09:08 Message: Logged In: YES user_id=11375 I think I'd prefer this patch with the platform=='cygwin' guard. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462258&group_id=5470 From noreply@sourceforge.net Tue Sep 18 22:11:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Sep 2001 14:11:01 -0700 Subject: [Patches] [ python-Patches-462296 ] Add attributes to os.stat results Message-ID: Patches item #462296, was opened at 2001-09-17 10:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Add attributes to os.stat results Initial Comment: See bug #111481, and PEP 0042. Both suggest that the return values for os.{stat,lstat,statvfs,fstatvfs} ought to be struct-like objects rather than simple tuples. With this patch, the os module will modify the aformentioned functions so that their results still obey the previous tuple protocol, but now have read-only attributes as well. In other words, "os.stat('filename')[0]" is now synonymous with "os.stat('filename').st_mode. The patch also modifies test_os.py to test the new behavior. In order to prevent old code from breaking, these new return types extend tuple. They also use the new attribute descriptor interface. (Thanks for PEP-025[23], Guido!) Backward compatibility: Code will only break if it assumes that type(os.stat(...)) == TupleType, or if it assumes that os.stat(...) has no attributes beyond those defined in tuple. ---------------------------------------------------------------------- >Comment By: Nick Mathewson (nickm) Date: 2001-09-18 14:11 Message: Logged In: YES user_id=499 Ah! Now I see. I hadn't realized that anybody used the posix module directly. (People really do this?) I'll try to write up a patch in C tonight or tomorrow morning. A couple of questions on which I could use advice: (1) Where is the proper place to put this kind of tuple-with-fields hybrid? Modules? Objects? In a new file or an existing one? (2) Should I try to make it general enough for non-stat use? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-18 00:54 Message: Logged In: YES user_id=21627 The problem with your second and third patch is that it includes an incompatibility for users of posix.stat (and friends), since it changes the siye of the tuple. If you want to continue to return a tuple (as the top-level data structure), you'll break compatibility for applications using the C module directly. An example of code that would be broken is mode, ino, dev, nlink, uid, gid, size, a, c, m = posix.stat(filename) To pass the additional fields, you already need your class _StatResult available in C. You may find a way to define it in Python and use it in C, but that has proven to be very fragile in the past. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-17 18:54 Message: Logged In: YES user_id=6380 Haven't had time to review the patch yet, but the idea of providing a structure with fields that doubles as a tuple is a good one. It's been tried before and can be done in pure Python as well. Regarding the field names: I think the field names should keep their st_ prefix -- IMO this makes the code more recognizable and hence readable. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 17:32 Message: Logged In: YES user_id=499 Here's the revised (*example only*) patch that takes the more portable approach I mention below. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 16:10 Message: Logged In: YES user_id=499 On further consideration, the approach taken in the second (*example only*) patch is indeed too fragile. The C code should not lengthen the tuple arbitrarily and depend on the Python code to decode it; instead, it should return a dictionary of extra fields. I think that this approach uses a minimum of C, is easily maintainable, and very extensible. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 15:53 Message: Logged In: YES user_id=499 Martin: I'm not entirely sure what you mean here; while my patch for extra fields requires a minor chunk of C (to access the struct fields), the rest still works in pure python. I'm attaching this second version for reference. I'm not sure it makes much sense to do this with pure C; it would certainly take a lot more code, with little benefit I can descern. But you're more experienced than I; what am I missing? I agree that the field naming is suboptimal; I was taking my lead from the stat and statvfs modules. If people prefer, we can name the fields whatever we like. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-17 15:24 Message: Logged In: YES user_id=21627 I second the request for supporting additional fields where available. At the same time, it appears unimplementable using pure Python. Consequently, I'd like to see this patch redone in C. The implementation strategy could probably remain the same, i.e. inherit from tuple for best compatibility; add the remaining fields as slots. It may be reasonable to implement attribute access using a custom getattr function, though. I have also my doubts about the naming of the fields. The st_ prefix originates from the time where struct fields were living in the global namespace (i.e. across different structures), so prefixing them for uniqueness was essential. I'm not sure whether we should inherit this into Python... ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 13:58 Message: Logged In: YES user_id=499 BTW, if this gets in, I have another patch that adds support for st_blksize, st_blocks, and st_rdev on platforms that support them. It don't expose these new fields in the tuple, as that would break all the old code that tries to unpack all the fields of the tuple. Instead, these fields are only accessible as attributes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 From noreply@sourceforge.net Wed Sep 19 04:29:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Sep 2001 20:29:13 -0700 Subject: [Patches] [ python-Patches-462754 ] no '_d' ending for mingw32 Message-ID: Patches item #462754, was opened at 2001-09-18 20:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462754&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Hдring (ghaering) Assigned to: A.M. Kuchling (akuchling) Summary: no '_d' ending for mingw32 Initial Comment: This patch prevents distutils from naming the extension modules _d.pyd when compiled with mingw32 on Windows in debug mode. Instead, the extension modules will get the normal name .pyd. Technically, the patch doesn't prevent the behaviour for mingw32, but only adds the _d for MS Visual C++ and Borland compilers (though I don't know about the Borland case). The reason for this? Adding "_d" doesn't make any sense for GNU compilers. I think it's just a MS Visual C++ madness. If you want to debug an extension module that was compiled with gcc, you have to use gdb anyway, because the debugging symbols of MSVC++ and gcc are incompatible. So you normally use a release Python version (from the python.org binary download) and compile your extensions with mingw32. To put it shortly: The current state is that you do a "setup.py build --compiler=mingw32 --debug" and then rename the extension modules, removing the _d. Then fire up gdb to debug your module. With this patch, the renaming isn't necessary anymore. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462754&group_id=5470 From noreply@sourceforge.net Wed Sep 19 04:44:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Sep 2001 20:44:25 -0700 Subject: [Patches] [ python-Patches-461337 ] Docs for SSL methods and objects Message-ID: Patches item #461337, was opened at 2001-09-13 13:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461337&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Hдring (ghaering) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Docs for SSL methods and objects Initial Comment: This is my try to fix bug #215026. Perhaps a link to the OpenSSL homepage should be added somewhere (so we don't have to explain all that private key and certificate stuff in the docs ourselves). I also think it should be indicated somewhere, that Python's SSL implementation is incomplete, not to be considered secure (certificates aren't checked) and thus (at least I hope so :-), likely to be changed in the future. Did I already say that the SSL stuff looks quite broken? ---------------------------------------------------------------------- >Comment By: Gerhard Hдring (ghaering) Date: 2001-09-18 20:44 Message: Logged In: YES user_id=163326 Please disregard my last comment. socket_ssl_doc.dif contains the right documentation fixes. The arguments to ssl() are *not* optional. ---------------------------------------------------------------------- Comment By: Gerhard Hдring (ghaering) Date: 2001-09-13 18:05 Message: Logged In: YES user_id=163326 I've updated the patch: in fact for the ssl() method the combination of (keyfile, certfile) is optional. That is, either supply both or none of these arguments. Nevertheless, a check of certificates doesn't take place in either case, that's why I added a "WARNING" to the ssl() function's documentation. ---------------------------------------------------------------------- Comment By: Gerhard Hдring (ghaering) Date: 2001-09-13 14:17 Message: Logged In: YES user_id=163326 Well, I don't fully understand the code either (and just know the basics about sockets and OpenSSL). With incomplete, I mean that it would be nice if the SSLObject were compatible to a socket object and thus interchangeable. This is currently not the case. Sockets have send() and recv() while the SSLObject has read() and write(). Another possibility would be to make the SSLObject a "file-like object". As for why I think it's broken: The ssl() method requires that you provide it with a private key file and a certficate key store (that contains known certifictates of Certificate Authorities (Verisign, ...) and server certificates). But it looks like the code doesn't check the certificates at all, and a forged certificate is silently ignored, even if it could be detected. I'm mainly drawing my conclusion from this line of code and the OpenSSL documentation for this function (socketmodule.c; newSSLObject()): SSL_CTX_set_verify(self->ctx, SSL_VERIFY_NONE, NULL); /* set verify lvl */ I'll try to look further into this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 13:39 Message: Logged In: YES user_id=6380 Thanks for the feedback, Gerhard. Unfortunately this code was donated and nobody at PythonLabs understands it enough to fix it. Do you want to help? At least tell us what you think "looks quite broken". If you know how to fix it, that would be great! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461337&group_id=5470 From noreply@sourceforge.net Wed Sep 19 04:46:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Sep 2001 20:46:28 -0700 Subject: [Patches] [ python-Patches-462754 ] no '_d' ending for mingw32 Message-ID: Patches item #462754, was opened at 2001-09-18 20:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462754&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Hдring (ghaering) Assigned to: A.M. Kuchling (akuchling) Summary: no '_d' ending for mingw32 Initial Comment: This patch prevents distutils from naming the extension modules _d.pyd when compiled with mingw32 on Windows in debug mode. Instead, the extension modules will get the normal name .pyd. Technically, the patch doesn't prevent the behaviour for mingw32, but only adds the _d for MS Visual C++ and Borland compilers (though I don't know about the Borland case). The reason for this? Adding "_d" doesn't make any sense for GNU compilers. I think it's just a MS Visual C++ madness. If you want to debug an extension module that was compiled with gcc, you have to use gdb anyway, because the debugging symbols of MSVC++ and gcc are incompatible. So you normally use a release Python version (from the python.org binary download) and compile your extensions with mingw32. To put it shortly: The current state is that you do a "setup.py build --compiler=mingw32 --debug" and then rename the extension modules, removing the _d. Then fire up gdb to debug your module. With this patch, the renaming isn't necessary anymore. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-09-18 20:46 Message: Logged In: YES user_id=31435 FYI, MSVC never adds _d on its own -- Mark Hammond and/or Guido forced it to do that. I don't remember why, but one of them explained it to me long ago and it made good sense at the time . MSCV normally compiles debug and release builds into distinct subdirectories, and uses the same names in both. But *our* MSVC setup forces it to compile both flavors of build directly into the PCbuild directory, so has to give the resulting DLLs and executables different names (else the second build would overwrite the results of the first build). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462754&group_id=5470 From noreply@sourceforge.net Wed Sep 19 05:03:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Sep 2001 21:03:50 -0700 Subject: [Patches] [ python-Patches-462759 ] socketmodule.c: SSL bugfixes Message-ID: Patches item #462759, was opened at 2001-09-18 21:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462759&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Hдring (ghaering) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule.c: SSL bugfixes Initial Comment: This patch fixes the following bugs: #461358: SSL constructor/destructor bugs #461353: SSL write doesn't check return codes #461350: SSL support crashes python It also adds more reliable error checking to the SSL methods. And it tries to clean up the code by removing unused variables, for example. I'm an OpenSSL newbie myself, so a code review definitely won't hurt. I'll also try myself if I can talk some OpenSSL experts into reviewing it. As for testcases, Python currently doesn't offer server-side SSL functionality, so any serious client-server testing isn't possible at the moment. I'm also unsure whether patch #452110, that adds this should be added in the current form. I'd rather see a seperate new sslmodule.c that implements something largely interface compatible with socketmodule.c, i. e. with .recv(), .makefile() and all the rest. This would, however, require a serious effort. I doubt that a new SSL implementation could be implemented in a stable way for Python 2.2. The new sslmodule.c could be a combination of the above mentioned patch, the BSD-licensed Python-OpenSSL modules and perhaps some of the current code. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462759&group_id=5470 From noreply@sourceforge.net Wed Sep 19 05:06:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Sep 2001 21:06:39 -0700 Subject: [Patches] [ python-Patches-462759 ] socketmodule.c: SSL bugfixes Message-ID: Patches item #462759, was opened at 2001-09-18 21:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462759&group_id=5470 Category: Modules Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Gerhard Hдring (ghaering) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule.c: SSL bugfixes Initial Comment: This patch fixes the following bugs: #461358: SSL constructor/destructor bugs #461353: SSL write doesn't check return codes #461350: SSL support crashes python It also adds more reliable error checking to the SSL methods. And it tries to clean up the code by removing unused variables, for example. I'm an OpenSSL newbie myself, so a code review definitely won't hurt. I'll also try myself if I can talk some OpenSSL experts into reviewing it. As for testcases, Python currently doesn't offer server-side SSL functionality, so any serious client-server testing isn't possible at the moment. I'm also unsure whether patch #452110, that adds this should be added in the current form. I'd rather see a seperate new sslmodule.c that implements something largely interface compatible with socketmodule.c, i. e. with .recv(), .makefile() and all the rest. This would, however, require a serious effort. I doubt that a new SSL implementation could be implemented in a stable way for Python 2.2. The new sslmodule.c could be a combination of the above mentioned patch, the BSD-licensed Python-OpenSSL modules and perhaps some of the current code. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462759&group_id=5470 From noreply@sourceforge.net Wed Sep 19 07:52:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Sep 2001 23:52:06 -0700 Subject: [Patches] [ python-Patches-462296 ] Add attributes to os.stat results Message-ID: Patches item #462296, was opened at 2001-09-17 10:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Add attributes to os.stat results Initial Comment: See bug #111481, and PEP 0042. Both suggest that the return values for os.{stat,lstat,statvfs,fstatvfs} ought to be struct-like objects rather than simple tuples. With this patch, the os module will modify the aformentioned functions so that their results still obey the previous tuple protocol, but now have read-only attributes as well. In other words, "os.stat('filename')[0]" is now synonymous with "os.stat('filename').st_mode. The patch also modifies test_os.py to test the new behavior. In order to prevent old code from breaking, these new return types extend tuple. They also use the new attribute descriptor interface. (Thanks for PEP-025[23], Guido!) Backward compatibility: Code will only break if it assumes that type(os.stat(...)) == TupleType, or if it assumes that os.stat(...) has no attributes beyond those defined in tuple. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-18 23:52 Message: Logged In: YES user_id=21627 Using posix.stat is common, see http://groups.yahoo.com/group/python-list/message/4349 http://www.washington.edu/computing/training/125/mkdoc.html http://groups.google.com/groups?th=7d7d118fed161e0&seekm=5qdjch%24dci%40nntp6.u.washington.edu for examples. None of these would break with your change, though, since they don't rely on the lenght of the tuple. If you are going to implement the type in C, I'd put it in the posix module. If you are going to implement it in Python (and only use it from the Posix module), making it general-purpose may be desirable. However, a number of things would need to be considered, so a PEP might be appropriate. If that is done, I'd propose an interface like tuple_with_attrs((value-tuple), (tuple-of-field-names), exposed-length-of-tuple)) ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-18 14:11 Message: Logged In: YES user_id=499 Ah! Now I see. I hadn't realized that anybody used the posix module directly. (People really do this?) I'll try to write up a patch in C tonight or tomorrow morning. A couple of questions on which I could use advice: (1) Where is the proper place to put this kind of tuple-with-fields hybrid? Modules? Objects? In a new file or an existing one? (2) Should I try to make it general enough for non-stat use? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-18 00:54 Message: Logged In: YES user_id=21627 The problem with your second and third patch is that it includes an incompatibility for users of posix.stat (and friends), since it changes the siye of the tuple. If you want to continue to return a tuple (as the top-level data structure), you'll break compatibility for applications using the C module directly. An example of code that would be broken is mode, ino, dev, nlink, uid, gid, size, a, c, m = posix.stat(filename) To pass the additional fields, you already need your class _StatResult available in C. You may find a way to define it in Python and use it in C, but that has proven to be very fragile in the past. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-17 18:54 Message: Logged In: YES user_id=6380 Haven't had time to review the patch yet, but the idea of providing a structure with fields that doubles as a tuple is a good one. It's been tried before and can be done in pure Python as well. Regarding the field names: I think the field names should keep their st_ prefix -- IMO this makes the code more recognizable and hence readable. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 17:32 Message: Logged In: YES user_id=499 Here's the revised (*example only*) patch that takes the more portable approach I mention below. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 16:10 Message: Logged In: YES user_id=499 On further consideration, the approach taken in the second (*example only*) patch is indeed too fragile. The C code should not lengthen the tuple arbitrarily and depend on the Python code to decode it; instead, it should return a dictionary of extra fields. I think that this approach uses a minimum of C, is easily maintainable, and very extensible. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 15:53 Message: Logged In: YES user_id=499 Martin: I'm not entirely sure what you mean here; while my patch for extra fields requires a minor chunk of C (to access the struct fields), the rest still works in pure python. I'm attaching this second version for reference. I'm not sure it makes much sense to do this with pure C; it would certainly take a lot more code, with little benefit I can descern. But you're more experienced than I; what am I missing? I agree that the field naming is suboptimal; I was taking my lead from the stat and statvfs modules. If people prefer, we can name the fields whatever we like. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-17 15:24 Message: Logged In: YES user_id=21627 I second the request for supporting additional fields where available. At the same time, it appears unimplementable using pure Python. Consequently, I'd like to see this patch redone in C. The implementation strategy could probably remain the same, i.e. inherit from tuple for best compatibility; add the remaining fields as slots. It may be reasonable to implement attribute access using a custom getattr function, though. I have also my doubts about the naming of the fields. The st_ prefix originates from the time where struct fields were living in the global namespace (i.e. across different structures), so prefixing them for uniqueness was essential. I'm not sure whether we should inherit this into Python... ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 13:58 Message: Logged In: YES user_id=499 BTW, if this gets in, I have another patch that adds support for st_blksize, st_blocks, and st_rdev on platforms that support them. It don't expose these new fields in the tuple, as that would break all the old code that tries to unpack all the fields of the tuple. Instead, these fields are only accessible as attributes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 From noreply@sourceforge.net Wed Sep 19 10:03:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Sep 2001 02:03:10 -0700 Subject: [Patches] [ python-Patches-462190 ] New C module for quopri assist Message-ID: Patches item #462190, was opened at 2001-09-17 00:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462190&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brandon Long (blong42) >Assigned to: Martin v. Lцwis (loewis) Summary: New C module for quopri assist Initial Comment: This patch adds a new module, quoted, and code in quopri to use this module if it exists. This module implements quoted printable encoding and decoding based on strings in C. This was required by a recent project of mine because 1MB quoted printable mail attachments (sometimes chosen to send PDF and PS data) would take 40+ minutes to encode and decode using the standard quopri python module. ---------------------------------------------------------------------- Comment By: Brandon Long (blong42) Date: 2001-09-18 13:32 Message: Logged In: YES user_id=325633 Ok, this version handles invalid escape sequences the same way, ie by leaving them as they were in the input stream. My original reason for writing this was performance, and the size of the input was already restricted to 1MB, hence the chosen in memory encode/decode. No one is likely to be using the current version for anything even approaching that size given the abysmal performance of the current version. Given that 2.2 adds the decodestring and encodestring versions, maybe we should have both, I'm not sure. The new mimelib module handles mail in memory, instead of using the file like operations of the rfc822 module. *shrug* Using PyString in that fashion I don't think will save anything... as the only external interfaces for that would do a copy on create with PyString_FromStringAndSize(), and then a realloc with the PyString_Resize() (though I could be missing something in there). ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-18 11:46 Message: Logged In: YES user_id=21627 The patch looks good to me. A couple of comments that may be worth consideration: - if backwards compatibility is an objective, boundary cases should be analysed in more detail. E.g. it appears that the case of invalid escape sequences (=EI) is handled differently. - the new module, when encoding one file into anothher, reads all data, whereas the old one would read line by line. Is that change desirable? - the C code could avoid copying the string if it allocated a PyString right away, and adjusted it with _Resize when it is done. ---------------------------------------------------------------------- Comment By: Brandon Long (blong42) Date: 2001-09-17 15:31 Message: Logged In: YES user_id=325633 Ok, this new patch adds the code to binascii, b2a_qp and a2b_qp. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-17 07:22 Message: Logged In: YES user_id=6380 It would make more sense to add this as another pair of encodings to the binascii module, which provides similar support for binhex, base64, and uuencode. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462190&group_id=5470 From noreply@sourceforge.net Wed Sep 19 13:24:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Sep 2001 05:24:35 -0700 Subject: [Patches] [ python-Patches-462849 ] Printing arbitrary Unicode strings Message-ID: Patches item #462849, was opened at 2001-09-19 05:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462849&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Lцwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Printing arbitrary Unicode strings Initial Comment: This patches arranges that print u"something with funny characters" passes the Unicode string to the file's write method, rather than insisting that it is converted to a string. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462849&group_id=5470 From noreply@sourceforge.net Wed Sep 19 14:29:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Sep 2001 06:29:09 -0700 Subject: [Patches] [ python-Patches-462849 ] Printing arbitrary Unicode strings Message-ID: Patches item #462849, was opened at 2001-09-19 05:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462849&group_id=5470 Category: Core (C code) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Martin v. Lцwis (loewis) >Assigned to: Martin v. Lцwis (loewis) Summary: Printing arbitrary Unicode strings Initial Comment: This patches arranges that print u"something with funny characters" passes the Unicode string to the file's write method, rather than insisting that it is converted to a string. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-19 06:29 Message: Logged In: YES user_id=6380 Looks fine to me, so check it in. Please also add a note to Misc/NEWS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462849&group_id=5470 From noreply@sourceforge.net Wed Sep 19 14:48:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Sep 2001 06:48:05 -0700 Subject: [Patches] [ python-Patches-462849 ] Printing arbitrary Unicode strings Message-ID: Patches item #462849, was opened at 2001-09-19 05:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462849&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Martin v. Lцwis (loewis) Assigned to: Martin v. Lцwis (loewis) Summary: Printing arbitrary Unicode strings Initial Comment: This patches arranges that print u"something with funny characters" passes the Unicode string to the file's write method, rather than insisting that it is converted to a string. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-19 06:48 Message: Logged In: YES user_id=21627 Committed as fileobject.c 2.127, Misc/NEWS 1.246. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-19 06:29 Message: Logged In: YES user_id=6380 Looks fine to me, so check it in. Please also add a note to Misc/NEWS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462849&group_id=5470 From noreply@sourceforge.net Wed Sep 19 14:48:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Sep 2001 06:48:30 -0700 Subject: [Patches] [ python-Patches-462849 ] Printing arbitrary Unicode strings Message-ID: Patches item #462849, was opened at 2001-09-19 05:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462849&group_id=5470 Category: Core (C code) Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Martin v. Lцwis (loewis) Assigned to: Martin v. Lцwis (loewis) Summary: Printing arbitrary Unicode strings Initial Comment: This patches arranges that print u"something with funny characters" passes the Unicode string to the file's write method, rather than insisting that it is converted to a string. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-19 06:48 Message: Logged In: YES user_id=21627 Committed as fileobject.c 2.127, Misc/NEWS 1.246. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-19 06:29 Message: Logged In: YES user_id=6380 Looks fine to me, so check it in. Please also add a note to Misc/NEWS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462849&group_id=5470 From noreply@sourceforge.net Wed Sep 19 18:32:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Sep 2001 10:32:20 -0700 Subject: [Patches] [ python-Patches-461321 ] Fix timeout=None in asyncore.py Message-ID: Patches item #461321, was opened at 2001-09-13 13:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461321&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Cesar Eduardo Barros (cesarb) Assigned to: Nobody/Anonymous (nobody) Summary: Fix timeout=None in asyncore.py Initial Comment: This patch makes poll2 and poll3 in asyncore.py work when the timeout argument is None instead of a number. The patch is against CVS 1.18 ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-19 10:32 Message: Logged In: YES user_id=21627 Thanks for the patch. I have committed it as asyncore 1.19. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461321&group_id=5470 From noreply@sourceforge.net Wed Sep 19 18:33:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Sep 2001 10:33:00 -0700 Subject: [Patches] [ python-Patches-453199 ] Cosmetic changes to libframework.tex Message-ID: Patches item #453199, was opened at 2001-08-19 21:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453199&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Cosmetic changes to libframework.tex Initial Comment: Most changes here are grammatical or cosmetic, to fit more in line with the documentation guidelines. In a few cases, parameter names were changed to match the source code (important for keyword argument passing). ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-07 16:38 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453199&group_id=5470 From noreply@sourceforge.net Wed Sep 19 18:35:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Sep 2001 10:35:55 -0700 Subject: [Patches] [ python-Patches-452174 ] cgi: new methods: getfirst(), getlist() Message-ID: Patches item #452174, was opened at 2001-08-17 11:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452174&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: cgi: new methods: getfirst(), getlist() Initial Comment: I find very annoying the need to check whether a user checked one or more checkboxes in a form like this: Currently, I must do something like this: value = form.getvalue("item") if type(value) is type([]): # Multiple items checked. else: # One item checked. I added two methods to cgi.py that simplify and make CGI value processing much more readable and intuitive. The first method ALWAYS returns a single value. Even if more values of the same name were posted, this method always returns only the first one, as a string. scalar_value = form.getfirst("item") scalar_value is now: '1' The second method ALWAYS returns a list. If only one value was posted then the method returns a list which contains this one value. list_values = form.getlist("item") list_values is now: ['1', '2'] This allows me to write much more compact code like: for item in form.getlist("item"): do_something() Using the getfirst() method I don't need to worry about a malicious user posting two values in a query string where I expect only one value. Documentation says: "If the submitted form data contains more than one field with the same name, the object retrieved by "form[key]" is not a FieldStorage or MiniFieldStorage instance but a list of such instances. Similarly, in this situation, "form.getvalue(key)" would return a list of strings. If you expect this possibility (i.e., when your HTML form contains multiple fields with the same name), use the type() function to determine whether you have a single instance or a list of instances." That's IMHO wrong - one shouldn't count on a client to provide valid input. If it doesn't, the script crashes. That's bad. So I added these two very simple methods to the FieldStorage class. The patch is against version 2.6 of the cgi.py module. ---------------------------------------------------------------------- Comment By: Tomas Styblo (tripiecz) Date: 2001-08-21 04:49 Message: Logged In: YES user_id=295775 Updated version of this patch is #453691 2001-08-21. This entry is now obsolete. ---------------------------------------------------------------------- Comment By: Tomas Styblo (tripiecz) Date: 2001-08-18 13:28 Message: Logged In: YES user_id=295775 Yes, I am. I'll update also the documentation. Some English native speaker will have to review the result, though ;) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 10:56 Message: Logged In: YES user_id=6380 So are yo gonna upload a new patch or do I have to do everything myself? :-) ---------------------------------------------------------------------- Comment By: Tomas Styblo (tripiecz) Date: 2001-08-17 18:15 Message: Logged In: YES user_id=295775 Sorry for the anonymous posting, I had forgotten to login before I submitted the patch. Of course, you are absolutely true. That's quite a shame I have been completely unaware of this trap for all the months I've been using Python. Thanks for the correction. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-17 11:28 Message: Logged In: YES user_id=6380 Nice idea, but I wouldn't use "default=[]" in the argument list. If the user modifies the list it returns, the default is permanently changed! I suggest that there's no need to allow the user to specify an alternate default for getlist(), so you can just delete this argument and say "return []" in the default case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452174&group_id=5470 From noreply@sourceforge.net Wed Sep 19 18:43:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Sep 2001 10:43:04 -0700 Subject: [Patches] [ python-Patches-462936 ] Improved modulefinder Message-ID: Patches item #462936, was opened at 2001-09-19 10:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462936&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Improved modulefinder Initial Comment: This patch adds two improvements to freeze/modulefinder. 1. ModuleFinder now keeps track of which module is imported by whom. 2. ModuleFinder, when instantiated with the new scan_extdeps=1 argument, tries to track dependencies of builtin and extension modules. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462936&group_id=5470 From noreply@sourceforge.net Wed Sep 19 18:46:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Sep 2001 10:46:24 -0700 Subject: [Patches] [ python-Patches-452232 ] timestamp function for time module Message-ID: Patches item #452232, was opened at 2001-08-17 14:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452232&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gareth Harris (garethharris) Assigned to: Nobody/Anonymous (nobody) Summary: timestamp function for time module Initial Comment: Timestamp creates timestamp strings in ISO or ODBC format in UTC or local timezones. It can also add microseconds where needed. Timestamps are often needed outside database or XML activities, so its proposed location is the time module. timestamp(secs=None,fmt='ISO',TZ=None,fracsec=None): '''Make ISO or ODBC timestamp from [current] time. Parameters: secs= float seconds, else default = time() fmt = 'ISO' use ISO 8601 standard format = "YYYY-MM-DDTHH:MM:SS.mmmmmmZ" Zulu or "YYYY-MM-DDTHH:MM:SS.mmmmmm-hh:mm" local else "YYYY-MM-DD HH:MM:SS.mmmmmm" ODBC TZ = None=GMT/UTC/Zulu, else local time zone fracsec = None, else add microseconds to string ''' Any improvement or standardization is welcome. Gareth Harris gharris@nrao.edu 2001-08-17T21:36:00Z ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-19 10:46 Message: Logged In: YES user_id=21627 Nice patch. If you want to see this included, you should complete it: Decide on location of the function, provide documentation and test cases. As the location, it may be that the calendar module could provide a home, but you may ask in the newsgroup. If you merely wanted to publish this code snippet, I suggest that you find a better home than the Python patch database, e.g. the Cookbook: http://aspn.activestate.com/ASPN/Cookbook/Python There are a number of other places that collect Python snippets; this is just one option. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452232&group_id=5470 From noreply@sourceforge.net Wed Sep 19 18:52:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Sep 2001 10:52:53 -0700 Subject: [Patches] [ python-Patches-452266 ] thread.kill_thread Message-ID: Patches item #452266, was opened at 2001-08-17 17:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Petrone (jpetrone) Assigned to: Guido van Rossum (gvanrossum) Summary: thread.kill_thread Initial Comment: Function to unsafely kill a thread. Implementations are included for posix and nt. If what I have looks reasonable I will add other platforms + docs. I've read Guido's usenet posts on this and understand the reasons against it, but I still think it might be worth having. Thread implementations like the ones in Java and win32 allow it with the caveat that it could result in deadlock, corrupted data, unclaimed resources, bodily harm, etc. Note that it also changes start_new_thread to return the id for the new thread. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-19 10:52 Message: Logged In: YES user_id=21627 One note on killing threads: Part of working "safely" would be that any reference to objects that the thread currently holds is released when the thread is killed. That essentially requires that all C stack frames perform the appropriate Py_DECREFs, which is not feasible through the thread kill mechanisms of the thread libraries (AFAIK). Instead, a Python exception is about the only approach that has a chance of working "safely". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-22 01:21 Message: Logged In: YES user_id=6380 Sending SIGINT may be easy, but that only covers the Unix side. Also, catching it requires more work, interfering with the existing signal handling, so this becomes A Project. (So, yes, the hard part is getting Python to process signals out of the main thread.) Thanks for the new patch! This is a step in the right direction. It came too late to be reviewed for 2.2a2, but I'll try to get it into 2.2a3. ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-08-20 21:21 Message: Logged In: YES user_id=71210 Sending SIGINT to a thread is pretty easy. Is the hard part of killing a thread with signals getting python to process signals outside of the main thread? At any rate, I'm attaching a new patch that returns the thread id from start_new_thread, without any of the kill_thread() stuff. It includes a change to libthread.tex. For platforms I don't really know I just had them return -1 on failure and 0 on success so they at least run. o Solaris, pthreads, pth - returns thread id, tested o NT - returns thread id, (should work, haven't tested after removing kill) o SGI, BeOS - returns thread id, untested o wince, OS/2, LWP, cthread, foobar - returns -1 on failure, 0 on success ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-20 06:01 Message: Logged In: YES user_id=6380 Thanks to Tim for jogging my memory. I think an interruption facility should be a way to send an exception to a thread, similar to KeyboardInterrupt -- the thread can then decide what to do (and since exceptions can happen anyway, the safety guarantee is not violated -- if the application doesn't release locks on exceptions, it is already unsafe). One problem is that it's probably most important to be able to stop a thread while it's blocked for I/O (a socket connect() or recv() from a non-responding host is a typical example). Unfortunately, the only way to do that on Unix is to send a real signal to the thread. On Windows, I have no idea. Note that part of this patch would still be useful: start_new_thread() should return a thread-id. ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-08-19 20:21 Message: Logged In: YES user_id=71210 While I would very much like to have full interruption functionality, I'm not sure how easily it could be done on all platforms. At the least it would be nice to have SOME sort of thread signalling. What guarantees about safety should python make? I've considered trying to add cleanup handlers to release interpreter locks and such, but didn't feel like putting that much effort into a patch that would likely be rejected anyway. I will look into adding cleanup routines if we can establish some requirements. I think I can do it in pthreads pretty easily. Dunno how easy the rest will be. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-19 14:24 Message: Logged In: YES user_id=31435 I've never called TerminateThread() on Win32, and given the dire wngs about it in the MS docs, never will. IMO Python shouldn't be in this business unless it can guarantee to do it safely. But it can't, so -1 from me. Java did get out of this business: What Java has that Python lacks (follow the link) is a way to "interrupt" a thread, and there's nothing that was possible with thread.stop() that isn't possible by building on interruption (although the places where people really want this are places where thread.stop() never worked anyway -- Java never had a gimmick as Draconian as Win32's TerminateThread() -- Java's thread.stop() was "stop if you can, but there are many reasons you may not be able to"). I'd be +1 on a thread interruption facility for Python, which amounts to a way to raise an exception in a different thread. But like Java's facility, it couldn't always guarantee the target thread would respond. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:27 Message: Logged In: YES user_id=6380 Assigned to Tim for review of the Windows code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:01 Message: Logged In: YES user_id=6380 I'm +0 with this, so it can go in if people really want it. (Though isn't this deprecated in Java?) The patch looks very thorough. Some concerns: - Patches for Doc/lib/libthread.tex (don't have to be perfect LaTeX, but must document new functionality). - For other OS thread implementations (e.g. pth, solaris, beos, os2) the thread ID returned by the thread module is always zero. - Some pthread implementations seem to have an issue that the thread-id as we calculate it is not necessarily unique, due to the opaqueness of the pthread_t structure. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 From noreply@sourceforge.net Wed Sep 19 18:53:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Sep 2001 10:53:35 -0700 Subject: [Patches] [ python-Patches-453204 ] GetArgv and ProgressBars (libmacui.tex) Message-ID: Patches item #453204, was opened at 2001-08-19 22:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453204&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: GetArgv and ProgressBars (libmacui.tex) Initial Comment: Documentation for the fairly recently added GetArgv function in Mac/Lib/EasyDialogs.py is included. Also, the documentation for ProgressBar objects has been greatly expanded. Further, many minor changes and corrections have been made throughout. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-19 10:53 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453204&group_id=5470 From noreply@sourceforge.net Wed Sep 19 18:55:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Sep 2001 10:55:45 -0700 Subject: [Patches] [ python-Patches-454790 ] Have getopt handle optional short args Message-ID: Patches item #454790, was opened at 2001-08-23 17:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454790&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: Have getopt handle optional short args Initial Comment: The GNU getopt implementation allows optional args to short arguments - two colons mean an option takes an optional arg; if there is text in the current argv-element, it is returned in optarg, otherwise optarg is set to zero. The attached patch implements this behaviour. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-19 10:55 Message: Logged In: YES user_id=21627 Adding this feature sounds like a good thing. A shallow review of the patch reveals two major problems with it, though: no patches to the documentation, no patches to test_getopt. Would you consider providing these missing pieces? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454790&group_id=5470 From noreply@sourceforge.net Wed Sep 19 19:10:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Sep 2001 11:10:11 -0700 Subject: [Patches] [ python-Patches-462296 ] Add attributes to os.stat results Message-ID: Patches item #462296, was opened at 2001-09-17 10:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Add attributes to os.stat results Initial Comment: See bug #111481, and PEP 0042. Both suggest that the return values for os.{stat,lstat,statvfs,fstatvfs} ought to be struct-like objects rather than simple tuples. With this patch, the os module will modify the aformentioned functions so that their results still obey the previous tuple protocol, but now have read-only attributes as well. In other words, "os.stat('filename')[0]" is now synonymous with "os.stat('filename').st_mode. The patch also modifies test_os.py to test the new behavior. In order to prevent old code from breaking, these new return types extend tuple. They also use the new attribute descriptor interface. (Thanks for PEP-025[23], Guido!) Backward compatibility: Code will only break if it assumes that type(os.stat(...)) == TupleType, or if it assumes that os.stat(...) has no attributes beyond those defined in tuple. ---------------------------------------------------------------------- >Comment By: Nick Mathewson (nickm) Date: 2001-09-19 11:10 Message: Logged In: YES user_id=499 I'm becoming more and more convinced that doing it in C is the right thing, but I have issue with doing it in the posix module. The stat function is provided on (nearly?) all platforms, and doing it in C will require minor changes to all of these modules. We can probably live with this, but I don't think we should duplicate code between all of the os modules. Is there some other appropriate place to put it in C? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-18 23:52 Message: Logged In: YES user_id=21627 Using posix.stat is common, see http://groups.yahoo.com/group/python-list/message/4349 http://www.washington.edu/computing/training/125/mkdoc.html http://groups.google.com/groups?th=7d7d118fed161e0&seekm=5qdjch%24dci%40nntp6.u.washington.edu for examples. None of these would break with your change, though, since they don't rely on the lenght of the tuple. If you are going to implement the type in C, I'd put it in the posix module. If you are going to implement it in Python (and only use it from the Posix module), making it general-purpose may be desirable. However, a number of things would need to be considered, so a PEP might be appropriate. If that is done, I'd propose an interface like tuple_with_attrs((value-tuple), (tuple-of-field-names), exposed-length-of-tuple)) ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-18 14:11 Message: Logged In: YES user_id=499 Ah! Now I see. I hadn't realized that anybody used the posix module directly. (People really do this?) I'll try to write up a patch in C tonight or tomorrow morning. A couple of questions on which I could use advice: (1) Where is the proper place to put this kind of tuple-with-fields hybrid? Modules? Objects? In a new file or an existing one? (2) Should I try to make it general enough for non-stat use? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-18 00:54 Message: Logged In: YES user_id=21627 The problem with your second and third patch is that it includes an incompatibility for users of posix.stat (and friends), since it changes the siye of the tuple. If you want to continue to return a tuple (as the top-level data structure), you'll break compatibility for applications using the C module directly. An example of code that would be broken is mode, ino, dev, nlink, uid, gid, size, a, c, m = posix.stat(filename) To pass the additional fields, you already need your class _StatResult available in C. You may find a way to define it in Python and use it in C, but that has proven to be very fragile in the past. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-17 18:54 Message: Logged In: YES user_id=6380 Haven't had time to review the patch yet, but the idea of providing a structure with fields that doubles as a tuple is a good one. It's been tried before and can be done in pure Python as well. Regarding the field names: I think the field names should keep their st_ prefix -- IMO this makes the code more recognizable and hence readable. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 17:32 Message: Logged In: YES user_id=499 Here's the revised (*example only*) patch that takes the more portable approach I mention below. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 16:10 Message: Logged In: YES user_id=499 On further consideration, the approach taken in the second (*example only*) patch is indeed too fragile. The C code should not lengthen the tuple arbitrarily and depend on the Python code to decode it; instead, it should return a dictionary of extra fields. I think that this approach uses a minimum of C, is easily maintainable, and very extensible. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 15:53 Message: Logged In: YES user_id=499 Martin: I'm not entirely sure what you mean here; while my patch for extra fields requires a minor chunk of C (to access the struct fields), the rest still works in pure python. I'm attaching this second version for reference. I'm not sure it makes much sense to do this with pure C; it would certainly take a lot more code, with little benefit I can descern. But you're more experienced than I; what am I missing? I agree that the field naming is suboptimal; I was taking my lead from the stat and statvfs modules. If people prefer, we can name the fields whatever we like. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-17 15:24 Message: Logged In: YES user_id=21627 I second the request for supporting additional fields where available. At the same time, it appears unimplementable using pure Python. Consequently, I'd like to see this patch redone in C. The implementation strategy could probably remain the same, i.e. inherit from tuple for best compatibility; add the remaining fields as slots. It may be reasonable to implement attribute access using a custom getattr function, though. I have also my doubts about the naming of the fields. The st_ prefix originates from the time where struct fields were living in the global namespace (i.e. across different structures), so prefixing them for uniqueness was essential. I'm not sure whether we should inherit this into Python... ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 13:58 Message: Logged In: YES user_id=499 BTW, if this gets in, I have another patch that adds support for st_blksize, st_blocks, and st_rdev on platforms that support them. It don't expose these new fields in the tuple, as that would break all the old code that tries to unpack all the fields of the tuple. Instead, these fields are only accessible as attributes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 From noreply@sourceforge.net Wed Sep 19 19:36:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Sep 2001 11:36:42 -0700 Subject: [Patches] [ python-Patches-462296 ] Add attributes to os.stat results Message-ID: Patches item #462296, was opened at 2001-09-17 10:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Add attributes to os.stat results Initial Comment: See bug #111481, and PEP 0042. Both suggest that the return values for os.{stat,lstat,statvfs,fstatvfs} ought to be struct-like objects rather than simple tuples. With this patch, the os module will modify the aformentioned functions so that their results still obey the previous tuple protocol, but now have read-only attributes as well. In other words, "os.stat('filename')[0]" is now synonymous with "os.stat('filename').st_mode. The patch also modifies test_os.py to test the new behavior. In order to prevent old code from breaking, these new return types extend tuple. They also use the new attribute descriptor interface. (Thanks for PEP-025[23], Guido!) Backward compatibility: Code will only break if it assumes that type(os.stat(...)) == TupleType, or if it assumes that os.stat(...) has no attributes beyond those defined in tuple. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-19 11:36 Message: Logged In: YES user_id=21627 There aren't actually so many copies of the module, since posixmodule implements "posix","nt", and "os2". I found alternative implementations in riscosmodule and macmodule. Still, putting the support type into a shared C file is appropriate. I can think of two candidate places: tupleobject.c and fileobject.c. It may be actually worthwhile attempting to share the stat() implementations as well, but that could be an add-on. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-19 11:10 Message: Logged In: YES user_id=499 I'm becoming more and more convinced that doing it in C is the right thing, but I have issue with doing it in the posix module. The stat function is provided on (nearly?) all platforms, and doing it in C will require minor changes to all of these modules. We can probably live with this, but I don't think we should duplicate code between all of the os modules. Is there some other appropriate place to put it in C? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-18 23:52 Message: Logged In: YES user_id=21627 Using posix.stat is common, see http://groups.yahoo.com/group/python-list/message/4349 http://www.washington.edu/computing/training/125/mkdoc.html http://groups.google.com/groups?th=7d7d118fed161e0&seekm=5qdjch%24dci%40nntp6.u.washington.edu for examples. None of these would break with your change, though, since they don't rely on the lenght of the tuple. If you are going to implement the type in C, I'd put it in the posix module. If you are going to implement it in Python (and only use it from the Posix module), making it general-purpose may be desirable. However, a number of things would need to be considered, so a PEP might be appropriate. If that is done, I'd propose an interface like tuple_with_attrs((value-tuple), (tuple-of-field-names), exposed-length-of-tuple)) ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-18 14:11 Message: Logged In: YES user_id=499 Ah! Now I see. I hadn't realized that anybody used the posix module directly. (People really do this?) I'll try to write up a patch in C tonight or tomorrow morning. A couple of questions on which I could use advice: (1) Where is the proper place to put this kind of tuple-with-fields hybrid? Modules? Objects? In a new file or an existing one? (2) Should I try to make it general enough for non-stat use? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-18 00:54 Message: Logged In: YES user_id=21627 The problem with your second and third patch is that it includes an incompatibility for users of posix.stat (and friends), since it changes the siye of the tuple. If you want to continue to return a tuple (as the top-level data structure), you'll break compatibility for applications using the C module directly. An example of code that would be broken is mode, ino, dev, nlink, uid, gid, size, a, c, m = posix.stat(filename) To pass the additional fields, you already need your class _StatResult available in C. You may find a way to define it in Python and use it in C, but that has proven to be very fragile in the past. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-17 18:54 Message: Logged In: YES user_id=6380 Haven't had time to review the patch yet, but the idea of providing a structure with fields that doubles as a tuple is a good one. It's been tried before and can be done in pure Python as well. Regarding the field names: I think the field names should keep their st_ prefix -- IMO this makes the code more recognizable and hence readable. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 17:32 Message: Logged In: YES user_id=499 Here's the revised (*example only*) patch that takes the more portable approach I mention below. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 16:10 Message: Logged In: YES user_id=499 On further consideration, the approach taken in the second (*example only*) patch is indeed too fragile. The C code should not lengthen the tuple arbitrarily and depend on the Python code to decode it; instead, it should return a dictionary of extra fields. I think that this approach uses a minimum of C, is easily maintainable, and very extensible. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 15:53 Message: Logged In: YES user_id=499 Martin: I'm not entirely sure what you mean here; while my patch for extra fields requires a minor chunk of C (to access the struct fields), the rest still works in pure python. I'm attaching this second version for reference. I'm not sure it makes much sense to do this with pure C; it would certainly take a lot more code, with little benefit I can descern. But you're more experienced than I; what am I missing? I agree that the field naming is suboptimal; I was taking my lead from the stat and statvfs modules. If people prefer, we can name the fields whatever we like. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-17 15:24 Message: Logged In: YES user_id=21627 I second the request for supporting additional fields where available. At the same time, it appears unimplementable using pure Python. Consequently, I'd like to see this patch redone in C. The implementation strategy could probably remain the same, i.e. inherit from tuple for best compatibility; add the remaining fields as slots. It may be reasonable to implement attribute access using a custom getattr function, though. I have also my doubts about the naming of the fields. The st_ prefix originates from the time where struct fields were living in the global namespace (i.e. across different structures), so prefixing them for uniqueness was essential. I'm not sure whether we should inherit this into Python... ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 13:58 Message: Logged In: YES user_id=499 BTW, if this gets in, I have another patch that adds support for st_blksize, st_blocks, and st_rdev on platforms that support them. It don't expose these new fields in the tuple, as that would break all the old code that tries to unpack all the fields of the tuple. Instead, these fields are only accessible as attributes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 From noreply@sourceforge.net Wed Sep 19 20:01:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Sep 2001 12:01:46 -0700 Subject: [Patches] [ python-Patches-449973 ] Useful call method on base class. Message-ID: Patches item #449973, was opened at 2001-08-10 18:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449973&group_id=5470 Category: XML Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Prescod (prescod) Assigned to: Fredrik Lundh (effbot) Summary: Useful call method on base class. Initial Comment: Most XML-RPC servers out there use a call method that dispatches XML-RPC method names to Python methods automatically. Because this behaviour is so common, I think it should be default behaviour. There will be a few cases where this behaviour is NOT appropriate but neither is the current behaviour. i.e. I am trying to reduce the necessity to subclass call, not completely remove it. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-19 12:01 Message: Logged In: YES user_id=21627 Why is it desirable to pass the method name as the first argument? Why are the other arguments not passed as *args? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449973&group_id=5470 From noreply@sourceforge.net Wed Sep 19 21:22:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Sep 2001 13:22:19 -0700 Subject: [Patches] [ python-Patches-462122 ] add readline startup and pre_event hooks Message-ID: Patches item #462122, was opened at 2001-09-16 16:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462122&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) >Assigned to: Martin v. Lцwis (loewis) Summary: add readline startup and pre_event hooks Initial Comment: Adds support for the readline rl_startup_hook and rl_pre_event_hook callbacks. For example, the startup hook can be used to insert text to begin editing rather than always starting with a blank entry. I just added the pre_event hook too since it was there. Supporting rl_event_hook could be done too, but its already set to PyOS_InputHook and I'm not sure what significance this has or if it could just be called in addition to that. In order to avoid too much code dupe I moved some stuff into a generic hook setter func. However I'm not 100% sure of the thread state stuff, if it really needs to store a seperate one per each hook or if it should only store one. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462122&group_id=5470 From noreply@sourceforge.net Wed Sep 19 21:28:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Sep 2001 13:28:57 -0700 Subject: [Patches] [ python-Patches-462936 ] Improved modulefinder Message-ID: Patches item #462936, was opened at 2001-09-19 10:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462936&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Improved modulefinder Initial Comment: This patch adds two improvements to freeze/modulefinder. 1. ModuleFinder now keeps track of which module is imported by whom. 2. ModuleFinder, when instantiated with the new scan_extdeps=1 argument, tries to track dependencies of builtin and extension modules. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-19 13:28 Message: Logged In: YES user_id=21627 I dislike the chunk on finding external dependencies. What is the typical use case (i.e. what module has what external dependencies)? It seems easier to hard-code knowledge about external dependencies into ModuleFinder; this hard-coded knowledge should cover all core modules. In addition, there should be an API to extend this knowledge for non-standard modules. Furthermore, by executing an import, you cannot be sure that you really find all dependencies - some may only show up when a certain function is used. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462936&group_id=5470 From noreply@sourceforge.net Wed Sep 19 22:03:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Sep 2001 14:03:52 -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: Martin v. Lцwis (loewis) Date: 2001-09-19 14:03 Message: Logged In: YES user_id=21627 It appears that the C++ fragment is broken and does not work as intended. Apparently, PyCppFunction is a member pointer, which is intended to be passed through to the invocation of pycfunction. However, AFAICT, addmethod converts the pointer-to-member-function into a void* before passing it into the methoddefs. This C++ code has undefined behaviour: there is no guarantee that a pointer-to-member can fit into a void*. In fact, on g++, a pointer-to-member is larger than a void* (8 bytes on a 32-bit machine). It may be possible to fix this. However, I think there are much more issues to integrating C++ classes into Python; such a class structure would add little if any value. Therefore, I'm in favour of rejecting this patch. ---------------------------------------------------------------------- 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 Thu Sep 20 05:35:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Sep 2001 21:35:26 -0700 Subject: [Patches] [ python-Patches-462296 ] Add attributes to os.stat results Message-ID: Patches item #462296, was opened at 2001-09-17 10:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Add attributes to os.stat results Initial Comment: See bug #111481, and PEP 0042. Both suggest that the return values for os.{stat,lstat,statvfs,fstatvfs} ought to be struct-like objects rather than simple tuples. With this patch, the os module will modify the aformentioned functions so that their results still obey the previous tuple protocol, but now have read-only attributes as well. In other words, "os.stat('filename')[0]" is now synonymous with "os.stat('filename').st_mode. The patch also modifies test_os.py to test the new behavior. In order to prevent old code from breaking, these new return types extend tuple. They also use the new attribute descriptor interface. (Thanks for PEP-025[23], Guido!) Backward compatibility: Code will only break if it assumes that type(os.stat(...)) == TupleType, or if it assumes that os.stat(...) has no attributes beyond those defined in tuple. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-19 21:35 Message: Logged In: YES user_id=6380 Or you could put it in modsupport.c, which is already a grab-bag of handy stuff. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-19 11:36 Message: Logged In: YES user_id=21627 There aren't actually so many copies of the module, since posixmodule implements "posix","nt", and "os2". I found alternative implementations in riscosmodule and macmodule. Still, putting the support type into a shared C file is appropriate. I can think of two candidate places: tupleobject.c and fileobject.c. It may be actually worthwhile attempting to share the stat() implementations as well, but that could be an add-on. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-19 11:10 Message: Logged In: YES user_id=499 I'm becoming more and more convinced that doing it in C is the right thing, but I have issue with doing it in the posix module. The stat function is provided on (nearly?) all platforms, and doing it in C will require minor changes to all of these modules. We can probably live with this, but I don't think we should duplicate code between all of the os modules. Is there some other appropriate place to put it in C? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-18 23:52 Message: Logged In: YES user_id=21627 Using posix.stat is common, see http://groups.yahoo.com/group/python-list/message/4349 http://www.washington.edu/computing/training/125/mkdoc.html http://groups.google.com/groups?th=7d7d118fed161e0&seekm=5qdjch%24dci%40nntp6.u.washington.edu for examples. None of these would break with your change, though, since they don't rely on the lenght of the tuple. If you are going to implement the type in C, I'd put it in the posix module. If you are going to implement it in Python (and only use it from the Posix module), making it general-purpose may be desirable. However, a number of things would need to be considered, so a PEP might be appropriate. If that is done, I'd propose an interface like tuple_with_attrs((value-tuple), (tuple-of-field-names), exposed-length-of-tuple)) ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-18 14:11 Message: Logged In: YES user_id=499 Ah! Now I see. I hadn't realized that anybody used the posix module directly. (People really do this?) I'll try to write up a patch in C tonight or tomorrow morning. A couple of questions on which I could use advice: (1) Where is the proper place to put this kind of tuple-with-fields hybrid? Modules? Objects? In a new file or an existing one? (2) Should I try to make it general enough for non-stat use? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-18 00:54 Message: Logged In: YES user_id=21627 The problem with your second and third patch is that it includes an incompatibility for users of posix.stat (and friends), since it changes the siye of the tuple. If you want to continue to return a tuple (as the top-level data structure), you'll break compatibility for applications using the C module directly. An example of code that would be broken is mode, ino, dev, nlink, uid, gid, size, a, c, m = posix.stat(filename) To pass the additional fields, you already need your class _StatResult available in C. You may find a way to define it in Python and use it in C, but that has proven to be very fragile in the past. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-17 18:54 Message: Logged In: YES user_id=6380 Haven't had time to review the patch yet, but the idea of providing a structure with fields that doubles as a tuple is a good one. It's been tried before and can be done in pure Python as well. Regarding the field names: I think the field names should keep their st_ prefix -- IMO this makes the code more recognizable and hence readable. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 17:32 Message: Logged In: YES user_id=499 Here's the revised (*example only*) patch that takes the more portable approach I mention below. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 16:10 Message: Logged In: YES user_id=499 On further consideration, the approach taken in the second (*example only*) patch is indeed too fragile. The C code should not lengthen the tuple arbitrarily and depend on the Python code to decode it; instead, it should return a dictionary of extra fields. I think that this approach uses a minimum of C, is easily maintainable, and very extensible. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 15:53 Message: Logged In: YES user_id=499 Martin: I'm not entirely sure what you mean here; while my patch for extra fields requires a minor chunk of C (to access the struct fields), the rest still works in pure python. I'm attaching this second version for reference. I'm not sure it makes much sense to do this with pure C; it would certainly take a lot more code, with little benefit I can descern. But you're more experienced than I; what am I missing? I agree that the field naming is suboptimal; I was taking my lead from the stat and statvfs modules. If people prefer, we can name the fields whatever we like. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-17 15:24 Message: Logged In: YES user_id=21627 I second the request for supporting additional fields where available. At the same time, it appears unimplementable using pure Python. Consequently, I'd like to see this patch redone in C. The implementation strategy could probably remain the same, i.e. inherit from tuple for best compatibility; add the remaining fields as slots. It may be reasonable to implement attribute access using a custom getattr function, though. I have also my doubts about the naming of the fields. The st_ prefix originates from the time where struct fields were living in the global namespace (i.e. across different structures), so prefixing them for uniqueness was essential. I'm not sure whether we should inherit this into Python... ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 13:58 Message: Logged In: YES user_id=499 BTW, if this gets in, I have another patch that adds support for st_blksize, st_blocks, and st_rdev on platforms that support them. It don't expose these new fields in the tuple, as that would break all the old code that tries to unpack all the fields of the tuple. Instead, these fields are only accessible as attributes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 From noreply@sourceforge.net Thu Sep 20 10:08:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Sep 2001 02:08:19 -0700 Subject: [Patches] [ python-Patches-415226 ] new base class for binary packaging Message-ID: Patches item #415226, was opened at 2001-04-10 12:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415226&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Alexander (mwa) Assigned to: A.M. Kuchling (akuchling) Summary: new base class for binary packaging Initial Comment: bdist_packager.py provides an abstract base class for bdist commands. It provides easy access to all the PEP 241 metadata fields, plus "revision" for the package revision and installation scripts for preinstall, postinstall preremove, and postremove. That covers the base characteristics of all the package managers that I'm familiar with. If anyone can think of any others, let me know, otherwise additional extensions would be implemented in the specific packager's commands. I would, however, discourage _requiring_ any additional fields. It would be nice if by simply supplying the PEP241 metadata under the [bdist_packager] section all subclassed packagers worked with no further effort. It also has rudimentary relocation support by including a --no-autorelocate option. The bdist_packager is also where I see creating seperate binary packages for sub-packages supported. My need for that is much less than my desire for it right now, so I didn't give it much thought as I wrote it. I'd be delighted to hear any comments and suggestions on how to approach sub-packaging, though. ---------------------------------------------------------------------- Comment By: david arnold (dja) Date: 2001-09-20 02:08 Message: Logged In: YES user_id=78574 i recently struck a case where i wanted the ability to run a post-install script on Windows (from a bdist_wininst-produced package). while i agree with what seems to be the basic intention of this patch, wouldn't it be more useful to have the various scripts run by the Python interpreter, rather than Bourne shell (which is extremely seldom available on Windows, MacOS, etc) ? i went looking for the source of the .exe file embedded in the wininst command, but couldn't find it. does anyone know where it lives? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-06-06 22:33 Message: Logged In: YES user_id=21627 Shouldn't the patch also modify the existing bdist commands to use this as a base class? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415226&group_id=5470 From noreply@sourceforge.net Thu Sep 20 10:42:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Sep 2001 02:42:07 -0700 Subject: [Patches] [ python-Patches-462936 ] Improved modulefinder Message-ID: Patches item #462936, was opened at 2001-09-19 10:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462936&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Improved modulefinder Initial Comment: This patch adds two improvements to freeze/modulefinder. 1. ModuleFinder now keeps track of which module is imported by whom. 2. ModuleFinder, when instantiated with the new scan_extdeps=1 argument, tries to track dependencies of builtin and extension modules. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2001-09-20 02:42 Message: Logged In: YES user_id=11105 The use case is to find as much dependencies as possible. Sure, you cannot assume that importing an extension module finds all dependencies - only those which are executed inside the initmodule function. OTOH, this covers a *lot* of problematic cases, pygame and numpy for example. The situation is (somewhat) similar to finding dependencies of python modules - only those donewith normal import statements are found, __import__, eval, or exec is not handled. A possible solution would be to run the script in 'profiling mode', where the script is actually run, and all imports are monitored. This is however far beyond ModuleFinder's scope. Hardcoding the knowledge about dependencies into ModuleFinder for the core modules would be possible although inelegant IMO. An API for non-standard modules would be possible, but how should this be used without executing any code? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-19 13:28 Message: Logged In: YES user_id=21627 I dislike the chunk on finding external dependencies. What is the typical use case (i.e. what module has what external dependencies)? It seems easier to hard-code knowledge about external dependencies into ModuleFinder; this hard-coded knowledge should cover all core modules. In addition, there should be an API to extend this knowledge for non-standard modules. Furthermore, by executing an import, you cannot be sure that you really find all dependencies - some may only show up when a certain function is used. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462936&group_id=5470 From noreply@sourceforge.net Thu Sep 20 11:34:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Sep 2001 03:34:49 -0700 Subject: [Patches] [ python-Patches-462635 ] Fix bugs in new encodings Message-ID: Patches item #462635, was opened at 2001-09-18 12:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462635&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 6 Submitted By: A.M. Kuchling (akuchling) Assigned to: M.-A. Lemburg (lemburg) Summary: Fix bugs in new encodings Initial Comment: Attempting to open a stream using the new uu/zlib/base64/etc encodings doesn't work. >>> import codecs >>> f=codecs.open('foo.gz', 'wb', encoding='zlib') >>> f.write('Output goes here. ' * 10) Traceback (most recent call last): File "", line 1, in ? File "/home/akuchlin/src/python/Lib/codecs.py", line 338, in write return self.writer.write(data) File "/home/akuchlin/src/python/Lib/codecs.py", line 137, in write data, consumed = self.encode(object, self.errors) TypeError: zlib_encode() takes at most 2 arguments (3 given) Python is returning a bound method for self.encode, so it's short by one argument. The supplied patch fixes this; there should also be a test case added to the test suite to exercise this code. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462635&group_id=5470 From noreply@sourceforge.net Thu Sep 20 11:36:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Sep 2001 03:36:49 -0700 Subject: [Patches] [ python-Patches-435971 ] Adds a UTF-7 codec Message-ID: Patches item #435971, was opened at 2001-06-24 19:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=435971&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: M.-A. Lemburg (lemburg) Summary: Adds a UTF-7 codec Initial Comment: This code adds UTF-7 (as described in RFC2152) support to Python. The encoder is hardwired in _codecsmodule.c to not encode allowable whitespace and set O characters (see RFC2152). If there is a standardized way (keyword arguments?) of passing optional arguments to encode methods, it would be trivial to make it possible to do so. Otherwise the patch is pretty straight-forward, I think. It touches: Objects/unicodeobject.c Modules/_codecsmodule.c Lib/test/test_unicode.py Include/unicodeobject.h and adds a new file: Lib/encodings/utf_7.py ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-09-20 03:36 Message: Logged In: YES user_id=38388 I've checked in the patch. Please upload the updates you have in mind as new patch. Thanks. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-08-10 18:19 Message: Logged In: YES user_id=108973 Have you had a chance to review this patch yet? If it looks ok to you then I will update it to include an optional arguments specifying if set O characters should be encoded. I'll also make it work with 32-bit unichars. Otherwise I won't bother because I don't need that for my own use. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-06-25 11:10 Message: Logged In: YES user_id=108973 OK, I see the utf-16 example. In a few weeks, when I have some time again, I might do the necessary changes and testing. It might even be nice to be able to specify a list of characters to escape, if they are dangerous for your application (of maybe it's just morning featuritis :-)). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-25 04:24 Message: Logged In: YES user_id=38388 encode functions can have optionl arguments (see for example the utf-16 codec or the charmap codec). They don't need to be keyword arguments although this would make them easier to handle in case we should ever want to change the API. I'll look at the patch more closely later this week or today. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=435971&group_id=5470 From noreply@sourceforge.net Thu Sep 20 11:38:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Sep 2001 03:38:26 -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: Postponed 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-09-20 03:38 Message: Logged In: YES user_id=38388 I am postponing this patch until the PEP process has started. This feature won't make it into Python 2.2. Walter, you may want to reference this patch in the PEP. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-16 03:53 Message: Logged In: YES user_id=38388 I think we ought to summarize these changes in a PEP to get some more feedback and testing from others as well. I'll look into this after I'm back from vacation on the 10.09. Given the release schedule I am not sure whether this feature will make it into 2.2. The size of the patch is huge and probably needs a lot of testing first. ---------------------------------------------------------------------- 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 Thu Sep 20 11:51:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Sep 2001 03:51:56 -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: M.-A. Lemburg (lemburg) Date: 2001-09-20 03:51 Message: Logged In: YES user_id=38388 I like the idea since it synchronizes str() and unicode() in terms of semantics. The patch is too radical though: the str() approach should only be used if everything else fails. ---------------------------------------------------------------------- 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 Sep 20 11:56:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Sep 2001 03:56:06 -0700 Subject: [Patches] [ python-Patches-446754 ] Enhanced unicode constructor Message-ID: Patches item #446754, was opened at 2001-08-01 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Walter Dцrwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: Enhanced unicode constructor Initial Comment: This patch (against descr-branch) uses a slightly enhanced version of PyObject_Unicode instead of PyUnicode_FromEncodedObject in the unicode constructor (Objects/unicodeobject.h/unicode_new), which gives the unicode constructor the same functionality as the str constructor: creating string representations with the __str__ method/tp_str slot. Example: Python 2.2a1 (#10, Aug 1 2001, 14:26:06) [GCC 2.95.2 19991024 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> str("u"), unicode("u") ('u', u'u') >>> str(u"u"), unicode(u"u") ('u', u'u') >>> str(None), unicode(None) ('None', u'None') >>> str(42), unicode(42) ('42', u'42') >>> str(23.), unicode(23.) ('23.0', u'23.0') >>> str([1,2,3]), unicode([1,2,3]) ('[1, 2, 3]', u'[1, 2, 3]') >>> str({"u": 23, u"ь": 42}), unicode({"u": 23, u"ь": 42}) ("{'u': 23, u'\xfc': 42}", u"{'u': 23, u'\\xfc': 42}") >>> class foo: ... def __init__(self, x): ... self.x = x ... def __str__(self): ... return self.x ... >>> str(foo("bar")), unicode(foo("bar")) ('bar', u'bar') >>> str(foo(u"bar")), unicode(foo(u"bar")) ('bar', u'bar') Passing the encoding and errors argument still works and the will be used for any 8bit string returned from __str__. Perhaps for symmetry encoding and errors arguments should be added to the str constructor too, which will be used when a unicode object is returned from __str__ for encoding the object. One problem is that unicode([u"ь"]) returns u"[u'\\xfc']" because __repr__ returns a 8bit escape encoded string, it would be better if the result was u"[u'\xfc']", but this would require a PyObject_UnicodeRepr (and/or changing the list tp_str slot (and many others) to return Unicode) ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-09-20 03:56 Message: Logged In: YES user_id=38388 Rejecting this patch: see patch #413333 -- this is basically the same request and the patch is not usable since it breaks the Unicode C API. I still like the idea of making str() and unicode() have similar semantics. ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-08-01 06:55 Message: Logged In: YES user_id=89016 Oops, sorry I accidentally hit the submit button! :-/ The foo class is the one from the first message. str(...) always does a unicodeescape encoding when it encounters a Unicode object, so you'll get escape characters, but this will not be decoded when constructing the unicode object. I.e. u"..." != unicode(str(u"...")). Basically the unicode type should have the same functionality as the str type to ease unicode migration. ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-08-01 06:49 Message: Logged In: YES user_id=89016 >>> unicode(u"ь") u'\xfc' *>>> unicode(str(u"ь")) Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range (128) >>> unicode(foo(u"ь")) u'\xfc' *>>> unicode(str(foo(u"ь"))) Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range (128) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-01 06:45 Message: Logged In: YES user_id=6380 What does this have to offer over unicode(str(x))? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 From noreply@sourceforge.net Thu Sep 20 13:50:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Sep 2001 05:50:08 -0700 Subject: [Patches] [ python-Patches-446754 ] Enhanced unicode constructor Message-ID: Patches item #446754, was opened at 2001-08-01 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 Category: None Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Walter Dцrwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: Enhanced unicode constructor Initial Comment: This patch (against descr-branch) uses a slightly enhanced version of PyObject_Unicode instead of PyUnicode_FromEncodedObject in the unicode constructor (Objects/unicodeobject.h/unicode_new), which gives the unicode constructor the same functionality as the str constructor: creating string representations with the __str__ method/tp_str slot. Example: Python 2.2a1 (#10, Aug 1 2001, 14:26:06) [GCC 2.95.2 19991024 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> str("u"), unicode("u") ('u', u'u') >>> str(u"u"), unicode(u"u") ('u', u'u') >>> str(None), unicode(None) ('None', u'None') >>> str(42), unicode(42) ('42', u'42') >>> str(23.), unicode(23.) ('23.0', u'23.0') >>> str([1,2,3]), unicode([1,2,3]) ('[1, 2, 3]', u'[1, 2, 3]') >>> str({"u": 23, u"ь": 42}), unicode({"u": 23, u"ь": 42}) ("{'u': 23, u'\xfc': 42}", u"{'u': 23, u'\\xfc': 42}") >>> class foo: ... def __init__(self, x): ... self.x = x ... def __str__(self): ... return self.x ... >>> str(foo("bar")), unicode(foo("bar")) ('bar', u'bar') >>> str(foo(u"bar")), unicode(foo(u"bar")) ('bar', u'bar') Passing the encoding and errors argument still works and the will be used for any 8bit string returned from __str__. Perhaps for symmetry encoding and errors arguments should be added to the str constructor too, which will be used when a unicode object is returned from __str__ for encoding the object. One problem is that unicode([u"ь"]) returns u"[u'\\xfc']" because __repr__ returns a 8bit escape encoded string, it would be better if the result was u"[u'\xfc']", but this would require a PyObject_UnicodeRepr (and/or changing the list tp_str slot (and many others) to return Unicode) ---------------------------------------------------------------------- >Comment By: Walter Dцrwald (doerwalter) Date: 2001-09-20 05:50 Message: Logged In: YES user_id=89016 OK, the new patch no longer changes the PyObject_Unicode signature. Now there are two functions: PyObject_Unicode with the old signature, and PyObject_UnicodeEx, which has the additional encoding and errors arguments. PyObject_Unicode(x) simply calls PyObject_UnicodeEx (x,NULL,NULL) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-09-20 03:56 Message: Logged In: YES user_id=38388 Rejecting this patch: see patch #413333 -- this is basically the same request and the patch is not usable since it breaks the Unicode C API. I still like the idea of making str() and unicode() have similar semantics. ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-08-01 06:55 Message: Logged In: YES user_id=89016 Oops, sorry I accidentally hit the submit button! :-/ The foo class is the one from the first message. str(...) always does a unicodeescape encoding when it encounters a Unicode object, so you'll get escape characters, but this will not be decoded when constructing the unicode object. I.e. u"..." != unicode(str(u"...")). Basically the unicode type should have the same functionality as the str type to ease unicode migration. ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-08-01 06:49 Message: Logged In: YES user_id=89016 >>> unicode(u"ь") u'\xfc' *>>> unicode(str(u"ь")) Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range (128) >>> unicode(foo(u"ь")) u'\xfc' *>>> unicode(str(foo(u"ь"))) Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range (128) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-01 06:45 Message: Logged In: YES user_id=6380 What does this have to offer over unicode(str(x))? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 From noreply@sourceforge.net Thu Sep 20 13:54:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Sep 2001 05:54:14 -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: Closed >Resolution: Accepted 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: M.-A. Lemburg (lemburg) Date: 2001-09-20 05:54 Message: Logged In: YES user_id=38388 I checked in a different patch which provides the same functionality. Please try it and post any enhancements as new patch. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-09-20 03:51 Message: Logged In: YES user_id=38388 I like the idea since it synchronizes str() and unicode() in terms of semantics. The patch is too radical though: the str() approach should only be used if everything else fails. ---------------------------------------------------------------------- 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 non-feedback-1@lb.bcentral.com Thu Sep 20 13:56:46 2001 From: non-feedback-1@lb.bcentral.com (Взаимовыгдное сотрудничество.) Date: 20 Sep 2001 12:56:46 -0000 Subject: [Patches] Ответ на запрос о продаже и покупке продукции Message-ID: <1000990606.86251.qmail@ech> Уважаемые господа! Организация ООО “ВИЭЛЬ-М” предлагает Вашему вниманию четыре вида нашей деятельности: Радиоэлектронные комплектующие, сварочные электроды(а также аппараты газводы), металл и электротехническую продукцию(сюда входит продажа люстры Чижевского). Более подробно ознакомиться с нашей продукцией, Вы можете на нашем сайте в интернет: www.viel.f2s.com Благодаря обширным связям с ведущими производителями и поставщиками не только в России, но и за рубежом, мы имеем возможность выполнять Ваши заказы наиболее полно и в кратчайшие сроки. Область электроники, это не только поставки приборов, аппаратуры, но и различные комплектующие как отечественных, так и зарубежных производителей электронной техники. Это такие фирмы как International Rectifier, Epcos, Bourns, Metex, unit-t и др. Сварочные электроды: мы продаём электроды от ведущих отечественных производителей. Все сварочные электроды соответствуют ГОСТу и имеют сертификат качества. Аппараты газированной воды: АГВ, АВ-2,АВ-3, POST-MIX и др. для охлаждения и выдачи газированных напитков в офисах, “горячих” цехах, на предприятиях и т.д. Металл : Предлагаем Х/К и Г/К листовой металлопркат. Светильники: По самым низким ценам для дома,офиса, скверов и парков. В настоящее время мы предлагаем уникальную разработку отечественных ученых:компенсирующие патрубки для безсварного соединения труб!!!(D от 25 до 1000мм.) Наши менеджеры имеют богатый опыт продаж, маркетинговых исследований,ведения переговоров с крупными поставщиками и потребителями товаров,что позволяет нам достать нужную Вам продукцию по выгодным для Вас ценам и в оптимально короткие сроки. Вашу потребность в продукции представленной на нашем сайте, можно отправить на наш факс: (095) 275-89-94, или по электронной почте: vielmos@yahoo.com Мы ждем Вас и выражаем уверенность в том, что обратившись к нам, Вы получите квалифицированную помощь, внимательное отношение к Вашим потребностям, оперативную обработку Вашего заказа. По всем вопросам вы можете обращаться по телефонам в г. Москва: (095) 275-89-94, 746-68-78. _______________________________________________________________________ Powered by List Builder To unsubscribe follow the link: http://lb.bcentral.com/ex/manage/subscriberprefs?customerid=15203&subid=F99BE039968DCC7D&msgnum=1 From noreply@sourceforge.net Thu Sep 20 14:05:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Sep 2001 06:05:12 -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: Postponed >Priority: 3 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-09-20 03:38 Message: Logged In: YES user_id=38388 I am postponing this patch until the PEP process has started. This feature won't make it into Python 2.2. Walter, you may want to reference this patch in the PEP. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-16 03:53 Message: Logged In: YES user_id=38388 I think we ought to summarize these changes in a PEP to get some more feedback and testing from others as well. I'll look into this after I'm back from vacation on the 10.09. Given the release schedule I am not sure whether this feature will make it into 2.2. The size of the patch is huge and probably needs a lot of testing first. ---------------------------------------------------------------------- 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 Thu Sep 20 16:04:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Sep 2001 08:04:06 -0700 Subject: [Patches] [ python-Patches-462522 ] code.py softspace attribute fix Message-ID: Patches item #462522, was opened at 2001-09-18 04:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462522&group_id=5470 Category: Modules Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Guido van Rossum (gvanrossum) Summary: code.py softspace attribute fix Initial Comment: I *think* this is required as fallout from the fact that ob.foo = 1 can raise AttributeError now. To someone who knows, this should be a no-brainer. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-09-20 08:04 Message: Logged In: YES user_id=6656 How's this? It's a bit of a noddy exaple, to be sure... I just remember being worried when I wrote softspace that it was being a bit fragile. >>> class F(object): ... def write(self, text): ... sys.__stdout__.write(text) ... def flush(self): ... sys.__stdout__.flush() ... softspace = property(lambda self:0) ... >>> sys.stdout = F() >>> import code >>> code.interact() Python 2.2a3+ (#1, Sep 18 2001, 07:44:02) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> Traceback (most recent call last): File "", line 1, in ? File "/home/crew/mwh/src/python/dist/src/Lib/code.py", line 307, in interact console.interact(banner) File "/home/crew/mwh/src/python/dist/src/Lib/code.py", line 244, in interact more = self.push(line) File "/home/crew/mwh/src/python/dist/src/Lib/code.py", line 266, in push more = self.runsource(source, self.filename) File "/home/crew/mwh/src/python/dist/src/Lib/code.py", line 87, in runsource self.runcode(code) File "/home/crew/mwh/src/python/dist/src/Lib/code.py", line 109, in runcode if softspace(sys.stdout, 0): File "/home/crew/mwh/src/python/dist/src/Lib/code.py", line 22, in softspace file.softspace = newvalue AttributeError: can't set attribute >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-18 06:34 Message: Logged In: YES user_id=6380 I've checked this in, but I'm leaving it open for now: can you show me how to reproduce the problem? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462522&group_id=5470 From noreply@sourceforge.net Thu Sep 20 16:26:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Sep 2001 08:26:02 -0700 Subject: [Patches] [ python-Patches-462522 ] code.py softspace attribute fix Message-ID: Patches item #462522, was opened at 2001-09-18 04:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462522&group_id=5470 Category: Modules Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Guido van Rossum (gvanrossum) Summary: code.py softspace attribute fix Initial Comment: I *think* this is required as fallout from the fact that ob.foo = 1 can raise AttributeError now. To someone who knows, this should be a no-brainer. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-20 08:26 Message: Logged In: YES user_id=6380 Thanks! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-09-20 08:04 Message: Logged In: YES user_id=6656 How's this? It's a bit of a noddy exaple, to be sure... I just remember being worried when I wrote softspace that it was being a bit fragile. >>> class F(object): ... def write(self, text): ... sys.__stdout__.write(text) ... def flush(self): ... sys.__stdout__.flush() ... softspace = property(lambda self:0) ... >>> sys.stdout = F() >>> import code >>> code.interact() Python 2.2a3+ (#1, Sep 18 2001, 07:44:02) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> Traceback (most recent call last): File "", line 1, in ? File "/home/crew/mwh/src/python/dist/src/Lib/code.py", line 307, in interact console.interact(banner) File "/home/crew/mwh/src/python/dist/src/Lib/code.py", line 244, in interact more = self.push(line) File "/home/crew/mwh/src/python/dist/src/Lib/code.py", line 266, in push more = self.runsource(source, self.filename) File "/home/crew/mwh/src/python/dist/src/Lib/code.py", line 87, in runsource self.runcode(code) File "/home/crew/mwh/src/python/dist/src/Lib/code.py", line 109, in runcode if softspace(sys.stdout, 0): File "/home/crew/mwh/src/python/dist/src/Lib/code.py", line 22, in softspace file.softspace = newvalue AttributeError: can't set attribute >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-18 06:34 Message: Logged In: YES user_id=6380 I've checked this in, but I'm leaving it open for now: can you show me how to reproduce the problem? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462522&group_id=5470 From baza_all@email.com Thu Sep 20 16:44:50 2001 From: baza_all@email.com (All emails) Date: Thu, 20 Sep 2001 18:44:50 +0300 Subject: [Patches] Databases !!! Message-ID: Новейшие эксклюзивные авторские сертифицированные базы данных электронных адресов (Email) с программой рассылки: - "фирмы Москвы" - 22.500 адресов (со встроенным рубрикатором) = 50$ - "все Emailы Москвы" - 42.000 адресов (предыдущие фирмы + 19.500 без разбивки) =70$ - "фирмы Санкт-Петербурга" (со встроенным рубрикатором) = 50$ - "фирмы России" (со встроенным рубрикатором) = 50$ - "фирмы СНГ" (со встроенным рубрикатором) = 50$ - "200.000 электронных адресов России и СНГ" (без разбивки) = 50$ moscow_email@email.com From info@rin.ru Thu Sep 20 17:20:00 2001 From: info@rin.ru (тПУУЙКУЛБС йОЖПТНБГЙПООБС CЕФШ) Date: Thu, 20 Sep 2001 20:20 +0400 Subject: [Patches] тПУУЙКУЛБС йОЖПТНБГЙПООБС CЕФШ Message-ID: <200109201621.f8KGKxK28477@ns.greenline> PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT7yz9PTycrTy8HRIOnOxs/SzcHDyc/OzsHR IPPF1Ng8L1RJVExFPg0KPE1FVEEgY29udGVudD0iQ29weXJpZ2h0IEdyZWVubGluZSAyMDAx IEthemFuLCBwcm9ncmFtbWVyIGJ5IFRzdmVuZ2VyIElnb3IgbWFpbHRvOmlnb3JAZ3JlZW5s aW5lLnJ1IiBuYW1lPUF1dGhvcj4NCjxzdHlsZT4NCmJvZHksIGlucHV0LCBzZWxlY3QsIHRh YmxlLCB0ZCwgdHIge0NPTE9SOiAjNTU1NTU1OyBGT05ULUZBTUlMWTogVGFob21hLCBHZW5l dmEsIEhlbHZldGljYSwgU2Fucy1zZXJpZiwgQXJpYWw7IEZPTlQtU0laRTogMTJweH0NCkE6 bGluayAgICB7Q09MT1I6ICM1NTU1Nzc7IFRFWFQtREVDT1JBVElPTjogbm9uZTt9DQpBOnZp c2l0ZWQge0NPTE9SOiAjNTU1NTc3OyBURVhULURFQ09SQVRJT046IG5vbmU7fQ0KQTpob3Zl ciAgIHtDT0xPUjogIzA2OGJmMDsgVEVYVC1ERUNPUkFUSU9OOiBub25lO30NCiNiaWcgICAg ICB7Q09MT1I6ICM1NTU1NTU7IEZPTlQtU0laRTogMzJweDsgZm9udC13ZWlnaHQ6IGJvbGQ7 fQ0KPC9zdHlsZT4NCjwvSEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZiBsZWZ0TWFyZ2lu PTIgdG9wTWFyZ2luPTIgbWFyZ2lud2lkdGg9IjIiIG1hcmdpbmhlaWdodD0iMiI+DQo8VEFC TEUgYmdDb2xvcj0jZmZmZmZmIGJvcmRlcj0wIGNlbGxQYWRkaW5nPTAgY2VsbFNwYWNpbmc9 MCB3aWR0aD0iMTAwJSI+DQogIDxUQk9EWT4NCiAgPFRSPg0KICAgIDxURCB2QWxpZ249dG9w PjxBIGhyZWY9Imh0dHA6Ly9yaW4ucnUiIGlkPWJpZz5SSU4ucnU8L0E+PC9URD4NCiAgICA8 VEQgdkFsaWduPXRvcD48QklHPjxCPvLP09PJytPLwdEg6c7Gz9LNwcPJz87OwdEg88XU2DxC PjwvQklHPjwvQj48L0I+PC9URD4NCiAgPFRSPg0KICA8VFI+DQogICAgPFREPiZuYnNwOzwv VEQ+DQogICAgPFREPvXXwdbBxc3ZyiDQz8zY2s/XwdTFzNggwsnazsXTLdDP0tTBzMEgIvLP 09PJytPLwdEg6c7Gz9LNwcPJz87OwdENCiAgICAgIPPF1NgiITxCUj7zz8/C3cHFzSD3wc0g zyDSwdPbydLFzsnJINDSxcTP09TB18zRxc3Px88gzsHNySDT0MXL1NLBDQogICAgICDpztTF 0s7F1C3V08zVxyw8QlI+0M/a18/M0cDdycgg0M/EztHU2CD3wdsgwsnazsXTIM7BIMvB3sXT 1NfFzs7PIM7P19nKDQogICAgICDV0s/Xxc7YINLB2tfJ1MnRLjwvVEQ+DQogIDxUUj4NCiAg PFRSPg0KICAgIDxURCBjb2xTcGFuPTI+PEJSPjxCSUc+98Hbxc3VINfOyc3BzsnAINDSxcTT 1MHXzNHA1NPROjwvQklHPjwvVEQ+DQogIDxUUj4NCiAgPFRSPg0KICAgIDxURCBhbGlnbj1y aWdodD48QQ0KICAgICAgaHJlZj0iaHR0cDovL3llbGxvd3BhZ2VzLnJpbi5ydSI+PEI+eWVs bG93cGFnZXMucmluLnJ1Jm5ic3A7PC9CPjwvQT48L1REPg0KICAgIDxURD7r0tXQzsXK28nK IMnOxs/SzcHDyc/OztnKIMvB1MHMz8cgz9LHwc7J2sHDycouPC9URD4NCiAgPFRSPg0KICA8 VFI+DQogICAgPFREIGFsaWduPXJpZ2h0PjxBIGhyZWY9Imh0dHA6Ly9tYXAucmluLnJ1Ij48 Qj5tYXAucmluLnJ1Jm5ic3A7PC9CPjwvQT48L1REPg0KICAgIDxURD7wz8zO2cog09DFy9TS IMnOxs/SzcHDyckgzyDSz9PTycrTy8nIINLFx8nPzsHILjwvVEQ+DQogIDxUUj4NCiAgPFRS Pg0KICAgIDxURCBhbGlnbj1yaWdodD48QQ0KICAgICAgaHJlZj0iaHR0cDovL21hcmtldC5y aW4ucnUiPjxCPm1hcmtldC5yaW4ucnUmbmJzcDs8L0I+PC9BPjwvVEQ+DQogICAgPFREPunO xs/SzcHDyc/OztnKINLFxdPU0iDSz9PTycrTy8nIINDSxcTQ0snR1MnKLCDUz9fB0s/XIMkg 1dPM1ccuPC9URD4NCiAgPFRSPg0KICA8VFI+DQogICAgPFREIGFsaWduPXJpZ2h0PjxBDQog ICAgICBocmVmPSJodHRwOi8vYWxsc2hvcC5yaW4ucnUiPjxCPmFsbHNob3AucmluLnJ1Jm5i c3A7PC9CPjwvQT48L1REPg0KICAgIDxURD7pztTF0s7F1C3NwcfB2snOINDSxcTQ0snR1MnK INLP2s7J3s7PyiDUz9LHz9fMySDJINXTzNXHLjwvVEQ+DQogIDxUUj4NCiAgPFRSPg0KICAg IDxURCBhbGlnbj1yaWdodD48QQ0KICAgIGhyZWY9Imh0dHA6Ly9kZXNrLnJpbi5ydSI+PEI+ ZGVzay5yaW4ucnUmbmJzcDs8L0I+PC9BPjwvVEQ+DQogICAgPFREPuTP08vBIMLF09DMwdTO 2cggz8Lf0dfMxc7JyiDTINLB09PZzMvPyiDPwt/R18zFzsnKINDPIGUtbWFpbC48L1REPg0K ICA8VFI+DQogIDxUUj4NCiAgICA8VEQgYWxpZ249cmlnaHQ+PEEgaHJlZj0iaHR0cDovL2pv Yi5yaW4ucnUiPjxCPmpvYi5yaW4ucnUmbmJzcDs8L0I+PC9BPjwvVEQ+DQogICAgPFREPunO 1MXSzsXULcHHxc7U09TXzyDQzyDU0tXEz9XT1NLPytPU19UuIPLB09PZzMvBIM/C39HXzMXO ycog0M8NCiAgICBlLW1haWwuPC9URD4NCiAgPFRSPg0KICA8VFI+DQogICAgPFREIGFsaWdu PXJpZ2h0PjxBDQogICAgICBocmVmPSJodHRwOi8vcnVzc2lhLnJpbi5ydSI+PEI+cnVzc2lh LnJpbi5ydSZuYnNwOzwvQj48L0E+PC9URD4NCiAgICA8VEQ+6dPUz9LJ0SwgwdLIydTFy9TV 0sEgySDL1czY1NXSwSDOwdLPxM/XIPLP09PJyS4g9NXSydPUyd7F08vJxSDGydLN2SDJDQog ICAgICDV08zVx8kuPC9URD4NCiAgPFRSPg0KICA8VFI+DQogICAgPFREIGFsaWduPXJpZ2h0 PjxBDQogICAgaHJlZj0iaHR0cDovL3VkZGkucmluLnJ1Ij48Qj51ZGRpLnJpbi5ydSZuYnNw OzwvQj48L0E+PC9URD4NCiAgICA8VEQ+7cXWxNXOwdLPxM7B0SDCwdrBIMTBzs7ZyCDP0sfB zsnawcPJyiDJINXTzNXHLiDi2dPU0tnKIMkgzMXHy8nKINDPydPLDQogICAgICDQwdLUzsXS z9cg0M8g19PFzdUgzcnS1S48L1REPg0KICA8VFI+DQogIDxUUj4NCiAgICA8VEQgYWxpZ249 cmlnaHQ+PEENCiAgICAgIGhyZWY9Imh0dHA6Ly9qdW1wZXIucmluLnJ1Ij48Qj5qdW1wZXIu cmluLnJ1Jm5ic3A7PC9CPjwvQT48L1REPg0KICAgIDxURD7yxcHM2M7PxSDV18XMyd7FzsnF INDP08XdwcXNz9PUySD3wdvFx88g08HK1MEuIOLF09DMwdTOwdEg0sXLzMHNwSDXDQogICAg ICDpztTF0s7F1C48L1REPg0KICA8VFI+DQogIDxUUj4NCiAgICA8VEQgYWxpZ249cmlnaHQ+ PEENCiAgICAgIGhyZWY9Imh0dHA6Ly93aGl0ZXBhZ2VzLnJpbi5ydSI+PEI+d2hpdGVwYWdl cy5yaW4ucnUmbmJzcDs8L0I+PC9BPjwvVEQ+DQogICAgPFREPvDPydPLINPUwdLZyCDE0tXa xcogySDOz9fZyCDazsHLz83ZyC4g+sHQz8zOydTFIMHOy8XU1SDV3sHT1M7Jy8EsIMkNCiAg ICAgIPfB28kgxNLV2tjRINPBzckg083Px9XUIM7BytTJIPfB0y48L1REPg0KICA8VFI+DQog IDxUUj4NCiAgICA8VEQgYWxpZ249cmlnaHQ+PEENCiAgICBocmVmPSJodHRwOi8vbGlua3Mu cmluLnJ1Ij48Qj5saW5rcy5yaW4ucnUmbmJzcDs8L0I+PC9BPjwvVEQ+DQogICAgPFREPuzV 3tvJxSDT09nMy8kg1yBJbnRlcm5ldC4g9cTPws7B0SDLzMHT08nGycvBw8nRIMkg0M/T1M/R zs7PxQ0KICAgICAgz8LOz9fMxc7JxS48L1REPg0KICA8VFI+DQogIDxUUj4NCiAgICA8VEQg YWxpZ249cmlnaHQ+PEENCiAgICAgIGhyZWY9Imh0dHA6Ly9oYXBweWVuZHMucmluLnJ1Ij48 Qj5oYXBweWVuZHMucmluLnJ1Jm5ic3A7PC9CPjwvQT48L1REPg0KICAgIDxURD7zzNXWwsEg 2s7By8/N09TXIC0g0sXHydPU0sHDydEgwc7LxdQgySDQz8nTyyDQwdLUzsXSwS48L1REPg0K ICA8VFI+DQogIDxUUj4NCiAgICA8VEQgYWxpZ249cmlnaHQ+PEENCiAgICAgIGhyZWY9Imh0 dHA6Ly9waG9uZS5yaW4ucnUiPjxCPnBob25lLnJpbi5ydSZuYnNwOzwvQj48L0E+PC9URD4N CiAgICA8VEQ+8M/J08vP18HRINPJ09TFzcEg0M8g1MXMxcbPzs7ZzSDLz8TBzSDJINPT2czL wc0gzsEg1MXMxcbPzs7ZxSDT0NLB18/eztnFINPJ09TFzdkgx8/Sz8TP1yDyz9PTyckuPC9U RD4NCiAgPFRSPg0KIA0KIA0KICA8VFI+DQogICAgPFREIGNvbFNwYW49Mj48QlI+8yDOwcnM 1d7byc3JINDP1sXMwc7J0c3JLDwvVEQ+DQogIDxUUj4NCiAgPFRSPg0KICAgIDxURCBjb2xT cGFuPTI+4cTNyc7J09TSwcPJ0SA8QSBocmVmPSJodHRwOi8vcmluLnJ1Ij48Qj5SSU4ucnU8 L0I+PC9BPjwvVEQ+DQogIDxUUj4NCiAgPFRSPg0KICAgIDxURCBjb2xTcGFuPTI+PEEgaHJl Zj0ibWFpbHRvOmluZm9AcmluLnJ1Ij48Qj5pbmZvQHJpbi5ydTwvQj48L0E+PC9URD4NCiAg PFRSPjwvVFI+PC9UQk9EWT48L1RBQkxFPjwvQk9EWT48L0hUTUw+DQoNCg== From noreply@sourceforge.net Thu Sep 20 20:16:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Sep 2001 12:16:36 -0700 Subject: [Patches] [ python-Patches-460751 ] --with-shared: python with shared lib Message-ID: Patches item #460751, was opened at 2001-09-11 14:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Martin v. Lцwis (loewis) Summary: --with-shared: python with shared lib Initial Comment: As a follow up to patch 400938 (https://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=400938), here is an implementation of the --with-shared configure option for building python on Posix systems as a shared library. Building python as shared library is activated with the --with-shared option on ./configure The following points are drawn to particular attention: - A configbuild.py module is generated and placed in the machine-dependent directory. It records most Python/Makefile variables (CC, CFLAG, LDSHARED...), and make them available in Python. - The build has been tested on: Linux2: OK SunOS5: OK IRIX64: Build OK, crash on test (bus error) - Inference with distutils: I found it very difficult understanding the distutil architecture and finding the right points of change; I minimized my interaction there. Furthermore, the availability of the 'configbuild' module overlaps some of the distutils; but 'configbuild' is very easy to use ... - Unresolved symbols: I turned on the symbol checking flags whenever possible, on behalf the its better generating the error on build than at runtime. - configure.in: I only edited the configure Bourne script, and did not bother with configure.in (actually, I deleted it) and its autoconfig/m4 macro comparses. Frederic Giacometti ---------------------------------------------------------------------- >Comment By: Frederic Giacometti (giacometti) Date: 2001-09-20 12:16 Message: Logged In: YES user_id=93657 The patch is against Python 2.1.1. I'll try to integrate this with the current source. I'll work with a single checkout across the multiple platforms. Regarding buildno: I was getting recursive dependency links, after I made the shared library dependent upon its .o files. I had to break the recursivity. What is dguxR4 ? Is it OSF1 V4.0, a.k.a. Digital Unix 4.0, a.k.a. Tru64 ? I have now access to an OSF1 v4.0 (a.k.a. DU 4.0). I'll do the build there. uname returns 'OSF1 ...' The -lsocket is needed for building the socket module, and had to be moved there (cf. Python/setup.py, I think). It is not used in the core, so I dropped it there. Dito for -ldsl. No symbols are missing when linking libpython2.1.so, anyway. These libraries just have now to be linked with the modules which use them. The rule I applied for deciding on libraries are: - link with all libraries necessaries so as to suppress all unresolved symbol output - link only with libraries whose absence triggers unresolved symbol outputs - -lmpc: You might be right, but then -lmpc should be present only on systems that need it (and, first of all these systems should be identified/documented). - fpectl: dito FG ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-18 10:05 Message: Logged In: YES user_id=21627 I've tried testing your patch, but I get numerous failed chunks when applying it against the current CVS. What version does this patch apply to? To simplify the integration, it would be greatly appreciated if you could use the current source base. >From reviewing the patch, I still have a number of concerns: - it appears that you change the mechanism by which buildno is incremented. Why? - There appear to extra white space changes (e.g. in the distclean chunk); those are naturally unrelated to the patch - please remove them - it appears that configuration knowledge for some platforms is lost when applying this patch, e.g. the dguxR4 special-casing of passing -pic is gone. Please try to integrate any such knowledge faithfully into your patch, instead of restricting its applicability to just the platforms where you've tested it on. - There is something going on with dropping -lsocket from the patch. What is that, and why does it happen? Instead, it appears that you put 'socket' and 'nsl' into setup.py. According to configure.in, this is wrong on some systems: they may not have the libraries, or the libraries may be broken. - Other libraries appear to suffer as well, such as removing -lmpc. That might mean that you break thread support on some systems. - the chunk to disable fpectl if nothing is known about the systems appears to be unrelated. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-17 10:36 Message: Logged In: YES user_id=93657 I'm attaching an updated patch where, following Martin suggestions: - I removed the configbuild thing, and replaced it with distutils.sysconfig.get_conf_var calls - I manually cleaned up the patch from unrelated changes (.cvsignore, @ Makefile modifiers...) Remains the configure.in thing. If one looks at autoconf: - it takes care of plateform idiosyncracies, for platform which do not follow posix API specs; this was of use in previous generation Unix OS's, and these legacy systems do not evolve anymore. On present Unixes, and with regard to the features used for building the core python engine, nothing moves, and autoconf updates bring nothing. Doesn't the Python 1.5.2's configure still works as it did the first day it was generated ... ? - autoconf is of use for configuring particular packages and libraries (e.g.: for configuring and building python extensions, Tkinter/Tk/TCL...); unfortunately this never worked with python, and the task is now assumed by the distutils. - In the Python core build, autoconf is of no help in anything sensible: thread, shared library, debug build, compiler options... All these were programmed manually in Bourne; and for doing the later, autoconf is a complexifying factor on something already fairly complex - i.e. a handicap -. - not to say, autoconf is of no use on non-posix plateforms (windows...) - last, and the least: autoconf now requires that perl be installed... Frederic Giacometti ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 18:36 Message: Logged In: YES user_id=6380 > What is the point of keeping using the autoconf thing when > it is easier to maintain configure directly, than going > through configure.in ? But it's not. One line of configure.in often expands to dozens (occasionally hundreds) of lines of configure. autoconf has arcane knowledge that gets updated with new autoconf releases. You are entitled to your opinion, but in this case, it's wrong. Go fork your own version of Python if you don't want to learn autoconf. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-12 16:06 Message: Logged In: YES user_id=93657 I am not willing to make anything difficult for anybody, but: What is the point of keeping using the autoconf thing when it is easier to maintain configure directly, than going through configure.in ? After configure has been generated once, it makes more sense to me to work directly on configure, and forget about configure.in. configure (pure Bourne shell) is a easier to understand, to troubleshoot, and to maintain that configure.in (a mixture of Bourne shell and autoconf m4 macros). I'll have a second look at the autoconf thing latter on - at present I hardly understand anything to configure.in, and got 'configure --with-shared' working with satisfaction across multiple platforms without undue difficulties. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 11:37 Message: Logged In: YES user_id=6380 > Autoconf is not installed on the commercial Unix > platforms, it is useless for me to learn it, and I was > better off directly editing ./configure. However, if others > are familiar with the tool, it should be straightforward for > them to retrocede the changes from configure to configure.in Sure. You'll just have to wait until we have time for that. You can make it easy for us to integrate your changes, or you can make it difficult. Your choice. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-12 11:12 Message: Logged In: YES user_id=93657 - I will remove the configbuild; since Martin pointed to me the existence of distutils.sysconfig.get_config_vars(). I did not know about this function... Thanks! On the fly, you'll also note the following potential problem with using get_config_vars() instead of configbuild: configbuild will report the actual values used for the build, whereas get_config_vars() will report erroneous values whenever the Makefile internal variables were overriden at build time (by either the environment, or by commandline assignment of the type 'make CC=gxx ...'); not to mention that configbuild does not need to find and parse the original Makefile (with all the potential problems associated). - The .purify line should be in the CVSROOT/cvsignore CVS admin file, not in .cvsignore in the root directory of the source distribution... - Autoconf is not installed on the commercial Unix platforms, it is useless for me to learn it, and I was better off directly editing ./configure. However, if others are familiar with the tool, it should be straightforward for them to retrocede the changes from configure to configure.in - I had to introduce THREADOBJ because you will note that, in the present implementation, Modules/thread.o appears multiple times in LIBOBJS, which causes warning at link time. Now, Modules/thread.o appears only once ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-12 01:06 Message: Logged In: YES user_id=21627 As for libtool: I strongly advise not to use it. It is broken in too many ways to enumerate. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-12 00:18 Message: Logged In: YES user_id=21627 I recommend to rework this patch to get rid of configbuild. I cannot see what you achieve with the configbuild module that you couldn't do with distutils.sysconfig.get_config_vars (which is capable of parsing the Makefile directly). I also recommend to go through the patch chunk by chunk, asking yourself whether this chunk *really* is needed to achieve the desired functionality. E.g. I cannot see the relationship of the .cvsignore chunk; I also believe that removal of .purify is incorrect. Likewise, while I sympathize with the unresolved symbols change, I believe it is unrelated to the main objective of this patch (building Python shared). What is the rationale for not changing configure.in? As-is, this patch is useless: configure will be overwritten everytime you run autoconf. Please get a copy of autoconf on one of your systems, change configure.in, run autoconf, and then provide us with a patch that only changes configure.in: everybody reviewing this patch should be capable of running autoconf. configure is a generated file and should not be edited manually. What is the rationale for the introduction of the THREADOBJ variable? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-11 19:03 Message: Logged In: YES user_id=6380 Haven't seen the patch yet, but I like the idea -- the command line option suggests that it shouldn't hurt platforms where it can't be done or has to be done differently. Alternative: we could also consider using libtool. I didn't like that much in the past, but maybe it would work. Dunno. Anybody know about it? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 From non-feedback-2@lb.bcentral.com Thu Sep 20 19:47:20 2001 From: non-feedback-2@lb.bcentral.com (Взаимовыгдное сотрудничество.) Date: 20 Sep 2001 18:47:20 -0000 Subject: [Patches] пФЧЕФ ОБ ЪБРТПУ П РТПДБЦЕ Й РПЛХРЛЕ РТПДХЛГЙЙ Message-ID: <1001011640.7363.qmail@ech> kodirovra KOI-8R ili Kirilica(windows) хЧБЦБЕНЩЕ ЗПУРПДБ! пТЗБОЙЪБГЙС ппп “чйьмш-н” РТЕДМБЗБЕФ чБЫЕНХ ЧОЙНБОЙА ЮЕФЩТЕ ЧЙДБ ОБЫЕК ДЕСФЕМШОПУФЙ: тБДЙПЬМЕЛФТПООЩЕ ЛПНРМЕЛФХАЭЙЕ, УЧБТПЮОЩЕ ЬМЕЛФТПДЩ(Б ФБЛЦЕ БРРБТБФЩ ЗБЪЧПДЩ), НЕФБММ Й ЬМЕЛФТПФЕИОЙЮЕУЛХА РТПДХЛГЙА(УАДБ ЧИПДЙФ РТПДБЦБ МАУФТЩ юЙЦЕЧУЛПЗП). вПМЕЕ РПДТПВОП ПЪОБЛПНЙФШУС У ОБЫЕК РТПДХЛГЙЕК, чЩ НПЦЕФЕ ОБ ОБЫЕН УБКФЕ Ч ЙОФЕТОЕФ: www.viel.f2s.com . вМБЗПДБТС ПВЫЙТОЩН УЧСЪСН У ЧЕДХЭЙНЙ РТПЙЪЧПДЙФЕМСНЙ Й РПУФБЧЭЙЛБНЙ ОЕ ФПМШЛП Ч тПУУЙЙ, ОП Й ЪБ ТХВЕЦПН, НЩ ЙНЕЕН ЧПЪНПЦОПУФШ ЧЩРПМОСФШ чБЫЙ ЪБЛБЪЩ ОБЙВПМЕЕ РПМОП Й Ч ЛТБФЮБКЫЙЕ УТПЛЙ. пВМБУФШ ЬМЕЛФТПОЙЛЙ, ЬФП ОЕ ФПМШЛП РПУФБЧЛЙ РТЙВПТПЧ, БРРБТБФХТЩ, ОП Й ТБЪМЙЮОЩЕ ЛПНРМЕЛФХАЭЙЕ ЛБЛ ПФЕЮЕУФЧЕООЩИ, ФБЛ Й ЪБТХВЕЦОЩИ РТПЙЪЧПДЙФЕМЕК ЬМЕЛФТПООПК ФЕИОЙЛЙ. ьФП ФБЛЙЕ ЖЙТНЩ ЛБЛ International Rectifier, Epcos, Bourns, Metex, unit-t Й ДТ. уЧБТПЮОЩЕ ЬМЕЛФТПДЩ: НЩ РТПДБЈН ЬМЕЛФТПДЩ ПФ ЧЕДХЭЙИ ПФЕЮЕУФЧЕООЩИ РТПЙЪЧПДЙФЕМЕК. чУЕ УЧБТПЮОЩЕ ЬМЕЛФТПДЩ УППФЧЕФУФЧХАФ зпуфХ Й ЙНЕАФ УЕТФЙЖЙЛБФ ЛБЮЕУФЧБ. бРРБТБФЩ ЗБЪЙТПЧБООПК ЧПДЩ: бзч, бч-2,бч-3, POST-MIX Й ДТ. ДМС ПИМБЦДЕОЙС Й ЧЩДБЮЙ ЗБЪЙТПЧБООЩИ ОБРЙФЛПЧ Ч ПЖЙУБИ, “ЗПТСЮЙИ” ГЕИБИ, ОБ РТЕДРТЙСФЙСИ Й Ф.Д. нЕФБММ : рТЕДМБЗБЕН и/л Й з/л МЙУФПЧПК НЕФБММПРТЛБФ. уЧЕФЙМШОЙЛЙ: рП УБНЩН ОЙЪЛЙН ГЕОБН ДМС ДПНБ,ПЖЙУБ, УЛЧЕТПЧ Й РБТЛПЧ. оБЫЙ НЕОЕДЦЕТЩ ЙНЕАФ ВПЗБФЩК ПРЩФ РТПДБЦ, НБТЛЕФЙОЗПЧЩИ ЙУУМЕДПЧБОЙК,ЧЕДЕОЙС РЕТЕЗПЧПТПЧ У ЛТХРОЩНЙ РПУФБЧЭЙЛБНЙ Й РПФТЕВЙФЕМСНЙ ФПЧБТПЧ,ЮФП РПЪЧПМСЕФ ОБН ДПУФБФШ ОХЦОХА чБН РТПДХЛГЙА РП ЧЩЗПДОЩН ДМС чБУ ГЕОБН Й Ч ПРФЙНБМШОП ЛПТПФЛЙЕ УТПЛЙ. чБЫХ РПФТЕВОПУФШ Ч РТПДХЛГЙЙ РТЕДУФБЧМЕООПК ОБ ОБЫЕН УБКФЕ, НПЦОП ПФРТБЧЙФШ ОБ ОБЫ ЖБЛУ: (095) 275-89-94, ЙМЙ РП ЬМЕЛФТПООПК РПЮФЕ: vielmos@yahoo.com нЩ ЦДЕН чБУ Й ЧЩТБЦБЕН ХЧЕТЕООПУФШ Ч ФПН, ЮФП ПВТБФЙЧЫЙУШ Л ОБН, чЩ РПМХЮЙФЕ ЛЧБМЙЖЙГЙТПЧБООХА РПНПЭШ, ЧОЙНБФЕМШОПЕ ПФОПЫЕОЙЕ Л чБЫЙН РПФТЕВОПУФСН, ПРЕТБФЙЧОХА ПВТБВПФЛХ чБЫЕЗП ЪБЛБЪБ. рП ЧУЕН ЧПРТПУБН ЧЩ НПЦЕФЕ ПВТБЭБФШУС РП ФЕМЕЖПОБН Ч З. нПУЛЧБ: (095) 275-89-94, 746-68-78. _______________________________________________________________________ Powered by List Builder To unsubscribe follow the link: http://lb.bcentral.com/ex/manage/subscriberprefs?customerid=15203&subid=35BEFE5B9FE5B401&msgnum=2 From noreply@sourceforge.net Fri Sep 21 01:24:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Sep 2001 17:24:41 -0700 Subject: [Patches] [ python-Patches-463421 ] speed up md5 module with real memcpy/set Message-ID: Patches item #463421, was opened at 2001-09-20 17:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=463421&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: speed up md5 module with real memcpy/set Initial Comment: Modules/md5c.c has its own for loop implementation of memcpy and memset, even with a note that they should be replaced with the real thing if possible. So, this patch just does it. It doesn't use autoconf checks for them since they seem to be used all over the existing code with no such checks so I guess we assume they exist. (some quick tests show about a 12% speedup from this change) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=463421&group_id=5470 From noreply@sourceforge.net Fri Sep 21 13:23:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Sep 2001 05:23:34 -0700 Subject: [Patches] [ python-Patches-446754 ] Enhanced unicode constructor Message-ID: Patches item #446754, was opened at 2001-08-01 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 Category: None Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Walter Dцrwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: Enhanced unicode constructor Initial Comment: This patch (against descr-branch) uses a slightly enhanced version of PyObject_Unicode instead of PyUnicode_FromEncodedObject in the unicode constructor (Objects/unicodeobject.h/unicode_new), which gives the unicode constructor the same functionality as the str constructor: creating string representations with the __str__ method/tp_str slot. Example: Python 2.2a1 (#10, Aug 1 2001, 14:26:06) [GCC 2.95.2 19991024 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> str("u"), unicode("u") ('u', u'u') >>> str(u"u"), unicode(u"u") ('u', u'u') >>> str(None), unicode(None) ('None', u'None') >>> str(42), unicode(42) ('42', u'42') >>> str(23.), unicode(23.) ('23.0', u'23.0') >>> str([1,2,3]), unicode([1,2,3]) ('[1, 2, 3]', u'[1, 2, 3]') >>> str({"u": 23, u"ь": 42}), unicode({"u": 23, u"ь": 42}) ("{'u': 23, u'\xfc': 42}", u"{'u': 23, u'\\xfc': 42}") >>> class foo: ... def __init__(self, x): ... self.x = x ... def __str__(self): ... return self.x ... >>> str(foo("bar")), unicode(foo("bar")) ('bar', u'bar') >>> str(foo(u"bar")), unicode(foo(u"bar")) ('bar', u'bar') Passing the encoding and errors argument still works and the will be used for any 8bit string returned from __str__. Perhaps for symmetry encoding and errors arguments should be added to the str constructor too, which will be used when a unicode object is returned from __str__ for encoding the object. One problem is that unicode([u"ь"]) returns u"[u'\\xfc']" because __repr__ returns a 8bit escape encoded string, it would be better if the result was u"[u'\xfc']", but this would require a PyObject_UnicodeRepr (and/or changing the list tp_str slot (and many others) to return Unicode) ---------------------------------------------------------------------- >Comment By: Walter Dцrwald (doerwalter) Date: 2001-09-21 05:23 Message: Logged In: YES user_id=89016 I've read the following in Misc/NEWS "PyUnicode_FromEncodedObject() now works very much like PyObject_Str(obj) in that it tries to use __str__/tp_str on the object if the object is not a string or buffer. This makes unicode() behave like str() when applied to non- string/buffer objects." I think this is the wrong way: The string constructor uses PyObject_Str, so the unicode constructor should use PyObject_Unicode (i.e. the extended version). As PyObject_UnicodeEx has additional arguments, maybe we should have a new function PyObject_StrEx with these additional arguments too. Then the string constructor could have these arguments too: >>> print str(u"\xfc\u2014", "latin-1", "replace") ь? This would really make string and unicode symmetric: unicode() creates a string either directy or via __str__/tp_str, if it encounters a 8bit string it uses the encoding and errors parameters to *decode* it. Likewise str () creates a 8bit string either directly or via __str__/tp_str, if it encounters a unicode object it uses the encoding and errors parameters to *encode* it. Would this change to the str constructor result in any backwards incompatiblities? ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-09-20 05:50 Message: Logged In: YES user_id=89016 OK, the new patch no longer changes the PyObject_Unicode signature. Now there are two functions: PyObject_Unicode with the old signature, and PyObject_UnicodeEx, which has the additional encoding and errors arguments. PyObject_Unicode(x) simply calls PyObject_UnicodeEx (x,NULL,NULL) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-09-20 03:56 Message: Logged In: YES user_id=38388 Rejecting this patch: see patch #413333 -- this is basically the same request and the patch is not usable since it breaks the Unicode C API. I still like the idea of making str() and unicode() have similar semantics. ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-08-01 06:55 Message: Logged In: YES user_id=89016 Oops, sorry I accidentally hit the submit button! :-/ The foo class is the one from the first message. str(...) always does a unicodeescape encoding when it encounters a Unicode object, so you'll get escape characters, but this will not be decoded when constructing the unicode object. I.e. u"..." != unicode(str(u"...")). Basically the unicode type should have the same functionality as the str type to ease unicode migration. ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-08-01 06:49 Message: Logged In: YES user_id=89016 >>> unicode(u"ь") u'\xfc' *>>> unicode(str(u"ь")) Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range (128) >>> unicode(foo(u"ь")) u'\xfc' *>>> unicode(str(foo(u"ь"))) Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range (128) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-01 06:45 Message: Logged In: YES user_id=6380 What does this have to offer over unicode(str(x))? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 From noreply@sourceforge.net Fri Sep 21 15:13:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Sep 2001 07:13:33 -0700 Subject: [Patches] [ python-Patches-446754 ] Enhanced unicode constructor Message-ID: Patches item #446754, was opened at 2001-08-01 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 Category: None Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Walter Dцrwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: Enhanced unicode constructor Initial Comment: This patch (against descr-branch) uses a slightly enhanced version of PyObject_Unicode instead of PyUnicode_FromEncodedObject in the unicode constructor (Objects/unicodeobject.h/unicode_new), which gives the unicode constructor the same functionality as the str constructor: creating string representations with the __str__ method/tp_str slot. Example: Python 2.2a1 (#10, Aug 1 2001, 14:26:06) [GCC 2.95.2 19991024 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> str("u"), unicode("u") ('u', u'u') >>> str(u"u"), unicode(u"u") ('u', u'u') >>> str(None), unicode(None) ('None', u'None') >>> str(42), unicode(42) ('42', u'42') >>> str(23.), unicode(23.) ('23.0', u'23.0') >>> str([1,2,3]), unicode([1,2,3]) ('[1, 2, 3]', u'[1, 2, 3]') >>> str({"u": 23, u"ь": 42}), unicode({"u": 23, u"ь": 42}) ("{'u': 23, u'\xfc': 42}", u"{'u': 23, u'\\xfc': 42}") >>> class foo: ... def __init__(self, x): ... self.x = x ... def __str__(self): ... return self.x ... >>> str(foo("bar")), unicode(foo("bar")) ('bar', u'bar') >>> str(foo(u"bar")), unicode(foo(u"bar")) ('bar', u'bar') Passing the encoding and errors argument still works and the will be used for any 8bit string returned from __str__. Perhaps for symmetry encoding and errors arguments should be added to the str constructor too, which will be used when a unicode object is returned from __str__ for encoding the object. One problem is that unicode([u"ь"]) returns u"[u'\\xfc']" because __repr__ returns a 8bit escape encoded string, it would be better if the result was u"[u'\xfc']", but this would require a PyObject_UnicodeRepr (and/or changing the list tp_str slot (and many others) to return Unicode) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-21 07:13 Message: Logged In: YES user_id=6380 I'm not keen on extending the str() signature. str() takes other argument types besides Unicode strings, but the encoding arguments only make sense for Unicode strings - ergo, I think the encoding should be a Unicode string method (which it is). I do think that PyObject_Unicode() in C should be closely tied to unicode() in Python. ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-09-21 05:23 Message: Logged In: YES user_id=89016 I've read the following in Misc/NEWS "PyUnicode_FromEncodedObject() now works very much like PyObject_Str(obj) in that it tries to use __str__/tp_str on the object if the object is not a string or buffer. This makes unicode() behave like str() when applied to non- string/buffer objects." I think this is the wrong way: The string constructor uses PyObject_Str, so the unicode constructor should use PyObject_Unicode (i.e. the extended version). As PyObject_UnicodeEx has additional arguments, maybe we should have a new function PyObject_StrEx with these additional arguments too. Then the string constructor could have these arguments too: >>> print str(u"\xfc\u2014", "latin-1", "replace") ь? This would really make string and unicode symmetric: unicode() creates a string either directy or via __str__/tp_str, if it encounters a 8bit string it uses the encoding and errors parameters to *decode* it. Likewise str () creates a 8bit string either directly or via __str__/tp_str, if it encounters a unicode object it uses the encoding and errors parameters to *encode* it. Would this change to the str constructor result in any backwards incompatiblities? ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-09-20 05:50 Message: Logged In: YES user_id=89016 OK, the new patch no longer changes the PyObject_Unicode signature. Now there are two functions: PyObject_Unicode with the old signature, and PyObject_UnicodeEx, which has the additional encoding and errors arguments. PyObject_Unicode(x) simply calls PyObject_UnicodeEx (x,NULL,NULL) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-09-20 03:56 Message: Logged In: YES user_id=38388 Rejecting this patch: see patch #413333 -- this is basically the same request and the patch is not usable since it breaks the Unicode C API. I still like the idea of making str() and unicode() have similar semantics. ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-08-01 06:55 Message: Logged In: YES user_id=89016 Oops, sorry I accidentally hit the submit button! :-/ The foo class is the one from the first message. str(...) always does a unicodeescape encoding when it encounters a Unicode object, so you'll get escape characters, but this will not be decoded when constructing the unicode object. I.e. u"..." != unicode(str(u"...")). Basically the unicode type should have the same functionality as the str type to ease unicode migration. ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-08-01 06:49 Message: Logged In: YES user_id=89016 >>> unicode(u"ь") u'\xfc' *>>> unicode(str(u"ь")) Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range (128) >>> unicode(foo(u"ь")) u'\xfc' *>>> unicode(str(foo(u"ь"))) Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range (128) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-01 06:45 Message: Logged In: YES user_id=6380 What does this have to offer over unicode(str(x))? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 From noreply@sourceforge.net Fri Sep 21 15:28:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Sep 2001 07:28:59 -0700 Subject: [Patches] [ python-Patches-446754 ] Enhanced unicode constructor Message-ID: Patches item #446754, was opened at 2001-08-01 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 Category: None Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Walter Dцrwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: Enhanced unicode constructor Initial Comment: This patch (against descr-branch) uses a slightly enhanced version of PyObject_Unicode instead of PyUnicode_FromEncodedObject in the unicode constructor (Objects/unicodeobject.h/unicode_new), which gives the unicode constructor the same functionality as the str constructor: creating string representations with the __str__ method/tp_str slot. Example: Python 2.2a1 (#10, Aug 1 2001, 14:26:06) [GCC 2.95.2 19991024 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> str("u"), unicode("u") ('u', u'u') >>> str(u"u"), unicode(u"u") ('u', u'u') >>> str(None), unicode(None) ('None', u'None') >>> str(42), unicode(42) ('42', u'42') >>> str(23.), unicode(23.) ('23.0', u'23.0') >>> str([1,2,3]), unicode([1,2,3]) ('[1, 2, 3]', u'[1, 2, 3]') >>> str({"u": 23, u"ь": 42}), unicode({"u": 23, u"ь": 42}) ("{'u': 23, u'\xfc': 42}", u"{'u': 23, u'\\xfc': 42}") >>> class foo: ... def __init__(self, x): ... self.x = x ... def __str__(self): ... return self.x ... >>> str(foo("bar")), unicode(foo("bar")) ('bar', u'bar') >>> str(foo(u"bar")), unicode(foo(u"bar")) ('bar', u'bar') Passing the encoding and errors argument still works and the will be used for any 8bit string returned from __str__. Perhaps for symmetry encoding and errors arguments should be added to the str constructor too, which will be used when a unicode object is returned from __str__ for encoding the object. One problem is that unicode([u"ь"]) returns u"[u'\\xfc']" because __repr__ returns a 8bit escape encoded string, it would be better if the result was u"[u'\xfc']", but this would require a PyObject_UnicodeRepr (and/or changing the list tp_str slot (and many others) to return Unicode) ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-09-21 07:28 Message: Logged In: YES user_id=38388 Let's move this discussion to python-dev. I've already started a thread on it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-21 07:13 Message: Logged In: YES user_id=6380 I'm not keen on extending the str() signature. str() takes other argument types besides Unicode strings, but the encoding arguments only make sense for Unicode strings - ergo, I think the encoding should be a Unicode string method (which it is). I do think that PyObject_Unicode() in C should be closely tied to unicode() in Python. ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-09-21 05:23 Message: Logged In: YES user_id=89016 I've read the following in Misc/NEWS "PyUnicode_FromEncodedObject() now works very much like PyObject_Str(obj) in that it tries to use __str__/tp_str on the object if the object is not a string or buffer. This makes unicode() behave like str() when applied to non- string/buffer objects." I think this is the wrong way: The string constructor uses PyObject_Str, so the unicode constructor should use PyObject_Unicode (i.e. the extended version). As PyObject_UnicodeEx has additional arguments, maybe we should have a new function PyObject_StrEx with these additional arguments too. Then the string constructor could have these arguments too: >>> print str(u"\xfc\u2014", "latin-1", "replace") ь? This would really make string and unicode symmetric: unicode() creates a string either directy or via __str__/tp_str, if it encounters a 8bit string it uses the encoding and errors parameters to *decode* it. Likewise str () creates a 8bit string either directly or via __str__/tp_str, if it encounters a unicode object it uses the encoding and errors parameters to *encode* it. Would this change to the str constructor result in any backwards incompatiblities? ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-09-20 05:50 Message: Logged In: YES user_id=89016 OK, the new patch no longer changes the PyObject_Unicode signature. Now there are two functions: PyObject_Unicode with the old signature, and PyObject_UnicodeEx, which has the additional encoding and errors arguments. PyObject_Unicode(x) simply calls PyObject_UnicodeEx (x,NULL,NULL) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-09-20 03:56 Message: Logged In: YES user_id=38388 Rejecting this patch: see patch #413333 -- this is basically the same request and the patch is not usable since it breaks the Unicode C API. I still like the idea of making str() and unicode() have similar semantics. ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-08-01 06:55 Message: Logged In: YES user_id=89016 Oops, sorry I accidentally hit the submit button! :-/ The foo class is the one from the first message. str(...) always does a unicodeescape encoding when it encounters a Unicode object, so you'll get escape characters, but this will not be decoded when constructing the unicode object. I.e. u"..." != unicode(str(u"...")). Basically the unicode type should have the same functionality as the str type to ease unicode migration. ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-08-01 06:49 Message: Logged In: YES user_id=89016 >>> unicode(u"ь") u'\xfc' *>>> unicode(str(u"ь")) Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range (128) >>> unicode(foo(u"ь")) u'\xfc' *>>> unicode(str(foo(u"ь"))) Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range (128) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-01 06:45 Message: Logged In: YES user_id=6380 What does this have to offer over unicode(str(x))? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 From noreply@sourceforge.net Fri Sep 21 15:56:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Sep 2001 07:56:26 -0700 Subject: [Patches] [ python-Patches-446754 ] Enhanced unicode constructor Message-ID: Patches item #446754, was opened at 2001-08-01 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 Category: None Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Walter Dцrwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: Enhanced unicode constructor Initial Comment: This patch (against descr-branch) uses a slightly enhanced version of PyObject_Unicode instead of PyUnicode_FromEncodedObject in the unicode constructor (Objects/unicodeobject.h/unicode_new), which gives the unicode constructor the same functionality as the str constructor: creating string representations with the __str__ method/tp_str slot. Example: Python 2.2a1 (#10, Aug 1 2001, 14:26:06) [GCC 2.95.2 19991024 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> str("u"), unicode("u") ('u', u'u') >>> str(u"u"), unicode(u"u") ('u', u'u') >>> str(None), unicode(None) ('None', u'None') >>> str(42), unicode(42) ('42', u'42') >>> str(23.), unicode(23.) ('23.0', u'23.0') >>> str([1,2,3]), unicode([1,2,3]) ('[1, 2, 3]', u'[1, 2, 3]') >>> str({"u": 23, u"ь": 42}), unicode({"u": 23, u"ь": 42}) ("{'u': 23, u'\xfc': 42}", u"{'u': 23, u'\\xfc': 42}") >>> class foo: ... def __init__(self, x): ... self.x = x ... def __str__(self): ... return self.x ... >>> str(foo("bar")), unicode(foo("bar")) ('bar', u'bar') >>> str(foo(u"bar")), unicode(foo(u"bar")) ('bar', u'bar') Passing the encoding and errors argument still works and the will be used for any 8bit string returned from __str__. Perhaps for symmetry encoding and errors arguments should be added to the str constructor too, which will be used when a unicode object is returned from __str__ for encoding the object. One problem is that unicode([u"ь"]) returns u"[u'\\xfc']" because __repr__ returns a 8bit escape encoded string, it would be better if the result was u"[u'\xfc']", but this would require a PyObject_UnicodeRepr (and/or changing the list tp_str slot (and many others) to return Unicode) ---------------------------------------------------------------------- >Comment By: Walter Dцrwald (doerwalter) Date: 2001-09-21 07:56 Message: Logged In: YES user_id=89016 I'm not on python-dev. http://mail.python.org/mailman/listinfo/python-dev says: "Subscription is by invitation only" ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-09-21 07:28 Message: Logged In: YES user_id=38388 Let's move this discussion to python-dev. I've already started a thread on it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-21 07:13 Message: Logged In: YES user_id=6380 I'm not keen on extending the str() signature. str() takes other argument types besides Unicode strings, but the encoding arguments only make sense for Unicode strings - ergo, I think the encoding should be a Unicode string method (which it is). I do think that PyObject_Unicode() in C should be closely tied to unicode() in Python. ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-09-21 05:23 Message: Logged In: YES user_id=89016 I've read the following in Misc/NEWS "PyUnicode_FromEncodedObject() now works very much like PyObject_Str(obj) in that it tries to use __str__/tp_str on the object if the object is not a string or buffer. This makes unicode() behave like str() when applied to non- string/buffer objects." I think this is the wrong way: The string constructor uses PyObject_Str, so the unicode constructor should use PyObject_Unicode (i.e. the extended version). As PyObject_UnicodeEx has additional arguments, maybe we should have a new function PyObject_StrEx with these additional arguments too. Then the string constructor could have these arguments too: >>> print str(u"\xfc\u2014", "latin-1", "replace") ь? This would really make string and unicode symmetric: unicode() creates a string either directy or via __str__/tp_str, if it encounters a 8bit string it uses the encoding and errors parameters to *decode* it. Likewise str () creates a 8bit string either directly or via __str__/tp_str, if it encounters a unicode object it uses the encoding and errors parameters to *encode* it. Would this change to the str constructor result in any backwards incompatiblities? ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-09-20 05:50 Message: Logged In: YES user_id=89016 OK, the new patch no longer changes the PyObject_Unicode signature. Now there are two functions: PyObject_Unicode with the old signature, and PyObject_UnicodeEx, which has the additional encoding and errors arguments. PyObject_Unicode(x) simply calls PyObject_UnicodeEx (x,NULL,NULL) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-09-20 03:56 Message: Logged In: YES user_id=38388 Rejecting this patch: see patch #413333 -- this is basically the same request and the patch is not usable since it breaks the Unicode C API. I still like the idea of making str() and unicode() have similar semantics. ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-08-01 06:55 Message: Logged In: YES user_id=89016 Oops, sorry I accidentally hit the submit button! :-/ The foo class is the one from the first message. str(...) always does a unicodeescape encoding when it encounters a Unicode object, so you'll get escape characters, but this will not be decoded when constructing the unicode object. I.e. u"..." != unicode(str(u"...")). Basically the unicode type should have the same functionality as the str type to ease unicode migration. ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-08-01 06:49 Message: Logged In: YES user_id=89016 >>> unicode(u"ь") u'\xfc' *>>> unicode(str(u"ь")) Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range (128) >>> unicode(foo(u"ь")) u'\xfc' *>>> unicode(str(foo(u"ь"))) Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range (128) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-01 06:45 Message: Logged In: YES user_id=6380 What does this have to offer over unicode(str(x))? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 From noreply@sourceforge.net Fri Sep 21 16:03:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Sep 2001 08:03:22 -0700 Subject: [Patches] [ python-Patches-446754 ] Enhanced unicode constructor Message-ID: Patches item #446754, was opened at 2001-08-01 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 Category: None Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Walter Dцrwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: Enhanced unicode constructor Initial Comment: This patch (against descr-branch) uses a slightly enhanced version of PyObject_Unicode instead of PyUnicode_FromEncodedObject in the unicode constructor (Objects/unicodeobject.h/unicode_new), which gives the unicode constructor the same functionality as the str constructor: creating string representations with the __str__ method/tp_str slot. Example: Python 2.2a1 (#10, Aug 1 2001, 14:26:06) [GCC 2.95.2 19991024 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> str("u"), unicode("u") ('u', u'u') >>> str(u"u"), unicode(u"u") ('u', u'u') >>> str(None), unicode(None) ('None', u'None') >>> str(42), unicode(42) ('42', u'42') >>> str(23.), unicode(23.) ('23.0', u'23.0') >>> str([1,2,3]), unicode([1,2,3]) ('[1, 2, 3]', u'[1, 2, 3]') >>> str({"u": 23, u"ь": 42}), unicode({"u": 23, u"ь": 42}) ("{'u': 23, u'\xfc': 42}", u"{'u': 23, u'\\xfc': 42}") >>> class foo: ... def __init__(self, x): ... self.x = x ... def __str__(self): ... return self.x ... >>> str(foo("bar")), unicode(foo("bar")) ('bar', u'bar') >>> str(foo(u"bar")), unicode(foo(u"bar")) ('bar', u'bar') Passing the encoding and errors argument still works and the will be used for any 8bit string returned from __str__. Perhaps for symmetry encoding and errors arguments should be added to the str constructor too, which will be used when a unicode object is returned from __str__ for encoding the object. One problem is that unicode([u"ь"]) returns u"[u'\\xfc']" because __repr__ returns a 8bit escape encoded string, it would be better if the result was u"[u'\xfc']", but this would require a PyObject_UnicodeRepr (and/or changing the list tp_str slot (and many others) to return Unicode) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-21 08:03 Message: Logged In: YES user_id=6380 Consider yourself invited. :-) ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-09-21 07:56 Message: Logged In: YES user_id=89016 I'm not on python-dev. http://mail.python.org/mailman/listinfo/python-dev says: "Subscription is by invitation only" ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-09-21 07:28 Message: Logged In: YES user_id=38388 Let's move this discussion to python-dev. I've already started a thread on it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-21 07:13 Message: Logged In: YES user_id=6380 I'm not keen on extending the str() signature. str() takes other argument types besides Unicode strings, but the encoding arguments only make sense for Unicode strings - ergo, I think the encoding should be a Unicode string method (which it is). I do think that PyObject_Unicode() in C should be closely tied to unicode() in Python. ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-09-21 05:23 Message: Logged In: YES user_id=89016 I've read the following in Misc/NEWS "PyUnicode_FromEncodedObject() now works very much like PyObject_Str(obj) in that it tries to use __str__/tp_str on the object if the object is not a string or buffer. This makes unicode() behave like str() when applied to non- string/buffer objects." I think this is the wrong way: The string constructor uses PyObject_Str, so the unicode constructor should use PyObject_Unicode (i.e. the extended version). As PyObject_UnicodeEx has additional arguments, maybe we should have a new function PyObject_StrEx with these additional arguments too. Then the string constructor could have these arguments too: >>> print str(u"\xfc\u2014", "latin-1", "replace") ь? This would really make string and unicode symmetric: unicode() creates a string either directy or via __str__/tp_str, if it encounters a 8bit string it uses the encoding and errors parameters to *decode* it. Likewise str () creates a 8bit string either directly or via __str__/tp_str, if it encounters a unicode object it uses the encoding and errors parameters to *encode* it. Would this change to the str constructor result in any backwards incompatiblities? ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-09-20 05:50 Message: Logged In: YES user_id=89016 OK, the new patch no longer changes the PyObject_Unicode signature. Now there are two functions: PyObject_Unicode with the old signature, and PyObject_UnicodeEx, which has the additional encoding and errors arguments. PyObject_Unicode(x) simply calls PyObject_UnicodeEx (x,NULL,NULL) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-09-20 03:56 Message: Logged In: YES user_id=38388 Rejecting this patch: see patch #413333 -- this is basically the same request and the patch is not usable since it breaks the Unicode C API. I still like the idea of making str() and unicode() have similar semantics. ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-08-01 06:55 Message: Logged In: YES user_id=89016 Oops, sorry I accidentally hit the submit button! :-/ The foo class is the one from the first message. str(...) always does a unicodeescape encoding when it encounters a Unicode object, so you'll get escape characters, but this will not be decoded when constructing the unicode object. I.e. u"..." != unicode(str(u"...")). Basically the unicode type should have the same functionality as the str type to ease unicode migration. ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-08-01 06:49 Message: Logged In: YES user_id=89016 >>> unicode(u"ь") u'\xfc' *>>> unicode(str(u"ь")) Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range (128) >>> unicode(foo(u"ь")) u'\xfc' *>>> unicode(str(foo(u"ь"))) Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range (128) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-01 06:45 Message: Logged In: YES user_id=6380 What does this have to offer over unicode(str(x))? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 From noreply@sourceforge.net Fri Sep 21 19:01:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Sep 2001 11:01:08 -0700 Subject: [Patches] [ python-Patches-462296 ] Add attributes to os.stat results Message-ID: Patches item #462296, was opened at 2001-09-17 10:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Add attributes to os.stat results Initial Comment: See bug #111481, and PEP 0042. Both suggest that the return values for os.{stat,lstat,statvfs,fstatvfs} ought to be struct-like objects rather than simple tuples. With this patch, the os module will modify the aformentioned functions so that their results still obey the previous tuple protocol, but now have read-only attributes as well. In other words, "os.stat('filename')[0]" is now synonymous with "os.stat('filename').st_mode. The patch also modifies test_os.py to test the new behavior. In order to prevent old code from breaking, these new return types extend tuple. They also use the new attribute descriptor interface. (Thanks for PEP-025[23], Guido!) Backward compatibility: Code will only break if it assumes that type(os.stat(...)) == TupleType, or if it assumes that os.stat(...) has no attributes beyond those defined in tuple. ---------------------------------------------------------------------- >Comment By: Nick Mathewson (nickm) Date: 2001-09-21 11:01 Message: Logged In: YES user_id=499 Well, here's a posixmodule-only, all-C version. If this seems like a good approach, I'll add some better docstrings, move it into whichever module you like, and make riscosmodule.c and macmodule.c use it too. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-19 21:35 Message: Logged In: YES user_id=6380 Or you could put it in modsupport.c, which is already a grab-bag of handy stuff. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-19 11:36 Message: Logged In: YES user_id=21627 There aren't actually so many copies of the module, since posixmodule implements "posix","nt", and "os2". I found alternative implementations in riscosmodule and macmodule. Still, putting the support type into a shared C file is appropriate. I can think of two candidate places: tupleobject.c and fileobject.c. It may be actually worthwhile attempting to share the stat() implementations as well, but that could be an add-on. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-19 11:10 Message: Logged In: YES user_id=499 I'm becoming more and more convinced that doing it in C is the right thing, but I have issue with doing it in the posix module. The stat function is provided on (nearly?) all platforms, and doing it in C will require minor changes to all of these modules. We can probably live with this, but I don't think we should duplicate code between all of the os modules. Is there some other appropriate place to put it in C? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-18 23:52 Message: Logged In: YES user_id=21627 Using posix.stat is common, see http://groups.yahoo.com/group/python-list/message/4349 http://www.washington.edu/computing/training/125/mkdoc.html http://groups.google.com/groups?th=7d7d118fed161e0&seekm=5qdjch%24dci%40nntp6.u.washington.edu for examples. None of these would break with your change, though, since they don't rely on the lenght of the tuple. If you are going to implement the type in C, I'd put it in the posix module. If you are going to implement it in Python (and only use it from the Posix module), making it general-purpose may be desirable. However, a number of things would need to be considered, so a PEP might be appropriate. If that is done, I'd propose an interface like tuple_with_attrs((value-tuple), (tuple-of-field-names), exposed-length-of-tuple)) ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-18 14:11 Message: Logged In: YES user_id=499 Ah! Now I see. I hadn't realized that anybody used the posix module directly. (People really do this?) I'll try to write up a patch in C tonight or tomorrow morning. A couple of questions on which I could use advice: (1) Where is the proper place to put this kind of tuple-with-fields hybrid? Modules? Objects? In a new file or an existing one? (2) Should I try to make it general enough for non-stat use? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-18 00:54 Message: Logged In: YES user_id=21627 The problem with your second and third patch is that it includes an incompatibility for users of posix.stat (and friends), since it changes the siye of the tuple. If you want to continue to return a tuple (as the top-level data structure), you'll break compatibility for applications using the C module directly. An example of code that would be broken is mode, ino, dev, nlink, uid, gid, size, a, c, m = posix.stat(filename) To pass the additional fields, you already need your class _StatResult available in C. You may find a way to define it in Python and use it in C, but that has proven to be very fragile in the past. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-17 18:54 Message: Logged In: YES user_id=6380 Haven't had time to review the patch yet, but the idea of providing a structure with fields that doubles as a tuple is a good one. It's been tried before and can be done in pure Python as well. Regarding the field names: I think the field names should keep their st_ prefix -- IMO this makes the code more recognizable and hence readable. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 17:32 Message: Logged In: YES user_id=499 Here's the revised (*example only*) patch that takes the more portable approach I mention below. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 16:10 Message: Logged In: YES user_id=499 On further consideration, the approach taken in the second (*example only*) patch is indeed too fragile. The C code should not lengthen the tuple arbitrarily and depend on the Python code to decode it; instead, it should return a dictionary of extra fields. I think that this approach uses a minimum of C, is easily maintainable, and very extensible. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 15:53 Message: Logged In: YES user_id=499 Martin: I'm not entirely sure what you mean here; while my patch for extra fields requires a minor chunk of C (to access the struct fields), the rest still works in pure python. I'm attaching this second version for reference. I'm not sure it makes much sense to do this with pure C; it would certainly take a lot more code, with little benefit I can descern. But you're more experienced than I; what am I missing? I agree that the field naming is suboptimal; I was taking my lead from the stat and statvfs modules. If people prefer, we can name the fields whatever we like. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-17 15:24 Message: Logged In: YES user_id=21627 I second the request for supporting additional fields where available. At the same time, it appears unimplementable using pure Python. Consequently, I'd like to see this patch redone in C. The implementation strategy could probably remain the same, i.e. inherit from tuple for best compatibility; add the remaining fields as slots. It may be reasonable to implement attribute access using a custom getattr function, though. I have also my doubts about the naming of the fields. The st_ prefix originates from the time where struct fields were living in the global namespace (i.e. across different structures), so prefixing them for uniqueness was essential. I'm not sure whether we should inherit this into Python... ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 13:58 Message: Logged In: YES user_id=499 BTW, if this gets in, I have another patch that adds support for st_blksize, st_blocks, and st_rdev on platforms that support them. It don't expose these new fields in the tuple, as that would break all the old code that tries to unpack all the fields of the tuple. Instead, these fields are only accessible as attributes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 From noreply@sourceforge.net Fri Sep 21 20:12:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Sep 2001 12:12:42 -0700 Subject: [Patches] [ python-Patches-463656 ] setup.py, --with-includepath, and LD_LIB Message-ID: Patches item #463656, was opened at 2001-09-21 12:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=463656&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Nobody/Anonymous (nobody) Summary: setup.py, --with-includepath, and LD_LIB Initial Comment: This patch improves the module detection capability in setup.py. The following improvements are implemented: - directories listed in LD_LIBRARY_PATH are also searched for shared libraries. - the --with-includepath option has been added to configure, to specify additional non-standard directories where the include files are to be searched for. The corresponding changes were added to setup.py (new function detect_include(), find_library_file() augmented, detect_tkinter() improved) I retroceeded manually the changes from configure into configure.in, but I did not run autoconf; you might want to double-check this. Sample aplication: ./configure --prefix=/something --with-includepath='/mgl/apps/include:/mgl/share/include' With this patch, I get Tkinter to build correctly without editing the Setup files, with non-standard tckl/tk 8.0 to 8.3 installations. where the only tcl.h file is in /mgl/share/include/tcl8.0 (therefore, tkinter is build with tcl8.0 on this configuration). FG ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=463656&group_id=5470 From noreply@sourceforge.net Fri Sep 21 21:07:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Sep 2001 13:07:34 -0700 Subject: [Patches] [ python-Patches-462296 ] Add attributes to os.stat results Message-ID: Patches item #462296, was opened at 2001-09-17 10:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Add attributes to os.stat results Initial Comment: See bug #111481, and PEP 0042. Both suggest that the return values for os.{stat,lstat,statvfs,fstatvfs} ought to be struct-like objects rather than simple tuples. With this patch, the os module will modify the aformentioned functions so that their results still obey the previous tuple protocol, but now have read-only attributes as well. In other words, "os.stat('filename')[0]" is now synonymous with "os.stat('filename').st_mode. The patch also modifies test_os.py to test the new behavior. In order to prevent old code from breaking, these new return types extend tuple. They also use the new attribute descriptor interface. (Thanks for PEP-025[23], Guido!) Backward compatibility: Code will only break if it assumes that type(os.stat(...)) == TupleType, or if it assumes that os.stat(...) has no attributes beyond those defined in tuple. ---------------------------------------------------------------------- >Comment By: Nick Mathewson (nickm) Date: 2001-09-21 13:07 Message: Logged In: YES user_id=499 And here's an even better all-C version. (This one doesn't use a dictionary to store optional attributes.) ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-21 11:01 Message: Logged In: YES user_id=499 Well, here's a posixmodule-only, all-C version. If this seems like a good approach, I'll add some better docstrings, move it into whichever module you like, and make riscosmodule.c and macmodule.c use it too. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-19 21:35 Message: Logged In: YES user_id=6380 Or you could put it in modsupport.c, which is already a grab-bag of handy stuff. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-19 11:36 Message: Logged In: YES user_id=21627 There aren't actually so many copies of the module, since posixmodule implements "posix","nt", and "os2". I found alternative implementations in riscosmodule and macmodule. Still, putting the support type into a shared C file is appropriate. I can think of two candidate places: tupleobject.c and fileobject.c. It may be actually worthwhile attempting to share the stat() implementations as well, but that could be an add-on. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-19 11:10 Message: Logged In: YES user_id=499 I'm becoming more and more convinced that doing it in C is the right thing, but I have issue with doing it in the posix module. The stat function is provided on (nearly?) all platforms, and doing it in C will require minor changes to all of these modules. We can probably live with this, but I don't think we should duplicate code between all of the os modules. Is there some other appropriate place to put it in C? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-18 23:52 Message: Logged In: YES user_id=21627 Using posix.stat is common, see http://groups.yahoo.com/group/python-list/message/4349 http://www.washington.edu/computing/training/125/mkdoc.html http://groups.google.com/groups?th=7d7d118fed161e0&seekm=5qdjch%24dci%40nntp6.u.washington.edu for examples. None of these would break with your change, though, since they don't rely on the lenght of the tuple. If you are going to implement the type in C, I'd put it in the posix module. If you are going to implement it in Python (and only use it from the Posix module), making it general-purpose may be desirable. However, a number of things would need to be considered, so a PEP might be appropriate. If that is done, I'd propose an interface like tuple_with_attrs((value-tuple), (tuple-of-field-names), exposed-length-of-tuple)) ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-18 14:11 Message: Logged In: YES user_id=499 Ah! Now I see. I hadn't realized that anybody used the posix module directly. (People really do this?) I'll try to write up a patch in C tonight or tomorrow morning. A couple of questions on which I could use advice: (1) Where is the proper place to put this kind of tuple-with-fields hybrid? Modules? Objects? In a new file or an existing one? (2) Should I try to make it general enough for non-stat use? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-18 00:54 Message: Logged In: YES user_id=21627 The problem with your second and third patch is that it includes an incompatibility for users of posix.stat (and friends), since it changes the siye of the tuple. If you want to continue to return a tuple (as the top-level data structure), you'll break compatibility for applications using the C module directly. An example of code that would be broken is mode, ino, dev, nlink, uid, gid, size, a, c, m = posix.stat(filename) To pass the additional fields, you already need your class _StatResult available in C. You may find a way to define it in Python and use it in C, but that has proven to be very fragile in the past. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-17 18:54 Message: Logged In: YES user_id=6380 Haven't had time to review the patch yet, but the idea of providing a structure with fields that doubles as a tuple is a good one. It's been tried before and can be done in pure Python as well. Regarding the field names: I think the field names should keep their st_ prefix -- IMO this makes the code more recognizable and hence readable. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 17:32 Message: Logged In: YES user_id=499 Here's the revised (*example only*) patch that takes the more portable approach I mention below. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 16:10 Message: Logged In: YES user_id=499 On further consideration, the approach taken in the second (*example only*) patch is indeed too fragile. The C code should not lengthen the tuple arbitrarily and depend on the Python code to decode it; instead, it should return a dictionary of extra fields. I think that this approach uses a minimum of C, is easily maintainable, and very extensible. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 15:53 Message: Logged In: YES user_id=499 Martin: I'm not entirely sure what you mean here; while my patch for extra fields requires a minor chunk of C (to access the struct fields), the rest still works in pure python. I'm attaching this second version for reference. I'm not sure it makes much sense to do this with pure C; it would certainly take a lot more code, with little benefit I can descern. But you're more experienced than I; what am I missing? I agree that the field naming is suboptimal; I was taking my lead from the stat and statvfs modules. If people prefer, we can name the fields whatever we like. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-17 15:24 Message: Logged In: YES user_id=21627 I second the request for supporting additional fields where available. At the same time, it appears unimplementable using pure Python. Consequently, I'd like to see this patch redone in C. The implementation strategy could probably remain the same, i.e. inherit from tuple for best compatibility; add the remaining fields as slots. It may be reasonable to implement attribute access using a custom getattr function, though. I have also my doubts about the naming of the fields. The st_ prefix originates from the time where struct fields were living in the global namespace (i.e. across different structures), so prefixing them for uniqueness was essential. I'm not sure whether we should inherit this into Python... ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 13:58 Message: Logged In: YES user_id=499 BTW, if this gets in, I have another patch that adds support for st_blksize, st_blocks, and st_rdev on platforms that support them. It don't expose these new fields in the tuple, as that would break all the old code that tries to unpack all the fields of the tuple. Instead, these fields are only accessible as attributes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 From noreply@sourceforge.net Fri Sep 21 23:01:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Sep 2001 15:01:20 -0700 Subject: [Patches] [ python-Patches-430706 ] Persistent connections in BaseHTTPServer Message-ID: Patches item #430706, was opened at 2001-06-06 08:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=430706&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Lawrence (lordsutch) Assigned to: Martin v. Lцwis (loewis) Summary: Persistent connections in BaseHTTPServer Initial Comment: This patch provides HTTP/1.1 persistent connection support in BaseHTTPServer.py. It is not enabled by default (for backwards compatibility) because Content-Length headers must be supplied for persistent connections to work correctly. ---------------------------------------------------------------------- >Comment By: Chris Lawrence (lordsutch) Date: 2001-09-21 15:01 Message: Logged In: YES user_id=6757 I've tracked that one down and will have an updated patch in a day or two... basically it just needs another else condition to handle the empty readline(). There are also some issues for subclasses that probably need to be documented to play nicely with bad clients like wget that claim to be HTTP 1.0 but do HTTP 1.1 stuff. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-18 09:36 Message: Logged In: YES user_id=21627 It still doesn't work right. If I access SimpleHTTPServer from a Netscape client, I get error messages like localhost - - [18/Sep/2001 18:32:22] code 400, message Bad request syntax ('') localhost - - [18/Sep/2001 18:32:22] "" 400 - These are caused because the client closes the connection after the first request (likely, after it finds out that the document it got contains no references to the same server anymore). However, the server continues to invoke handle_one_request, which reads the empty line and fails to recognize that the client has closed the connection. ---------------------------------------------------------------------- Comment By: Chris Lawrence (lordsutch) Date: 2001-09-15 01:15 Message: Logged In: YES user_id=6757 I reworked the patch a bit to ensure HTTP 1.1 mode is only used if the handler class is in HTTP 1.1 mode, and modified the test() functions in the server classes to add a "protocol" option. I also modified SimpleHTTPServer to send Content-Length headers for the implemented classes. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-04 04:40 Message: Logged In: YES user_id=21627 The patch in its current form seems to be broken. To see the problem, please run SimpleHTTPServer on some directory, then access it with a HTTP/1.1 client (e.g. Netscape 4.7). The server will use the protocol version HTTP/1.0, but the client will initially send 1.1, and send a Connection: Keep-alive header. As a result, self.close_connection is set to 0, despite using HTTP/1.0. In turn, the HTTP server won't send a content length, and won't close the connection either. Netscape waits forever from some completion which never occurs, since the server waits for the next request on the same connection. It might be useful to enhance the SimpleHTTPServer test() function to optionally operate in HTTP/1.1 mode (including sending a proper ContentLength). Doing the same for the CGI HTTP server is probably less useful. ---------------------------------------------------------------------- Comment By: Chris Lawrence (lordsutch) Date: 2001-08-29 20:21 Message: Logged In: YES user_id=6757 I have updated the patch against current CVS and have added documentation. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-08 13:43 Message: Logged In: YES user_id=21627 I haven't studied the patch in detail, yet, but I have a few comments on the style: - there is no need to quote all authors of the RFC. Also, the reference to long-ago expired HTTP draft should go; just replace it with a single reference to the RFC number (giving an URL for the RFC might be convenient) - Where is the documentation? A patch to Doc/lib/libbasehttp.tex would be appreciated. If you don't speak TeX, don't worry: Just write plain text, we'll do the mark-up. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=430706&group_id=5470 From noreply@sourceforge.net Fri Sep 21 23:21:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Sep 2001 15:21:02 -0700 Subject: [Patches] [ python-Patches-463698 ] add iterator IF to StringIO/cStringIO Message-ID: Patches item #463698, was opened at 2001-09-21 15:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=463698&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barry Warsaw (bwarsaw) Assigned to: Tim Peters (tim_one) Summary: add iterator IF to StringIO/cStringIO Initial Comment: The following patch adds support for the iterator interface in both StringIO and cStringIO. Like file objects, iter(aStringIO) or iter(a_cStringIO) gives an iterator object whose .next() method traverses by calling readline() on the underlying object, raising StopIteration when an empty string is reached. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=463698&group_id=5470 From noreply@sourceforge.net Fri Sep 21 23:48:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Sep 2001 15:48:47 -0700 Subject: [Patches] [ python-Patches-463698 ] add iterator IF to StringIO/cStringIO Message-ID: Patches item #463698, was opened at 2001-09-21 15:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=463698&group_id=5470 Category: Library (Lib) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Barry Warsaw (bwarsaw) >Assigned to: Barry Warsaw (bwarsaw) Summary: add iterator IF to StringIO/cStringIO Initial Comment: The following patch adds support for the iterator interface in both StringIO and cStringIO. Like file objects, iter(aStringIO) or iter(a_cStringIO) gives an iterator object whose .next() method traverses by calling readline() on the underlying object, raising StopIteration when an empty string is reached. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-09-21 15:48 Message: Logged In: YES user_id=31435 The code looks fine, but you need doc changes and some new test cases (in test_StringIO.py) too. But you knew that, so I won't insult you by mentioning it . ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=463698&group_id=5470 From noreply@sourceforge.net Sat Sep 22 04:14:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Sep 2001 20:14:44 -0700 Subject: [Patches] [ python-Patches-463698 ] add iterator IF to StringIO/cStringIO Message-ID: Patches item #463698, was opened at 2001-09-21 15:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=463698&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Barry Warsaw (bwarsaw) Assigned to: Barry Warsaw (bwarsaw) Summary: add iterator IF to StringIO/cStringIO Initial Comment: The following patch adds support for the iterator interface in both StringIO and cStringIO. Like file objects, iter(aStringIO) or iter(a_cStringIO) gives an iterator object whose .next() method traverses by calling readline() on the underlying object, raising StopIteration when an empty string is reached. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-09-21 20:14 Message: Logged In: YES user_id=12800 Thank you. :) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-21 15:48 Message: Logged In: YES user_id=31435 The code looks fine, but you need doc changes and some new test cases (in test_StringIO.py) too. But you knew that, so I won't insult you by mentioning it . ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=463698&group_id=5470 From noreply@sourceforge.net Sat Sep 22 05:27:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Sep 2001 21:27:03 -0700 Subject: [Patches] [ python-Patches-463698 ] add iterator IF to StringIO/cStringIO Message-ID: Patches item #463698, was opened at 2001-09-21 15:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=463698&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Barry Warsaw (bwarsaw) Assigned to: Barry Warsaw (bwarsaw) Summary: add iterator IF to StringIO/cStringIO Initial Comment: The following patch adds support for the iterator interface in both StringIO and cStringIO. Like file objects, iter(aStringIO) or iter(a_cStringIO) gives an iterator object whose .next() method traverses by calling readline() on the underlying object, raising StopIteration when an empty string is reached. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-09-21 21:27 Message: Logged In: YES user_id=12800 Checking in the code & test case. I think the documentation can refer to the fact that StringIO's are file-like, so when file objects document that they can be iterated over, so will StringIO's. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-09-21 20:14 Message: Logged In: YES user_id=12800 Thank you. :) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-21 15:48 Message: Logged In: YES user_id=31435 The code looks fine, but you need doc changes and some new test cases (in test_StringIO.py) too. But you knew that, so I won't insult you by mentioning it . ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=463698&group_id=5470 From noreply@sourceforge.net Sat Sep 22 05:39:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Sep 2001 21:39:39 -0700 Subject: [Patches] [ python-Patches-463698 ] add iterator IF to StringIO/cStringIO Message-ID: Patches item #463698, was opened at 2001-09-21 15:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=463698&group_id=5470 Category: Library (Lib) Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Barry Warsaw (bwarsaw) Assigned to: Barry Warsaw (bwarsaw) Summary: add iterator IF to StringIO/cStringIO Initial Comment: The following patch adds support for the iterator interface in both StringIO and cStringIO. Like file objects, iter(aStringIO) or iter(a_cStringIO) gives an iterator object whose .next() method traverses by calling readline() on the underlying object, raising StopIteration when an empty string is reached. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-09-21 21:39 Message: Logged In: YES user_id=12800 Committed and closed. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-09-21 21:27 Message: Logged In: YES user_id=12800 Checking in the code & test case. I think the documentation can refer to the fact that StringIO's are file-like, so when file objects document that they can be iterated over, so will StringIO's. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-09-21 20:14 Message: Logged In: YES user_id=12800 Thank you. :) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-21 15:48 Message: Logged In: YES user_id=31435 The code looks fine, but you need doc changes and some new test cases (in test_StringIO.py) too. But you knew that, so I won't insult you by mentioning it . ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=463698&group_id=5470 From noreply@sourceforge.net Sun Sep 23 15:03:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 23 Sep 2001 07:03:54 -0700 Subject: [Patches] [ python-Patches-464070 ] Decode underscore in quopri.decode Message-ID: Patches item #464070, was opened at 2001-09-23 07:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=464070&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kent Engstrцm (kente) Assigned to: Nobody/Anonymous (nobody) Summary: Decode underscore in quopri.decode Initial Comment: See bug 463996. This is a minimal implementation of underscore decoding. No encoding. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=464070&group_id=5470 From noreply@sourceforge.net Sun Sep 23 17:27:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 23 Sep 2001 09:27:08 -0700 Subject: [Patches] [ python-Patches-464070 ] Decode underscore in quopri.decode Message-ID: Patches item #464070, was opened at 2001-09-23 07:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=464070&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kent Engstrцm (kente) Assigned to: Nobody/Anonymous (nobody) Summary: Decode underscore in quopri.decode Initial Comment: See bug 463996. This is a minimal implementation of underscore decoding. No encoding. ---------------------------------------------------------------------- >Comment By: Kent Engstrцm (kente) Date: 2001-09-23 09:27 Message: Logged In: YES user_id=178855 Patch upload seems to have failed. Retrying. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=464070&group_id=5470 From GhenadieP@HOTMAIL.COM Sun Sep 23 21:39:33 2001 From: GhenadieP@HOTMAIL.COM (GhenadieP@HOTMAIL.COM) Date: Sun, 23 Sep 2001 22:39:33 +0200 (CEST) Subject: [Patches] regarding job Message-ID: <20010923203933.73C887CAE@shark.amis.net> Dear Sir, I found your e-mail address on the net. I see Your activity is related with software development. I hope you are interested in experienced software developers. I am currently seeking work. If you have a site where I should fill a form, please, reply me, so that I will go there and fill that form. Below is my resume. If in your consideration I can be usefull for you, please call me or send me a message. Thank you. RESUME --------------------------------------------------------------- Name: Ghenadie Plingau Tel: +386 31 710 519 ; +373 2 292976 Email: ghenadiep@hotmail.com; pghena@hotmail.com Language: English, French IT experience: 5+ Years Knowledge’s summary and basic concepts: - Component based design concepts - Object oriented thinking - Windows applications development experience - Microsoft development technologies stickler - database designing and SQL transactions experience - Web UI orientation Good knowledges of Delphi/VCL, C++/COM/ATL, Win32 API, ADO, ODBC, XML, HTTP. Programming tools experience: Visual C++, Visual Basic, Borland C++/Delphi Databases: MS SQLServer, Oracle, Sybase, Access Education: * 1989-1991 Mathematical Lyceum "C.Negruzzi", Iasi, Romania, BSc in Mathematics * 1994-1999 Academy of Economic Studies of Moldova, Banking & SE Career Summary Project: RISP-SQL Time: Dec.2000- Organization: E.R.S. Rokada Inzeniring d.o.o. Ljubljana, Slovenia (rokada@amis.net) Position: Software developer Tools: Delphi, Visual C++, SQL Server 2000 Description: Developing a database application for SQL Server 2000 using Delphi, COM/OLE for internal data interchanging between modules, VCL and ExpressQuantumGrid Suite for UI. Developed multithread applications, wrote recursive stored procedures and extended procedures for SQL Server, ActiveX components for AutoCAD and MS Office automation. Got experience in analyzing database performance, records fetching, SQL coding, Data Warehousing, Data Mining, Data Modeling. Especially focuses on developing data aware components and implementing new features in existed components by adding new properties and events. Created both data aware and non data aware components for performing direct lookup on server by runtime generation of SQL statement and sending them to the server during the information input, that allows only input of names and codes that exists in database directory table. Created an application wizard for automatic upgrading of the structure of target database based on an template script with the condition of keeping the data in the target database using SQL DMO. Created Report designer based on Quick Report libraries that allows runtime customization of report items and bands and storing all settings in an XML file. Designer looks similar like Delphi form designer. Created runtime assembler of application menu out of an XML file that stores GUID and interface method number of each menu item command. Interface is unique and supported by all COM objects. Managing source code using MS Source Safe and created batch files for automating building process and creation of installation kit. Developed modules for Web deployment of reports, dynamical generation of http for web pages. Project: e-tools Time: May 2000 - Sep 2000 Organization: Edifecs Commerce Inc, Seattle, USA (joed@edifecs.com) Position: Independent Contractor Tools: MS Visual C++, WinCVS Description: Developed server side and implemented user interfaces of a component, part of an application designed for business process modeling based on EDI standards. Designed and developed a search engine that seeks in a special formated file that contain EDI standards. Search results are displayed in a tree on the UI or saved in XML format. Designed classes and protocols of data interchanging between them. Worked with linked lists, binary trees, STL containers, templates. Got experience in designing object classes for well encapsulated objects, implementing recursive member functions. Analyzed performance, performed unit tests. Project: SQL-Buch Time: Feb 1999 - May 2000 Organization: Technical University of Moldova, Chisinau, Moldova (perju@adm.utm.md) Position: Software Design Lead Task: Provided technical leadership to a team of developers, developing software for business and financial accounting. Tools: MS Visual C++, MFC, Visual Basic, Delphi, SQL Server, Sybase SQL, MySQL (LINUX), ODBC, ADO, MIDAS, DCOM Description: Was responsible for planning and scheduling technical assignments and goals, defining and analyzing requirements, training, and contributing in performance reviews. Administrated and designed relational databases, wrote SQL code for transactions, implemented User Interfaces, developed multi-tied database applications. Got experience in API level Windows programming. Gained excellent skills in working with all Visual Studio tools. Created COM-based application servers for providing services over a local network and via internet. Created installations kits and CAB files for Web deployment of ActiveX controls. Project: A-BANCO Time: Apr 1996 - Feb 1999 Organization: «A-BANCO» SRL Chisinau, Moldova Position: Programmer Task: Informational support Tools: MS Access, Visual Basic, dBase Description: Developed information system of the company including book keeping, production control and resource management. Worked jointly with book-keepers, solving their needs and requirements. Designed databases, developed application for MS Access using Access tools, VBA coding and MS Office applications automation. Developed a set of MS Access, VB and Delphi applications, which are able to provide any small company from Moldova with the most often used and most needed documents and reports, that meet all accounting standards and are able to facilitate book-keeping and document management. Lots of C and Pascal programming under DOS. From noreply@sourceforge.net Sun Sep 23 22:50:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 23 Sep 2001 14:50:25 -0700 Subject: [Patches] [ python-Patches-462936 ] Improved modulefinder Message-ID: Patches item #462936, was opened at 2001-09-19 10:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462936&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Improved modulefinder Initial Comment: This patch adds two improvements to freeze/modulefinder. 1. ModuleFinder now keeps track of which module is imported by whom. 2. ModuleFinder, when instantiated with the new scan_extdeps=1 argument, tries to track dependencies of builtin and extension modules. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-23 14:50 Message: Logged In: YES user_id=21627 I would still prefer the inelegant approach. Your approach appears to be quite dangerous: the packager would essentially run arbitrary C code... If you absolutely have to use such a feature, I think you can do better than analysing the python -v output: watch sys.modules before and after the import. As for extending the hard-coded knowledge: I was suggesting that the packaging tool that uses modulefinder has a mechanism to extend the hard-coded knowledge by other hard-coded knowledge (which lives in the packaging tool, instead of living in modulefinder). If the packaging tool absolutely wants to, it also could run the Python interpreter through a pipe and put the gathered output into modulefinder :-) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-09-20 02:42 Message: Logged In: YES user_id=11105 The use case is to find as much dependencies as possible. Sure, you cannot assume that importing an extension module finds all dependencies - only those which are executed inside the initmodule function. OTOH, this covers a *lot* of problematic cases, pygame and numpy for example. The situation is (somewhat) similar to finding dependencies of python modules - only those donewith normal import statements are found, __import__, eval, or exec is not handled. A possible solution would be to run the script in 'profiling mode', where the script is actually run, and all imports are monitored. This is however far beyond ModuleFinder's scope. Hardcoding the knowledge about dependencies into ModuleFinder for the core modules would be possible although inelegant IMO. An API for non-standard modules would be possible, but how should this be used without executing any code? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-19 13:28 Message: Logged In: YES user_id=21627 I dislike the chunk on finding external dependencies. What is the typical use case (i.e. what module has what external dependencies)? It seems easier to hard-code knowledge about external dependencies into ModuleFinder; this hard-coded knowledge should cover all core modules. In addition, there should be an API to extend this knowledge for non-standard modules. Furthermore, by executing an import, you cannot be sure that you really find all dependencies - some may only show up when a certain function is used. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462936&group_id=5470 From noreply@sourceforge.net Sun Sep 23 22:53:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 23 Sep 2001 14:53:21 -0700 Subject: [Patches] [ python-Patches-463421 ] speed up md5 module with real memcpy/set Message-ID: Patches item #463421, was opened at 2001-09-20 17:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=463421&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) >Assigned to: Martin v. Lцwis (loewis) Summary: speed up md5 module with real memcpy/set Initial Comment: Modules/md5c.c has its own for loop implementation of memcpy and memset, even with a note that they should be replaced with the real thing if possible. So, this patch just does it. It doesn't use autoconf checks for them since they seem to be used all over the existing code with no such checks so I guess we assume they exist. (some quick tests show about a 12% speedup from this change) ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-23 14:53 Message: Logged In: YES user_id=21627 The patch looks good to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=463421&group_id=5470 From noreply@sourceforge.net Mon Sep 24 09:44:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 24 Sep 2001 01:44:31 -0700 Subject: [Patches] [ python-Patches-462296 ] Add attributes to os.stat results Message-ID: Patches item #462296, was opened at 2001-09-17 10:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Add attributes to os.stat results Initial Comment: See bug #111481, and PEP 0042. Both suggest that the return values for os.{stat,lstat,statvfs,fstatvfs} ought to be struct-like objects rather than simple tuples. With this patch, the os module will modify the aformentioned functions so that their results still obey the previous tuple protocol, but now have read-only attributes as well. In other words, "os.stat('filename')[0]" is now synonymous with "os.stat('filename').st_mode. The patch also modifies test_os.py to test the new behavior. In order to prevent old code from breaking, these new return types extend tuple. They also use the new attribute descriptor interface. (Thanks for PEP-025[23], Guido!) Backward compatibility: Code will only break if it assumes that type(os.stat(...)) == TupleType, or if it assumes that os.stat(...) has no attributes beyond those defined in tuple. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-24 01:44 Message: Logged In: YES user_id=21627 The patch looks good to me. Are you willing to revise it one more time to cover all the stat implementations? A few comments on the implementation: - Why do you try to have your type participate in GC? they will never be part of a cycle. If that ever becomes an issue, you probably need to implement a traversal function as well. - I'd avoid declaring PosixStatResult, since the field declarations are misleading. Instead, you should just add the right number of additional in the type declaration. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-21 13:07 Message: Logged In: YES user_id=499 And here's an even better all-C version. (This one doesn't use a dictionary to store optional attributes.) ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-21 11:01 Message: Logged In: YES user_id=499 Well, here's a posixmodule-only, all-C version. If this seems like a good approach, I'll add some better docstrings, move it into whichever module you like, and make riscosmodule.c and macmodule.c use it too. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-19 21:35 Message: Logged In: YES user_id=6380 Or you could put it in modsupport.c, which is already a grab-bag of handy stuff. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-19 11:36 Message: Logged In: YES user_id=21627 There aren't actually so many copies of the module, since posixmodule implements "posix","nt", and "os2". I found alternative implementations in riscosmodule and macmodule. Still, putting the support type into a shared C file is appropriate. I can think of two candidate places: tupleobject.c and fileobject.c. It may be actually worthwhile attempting to share the stat() implementations as well, but that could be an add-on. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-19 11:10 Message: Logged In: YES user_id=499 I'm becoming more and more convinced that doing it in C is the right thing, but I have issue with doing it in the posix module. The stat function is provided on (nearly?) all platforms, and doing it in C will require minor changes to all of these modules. We can probably live with this, but I don't think we should duplicate code between all of the os modules. Is there some other appropriate place to put it in C? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-18 23:52 Message: Logged In: YES user_id=21627 Using posix.stat is common, see http://groups.yahoo.com/group/python-list/message/4349 http://www.washington.edu/computing/training/125/mkdoc.html http://groups.google.com/groups?th=7d7d118fed161e0&seekm=5qdjch%24dci%40nntp6.u.washington.edu for examples. None of these would break with your change, though, since they don't rely on the lenght of the tuple. If you are going to implement the type in C, I'd put it in the posix module. If you are going to implement it in Python (and only use it from the Posix module), making it general-purpose may be desirable. However, a number of things would need to be considered, so a PEP might be appropriate. If that is done, I'd propose an interface like tuple_with_attrs((value-tuple), (tuple-of-field-names), exposed-length-of-tuple)) ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-18 14:11 Message: Logged In: YES user_id=499 Ah! Now I see. I hadn't realized that anybody used the posix module directly. (People really do this?) I'll try to write up a patch in C tonight or tomorrow morning. A couple of questions on which I could use advice: (1) Where is the proper place to put this kind of tuple-with-fields hybrid? Modules? Objects? In a new file or an existing one? (2) Should I try to make it general enough for non-stat use? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-18 00:54 Message: Logged In: YES user_id=21627 The problem with your second and third patch is that it includes an incompatibility for users of posix.stat (and friends), since it changes the siye of the tuple. If you want to continue to return a tuple (as the top-level data structure), you'll break compatibility for applications using the C module directly. An example of code that would be broken is mode, ino, dev, nlink, uid, gid, size, a, c, m = posix.stat(filename) To pass the additional fields, you already need your class _StatResult available in C. You may find a way to define it in Python and use it in C, but that has proven to be very fragile in the past. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-17 18:54 Message: Logged In: YES user_id=6380 Haven't had time to review the patch yet, but the idea of providing a structure with fields that doubles as a tuple is a good one. It's been tried before and can be done in pure Python as well. Regarding the field names: I think the field names should keep their st_ prefix -- IMO this makes the code more recognizable and hence readable. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 17:32 Message: Logged In: YES user_id=499 Here's the revised (*example only*) patch that takes the more portable approach I mention below. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 16:10 Message: Logged In: YES user_id=499 On further consideration, the approach taken in the second (*example only*) patch is indeed too fragile. The C code should not lengthen the tuple arbitrarily and depend on the Python code to decode it; instead, it should return a dictionary of extra fields. I think that this approach uses a minimum of C, is easily maintainable, and very extensible. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 15:53 Message: Logged In: YES user_id=499 Martin: I'm not entirely sure what you mean here; while my patch for extra fields requires a minor chunk of C (to access the struct fields), the rest still works in pure python. I'm attaching this second version for reference. I'm not sure it makes much sense to do this with pure C; it would certainly take a lot more code, with little benefit I can descern. But you're more experienced than I; what am I missing? I agree that the field naming is suboptimal; I was taking my lead from the stat and statvfs modules. If people prefer, we can name the fields whatever we like. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-17 15:24 Message: Logged In: YES user_id=21627 I second the request for supporting additional fields where available. At the same time, it appears unimplementable using pure Python. Consequently, I'd like to see this patch redone in C. The implementation strategy could probably remain the same, i.e. inherit from tuple for best compatibility; add the remaining fields as slots. It may be reasonable to implement attribute access using a custom getattr function, though. I have also my doubts about the naming of the fields. The st_ prefix originates from the time where struct fields were living in the global namespace (i.e. across different structures), so prefixing them for uniqueness was essential. I'm not sure whether we should inherit this into Python... ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 13:58 Message: Logged In: YES user_id=499 BTW, if this gets in, I have another patch that adds support for st_blksize, st_blocks, and st_rdev on platforms that support them. It don't expose these new fields in the tuple, as that would break all the old code that tries to unpack all the fields of the tuple. Instead, these fields are only accessible as attributes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 From noreply@sourceforge.net Mon Sep 24 14:52:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 24 Sep 2001 06:52:24 -0700 Subject: [Patches] [ python-Patches-463421 ] speed up md5 module with real memcpy/set Message-ID: Patches item #463421, was opened at 2001-09-20 17:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=463421&group_id=5470 Category: Modules Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Martin v. Lцwis (loewis) Summary: speed up md5 module with real memcpy/set Initial Comment: Modules/md5c.c has its own for loop implementation of memcpy and memset, even with a note that they should be replaced with the real thing if possible. So, this patch just does it. It doesn't use autoconf checks for them since they seem to be used all over the existing code with no such checks so I guess we assume they exist. (some quick tests show about a 12% speedup from this change) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-24 06:52 Message: Logged In: YES user_id=6380 Looks good to me. Looks like the original code was written super-carefully, without assuming a moderm C library, and we didn't read it very carefully to notice this when we imported it. :-) ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-23 14:53 Message: Logged In: YES user_id=21627 The patch looks good to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=463421&group_id=5470 From noreply@sourceforge.net Mon Sep 24 16:41:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 24 Sep 2001 08:41:50 -0700 Subject: [Patches] [ python-Patches-462596 ] StringIO Enhancement Message-ID: Patches item #462596, was opened at 2001-09-18 10:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462596&group_id=5470 Category: Library (Lib) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: M.-A. Lemburg (lemburg) >Assigned to: M.-A. Lemburg (lemburg) Summary: StringIO Enhancement Initial Comment: This patch allows using arbitrary read-buffer compatible objects as basis for StringIO and cStringIO objects. Previously, StringIO.py and cStringIO could only handle Python string objects as input buffer and in the .write() methods. The patch modifies the two modules in a way which automatically translates the used objects into strings (using the "s#" parser marker or str() to implement the conversion), e.g. Unicode objects, buffers, memory mapped files, etc. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-24 08:41 Message: Logged In: YES user_id=6380 Looks fine to me. Just check it in... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462596&group_id=5470 From noreply@sourceforge.net Mon Sep 24 16:44:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 24 Sep 2001 08:44:03 -0700 Subject: [Patches] [ python-Patches-462759 ] socketmodule.c: SSL bugfixes Message-ID: Patches item #462759, was opened at 2001-09-18 21:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462759&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 7 Submitted By: Gerhard Hдring (ghaering) >Assigned to: Barry Warsaw (bwarsaw) Summary: socketmodule.c: SSL bugfixes Initial Comment: This patch fixes the following bugs: #461358: SSL constructor/destructor bugs #461353: SSL write doesn't check return codes #461350: SSL support crashes python It also adds more reliable error checking to the SSL methods. And it tries to clean up the code by removing unused variables, for example. I'm an OpenSSL newbie myself, so a code review definitely won't hurt. I'll also try myself if I can talk some OpenSSL experts into reviewing it. As for testcases, Python currently doesn't offer server-side SSL functionality, so any serious client-server testing isn't possible at the moment. I'm also unsure whether patch #452110, that adds this should be added in the current form. I'd rather see a seperate new sslmodule.c that implements something largely interface compatible with socketmodule.c, i. e. with .recv(), .makefile() and all the rest. This would, however, require a serious effort. I doubt that a new SSL implementation could be implemented in a stable way for Python 2.2. The new sslmodule.c could be a combination of the above mentioned patch, the BSD-licensed Python-OpenSSL modules and perhaps some of the current code. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462759&group_id=5470 From noreply@sourceforge.net Mon Sep 24 17:42:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 24 Sep 2001 09:42:09 -0700 Subject: [Patches] [ python-Patches-446754 ] Enhanced unicode constructor Message-ID: Patches item #446754, was opened at 2001-08-01 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 Category: None Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Walter Dцrwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: Enhanced unicode constructor Initial Comment: This patch (against descr-branch) uses a slightly enhanced version of PyObject_Unicode instead of PyUnicode_FromEncodedObject in the unicode constructor (Objects/unicodeobject.h/unicode_new), which gives the unicode constructor the same functionality as the str constructor: creating string representations with the __str__ method/tp_str slot. Example: Python 2.2a1 (#10, Aug 1 2001, 14:26:06) [GCC 2.95.2 19991024 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> str("u"), unicode("u") ('u', u'u') >>> str(u"u"), unicode(u"u") ('u', u'u') >>> str(None), unicode(None) ('None', u'None') >>> str(42), unicode(42) ('42', u'42') >>> str(23.), unicode(23.) ('23.0', u'23.0') >>> str([1,2,3]), unicode([1,2,3]) ('[1, 2, 3]', u'[1, 2, 3]') >>> str({"u": 23, u"ь": 42}), unicode({"u": 23, u"ь": 42}) ("{'u': 23, u'\xfc': 42}", u"{'u': 23, u'\\xfc': 42}") >>> class foo: ... def __init__(self, x): ... self.x = x ... def __str__(self): ... return self.x ... >>> str(foo("bar")), unicode(foo("bar")) ('bar', u'bar') >>> str(foo(u"bar")), unicode(foo(u"bar")) ('bar', u'bar') Passing the encoding and errors argument still works and the will be used for any 8bit string returned from __str__. Perhaps for symmetry encoding and errors arguments should be added to the str constructor too, which will be used when a unicode object is returned from __str__ for encoding the object. One problem is that unicode([u"ь"]) returns u"[u'\\xfc']" because __repr__ returns a 8bit escape encoded string, it would be better if the result was u"[u'\xfc']", but this would require a PyObject_UnicodeRepr (and/or changing the list tp_str slot (and many others) to return Unicode) ---------------------------------------------------------------------- >Comment By: Walter Dцrwald (doerwalter) Date: 2001-09-24 09:42 Message: Logged In: YES user_id=89016 I tried subscribing from http://mail.python.org/mailman/listinfo/python-dev, but sofar nothing has happened, can someone please subscribe me to python-dev? (email address is walter@livinglogic.de) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-21 08:03 Message: Logged In: YES user_id=6380 Consider yourself invited. :-) ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-09-21 07:56 Message: Logged In: YES user_id=89016 I'm not on python-dev. http://mail.python.org/mailman/listinfo/python-dev says: "Subscription is by invitation only" ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-09-21 07:28 Message: Logged In: YES user_id=38388 Let's move this discussion to python-dev. I've already started a thread on it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-21 07:13 Message: Logged In: YES user_id=6380 I'm not keen on extending the str() signature. str() takes other argument types besides Unicode strings, but the encoding arguments only make sense for Unicode strings - ergo, I think the encoding should be a Unicode string method (which it is). I do think that PyObject_Unicode() in C should be closely tied to unicode() in Python. ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-09-21 05:23 Message: Logged In: YES user_id=89016 I've read the following in Misc/NEWS "PyUnicode_FromEncodedObject() now works very much like PyObject_Str(obj) in that it tries to use __str__/tp_str on the object if the object is not a string or buffer. This makes unicode() behave like str() when applied to non- string/buffer objects." I think this is the wrong way: The string constructor uses PyObject_Str, so the unicode constructor should use PyObject_Unicode (i.e. the extended version). As PyObject_UnicodeEx has additional arguments, maybe we should have a new function PyObject_StrEx with these additional arguments too. Then the string constructor could have these arguments too: >>> print str(u"\xfc\u2014", "latin-1", "replace") ь? This would really make string and unicode symmetric: unicode() creates a string either directy or via __str__/tp_str, if it encounters a 8bit string it uses the encoding and errors parameters to *decode* it. Likewise str () creates a 8bit string either directly or via __str__/tp_str, if it encounters a unicode object it uses the encoding and errors parameters to *encode* it. Would this change to the str constructor result in any backwards incompatiblities? ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-09-20 05:50 Message: Logged In: YES user_id=89016 OK, the new patch no longer changes the PyObject_Unicode signature. Now there are two functions: PyObject_Unicode with the old signature, and PyObject_UnicodeEx, which has the additional encoding and errors arguments. PyObject_Unicode(x) simply calls PyObject_UnicodeEx (x,NULL,NULL) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-09-20 03:56 Message: Logged In: YES user_id=38388 Rejecting this patch: see patch #413333 -- this is basically the same request and the patch is not usable since it breaks the Unicode C API. I still like the idea of making str() and unicode() have similar semantics. ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-08-01 06:55 Message: Logged In: YES user_id=89016 Oops, sorry I accidentally hit the submit button! :-/ The foo class is the one from the first message. str(...) always does a unicodeescape encoding when it encounters a Unicode object, so you'll get escape characters, but this will not be decoded when constructing the unicode object. I.e. u"..." != unicode(str(u"...")). Basically the unicode type should have the same functionality as the str type to ease unicode migration. ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-08-01 06:49 Message: Logged In: YES user_id=89016 >>> unicode(u"ь") u'\xfc' *>>> unicode(str(u"ь")) Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range (128) >>> unicode(foo(u"ь")) u'\xfc' *>>> unicode(str(foo(u"ь"))) Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range (128) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-01 06:45 Message: Logged In: YES user_id=6380 What does this have to offer over unicode(str(x))? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 From noreply@sourceforge.net Mon Sep 24 17:46:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 24 Sep 2001 09:46:45 -0700 Subject: [Patches] [ python-Patches-446754 ] Enhanced unicode constructor Message-ID: Patches item #446754, was opened at 2001-08-01 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 Category: None Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Walter Dцrwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: Enhanced unicode constructor Initial Comment: This patch (against descr-branch) uses a slightly enhanced version of PyObject_Unicode instead of PyUnicode_FromEncodedObject in the unicode constructor (Objects/unicodeobject.h/unicode_new), which gives the unicode constructor the same functionality as the str constructor: creating string representations with the __str__ method/tp_str slot. Example: Python 2.2a1 (#10, Aug 1 2001, 14:26:06) [GCC 2.95.2 19991024 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> str("u"), unicode("u") ('u', u'u') >>> str(u"u"), unicode(u"u") ('u', u'u') >>> str(None), unicode(None) ('None', u'None') >>> str(42), unicode(42) ('42', u'42') >>> str(23.), unicode(23.) ('23.0', u'23.0') >>> str([1,2,3]), unicode([1,2,3]) ('[1, 2, 3]', u'[1, 2, 3]') >>> str({"u": 23, u"ь": 42}), unicode({"u": 23, u"ь": 42}) ("{'u': 23, u'\xfc': 42}", u"{'u': 23, u'\\xfc': 42}") >>> class foo: ... def __init__(self, x): ... self.x = x ... def __str__(self): ... return self.x ... >>> str(foo("bar")), unicode(foo("bar")) ('bar', u'bar') >>> str(foo(u"bar")), unicode(foo(u"bar")) ('bar', u'bar') Passing the encoding and errors argument still works and the will be used for any 8bit string returned from __str__. Perhaps for symmetry encoding and errors arguments should be added to the str constructor too, which will be used when a unicode object is returned from __str__ for encoding the object. One problem is that unicode([u"ь"]) returns u"[u'\\xfc']" because __repr__ returns a 8bit escape encoded string, it would be better if the result was u"[u'\xfc']", but this would require a PyObject_UnicodeRepr (and/or changing the list tp_str slot (and many others) to return Unicode) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-24 09:46 Message: Logged In: YES user_id=6380 The administrators have been sleeping. I've approved your request (and about a dozen others, and rejected 9 spams :-). ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-09-24 09:42 Message: Logged In: YES user_id=89016 I tried subscribing from http://mail.python.org/mailman/listinfo/python-dev, but sofar nothing has happened, can someone please subscribe me to python-dev? (email address is walter@livinglogic.de) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-21 08:03 Message: Logged In: YES user_id=6380 Consider yourself invited. :-) ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-09-21 07:56 Message: Logged In: YES user_id=89016 I'm not on python-dev. http://mail.python.org/mailman/listinfo/python-dev says: "Subscription is by invitation only" ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-09-21 07:28 Message: Logged In: YES user_id=38388 Let's move this discussion to python-dev. I've already started a thread on it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-21 07:13 Message: Logged In: YES user_id=6380 I'm not keen on extending the str() signature. str() takes other argument types besides Unicode strings, but the encoding arguments only make sense for Unicode strings - ergo, I think the encoding should be a Unicode string method (which it is). I do think that PyObject_Unicode() in C should be closely tied to unicode() in Python. ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-09-21 05:23 Message: Logged In: YES user_id=89016 I've read the following in Misc/NEWS "PyUnicode_FromEncodedObject() now works very much like PyObject_Str(obj) in that it tries to use __str__/tp_str on the object if the object is not a string or buffer. This makes unicode() behave like str() when applied to non- string/buffer objects." I think this is the wrong way: The string constructor uses PyObject_Str, so the unicode constructor should use PyObject_Unicode (i.e. the extended version). As PyObject_UnicodeEx has additional arguments, maybe we should have a new function PyObject_StrEx with these additional arguments too. Then the string constructor could have these arguments too: >>> print str(u"\xfc\u2014", "latin-1", "replace") ь? This would really make string and unicode symmetric: unicode() creates a string either directy or via __str__/tp_str, if it encounters a 8bit string it uses the encoding and errors parameters to *decode* it. Likewise str () creates a 8bit string either directly or via __str__/tp_str, if it encounters a unicode object it uses the encoding and errors parameters to *encode* it. Would this change to the str constructor result in any backwards incompatiblities? ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-09-20 05:50 Message: Logged In: YES user_id=89016 OK, the new patch no longer changes the PyObject_Unicode signature. Now there are two functions: PyObject_Unicode with the old signature, and PyObject_UnicodeEx, which has the additional encoding and errors arguments. PyObject_Unicode(x) simply calls PyObject_UnicodeEx (x,NULL,NULL) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-09-20 03:56 Message: Logged In: YES user_id=38388 Rejecting this patch: see patch #413333 -- this is basically the same request and the patch is not usable since it breaks the Unicode C API. I still like the idea of making str() and unicode() have similar semantics. ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-08-01 06:55 Message: Logged In: YES user_id=89016 Oops, sorry I accidentally hit the submit button! :-/ The foo class is the one from the first message. str(...) always does a unicodeescape encoding when it encounters a Unicode object, so you'll get escape characters, but this will not be decoded when constructing the unicode object. I.e. u"..." != unicode(str(u"...")). Basically the unicode type should have the same functionality as the str type to ease unicode migration. ---------------------------------------------------------------------- Comment By: Walter Dцrwald (doerwalter) Date: 2001-08-01 06:49 Message: Logged In: YES user_id=89016 >>> unicode(u"ь") u'\xfc' *>>> unicode(str(u"ь")) Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range (128) >>> unicode(foo(u"ь")) u'\xfc' *>>> unicode(str(foo(u"ь"))) Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range (128) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-01 06:45 Message: Logged In: YES user_id=6380 What does this have to offer over unicode(str(x))? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id=5470 From noreply@sourceforge.net Mon Sep 24 18:15:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 24 Sep 2001 10:15:14 -0700 Subject: [Patches] [ python-Patches-463421 ] speed up md5 module with real memcpy/set Message-ID: Patches item #463421, was opened at 2001-09-20 17:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=463421&group_id=5470 Category: Modules Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Martin v. Lцwis (loewis) Summary: speed up md5 module with real memcpy/set Initial Comment: Modules/md5c.c has its own for loop implementation of memcpy and memset, even with a note that they should be replaced with the real thing if possible. So, this patch just does it. It doesn't use autoconf checks for them since they seem to be used all over the existing code with no such checks so I guess we assume they exist. (some quick tests show about a 12% speedup from this change) ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-24 10:15 Message: Logged In: YES user_id=21627 Committed as 2.7 of md5.c. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-24 06:52 Message: Logged In: YES user_id=6380 Looks good to me. Looks like the original code was written super-carefully, without assuming a moderm C library, and we didn't read it very carefully to notice this when we imported it. :-) ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-23 14:53 Message: Logged In: YES user_id=21627 The patch looks good to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=463421&group_id=5470 From rusgarden@zensearch.net Mon Sep 24 22:02:05 2001 From: rusgarden@zensearch.net (Компания "Русский Сад") Date: Mon, 24 Sep 2001 22:02:05 +0100 (GMT) Subject: [Patches] Озеленение и ландшафтный дизайн Message-ID: <20010924210205.5C6B551AD@orinoco.portland.co.uk> Здравствуйте Ирина Александровна! Наша компания способна качественно и в кратчайшие сроки выполнить работы на Вашем объекте. Компания "Русский Сад" специализируется на озеленении и благоустройстве территорий. Заключив с нами договор, Вы получаете бесплатное сервисное обеспечение до конца года и льготный договор на абонентское обслуживание. Мы берем на обслуживание территории любой сложности. Стоимость годового абоненского обслуживания от 500 у.е.. Мы производим различные виды работ, в том числе мы создаем: - газоны - живые изгороди - альпинарии - клумбы - бордюры - садовые дорожки - кустарниковые посадки - посадки деревьев Также мы проводим ландшафтное проектирование, создаем дендропланы, предлагаем дизайнерское сопровождение объекта на любой стадии готовности. Все наши клиенты получают бесплатные консультации по сопровождению выполненных нами объектов. Компания "Русский Сад" является единственной компанией на рынке, производящей озеленительные и ландшафтные работы в любом регионе страны, при этом, не повышая стоимость работ. Если Вы решите производить работы своими силами, Вы можете вызвать для сопровождения проекта нашего консультанта. Компания "Русский Сад" готова взять на себя все сервисное обеспечение территорий любой сложности и размера. Мы приглашаем Вас посетить наш сайт http://rusgarden.ru/ где Вы можете ознакомиться с деятельностью компании, кратким прайс-листом и образцами выполненных работ, а также "Партнерской и "Региональной" программами. С уважением к Вам. Компания "Русский Сад" From noreply@sourceforge.net Tue Sep 25 02:06:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 24 Sep 2001 18:06:41 -0700 Subject: [Patches] [ python-Patches-460751 ] --with-shared: python with shared lib Message-ID: Patches item #460751, was opened at 2001-09-11 14:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Martin v. Lцwis (loewis) Summary: --with-shared: python with shared lib Initial Comment: As a follow up to patch 400938 (https://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=400938), here is an implementation of the --with-shared configure option for building python on Posix systems as a shared library. Building python as shared library is activated with the --with-shared option on ./configure The following points are drawn to particular attention: - A configbuild.py module is generated and placed in the machine-dependent directory. It records most Python/Makefile variables (CC, CFLAG, LDSHARED...), and make them available in Python. - The build has been tested on: Linux2: OK SunOS5: OK IRIX64: Build OK, crash on test (bus error) - Inference with distutils: I found it very difficult understanding the distutil architecture and finding the right points of change; I minimized my interaction there. Furthermore, the availability of the 'configbuild' module overlaps some of the distutils; but 'configbuild' is very easy to use ... - Unresolved symbols: I turned on the symbol checking flags whenever possible, on behalf the its better generating the error on build than at runtime. - configure.in: I only edited the configure Bourne script, and did not bother with configure.in (actually, I deleted it) and its autoconfig/m4 macro comparses. Frederic Giacometti ---------------------------------------------------------------------- >Comment By: Frederic Giacometti (giacometti) Date: 2001-09-24 18:06 Message: Logged In: YES user_id=93657 Martin, I'm attaching a tar containing a diff against the CVS mainline (sync last Friday), and the comments on the changes in a different file. I put the changes in configure.in, from configure, but after running autoconf, the --with-shared option has no effect. Hopefully, this is not much. The small changes for building threaded python on OSF/1 are in the same zone as those edited for the change, so I could not separate them out. FG ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-20 12:16 Message: Logged In: YES user_id=93657 The patch is against Python 2.1.1. I'll try to integrate this with the current source. I'll work with a single checkout across the multiple platforms. Regarding buildno: I was getting recursive dependency links, after I made the shared library dependent upon its .o files. I had to break the recursivity. What is dguxR4 ? Is it OSF1 V4.0, a.k.a. Digital Unix 4.0, a.k.a. Tru64 ? I have now access to an OSF1 v4.0 (a.k.a. DU 4.0). I'll do the build there. uname returns 'OSF1 ...' The -lsocket is needed for building the socket module, and had to be moved there (cf. Python/setup.py, I think). It is not used in the core, so I dropped it there. Dito for -ldsl. No symbols are missing when linking libpython2.1.so, anyway. These libraries just have now to be linked with the modules which use them. The rule I applied for deciding on libraries are: - link with all libraries necessaries so as to suppress all unresolved symbol output - link only with libraries whose absence triggers unresolved symbol outputs - -lmpc: You might be right, but then -lmpc should be present only on systems that need it (and, first of all these systems should be identified/documented). - fpectl: dito FG ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-18 10:05 Message: Logged In: YES user_id=21627 I've tried testing your patch, but I get numerous failed chunks when applying it against the current CVS. What version does this patch apply to? To simplify the integration, it would be greatly appreciated if you could use the current source base. >From reviewing the patch, I still have a number of concerns: - it appears that you change the mechanism by which buildno is incremented. Why? - There appear to extra white space changes (e.g. in the distclean chunk); those are naturally unrelated to the patch - please remove them - it appears that configuration knowledge for some platforms is lost when applying this patch, e.g. the dguxR4 special-casing of passing -pic is gone. Please try to integrate any such knowledge faithfully into your patch, instead of restricting its applicability to just the platforms where you've tested it on. - There is something going on with dropping -lsocket from the patch. What is that, and why does it happen? Instead, it appears that you put 'socket' and 'nsl' into setup.py. According to configure.in, this is wrong on some systems: they may not have the libraries, or the libraries may be broken. - Other libraries appear to suffer as well, such as removing -lmpc. That might mean that you break thread support on some systems. - the chunk to disable fpectl if nothing is known about the systems appears to be unrelated. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-17 10:36 Message: Logged In: YES user_id=93657 I'm attaching an updated patch where, following Martin suggestions: - I removed the configbuild thing, and replaced it with distutils.sysconfig.get_conf_var calls - I manually cleaned up the patch from unrelated changes (.cvsignore, @ Makefile modifiers...) Remains the configure.in thing. If one looks at autoconf: - it takes care of plateform idiosyncracies, for platform which do not follow posix API specs; this was of use in previous generation Unix OS's, and these legacy systems do not evolve anymore. On present Unixes, and with regard to the features used for building the core python engine, nothing moves, and autoconf updates bring nothing. Doesn't the Python 1.5.2's configure still works as it did the first day it was generated ... ? - autoconf is of use for configuring particular packages and libraries (e.g.: for configuring and building python extensions, Tkinter/Tk/TCL...); unfortunately this never worked with python, and the task is now assumed by the distutils. - In the Python core build, autoconf is of no help in anything sensible: thread, shared library, debug build, compiler options... All these were programmed manually in Bourne; and for doing the later, autoconf is a complexifying factor on something already fairly complex - i.e. a handicap -. - not to say, autoconf is of no use on non-posix plateforms (windows...) - last, and the least: autoconf now requires that perl be installed... Frederic Giacometti ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 18:36 Message: Logged In: YES user_id=6380 > What is the point of keeping using the autoconf thing when > it is easier to maintain configure directly, than going > through configure.in ? But it's not. One line of configure.in often expands to dozens (occasionally hundreds) of lines of configure. autoconf has arcane knowledge that gets updated with new autoconf releases. You are entitled to your opinion, but in this case, it's wrong. Go fork your own version of Python if you don't want to learn autoconf. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-12 16:06 Message: Logged In: YES user_id=93657 I am not willing to make anything difficult for anybody, but: What is the point of keeping using the autoconf thing when it is easier to maintain configure directly, than going through configure.in ? After configure has been generated once, it makes more sense to me to work directly on configure, and forget about configure.in. configure (pure Bourne shell) is a easier to understand, to troubleshoot, and to maintain that configure.in (a mixture of Bourne shell and autoconf m4 macros). I'll have a second look at the autoconf thing latter on - at present I hardly understand anything to configure.in, and got 'configure --with-shared' working with satisfaction across multiple platforms without undue difficulties. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 11:37 Message: Logged In: YES user_id=6380 > Autoconf is not installed on the commercial Unix > platforms, it is useless for me to learn it, and I was > better off directly editing ./configure. However, if others > are familiar with the tool, it should be straightforward for > them to retrocede the changes from configure to configure.in Sure. You'll just have to wait until we have time for that. You can make it easy for us to integrate your changes, or you can make it difficult. Your choice. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-12 11:12 Message: Logged In: YES user_id=93657 - I will remove the configbuild; since Martin pointed to me the existence of distutils.sysconfig.get_config_vars(). I did not know about this function... Thanks! On the fly, you'll also note the following potential problem with using get_config_vars() instead of configbuild: configbuild will report the actual values used for the build, whereas get_config_vars() will report erroneous values whenever the Makefile internal variables were overriden at build time (by either the environment, or by commandline assignment of the type 'make CC=gxx ...'); not to mention that configbuild does not need to find and parse the original Makefile (with all the potential problems associated). - The .purify line should be in the CVSROOT/cvsignore CVS admin file, not in .cvsignore in the root directory of the source distribution... - Autoconf is not installed on the commercial Unix platforms, it is useless for me to learn it, and I was better off directly editing ./configure. However, if others are familiar with the tool, it should be straightforward for them to retrocede the changes from configure to configure.in - I had to introduce THREADOBJ because you will note that, in the present implementation, Modules/thread.o appears multiple times in LIBOBJS, which causes warning at link time. Now, Modules/thread.o appears only once ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-12 01:06 Message: Logged In: YES user_id=21627 As for libtool: I strongly advise not to use it. It is broken in too many ways to enumerate. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-12 00:18 Message: Logged In: YES user_id=21627 I recommend to rework this patch to get rid of configbuild. I cannot see what you achieve with the configbuild module that you couldn't do with distutils.sysconfig.get_config_vars (which is capable of parsing the Makefile directly). I also recommend to go through the patch chunk by chunk, asking yourself whether this chunk *really* is needed to achieve the desired functionality. E.g. I cannot see the relationship of the .cvsignore chunk; I also believe that removal of .purify is incorrect. Likewise, while I sympathize with the unresolved symbols change, I believe it is unrelated to the main objective of this patch (building Python shared). What is the rationale for not changing configure.in? As-is, this patch is useless: configure will be overwritten everytime you run autoconf. Please get a copy of autoconf on one of your systems, change configure.in, run autoconf, and then provide us with a patch that only changes configure.in: everybody reviewing this patch should be capable of running autoconf. configure is a generated file and should not be edited manually. What is the rationale for the introduction of the THREADOBJ variable? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-11 19:03 Message: Logged In: YES user_id=6380 Haven't seen the patch yet, but I like the idea -- the command line option suggests that it shouldn't hurt platforms where it can't be done or has to be done differently. Alternative: we could also consider using libtool. I didn't like that much in the past, but maybe it would work. Dunno. Anybody know about it? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 From noreply@sourceforge.net Tue Sep 25 07:42:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 24 Sep 2001 23:42:44 -0700 Subject: [Patches] [ python-Patches-403753 ] zlib decompress; uncontrollable memory usage Message-ID: Patches item #403753, was opened at 2001-02-12 08:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403753&group_id=5470 Category: Modules Group: None Status: Open Resolution: Out of Date Priority: 5 Submitted By: Toby Dickenson (htrd) Assigned to: Jeremy Hylton (jhylton) Summary: zlib decompress; uncontrollable memory usage Initial Comment: zlib's decompress method will allocate as much memory as is needed to hold the decompressed output. The length of the output buffer may be very much larger than the length of the input buffer, and the python code calling the decompress method has no other way to control how much memory is allocated. In experimentation, I seen decompress generate output that is 1000 times larger than its input These characteristics may make the decompress method unsuitable for handling data obtained from untrusted sources (for example, in a http proxy which implements gzip encoding) since it may be vulnerable to a denial of service attack. A malicious user could construct a moderately sized input which forces 'decompress' to try to allocate too much memory. This patch adds a new method, decompress_incremental, which allows the caller to specify the maximum size of the output. This method returns the excess input, in addition to the decompressed output. It is possible to solve this problem without a patch: If input is fed to the decompressor a few tens of bytes at a time, memory usage will surge by (at most) a few tens of kilobytes. Such a process is a kludge, and much less efficient that the approach used in this patch. (Ive not been able to test the documentation patch; I hope its ok) (This patch also includes the change from Patch #103748) ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-09-24 23:42 Message: Logged In: YES user_id=23486 I have integrated this patch into the latest Python CVS tree, with a few additional modifications. * added spaces into the documentation patch & verified that doc building works; * fixed problem where the 'unconsumed_tail' attribute returned was *actually* the unused_data attribute; this was caused by indiscriminate cutting & pasting ;). * put in a few additional comments and fixed the code for 80 cols. It doesn't look like I can submit an attachment with this comment (?); I will e-mail it to both loewis & htrd. ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-09-10 07:18 Message: Logged In: YES user_id=46460 I volunteer to update it ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-07 10:03 Message: Logged In: YES user_id=21627 Since this patch has been sitting around for such a long time, it eventually got outdated, due to the conflicting MT patch. Any volunteers to update it? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-06-04 13:55 Message: Logged In: YES user_id=21627 The patch looks good to me; I recommend to approve it. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-04-10 10:52 Message: Logged In: YES user_id=11375 I've let this patch gather dust long enough. Unassigning so that someone else can review it. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2001-04-07 00:20 Message: Logged In: YES user_id=413 as a side note. I believe I implemented a python workaround for this problem by just decompressing data in small chunks (4k at a time) using a decompressor object. see the mojonation project on sourceforge if you're curious. (specifically, in the mojonation evil module, look at common/mojoutil.py for function named safe_zlib_decompress). Regardless, I like thie idea of this patch. It would be good to have that in the main API and documentation for simplicity. (and because there are too many programmers out there who don't realize potential denial of service issues on their own...) ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-22 04:50 Message: New patch implementing a new optional parameter to .decompress, and a new attribute .unconsumed_tail ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-22 03:42 Message: Waaah - that last comment should be 'cant' not 'can' ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-22 03:40 Message: We can reuse .unused_data without introducing an ambiguity. I will prepare a patch that uses a new attribute .unconsumed_tail ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-02-21 11:32 Message: Doesn't .unused_data serve much the same purpose, though? So that even with a maximum size, .decompress() always returns a string, and .unused_data would contain the unprocessed data. ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-21 06:00 Message: I did consider that.... An extra change that you didnt mention is the need for a different return value. Currently .decompress() always returns a string. The new method in my patch returns a tuple containing the same string, and an integer specifying how many bytes were consumed from the input. Overloading return values based on an optional parameter seems a little hairy to me, but I would be happy to change the patch if that is your preferred option. I also considered (and rejected) the possibility of adding an optional max-size argument to .decompress() as you suggest, but raising an exception if this limit is exceeded. This avoids the need for an extra return value, but looses out on flexibility. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-02-20 18:48 Message: Rather than introducing a new method, why not just add an optional maxlen argument to .decompress(). I think the changes would be: * add 'int maxlen=-1;' * add "...|i" ... ,&maxlen to the argument parsing * if maxlen != -1, length = maxlen else length = DEFAULTALLOC; * Add '&& maxlen==-1' to the while loop. (Use the current CVS; I just checked in a patch rearranging the zlib module a bit.) Do you want to make those changes and resubmit the patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403753&group_id=5470 From noreply@sourceforge.net Tue Sep 25 11:37:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 25 Sep 2001 03:37:52 -0700 Subject: [Patches] [ python-Patches-460751 ] --with-shared: python with shared lib Message-ID: Patches item #460751, was opened at 2001-09-11 14:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Martin v. Lцwis (loewis) Summary: --with-shared: python with shared lib Initial Comment: As a follow up to patch 400938 (https://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=400938), here is an implementation of the --with-shared configure option for building python on Posix systems as a shared library. Building python as shared library is activated with the --with-shared option on ./configure The following points are drawn to particular attention: - A configbuild.py module is generated and placed in the machine-dependent directory. It records most Python/Makefile variables (CC, CFLAG, LDSHARED...), and make them available in Python. - The build has been tested on: Linux2: OK SunOS5: OK IRIX64: Build OK, crash on test (bus error) - Inference with distutils: I found it very difficult understanding the distutil architecture and finding the right points of change; I minimized my interaction there. Furthermore, the availability of the 'configbuild' module overlaps some of the distutils; but 'configbuild' is very easy to use ... - Unresolved symbols: I turned on the symbol checking flags whenever possible, on behalf the its better generating the error on build than at runtime. - configure.in: I only edited the configure Bourne script, and did not bother with configure.in (actually, I deleted it) and its autoconfig/m4 macro comparses. Frederic Giacometti ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-09-25 03:37 Message: Logged In: YES user_id=21627 PLEASE do not put unrelated changes into your patches. What does "--with-shared: python with shared lib" have to do with removing @ prefixes in the makefile???? I'm close to giving up reviewing your patches, and waiting for somebody else to reject them. Likewise, why did you remove the makedepend support? It may be broken, but the objective of this patch has nothing to do with this. Same for reconfigure; to re-run configure with the same options, just invoke 'make'. If you think there is a problem, report a bug. The problem with the generated configure not recognizing --with-shared is that you put the AC_ARG_WITH after the check for build_as_shared into configure.in. Just move the AC_ARG_WITH somewhat up. Never use ld to link on Unix, always use $(CC); otherwise, people will complain that linking in C++ modules will fail. To pass options to the linker using the SunPRO compiler, use the -Wl,