From noreply@sourceforge.net Sat Feb 1 03:13:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 19:13:57 -0800 Subject: [Patches] [ python-Patches-678531 ] zlib module needs decompress flush. Message-ID: Patches item #678531, was opened at 2003-02-01 03:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678531&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Scott David Daniels (scott_daniels) Assigned to: Nobody/Anonymous (nobody) Summary: zlib module needs decompress flush. Initial Comment: Python 2.3 current (should work on 2,1 and 2.2 as well) OS: Win2K The zlibmodule.c sources mistakenly don't implement flush() on decompression objects. The assumption is that all data will have been extracted once all of the source is available. This patch simply implements flush in the obvious way. As mentioned in bug #640230, the previous test did not successfully test the decompression object. I'll attach in a subsequent patch a PyUnit-style test_zlib.py that exercises zlib and checks the buffer flushing (because I don't see how to attach two files). -Scott ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678531&group_id=5470 From noreply@sourceforge.net Sat Feb 1 08:27:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 01 Feb 2003 00:27:37 -0800 Subject: [Patches] [ python-Patches-678211 ] buildpkg.py fixes for finding resources Message-ID: Patches item #678211, was opened at 2003-01-31 17:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678211&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robin Dunn (robind) >Assigned to: Jack Jansen (jackjansen) Summary: buildpkg.py fixes for finding resources Initial Comment: Mac/scripts.buildpkg.py has some incorrect code for finding and building the installer resources, at least I couldn't get it to work as-is and it didn't quite match some docs I found. This patch fixes the isntallation of the various pre/post scripts and also adds the ability to use the RootVolumeOnly directive. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-02-01 09:27 Message: Logged In: YES user_id=92689 No it's not mine, it's Dinu Gherman's. But since he's not a Python developer I can't assign to him... I've never even looked at this script :-(. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-01 00:21 Message: Logged In: YES user_id=45365 This is Just's, and I haven't looked at it at all yet, so I'm reassiging to him. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678211&group_id=5470 From noreply@sourceforge.net Sat Feb 1 08:41:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 01 Feb 2003 00:41:35 -0800 Subject: [Patches] [ python-Patches-678218 ] Adds icon support to bundlebuilder.py Message-ID: Patches item #678218, was opened at 2003-01-31 17:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678218&group_id=5470 Category: Macintosh Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Just van Rossum (jvr) Summary: Adds icon support to bundlebuilder.py Initial Comment: This patch adds support for an --iconfile parameter and etc. to bundlebuilder.py and if given will copy the given icon file to the bundle's resources and will set the CFBundleIconFile value in the plist file. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-02-01 09:41 Message: Logged In: YES user_id=92689 Thanks! Applied, but slightly modified. It's in rev. 1.5 of bundlebuilder.py. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-01 00:22 Message: Logged In: YES user_id=45365 Another of Just's scriipts that I'm not familiar with (yet)... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678218&group_id=5470 From noreply@sourceforge.net Sat Feb 1 08:43:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 01 Feb 2003 00:43:20 -0800 Subject: [Patches] [ python-Patches-678211 ] buildpkg.py fixes for finding resources Message-ID: Patches item #678211, was opened at 2003-01-31 17:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678211&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robin Dunn (robind) >Assigned to: Just van Rossum (jvr) Summary: buildpkg.py fixes for finding resources Initial Comment: Mac/scripts.buildpkg.py has some incorrect code for finding and building the installer resources, at least I couldn't get it to work as-is and it didn't quite match some docs I found. This patch fixes the isntallation of the various pre/post scripts and also adds the ability to use the RootVolumeOnly directive. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-02-01 09:43 Message: Logged In: YES user_id=92689 Assigning back to me, I'll contact Dinu. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-01 09:27 Message: Logged In: YES user_id=92689 No it's not mine, it's Dinu Gherman's. But since he's not a Python developer I can't assign to him... I've never even looked at this script :-(. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-01 00:21 Message: Logged In: YES user_id=45365 This is Just's, and I haven't looked at it at all yet, so I'm reassiging to him. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678211&group_id=5470 From noreply@sourceforge.net Sat Feb 1 10:13:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 01 Feb 2003 02:13:54 -0800 Subject: [Patches] [ python-Patches-678211 ] buildpkg.py fixes for finding resources Message-ID: Patches item #678211, was opened at 2003-01-31 17:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678211&group_id=5470 Category: Macintosh Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Just van Rossum (jvr) Summary: buildpkg.py fixes for finding resources Initial Comment: Mac/scripts.buildpkg.py has some incorrect code for finding and building the installer resources, at least I couldn't get it to work as-is and it didn't quite match some docs I found. This patch fixes the isntallation of the various pre/post scripts and also adds the ability to use the RootVolumeOnly directive. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-02-01 11:13 Message: Logged In: YES user_id=92689 Approved (but not tested) by Dinu, checked in as rev. 1.3. Thanks Robin! ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-01 09:43 Message: Logged In: YES user_id=92689 Assigning back to me, I'll contact Dinu. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-01 09:27 Message: Logged In: YES user_id=92689 No it's not mine, it's Dinu Gherman's. But since he's not a Python developer I can't assign to him... I've never even looked at this script :-(. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-01 00:21 Message: Logged In: YES user_id=45365 This is Just's, and I haven't looked at it at all yet, so I'm reassiging to him. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678211&group_id=5470 From noreply@sourceforge.net Sun Feb 2 04:08:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 01 Feb 2003 20:08:40 -0800 Subject: [Patches] [ python-Patches-678899 ] Use ifilter in sets module Message-ID: Patches item #678899, was opened at 2003-02-01 23:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678899&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Guido van Rossum (gvanrossum) Summary: Use ifilter in sets module Initial Comment: If it's not overzealous, I would like to apply itertools.ifilter to sets module to speed-up a few of the methods there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678899&group_id=5470 From noreply@sourceforge.net Sun Feb 2 04:21:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 01 Feb 2003 20:21:07 -0800 Subject: [Patches] [ python-Patches-661796 ] BZ2File leaking fd and memory Message-ID: Patches item #661796, was opened at 2003-01-03 19:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661796&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Gustavo Niemeyer (niemeyer) Summary: BZ2File leaking fd and memory Initial Comment: The attached patch fixes BZ2File() leaking the fd and PyFileObject* info (name, read ahead buffer) when an object is deleted. I'm not sure the patch fixes these problems in the best way. It exposes most of the implementation from fileobject.c::file_dealloc() through a private API _PyFile_Dealloc(). BZ2File derives from PyFileObject. Make sure the file: 'empty' exists and do: from bz2 import * A simple test which demonstrates the problem is: for i in range(100000): o = BZ2File('empty') ; del o Without the patch, you quickly get: IOError: [Errno 24] Too many open files: 'empty' You can modify this to: for i in range(100000): o = BZ2File('empty') ; o.close() ; del o Now you can see the memory leaks. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-02-02 04:21 Message: Logged In: YES user_id=7887 Ok, I've started to "unparent" the bz2 code. OTOH, I've just realised what a lot of code, full of #ifdef's, I'll have to copy, mostly unchanged. The following functions file_new(), file_init(), open_the_file(), fill_file_fields(), dircheck(), close_file(), get_newlines(), _portable_fseek(), file_seek(), file_repr(), and the following arrays file_memberlist[], file_getsetlist[] My question is, do you think it's better to maintain all this code duplicated than maintaining bz2 up to date? I'll do the job, if you still think this is great. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-22 17:29 Message: Logged In: YES user_id=6380 If you could, that would be great. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-01-22 15:39 Message: Logged In: YES user_id=7887 Ok. Do you want me to work on this for 2.3? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-21 19:24 Message: Logged In: YES user_id=6380 FileObject sharing: I see. But I still think it's a bad idea, and you're better off using stdio methods directly (as the evolution of the FileObject implementation has already shown). ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-01-20 20:44 Message: Logged In: YES user_id=7887 Sorry about the delay. I was on a not-so-short vacation. nnorwitz: Thanks for the patch. I'll check the problem (for my own understanding) and most certainly apply it. gvanrossum: BZ2File used to share a lot of code with FileObject. Unfortunately (for the BZ2File side), FileObject changed considerably post 2.2, and some of the code had to be moved to BZ2File itself. It still uses some code from FileObject, though (open, close, seek, part of the softspace handling, access to attributes and some common methods). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-05 21:11 Message: Logged In: YES user_id=6380 Um, I don't understand why the BZ2File class inherits from FileObject. It doesn't seem to be inheriting any code, and there's no reason to inherit from FileObject just to make a file-like object. Maybe it was a misunderstanding? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 20:09 Message: Logged In: YES user_id=33168 I've found a better solution: change the last line of BZ2File_dealloc() from: ((PyObject*)self)->ob_type->tp_free((PyObject *)self); to PyFile_Type.tp_dealloc((PyObject *)self); Updated patch attached. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 19:48 Message: Logged In: YES user_id=21627 Assigning to the author of the module for review. Gustavo, if you can't find the time for a review, feel free to unassign it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661796&group_id=5470 From noreply@sourceforge.net Sun Feb 2 06:36:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 01 Feb 2003 22:36:00 -0800 Subject: [Patches] [ python-Patches-625513 ] sets.BaseSet.isdisjointset(other) Message-ID: Patches item #625513, was opened at 2002-10-18 23:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=625513&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Shane Holloway (shane_holloway) Assigned to: Nobody/Anonymous (nobody) Summary: sets.BaseSet.isdisjointset(other) Initial Comment: Provides an optimized test for disjoint sets without creating an intersection, and returning after finding first shared element. ---------------------------------------------------------------------- >Comment By: Shane Holloway (shane_holloway) Date: 2003-02-01 23:36 Message: Logged In: YES user_id=283742 Closing this is fine with me. =) I learned a lot in the process, if nothing else! Thanks to all who gave it a look. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-29 18:12 Message: Logged In: YES user_id=80475 Can this be closed due to lack of interest? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-12-12 16:17 Message: Logged In: YES user_id=80475 Here is an alternative implementation: >>> def isdisjoint(a,b): ... return len(a) != len(a|b) The underlying dict.copy() and dict.update() help give this a speed advantage. ---------------------------------------------------------------------- Comment By: Shane Holloway (shane_holloway) Date: 2002-10-22 12:32 Message: Logged In: YES user_id=283742 I definitely agree that this disjoint set test and an intersection both have linear time complexity, but the intersection also has a memory complexity that a disjoint test does not have. Secondly, in the case of an intersecting set, it short-circuts the rest of the loop since it already has the answer, halving the time complexity on average. However, disjoint test doesn't benefit from the C-loop of filter that the intersection does. When I wrote this patch, I was creating some large sets doing reachability searches, and I wanted to merge the intersecting ones. I started by examining the length of the intersection, but the time to allocate the complete result was bottlenecking things. (400K entries.) Thus I wrote the disjoint test and things went much faster. But, as you said, this is neither common nor compelling. So I assumed it was a common enough function that others would profit from having it the standard library. It was certainly all over my set theory classes a few years ago. ;) Perhaps what we need is more c-loop functions to add to map, filter and reduce? A function called 'first' would work wonders here and other places. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-21 23:54 Message: Logged In: YES user_id=80475 In general, I'm a fan of early-out routines, but I agree with Tim, unless this patch solves a compelling common case and is clear about when and whether it can be used to advantage, the filter based itersection method remains the best solution for the general case. Unless a compelling, common use case can be shown, I recommend that we don't fatten the interface further. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-10-19 00:33 Message: Logged In: YES user_id=31435 In what sense is this optimized? People usually mean "speed" when they use that word without qualification, but this surely runs much slower (most of the time) if the sets are in fact disjoint. OTOH, I'm sure it does run much faster (most of the time) if the sets have the same elements. If a method is merely provided for speed in *some* cases, it's generally a hard sell. It would help your case if the docs here spelled out exactly when and why someone would want to use the new method; else it appears mysteriously redundant. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=625513&group_id=5470 From noreply@sourceforge.net Sun Feb 2 12:57:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 02 Feb 2003 04:57:06 -0800 Subject: [Patches] [ python-Patches-661796 ] BZ2File leaking fd and memory Message-ID: Patches item #661796, was opened at 2003-01-03 14:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661796&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Gustavo Niemeyer (niemeyer) Summary: BZ2File leaking fd and memory Initial Comment: The attached patch fixes BZ2File() leaking the fd and PyFileObject* info (name, read ahead buffer) when an object is deleted. I'm not sure the patch fixes these problems in the best way. It exposes most of the implementation from fileobject.c::file_dealloc() through a private API _PyFile_Dealloc(). BZ2File derives from PyFileObject. Make sure the file: 'empty' exists and do: from bz2 import * A simple test which demonstrates the problem is: for i in range(100000): o = BZ2File('empty') ; del o Without the patch, you quickly get: IOError: [Errno 24] Too many open files: 'empty' You can modify this to: for i in range(100000): o = BZ2File('empty') ; o.close() ; del o Now you can see the memory leaks. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-02 07:57 Message: Logged In: YES user_id=6380 I don't understand. Why would you want to copy all the implementation details of those functions? Have a look at how the zlib module emulates a file. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-02-01 23:21 Message: Logged In: YES user_id=7887 Ok, I've started to "unparent" the bz2 code. OTOH, I've just realised what a lot of code, full of #ifdef's, I'll have to copy, mostly unchanged. The following functions file_new(), file_init(), open_the_file(), fill_file_fields(), dircheck(), close_file(), get_newlines(), _portable_fseek(), file_seek(), file_repr(), and the following arrays file_memberlist[], file_getsetlist[] My question is, do you think it's better to maintain all this code duplicated than maintaining bz2 up to date? I'll do the job, if you still think this is great. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-22 12:29 Message: Logged In: YES user_id=6380 If you could, that would be great. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-01-22 10:39 Message: Logged In: YES user_id=7887 Ok. Do you want me to work on this for 2.3? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-21 14:24 Message: Logged In: YES user_id=6380 FileObject sharing: I see. But I still think it's a bad idea, and you're better off using stdio methods directly (as the evolution of the FileObject implementation has already shown). ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-01-20 15:44 Message: Logged In: YES user_id=7887 Sorry about the delay. I was on a not-so-short vacation. nnorwitz: Thanks for the patch. I'll check the problem (for my own understanding) and most certainly apply it. gvanrossum: BZ2File used to share a lot of code with FileObject. Unfortunately (for the BZ2File side), FileObject changed considerably post 2.2, and some of the code had to be moved to BZ2File itself. It still uses some code from FileObject, though (open, close, seek, part of the softspace handling, access to attributes and some common methods). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-05 16:11 Message: Logged In: YES user_id=6380 Um, I don't understand why the BZ2File class inherits from FileObject. It doesn't seem to be inheriting any code, and there's no reason to inherit from FileObject just to make a file-like object. Maybe it was a misunderstanding? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 15:09 Message: Logged In: YES user_id=33168 I've found a better solution: change the last line of BZ2File_dealloc() from: ((PyObject*)self)->ob_type->tp_free((PyObject *)self); to PyFile_Type.tp_dealloc((PyObject *)self); Updated patch attached. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 14:48 Message: Logged In: YES user_id=21627 Assigning to the author of the module for review. Gustavo, if you can't find the time for a review, feel free to unassign it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661796&group_id=5470 From noreply@sourceforge.net Sun Feb 2 14:33:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 02 Feb 2003 06:33:35 -0800 Subject: [Patches] [ python-Patches-678899 ] Use ifilter in sets module Message-ID: Patches item #678899, was opened at 2003-02-01 23:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678899&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Guido van Rossum (gvanrossum) Summary: Use ifilter in sets module Initial Comment: If it's not overzealous, I would like to apply itertools.ifilter to sets module to speed-up a few of the methods there. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-02 09:33 Message: Logged In: YES user_id=80475 Applied as Lib/sets.py 1.38 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678899&group_id=5470 From noreply@sourceforge.net Sun Feb 2 18:11:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 02 Feb 2003 10:11:31 -0800 Subject: [Patches] [ python-Patches-675034 ] More flexible py-shell interpreter selection Message-ID: Patches item #675034, was opened at 2003-01-26 14:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675034&group_id=5470 Category: Demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Haggerty (mhagger) Assigned to: Nobody/Anonymous (nobody) Summary: More flexible py-shell interpreter selection Initial Comment: Currently in python-mode.el, py-which-shell (the command used to start the python interpreter) is limited to "python" or "jpython". This patch makes it possible to specify an arbitrary command at invocation time, including a command that is specified relative to the current path. The problem: I am working on a project where jython is embedded within our application. The application optionally allows console access to the jython interpreter. The application is started by running a shell script which sets some environment variables then invokes the jython interpreter with a large number of arguments. I would like to use py-shell within emacs to interact with the application. However, it is impractical to start the application under py-shell for two reasons: 1. The command that needs to be invoked is neither "python" nor "jython", and in fact would require many arguments; 2. The command is not necessary installed in the PATH. Similar problems occur even if one sometimes wants to start an alternative python interpreter (such as "python2" under redhat) or an interpreter that is not in PATH (for example, if testing a new version of python). Therefore I have written a patch to python-mode.py that changes the py-shell command as follows: + If there is no prefix argument, the usual python (or jython) interpreter is invoked without further interaction as before. + If there is a prefix argument, then the user is asked what command to invoke with the "standard command" as the default input: command: python -i The user can edit the command to run whatever s/he wants. + The command typed by the user is invoked via "$SHELL -c 'COMMAND'" so that the user's program is first sought in the emacs default directory (generally, the directory related to the current emacs buffer). This allows the user to type, for example, command: ./my_test_interpreter -i I am a novice at emacs lisp, but the patch is simple (only about 10 lines changed) and it seems to work for me. The patch applies to the CVS version of python-mode.el as of today (2003-01-26), but the same patch can be applied to the version that was released with Python-2.1. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-02 13:11 Message: Logged In: YES user_id=33168 How does this relate to patch 574750? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675034&group_id=5470 From noreply@sourceforge.net Mon Feb 3 09:16:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Feb 2003 01:16:17 -0800 Subject: [Patches] [ python-Patches-679383 ] xmlrpclib: better string encoding in responce package Message-ID: Patches item #679383, was opened at 2003-02-03 12:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=679383&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike D. Rozhnov (mrozhnov) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib: better string encoding in responce package Initial Comment: ServerProxy class has optional 'encoding' argument. For now, this argument is used for packet encoding. 8-bit strings in the data structure are assumed to use this encoding, unicode strings converted to this encoding. But Unmarshaller class, that process response, use '_stringify' function for converting 7-bit strings to Python strings, 8-bit strings remains as unicode Python strings. It seems more logicaly to convert strings in responce package to Python strings with encoding which used in ServerProxy constructor. This patch adds optional 'encoding' argument to Unmarshaller class, Transport class and loads function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=679383&group_id=5470 From noreply@sourceforge.net Mon Feb 3 09:47:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Feb 2003 01:47:48 -0800 Subject: [Patches] [ python-Patches-679392 ] SimpleXMLRPCServer: optional 'encoding' argument Message-ID: Patches item #679392, was opened at 2003-02-03 12:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=679392&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike D. Rozhnov (mrozhnov) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleXMLRPCServer: optional 'encoding' argument Initial Comment: Note: this patch depend on xmlrpclib patch #679383 This patch allow encode unicode strings to 8-bit strings using 'encoding' parameter. This can be usefull if XML-RPC server process strings in non ASCII encodings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=679392&group_id=5470 From noreply@sourceforge.net Mon Feb 3 10:45:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Feb 2003 02:45:43 -0800 Subject: [Patches] [ python-Patches-675034 ] More flexible py-shell interpreter selection Message-ID: Patches item #675034, was opened at 2003-01-26 14:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675034&group_id=5470 Category: Demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Haggerty (mhagger) Assigned to: Nobody/Anonymous (nobody) Summary: More flexible py-shell interpreter selection Initial Comment: Currently in python-mode.el, py-which-shell (the command used to start the python interpreter) is limited to "python" or "jpython". This patch makes it possible to specify an arbitrary command at invocation time, including a command that is specified relative to the current path. The problem: I am working on a project where jython is embedded within our application. The application optionally allows console access to the jython interpreter. The application is started by running a shell script which sets some environment variables then invokes the jython interpreter with a large number of arguments. I would like to use py-shell within emacs to interact with the application. However, it is impractical to start the application under py-shell for two reasons: 1. The command that needs to be invoked is neither "python" nor "jython", and in fact would require many arguments; 2. The command is not necessary installed in the PATH. Similar problems occur even if one sometimes wants to start an alternative python interpreter (such as "python2" under redhat) or an interpreter that is not in PATH (for example, if testing a new version of python). Therefore I have written a patch to python-mode.py that changes the py-shell command as follows: + If there is no prefix argument, the usual python (or jython) interpreter is invoked without further interaction as before. + If there is a prefix argument, then the user is asked what command to invoke with the "standard command" as the default input: command: python -i The user can edit the command to run whatever s/he wants. + The command typed by the user is invoked via "$SHELL -c 'COMMAND'" so that the user's program is first sought in the emacs default directory (generally, the directory related to the current emacs buffer). This allows the user to type, for example, command: ./my_test_interpreter -i I am a novice at emacs lisp, but the patch is simple (only about 10 lines changed) and it seems to work for me. The patch applies to the CVS version of python-mode.el as of today (2003-01-26), but the same patch can be applied to the version that was released with Python-2.1. ---------------------------------------------------------------------- >Comment By: Michael Haggerty (mhagger) Date: 2003-02-03 05:45 Message: Logged In: YES user_id=38106 The two patches are largely orthogonal. This patch would provide a workaround until patch 574750 is implemented and also a fallback for people who still want to invoke "jpython" rather than "jython". If the implementer decides to remove the whole "py-toggle-shells" mechanism, then this patch would be a kind of substitute, but I am not advocating that change. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-02 13:11 Message: Logged In: YES user_id=33168 How does this relate to patch 574750? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675034&group_id=5470 From noreply@sourceforge.net Mon Feb 3 11:50:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Feb 2003 03:50:28 -0800 Subject: [Patches] [ python-Patches-664131 ] distutils config exe_extension on Mac OS X, Linux Message-ID: Patches item #664131, was opened at 2003-01-08 03:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664131&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Nobody/Anonymous (nobody) Summary: distutils config exe_extension on Mac OS X, Linux Initial Comment: I have been using distutils' "python setup.py config" command in order to do some configuration steps before the build and install. On Linux and Mac OS X, when doing trial compilations I get this error: File "/usr/local/lib/python2.3/distutils/command/config.py", line 154, in _link prog = prog + self.compiler.exe_extension TypeError: cannot concatenate 'str' and 'NoneType' objects The problem is that on Mac OS X and Linux, self.compiler.exe_extension is None instead of "", and Python doesn't allow None to be concatenated with a string. The solution would be either to set self.compiler.exe_extension to "" instead of None, or to check if self.compiler.exe_extension is None before concatenating. The attached patch does the latter: if self.compiler.exe_extension: prog = prog + self.compiler.exe_extension Changing self.compiler.exe_extension to "" instead of None may be a cleaner solution, but I don't know how that would affect other parts of the distutils, which is why I went with the solution above. Michiel de Hoon (mdehoon@ims.u-tokyo.ac.jp) University of Tokyo, Human Genome Center ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-02-03 12:50 Message: Logged In: YES user_id=92689 Apart from the tab character in the patch, this looks good. Checked in as rev. 1.16 of distutils/command/config.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664131&group_id=5470 From noreply@sourceforge.net Mon Feb 3 12:07:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Feb 2003 04:07:18 -0800 Subject: [Patches] [ python-Patches-661796 ] BZ2File leaking fd and memory Message-ID: Patches item #661796, was opened at 2003-01-03 19:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661796&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Gustavo Niemeyer (niemeyer) Summary: BZ2File leaking fd and memory Initial Comment: The attached patch fixes BZ2File() leaking the fd and PyFileObject* info (name, read ahead buffer) when an object is deleted. I'm not sure the patch fixes these problems in the best way. It exposes most of the implementation from fileobject.c::file_dealloc() through a private API _PyFile_Dealloc(). BZ2File derives from PyFileObject. Make sure the file: 'empty' exists and do: from bz2 import * A simple test which demonstrates the problem is: for i in range(100000): o = BZ2File('empty') ; del o Without the patch, you quickly get: IOError: [Errno 24] Too many open files: 'empty' You can modify this to: for i in range(100000): o = BZ2File('empty') ; o.close() ; del o Now you can see the memory leaks. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-02-03 12:07 Message: Logged In: YES user_id=7887 zlib module doesn't emulate a file at C level. It also does not implement as many features as the BZ2File does (universal newlines, buffered IO, etc). The strange thing is, I thought it was a good thing to develop inheriting FileObject that way, since it would save code and maintenance, while being fast. I also thought it was a good model to make BZ2File behave as a subclass (I even mentioned that in the documentation). I'm surprised for being wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-02 12:57 Message: Logged In: YES user_id=6380 I don't understand. Why would you want to copy all the implementation details of those functions? Have a look at how the zlib module emulates a file. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-02-02 04:21 Message: Logged In: YES user_id=7887 Ok, I've started to "unparent" the bz2 code. OTOH, I've just realised what a lot of code, full of #ifdef's, I'll have to copy, mostly unchanged. The following functions file_new(), file_init(), open_the_file(), fill_file_fields(), dircheck(), close_file(), get_newlines(), _portable_fseek(), file_seek(), file_repr(), and the following arrays file_memberlist[], file_getsetlist[] My question is, do you think it's better to maintain all this code duplicated than maintaining bz2 up to date? I'll do the job, if you still think this is great. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-22 17:29 Message: Logged In: YES user_id=6380 If you could, that would be great. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-01-22 15:39 Message: Logged In: YES user_id=7887 Ok. Do you want me to work on this for 2.3? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-21 19:24 Message: Logged In: YES user_id=6380 FileObject sharing: I see. But I still think it's a bad idea, and you're better off using stdio methods directly (as the evolution of the FileObject implementation has already shown). ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-01-20 20:44 Message: Logged In: YES user_id=7887 Sorry about the delay. I was on a not-so-short vacation. nnorwitz: Thanks for the patch. I'll check the problem (for my own understanding) and most certainly apply it. gvanrossum: BZ2File used to share a lot of code with FileObject. Unfortunately (for the BZ2File side), FileObject changed considerably post 2.2, and some of the code had to be moved to BZ2File itself. It still uses some code from FileObject, though (open, close, seek, part of the softspace handling, access to attributes and some common methods). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-05 21:11 Message: Logged In: YES user_id=6380 Um, I don't understand why the BZ2File class inherits from FileObject. It doesn't seem to be inheriting any code, and there's no reason to inherit from FileObject just to make a file-like object. Maybe it was a misunderstanding? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 20:09 Message: Logged In: YES user_id=33168 I've found a better solution: change the last line of BZ2File_dealloc() from: ((PyObject*)self)->ob_type->tp_free((PyObject *)self); to PyFile_Type.tp_dealloc((PyObject *)self); Updated patch attached. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 19:48 Message: Logged In: YES user_id=21627 Assigning to the author of the module for review. Gustavo, if you can't find the time for a review, feel free to unassign it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661796&group_id=5470 From noreply@sourceforge.net Mon Feb 3 14:03:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Feb 2003 06:03:25 -0800 Subject: [Patches] [ python-Patches-679505 ] Deprecate rotor module Message-ID: Patches item #679505, was opened at 2003-02-03 09:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=679505&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 4 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Deprecate rotor module Initial Comment: Here's a trivial patch that marks the rotor module as deprecated. To be used if Paul Rubin's AES module goes into 2.3 (maybe even if it doesn't). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=679505&group_id=5470 From noreply@sourceforge.net Mon Feb 3 14:04:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Feb 2003 06:04:17 -0800 Subject: [Patches] [ python-Patches-679505 ] Deprecate rotor module Message-ID: Patches item #679505, was opened at 2003-02-03 09:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=679505&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 4 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Deprecate rotor module Initial Comment: Here's a trivial patch that marks the rotor module as deprecated. To be used if Paul Rubin's AES module goes into 2.3 (maybe even if it doesn't). ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-02-03 09:04 Message: Logged In: YES user_id=11375 Attach patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=679505&group_id=5470 From noreply@sourceforge.net Mon Feb 3 14:52:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Feb 2003 06:52:09 -0800 Subject: [Patches] [ python-Patches-661437 ] apply() should get PendingDeprecation Message-ID: Patches item #661437, was opened at 2003-01-03 03:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661437&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: apply() should get PendingDeprecation Initial Comment: Submitting this so I don't forget about it . ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-02-03 15:52 Message: Logged In: YES user_id=92689 I'd say, check it in, get it over with. The patch looks fine. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 22:34 Message: Logged In: YES user_id=33168 You mean, like these two lines at line 72 of Python/bltinmodule.c :-) + PyErr_Warn(PyExc_PendingDeprecationWarning, + "use func(*args, **kwargs) instead of apply()"); Perhaps func should be function(...). Let me know if you want me to check that in. I did attach a patch too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661437&group_id=5470 From noreply@sourceforge.net Mon Feb 3 14:51:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Feb 2003 06:51:49 -0800 Subject: [Patches] [ python-Patches-661796 ] BZ2File leaking fd and memory Message-ID: Patches item #661796, was opened at 2003-01-03 14:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661796&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Gustavo Niemeyer (niemeyer) Summary: BZ2File leaking fd and memory Initial Comment: The attached patch fixes BZ2File() leaking the fd and PyFileObject* info (name, read ahead buffer) when an object is deleted. I'm not sure the patch fixes these problems in the best way. It exposes most of the implementation from fileobject.c::file_dealloc() through a private API _PyFile_Dealloc(). BZ2File derives from PyFileObject. Make sure the file: 'empty' exists and do: from bz2 import * A simple test which demonstrates the problem is: for i in range(100000): o = BZ2File('empty') ; del o Without the patch, you quickly get: IOError: [Errno 24] Too many open files: 'empty' You can modify this to: for i in range(100000): o = BZ2File('empty') ; o.close() ; del o Now you can see the memory leaks. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 09:51 Message: Logged In: YES user_id=6380 IMO, being a subclass of a concrete class typically only makes sense if you can maintain the meaning of the instance variables defined by the base class. In this case I don't believe that's the case. If looks like you are using subclassing from the file class where you should really be using an instance variable that points to a regular file object. For example, operations on the file descriptor returned by fileno() have a very different effect for a BZ2file than for a regular file (since they manipulate the compressed file rather than the uncompressed byte stream represented by the BZ2file). You may also confuse other parts of the Python runtime that assume that when they see a file instance they can extract the underlying stdio FILE* from it and manipulate that. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-02-03 07:07 Message: Logged In: YES user_id=7887 zlib module doesn't emulate a file at C level. It also does not implement as many features as the BZ2File does (universal newlines, buffered IO, etc). The strange thing is, I thought it was a good thing to develop inheriting FileObject that way, since it would save code and maintenance, while being fast. I also thought it was a good model to make BZ2File behave as a subclass (I even mentioned that in the documentation). I'm surprised for being wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-02 07:57 Message: Logged In: YES user_id=6380 I don't understand. Why would you want to copy all the implementation details of those functions? Have a look at how the zlib module emulates a file. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-02-01 23:21 Message: Logged In: YES user_id=7887 Ok, I've started to "unparent" the bz2 code. OTOH, I've just realised what a lot of code, full of #ifdef's, I'll have to copy, mostly unchanged. The following functions file_new(), file_init(), open_the_file(), fill_file_fields(), dircheck(), close_file(), get_newlines(), _portable_fseek(), file_seek(), file_repr(), and the following arrays file_memberlist[], file_getsetlist[] My question is, do you think it's better to maintain all this code duplicated than maintaining bz2 up to date? I'll do the job, if you still think this is great. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-22 12:29 Message: Logged In: YES user_id=6380 If you could, that would be great. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-01-22 10:39 Message: Logged In: YES user_id=7887 Ok. Do you want me to work on this for 2.3? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-21 14:24 Message: Logged In: YES user_id=6380 FileObject sharing: I see. But I still think it's a bad idea, and you're better off using stdio methods directly (as the evolution of the FileObject implementation has already shown). ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-01-20 15:44 Message: Logged In: YES user_id=7887 Sorry about the delay. I was on a not-so-short vacation. nnorwitz: Thanks for the patch. I'll check the problem (for my own understanding) and most certainly apply it. gvanrossum: BZ2File used to share a lot of code with FileObject. Unfortunately (for the BZ2File side), FileObject changed considerably post 2.2, and some of the code had to be moved to BZ2File itself. It still uses some code from FileObject, though (open, close, seek, part of the softspace handling, access to attributes and some common methods). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-05 16:11 Message: Logged In: YES user_id=6380 Um, I don't understand why the BZ2File class inherits from FileObject. It doesn't seem to be inheriting any code, and there's no reason to inherit from FileObject just to make a file-like object. Maybe it was a misunderstanding? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 15:09 Message: Logged In: YES user_id=33168 I've found a better solution: change the last line of BZ2File_dealloc() from: ((PyObject*)self)->ob_type->tp_free((PyObject *)self); to PyFile_Type.tp_dealloc((PyObject *)self); Updated patch attached. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 14:48 Message: Logged In: YES user_id=21627 Assigning to the author of the module for review. Gustavo, if you can't find the time for a review, feel free to unassign it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661796&group_id=5470 From noreply@sourceforge.net Mon Feb 3 15:52:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Feb 2003 07:52:08 -0800 Subject: [Patches] [ python-Patches-661796 ] BZ2File leaking fd and memory Message-ID: Patches item #661796, was opened at 2003-01-03 19:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661796&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Gustavo Niemeyer (niemeyer) Summary: BZ2File leaking fd and memory Initial Comment: The attached patch fixes BZ2File() leaking the fd and PyFileObject* info (name, read ahead buffer) when an object is deleted. I'm not sure the patch fixes these problems in the best way. It exposes most of the implementation from fileobject.c::file_dealloc() through a private API _PyFile_Dealloc(). BZ2File derives from PyFileObject. Make sure the file: 'empty' exists and do: from bz2 import * A simple test which demonstrates the problem is: for i in range(100000): o = BZ2File('empty') ; del o Without the patch, you quickly get: IOError: [Errno 24] Too many open files: 'empty' You can modify this to: for i in range(100000): o = BZ2File('empty') ; o.close() ; del o Now you can see the memory leaks. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-02-03 15:52 Message: Logged In: YES user_id=7887 Ok.. I can't find a good way to workaround the presented reasons. I'll work to unparent BZ2File. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 14:51 Message: Logged In: YES user_id=6380 IMO, being a subclass of a concrete class typically only makes sense if you can maintain the meaning of the instance variables defined by the base class. In this case I don't believe that's the case. If looks like you are using subclassing from the file class where you should really be using an instance variable that points to a regular file object. For example, operations on the file descriptor returned by fileno() have a very different effect for a BZ2file than for a regular file (since they manipulate the compressed file rather than the uncompressed byte stream represented by the BZ2file). You may also confuse other parts of the Python runtime that assume that when they see a file instance they can extract the underlying stdio FILE* from it and manipulate that. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-02-03 12:07 Message: Logged In: YES user_id=7887 zlib module doesn't emulate a file at C level. It also does not implement as many features as the BZ2File does (universal newlines, buffered IO, etc). The strange thing is, I thought it was a good thing to develop inheriting FileObject that way, since it would save code and maintenance, while being fast. I also thought it was a good model to make BZ2File behave as a subclass (I even mentioned that in the documentation). I'm surprised for being wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-02 12:57 Message: Logged In: YES user_id=6380 I don't understand. Why would you want to copy all the implementation details of those functions? Have a look at how the zlib module emulates a file. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-02-02 04:21 Message: Logged In: YES user_id=7887 Ok, I've started to "unparent" the bz2 code. OTOH, I've just realised what a lot of code, full of #ifdef's, I'll have to copy, mostly unchanged. The following functions file_new(), file_init(), open_the_file(), fill_file_fields(), dircheck(), close_file(), get_newlines(), _portable_fseek(), file_seek(), file_repr(), and the following arrays file_memberlist[], file_getsetlist[] My question is, do you think it's better to maintain all this code duplicated than maintaining bz2 up to date? I'll do the job, if you still think this is great. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-22 17:29 Message: Logged In: YES user_id=6380 If you could, that would be great. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-01-22 15:39 Message: Logged In: YES user_id=7887 Ok. Do you want me to work on this for 2.3? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-21 19:24 Message: Logged In: YES user_id=6380 FileObject sharing: I see. But I still think it's a bad idea, and you're better off using stdio methods directly (as the evolution of the FileObject implementation has already shown). ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-01-20 20:44 Message: Logged In: YES user_id=7887 Sorry about the delay. I was on a not-so-short vacation. nnorwitz: Thanks for the patch. I'll check the problem (for my own understanding) and most certainly apply it. gvanrossum: BZ2File used to share a lot of code with FileObject. Unfortunately (for the BZ2File side), FileObject changed considerably post 2.2, and some of the code had to be moved to BZ2File itself. It still uses some code from FileObject, though (open, close, seek, part of the softspace handling, access to attributes and some common methods). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-05 21:11 Message: Logged In: YES user_id=6380 Um, I don't understand why the BZ2File class inherits from FileObject. It doesn't seem to be inheriting any code, and there's no reason to inherit from FileObject just to make a file-like object. Maybe it was a misunderstanding? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 20:09 Message: Logged In: YES user_id=33168 I've found a better solution: change the last line of BZ2File_dealloc() from: ((PyObject*)self)->ob_type->tp_free((PyObject *)self); to PyFile_Type.tp_dealloc((PyObject *)self); Updated patch attached. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 19:48 Message: Logged In: YES user_id=21627 Assigning to the author of the module for review. Gustavo, if you can't find the time for a review, feel free to unassign it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661796&group_id=5470 From noreply@sourceforge.net Mon Feb 3 16:09:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Feb 2003 08:09:41 -0800 Subject: [Patches] [ python-Patches-661796 ] BZ2File leaking fd and memory Message-ID: Patches item #661796, was opened at 2003-01-03 14:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661796&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Gustavo Niemeyer (niemeyer) Summary: BZ2File leaking fd and memory Initial Comment: The attached patch fixes BZ2File() leaking the fd and PyFileObject* info (name, read ahead buffer) when an object is deleted. I'm not sure the patch fixes these problems in the best way. It exposes most of the implementation from fileobject.c::file_dealloc() through a private API _PyFile_Dealloc(). BZ2File derives from PyFileObject. Make sure the file: 'empty' exists and do: from bz2 import * A simple test which demonstrates the problem is: for i in range(100000): o = BZ2File('empty') ; del o Without the patch, you quickly get: IOError: [Errno 24] Too many open files: 'empty' You can modify this to: for i in range(100000): o = BZ2File('empty') ; o.close() ; del o Now you can see the memory leaks. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 11:09 Message: Logged In: YES user_id=6380 Thanks! I expect you'll be surprised at the gained clarity of the resulting code. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-02-03 10:52 Message: Logged In: YES user_id=7887 Ok.. I can't find a good way to workaround the presented reasons. I'll work to unparent BZ2File. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 09:51 Message: Logged In: YES user_id=6380 IMO, being a subclass of a concrete class typically only makes sense if you can maintain the meaning of the instance variables defined by the base class. In this case I don't believe that's the case. If looks like you are using subclassing from the file class where you should really be using an instance variable that points to a regular file object. For example, operations on the file descriptor returned by fileno() have a very different effect for a BZ2file than for a regular file (since they manipulate the compressed file rather than the uncompressed byte stream represented by the BZ2file). You may also confuse other parts of the Python runtime that assume that when they see a file instance they can extract the underlying stdio FILE* from it and manipulate that. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-02-03 07:07 Message: Logged In: YES user_id=7887 zlib module doesn't emulate a file at C level. It also does not implement as many features as the BZ2File does (universal newlines, buffered IO, etc). The strange thing is, I thought it was a good thing to develop inheriting FileObject that way, since it would save code and maintenance, while being fast. I also thought it was a good model to make BZ2File behave as a subclass (I even mentioned that in the documentation). I'm surprised for being wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-02 07:57 Message: Logged In: YES user_id=6380 I don't understand. Why would you want to copy all the implementation details of those functions? Have a look at how the zlib module emulates a file. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-02-01 23:21 Message: Logged In: YES user_id=7887 Ok, I've started to "unparent" the bz2 code. OTOH, I've just realised what a lot of code, full of #ifdef's, I'll have to copy, mostly unchanged. The following functions file_new(), file_init(), open_the_file(), fill_file_fields(), dircheck(), close_file(), get_newlines(), _portable_fseek(), file_seek(), file_repr(), and the following arrays file_memberlist[], file_getsetlist[] My question is, do you think it's better to maintain all this code duplicated than maintaining bz2 up to date? I'll do the job, if you still think this is great. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-22 12:29 Message: Logged In: YES user_id=6380 If you could, that would be great. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-01-22 10:39 Message: Logged In: YES user_id=7887 Ok. Do you want me to work on this for 2.3? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-21 14:24 Message: Logged In: YES user_id=6380 FileObject sharing: I see. But I still think it's a bad idea, and you're better off using stdio methods directly (as the evolution of the FileObject implementation has already shown). ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-01-20 15:44 Message: Logged In: YES user_id=7887 Sorry about the delay. I was on a not-so-short vacation. nnorwitz: Thanks for the patch. I'll check the problem (for my own understanding) and most certainly apply it. gvanrossum: BZ2File used to share a lot of code with FileObject. Unfortunately (for the BZ2File side), FileObject changed considerably post 2.2, and some of the code had to be moved to BZ2File itself. It still uses some code from FileObject, though (open, close, seek, part of the softspace handling, access to attributes and some common methods). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-05 16:11 Message: Logged In: YES user_id=6380 Um, I don't understand why the BZ2File class inherits from FileObject. It doesn't seem to be inheriting any code, and there's no reason to inherit from FileObject just to make a file-like object. Maybe it was a misunderstanding? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 15:09 Message: Logged In: YES user_id=33168 I've found a better solution: change the last line of BZ2File_dealloc() from: ((PyObject*)self)->ob_type->tp_free((PyObject *)self); to PyFile_Type.tp_dealloc((PyObject *)self); Updated patch attached. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 14:48 Message: Logged In: YES user_id=21627 Assigning to the author of the module for review. Gustavo, if you can't find the time for a review, feel free to unassign it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661796&group_id=5470 From noreply@sourceforge.net Mon Feb 3 19:29:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Feb 2003 11:29:35 -0800 Subject: [Patches] [ python-Patches-649762 ] Fix: asynchat.py: endless loop Message-ID: Patches item #649762, was opened at 2002-12-06 16:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=649762&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Bernhard Reiter (ber) >Assigned to: A.M. Kuchling (akuchling) Summary: Fix: asynchat.py: endless loop Initial Comment: Patch against asynchat.py revision 1.19 in Python SF CVS. Fixes endless loop when terminator='' is used. Diagnosis: If we do not catch the empty string no buffer will be consumed lin line 134 and the while loop does not terminate. Cure: Go back to old behaviour and call collect everything with '' and None. Background: Especially annoying because early versions (rev 1.1, coming with python1.5) did not have this bug and the comment in set_terminator() says that strings of all length are okay (among other things). The bug was introduced in rev 1.2. Bernhard Reiter ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2002-12-06 17:37 Message: Logged In: YES user_id=113859 The patch also fixes the terminator=0 problem which is similiar. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=649762&group_id=5470 From noreply@sourceforge.net Mon Feb 3 19:34:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Feb 2003 11:34:03 -0800 Subject: [Patches] [ python-Patches-649762 ] Fix: asynchat.py: endless loop Message-ID: Patches item #649762, was opened at 2002-12-06 16:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=649762&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Bernhard Reiter (ber) Assigned to: A.M. Kuchling (akuchling) Summary: Fix: asynchat.py: endless loop Initial Comment: Patch against asynchat.py revision 1.19 in Python SF CVS. Fixes endless loop when terminator='' is used. Diagnosis: If we do not catch the empty string no buffer will be consumed lin line 134 and the while loop does not terminate. Cure: Go back to old behaviour and call collect everything with '' and None. Background: Especially annoying because early versions (rev 1.1, coming with python1.5) did not have this bug and the comment in set_terminator() says that strings of all length are okay (among other things). The bug was introduced in rev 1.2. Bernhard Reiter ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-02-03 14:34 Message: Logged In: YES user_id=11375 Surely in your patched version, the code should be 'if not terminator: ...'. Otherwise the patch reverses the sense of the test. ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2002-12-06 17:37 Message: Logged In: YES user_id=113859 The patch also fixes the terminator=0 problem which is similiar. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=649762&group_id=5470 From noreply@sourceforge.net Mon Feb 3 19:39:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Feb 2003 11:39:01 -0800 Subject: [Patches] [ python-Patches-649762 ] Fix: asynchat.py: endless loop Message-ID: Patches item #649762, was opened at 2002-12-06 22:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=649762&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Bernhard Reiter (ber) Assigned to: A.M. Kuchling (akuchling) Summary: Fix: asynchat.py: endless loop Initial Comment: Patch against asynchat.py revision 1.19 in Python SF CVS. Fixes endless loop when terminator='' is used. Diagnosis: If we do not catch the empty string no buffer will be consumed lin line 134 and the while loop does not terminate. Cure: Go back to old behaviour and call collect everything with '' and None. Background: Especially annoying because early versions (rev 1.1, coming with python1.5) did not have this bug and the comment in set_terminator() says that strings of all length are okay (among other things). The bug was introduced in rev 1.2. Bernhard Reiter ---------------------------------------------------------------------- >Comment By: Bernhard Reiter (ber) Date: 2003-02-03 20:39 Message: Logged In: YES user_id=113859 Yes, of course. I stopped experimenting with numeric and empty string terminators after hitting this bug, so I uploaded the flawed fix. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-03 20:34 Message: Logged In: YES user_id=11375 Surely in your patched version, the code should be 'if not terminator: ...'. Otherwise the patch reverses the sense of the test. ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2002-12-06 23:37 Message: Logged In: YES user_id=113859 The patch also fixes the terminator=0 problem which is similiar. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=649762&group_id=5470 From noreply@sourceforge.net Mon Feb 3 20:30:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Feb 2003 12:30:32 -0800 Subject: [Patches] [ python-Patches-661437 ] apply() should get PendingDeprecation Message-ID: Patches item #661437, was opened at 2003-01-02 21:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661437&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) >Assigned to: Neal Norwitz (nnorwitz) Summary: apply() should get PendingDeprecation Initial Comment: Submitting this so I don't forget about it . ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-03 15:30 Message: Logged In: YES user_id=33168 Checked in as Python/bltinmodule.c 2.272 ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-03 09:52 Message: Logged In: YES user_id=92689 I'd say, check it in, get it over with. The patch looks fine. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 16:34 Message: Logged In: YES user_id=33168 You mean, like these two lines at line 72 of Python/bltinmodule.c :-) + PyErr_Warn(PyExc_PendingDeprecationWarning, + "use func(*args, **kwargs) instead of apply()"); Perhaps func should be function(...). Let me know if you want me to check that in. I did attach a patch too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661437&group_id=5470 From noreply@sourceforge.net Mon Feb 3 20:36:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Feb 2003 12:36:26 -0800 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 21:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 21:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 15:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 21:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 18:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 18:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 17:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 20:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 15:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 17:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 21:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Mon Feb 3 20:53:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Feb 2003 12:53:44 -0800 Subject: [Patches] [ python-Patches-678531 ] zlib module needs decompress flush. Message-ID: Patches item #678531, was opened at 2003-01-31 22:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678531&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Scott David Daniels (scott_daniels) Assigned to: Nobody/Anonymous (nobody) Summary: zlib module needs decompress flush. Initial Comment: Python 2.3 current (should work on 2,1 and 2.2 as well) OS: Win2K The zlibmodule.c sources mistakenly don't implement flush() on decompression objects. The assumption is that all data will have been extracted once all of the source is available. This patch simply implements flush in the obvious way. As mentioned in bug #640230, the previous test did not successfully test the decompression object. I'll attach in a subsequent patch a PyUnit-style test_zlib.py that exercises zlib and checks the buffer flushing (because I don't see how to attach two files). -Scott ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 15:53 Message: Logged In: YES user_id=6380 All checked in. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678531&group_id=5470 From noreply@sourceforge.net Mon Feb 3 21:10:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Feb 2003 13:10:30 -0800 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 15:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 16:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 15:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 09:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 15:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 12:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 12:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 11:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 14:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 09:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 11:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 15:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Mon Feb 3 22:44:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Feb 2003 14:44:32 -0800 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 21:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 23:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 22:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 21:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 15:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 21:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 18:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 18:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 17:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 20:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 15:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 17:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 21:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Mon Feb 3 22:56:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Feb 2003 14:56:31 -0800 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 15:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 17:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 17:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 16:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 15:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 09:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 15:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 12:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 12:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 11:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 14:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 09:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 11:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 15:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Mon Feb 3 23:13:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Feb 2003 15:13:06 -0800 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 21:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Walter Dörwald (doerwalter) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 00:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 23:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 23:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 22:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 21:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 15:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 21:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 18:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 18:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 17:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 20:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 15:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 17:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 21:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Tue Feb 4 12:09:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 04:09:39 -0800 Subject: [Patches] [ python-Patches-680146 ] _iconv_module type casting and spelling errors Message-ID: Patches item #680146, was opened at 2003-02-04 14:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: _iconv_module type casting and spelling errors Initial Comment: Compiling under SGI Irix and MIPSPro, I corrected two type casts which under gcc are plain warnings. They are both related to size_t and int comparisons, since size_t is unsigned. I also corrected the spelling mistake of "choosen" instead of "chosen" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 From noreply@sourceforge.net Tue Feb 4 12:12:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 04:12:39 -0800 Subject: [Patches] [ python-Patches-680146 ] _iconv_module type casting and spelling errors Message-ID: Patches item #680146, was opened at 2003-02-04 14:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: _iconv_module type casting and spelling errors Initial Comment: Compiling under SGI Irix and MIPSPro, I corrected two type casts which under gcc are plain warnings. They are both related to size_t and int comparisons, since size_t is unsigned. I also corrected the spelling mistake of "choosen" instead of "chosen" ---------------------------------------------------------------------- >Comment By: Christos Georgiou (tzot) Date: 2003-02-04 14:12 Message: Logged In: YES user_id=539787 For some reason the attachment was not uploaded the first time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 From noreply@sourceforge.net Tue Feb 4 12:28:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 04:28:16 -0800 Subject: [Patches] [ python-Patches-680146 ] _iconv_module type casting and spelling errors Message-ID: Patches item #680146, was opened at 2003-02-04 14:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: _iconv_module type casting and spelling errors Initial Comment: Compiling under SGI Irix and MIPSPro, I corrected two type casts which under gcc are plain warnings. They are both related to size_t and int comparisons, since size_t is unsigned. I also corrected the spelling mistake of "choosen" instead of "chosen" ---------------------------------------------------------------------- >Comment By: Christos Georgiou (tzot) Date: 2003-02-04 14:28 Message: Logged In: YES user_id=539787 Third attempt: the checkbox is checked ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 14:12 Message: Logged In: YES user_id=539787 For some reason the attachment was not uploaded the first time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 From noreply@sourceforge.net Tue Feb 4 13:47:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 05:47:41 -0800 Subject: [Patches] [ python-Patches-660485 ] Cygwin _tkinter Tcl/Tk 8.3 patch Message-ID: Patches item #660485, was opened at 2002-12-31 10:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=660485&group_id=5470 Category: Modules Group: None >Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) >Assigned to: Martin v. Löwis (loewis) Summary: Cygwin _tkinter Tcl/Tk 8.3 patch Initial Comment: The attached patch enables Cygwin Python to build cleanly against the latest Cygwin Tcl/Tk which is based on Tcl/Tk 8.3. It also prevents building against the real X headers, if installed. Note that the first _tkinter.c hunk is only to suppress the following compiler warning: /home/jt/src/PythonCvs/Modules/_tkinter.c:66:1: warning: "CONST" redefined In file included from /home/jt/src/PythonCvs/Modules/_tkinter.c:56: /usr/include/tcl.h:280:1: warning: this is the location of the previous definition I can eliminate this hunk if you wish. OK to apply? ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-02-04 04:47 Message: Logged In: YES user_id=86216 The attached patch reverts the following: It also prevents building against the real X headers, if installed. After discussions with the Cygwin project lead, I believe that building against the real X headers is OK. Especially, since the psuedo-X headers are *not* installed by the Cygwin Tcl/Tk binary package. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-12-31 11:32 Message: Logged In: YES user_id=86216 > I think the line #undef CONST should be added > unconditionally before the #define CONST. Agreed. Checked in as: Modules/_tkinter.c 1.141 setup.py 1.131 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-31 10:58 Message: Logged In: YES user_id=21627 I think the line #undef CONST should be added unconditionally before the #define CONST. Apart from that, the patch is fine. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-12-31 10:43 Message: Logged In: YES user_id=86216 Hmm...The patch file vanished! I also did not get a confirmation that my patch was successfully submitted. Nevertheless, I am trying again... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-31 10:41 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=660485&group_id=5470 From noreply@sourceforge.net Tue Feb 4 14:04:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 06:04:49 -0800 Subject: [Patches] [ python-Patches-674396 ] Expand dbshelve to have full shelve/dict interface Message-ID: Patches item #674396, was opened at 2003-01-24 20:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=674396&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Raymond Hettinger (rhettinger) Summary: Expand dbshelve to have full shelve/dict interface Initial Comment: Use the new DictMixin to grant all mapping methods to dbshelve. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-02-04 09:04 Message: Logged In: YES user_id=11375 Both patches look fine to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=674396&group_id=5470 From noreply@sourceforge.net Tue Feb 4 17:02:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 09:02:30 -0800 Subject: [Patches] [ python-Patches-670715 ] Universal Unicode Codec for POSIX iconv Message-ID: Patches item #670715, was opened at 2003-01-19 18:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Martin v. Löwis (loewis) Summary: Universal Unicode Codec for POSIX iconv Initial Comment: Here's the unicode codec using POSIX iconv(3) library. Tested on these platforms and seems to work: FreeBSD/i386, FreeBSD/alpha, FreeBSD/ia64, FreeBSD/sparc64, MacOS X/ppc, HP-UX/pa-risc2 This codec implementation supports PEP293, also. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 19:02 Message: Logged In: YES user_id=539787 I am afraid that SGI Irix' iconv must be added to the list of scary commercial implementations... at first the module did not compile due to two missing typecasts (see patch 680146), but even after that, the module fails (and python dumps core): Fatal Python error: can't initialize the _iconv_codec module: iconv_open() failed Abort (core dumped) (message at line 674 of the module) This is because Irix iconv knows nothing about ASCII encoding... I changed the "ASCII" argument to something existing, "ISO8859_7" which is my country's encoding, and then python dumps core with: Fatal Python error: can't initialize the _iconv_codec module: mixed endianess Abort (core dumped) MIPS processors are big endian. python works fine in all my programs where there is no use of str.decode and unicode.encode . To make sure that the problem exists only in this module, I need to compile without the _iconv_codec . Do I do that by changing setup.py? This seems the way, but I haven't succeeded yet. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-30 22:04 Message: Logged In: YES user_id=89016 I checked in a version of iconvcodec-3.txt that does a byte swapping check in the init function as Modules/_iconv_codec.c 1.5 ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-30 20:26 Message: Logged In: YES user_id=89016 iconvcodec-3.txt does byteswapping under the following conditions: #ifndef WORDS_BIGENDIAN #ifdef __GNU_LIBRARY__ Byteswapping is done before encoding to the whole input and to every piece returned from iconv() for decoding. Detecting whether byteswapping is neccessary might not work reliably with the above tests. If this is the case, a test call to iconv() should probably be done in Modules/_conv_codec.c::init_iconv_codec() to determine whether to byte swap or not. Another possibility might be to use utf-16/utf-32 instead of ucs-2/ucs-4. One test still fails: test_sane(), because it uses the internal encoding in Python, where the real endianness is of course unknown. The test also assumes a narrow Python build. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2003-01-26 17:19 Message: Logged In: YES user_id=55188 Thank you very much for your works. I'm working on UCS endian detection and UCS transparent wrapper for UTF-{8,16}. I'll submit new patch in a week. Please feel free to change my codes because I'm not familiar with python code convention and culture. :-) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-26 13:32 Message: Logged In: YES user_id=21627 I have committed it now with minimal changes so that it works on Linux, as setup.py 1.138 __init__.py 1.15 iconv_codec.py 1.1 regrtest.py 1.117 NEWS 1.627 I will make further changes; please watch the CVS. If you would like to make further changes, please submit patches against the CVS. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-22 03:07 Message: Logged In: YES user_id=21627 Hmm. I see that Solaris does support conversion of CJK to UTF-8. So even though we cannot convert into the internal encoding, we could still convert through UTF-8. Looking at /usr/lib/nls/iconv/config.iconv of HP-UX 11.11, I see conversions from and to ucs2, for iso-8859, eucJP, sjis, eucTW, big5, roc15, kore5, hp15CN, and many IBM code pages. So I think the iconv codec should convert into the Python internal representation if possible. If no encoding name for that is known, it should convert to ucs2 (be) if possible, or else to UTF-8; in all cases, it will then construct a Unicode object from the resulting string. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2003-01-22 02:21 Message: Logged In: YES user_id=55188 iconv implementations on commercial UNIXes are very scary. Solaris implementation: no support for CJK <-> UCS conversion. They support UCS[24] only for iso-8859 and UTFs. HP-UX implementation: They have useless iconv. HP-UX iconv has no unicode support. BSD implementation (Konstantin Chuguev's): compatible with this patch (provides ucs-[24]-internal) GLIBC implementation: provides ucs-[24] and they are same with GNU iconv's ucs-[24]-internal. Because ucs-[24] of GNU/BSD implentation is big endian always. We can't use ucs-[24] for every platform. In conclusion, we must use 3rd party iconv on Solaris or HP-UX. And, we need to detect whether the linked iconv is GNU/BSD iconv or GLIBC iconv. (how?) I'll investigate how to detect them, but ... :) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-22 00:27 Message: Logged In: YES user_id=21627 I'm quite happy with this patch, and will apply it shortly. However, I am concerned that it is specific for GNU iconv. IMO, there should be machinery to find out the "internal" encoding, in case native the native iconv implementation is used instead of GNU iconv. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2003-01-20 15:33 Message: Logged In: YES user_id=55188 Thank you for comments. :-> I uploaded a new revised patch with unittest and some code style fixes. I saw Martin v. Loewis's iconvcodecs about a years ago. His implementation is very neat, but it had a limit on error handling due to recursive call. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-20 00:56 Message: Logged In: YES user_id=38388 The patch looks good, but you'll need to add some form of testing to underline the "seems to work" :-) Some docs on how to use the codec would also be needed. Martin von Loewis has written a similar codec some months ago. Perhaps you two could get in touch and sort out the details ?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470 From noreply@sourceforge.net Tue Feb 4 17:51:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 09:51:16 -0800 Subject: [Patches] [ python-Patches-680146 ] _iconv_module type casting and spelling errors Message-ID: Patches item #680146, was opened at 2003-02-04 14:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: _iconv_module type casting and spelling errors Initial Comment: Compiling under SGI Irix and MIPSPro, I corrected two type casts which under gcc are plain warnings. They are both related to size_t and int comparisons, since size_t is unsigned. I also corrected the spelling mistake of "choosen" instead of "chosen" ---------------------------------------------------------------------- >Comment By: Christos Georgiou (tzot) Date: 2003-02-04 19:51 Message: Logged In: YES user_id=539787 Yes, it makes sense (and no compilation errors or warnings). Now, if only I could manage to ignore completely iconv, because Irix iconv has no ASCII encoding and there are problems with the big-endianess (see my notes to patch 670715). I need to delve into the problem with big-endian architecture, but first I would like to compile ignoring completely the _iconv_codec module; I do not know how to do that, though. (I'm messing with setup.py now). We can close this patch here, thank you. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 19:32 Message: Logged In: YES user_id=539787 The code is: res = iconv(hdl, &inptr, &insize, &outptr, (size_t *)&outsize); if (res == (size_t)-1) MIPSPro compiler 7.3 unfortunately throws an error instead of a warning, even if res is int, because iconv returns size_t, which is unsigned. This is erroneous on MIPSPro's behalf, but it's harmless. I'm gonna check your patch in a quarter. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 19:26 Message: Logged In: YES user_id=33168 I'm not sure why you've case res == (size_t)-1. All other changes make sense. I've modified the patch a bit so that insize and outsize are size_t instead of int. Does this make sense and work for you? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 14:28 Message: Logged In: YES user_id=539787 Third attempt: the checkbox is checked ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 14:12 Message: Logged In: YES user_id=539787 For some reason the attachment was not uploaded the first time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 From noreply@sourceforge.net Tue Feb 4 17:54:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 09:54:44 -0800 Subject: [Patches] [ python-Patches-680146 ] _iconv_module type casting and spelling errors Message-ID: Patches item #680146, was opened at 2003-02-04 13:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 Category: Modules Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Christos Georgiou (tzot) >Assigned to: Walter Dörwald (doerwalter) Summary: _iconv_module type casting and spelling errors Initial Comment: Compiling under SGI Irix and MIPSPro, I corrected two type casts which under gcc are plain warnings. They are both related to size_t and int comparisons, since size_t is unsigned. I also corrected the spelling mistake of "choosen" instead of "chosen" ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 18:54 Message: Logged In: YES user_id=89016 OK, I checked in a slightly different version. Can you check whether the warnings are still gone? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 18:51 Message: Logged In: YES user_id=539787 Yes, it makes sense (and no compilation errors or warnings). Now, if only I could manage to ignore completely iconv, because Irix iconv has no ASCII encoding and there are problems with the big-endianess (see my notes to patch 670715). I need to delve into the problem with big-endian architecture, but first I would like to compile ignoring completely the _iconv_codec module; I do not know how to do that, though. (I'm messing with setup.py now). We can close this patch here, thank you. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 18:32 Message: Logged In: YES user_id=539787 The code is: res = iconv(hdl, &inptr, &insize, &outptr, (size_t *)&outsize); if (res == (size_t)-1) MIPSPro compiler 7.3 unfortunately throws an error instead of a warning, even if res is int, because iconv returns size_t, which is unsigned. This is erroneous on MIPSPro's behalf, but it's harmless. I'm gonna check your patch in a quarter. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 18:26 Message: Logged In: YES user_id=33168 I'm not sure why you've case res == (size_t)-1. All other changes make sense. I've modified the patch a bit so that insize and outsize are size_t instead of int. Does this make sense and work for you? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 13:28 Message: Logged In: YES user_id=539787 Third attempt: the checkbox is checked ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 13:12 Message: Logged In: YES user_id=539787 For some reason the attachment was not uploaded the first time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 From noreply@sourceforge.net Tue Feb 4 17:58:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 09:58:23 -0800 Subject: [Patches] [ python-Patches-680146 ] _iconv_module type casting and spelling errors Message-ID: Patches item #680146, was opened at 2003-02-04 07:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Walter Dörwald (doerwalter) Summary: _iconv_module type casting and spelling errors Initial Comment: Compiling under SGI Irix and MIPSPro, I corrected two type casts which under gcc are plain warnings. They are both related to size_t and int comparisons, since size_t is unsigned. I also corrected the spelling mistake of "choosen" instead of "chosen" ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 12:58 Message: Logged In: YES user_id=33168 Attaching a patch with more changes. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 12:54 Message: Logged In: YES user_id=89016 OK, I checked in a slightly different version. Can you check whether the warnings are still gone? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 12:51 Message: Logged In: YES user_id=539787 Yes, it makes sense (and no compilation errors or warnings). Now, if only I could manage to ignore completely iconv, because Irix iconv has no ASCII encoding and there are problems with the big-endianess (see my notes to patch 670715). I need to delve into the problem with big-endian architecture, but first I would like to compile ignoring completely the _iconv_codec module; I do not know how to do that, though. (I'm messing with setup.py now). We can close this patch here, thank you. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 12:32 Message: Logged In: YES user_id=539787 The code is: res = iconv(hdl, &inptr, &insize, &outptr, (size_t *)&outsize); if (res == (size_t)-1) MIPSPro compiler 7.3 unfortunately throws an error instead of a warning, even if res is int, because iconv returns size_t, which is unsigned. This is erroneous on MIPSPro's behalf, but it's harmless. I'm gonna check your patch in a quarter. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 12:26 Message: Logged In: YES user_id=33168 I'm not sure why you've case res == (size_t)-1. All other changes make sense. I've modified the patch a bit so that insize and outsize are size_t instead of int. Does this make sense and work for you? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 07:28 Message: Logged In: YES user_id=539787 Third attempt: the checkbox is checked ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 07:12 Message: Logged In: YES user_id=539787 For some reason the attachment was not uploaded the first time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 From noreply@sourceforge.net Tue Feb 4 17:58:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 09:58:38 -0800 Subject: [Patches] [ python-Patches-680146 ] _iconv_module type casting and spelling errors Message-ID: Patches item #680146, was opened at 2003-02-04 13:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Walter Dörwald (doerwalter) Summary: _iconv_module type casting and spelling errors Initial Comment: Compiling under SGI Irix and MIPSPro, I corrected two type casts which under gcc are plain warnings. They are both related to size_t and int comparisons, since size_t is unsigned. I also corrected the spelling mistake of "choosen" instead of "chosen" ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 18:58 Message: Logged In: YES user_id=89016 Argl, Neal was faster! ;) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 18:58 Message: Logged In: YES user_id=33168 Attaching a patch with more changes. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 18:54 Message: Logged In: YES user_id=89016 OK, I checked in a slightly different version. Can you check whether the warnings are still gone? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 18:51 Message: Logged In: YES user_id=539787 Yes, it makes sense (and no compilation errors or warnings). Now, if only I could manage to ignore completely iconv, because Irix iconv has no ASCII encoding and there are problems with the big-endianess (see my notes to patch 670715). I need to delve into the problem with big-endian architecture, but first I would like to compile ignoring completely the _iconv_codec module; I do not know how to do that, though. (I'm messing with setup.py now). We can close this patch here, thank you. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 18:32 Message: Logged In: YES user_id=539787 The code is: res = iconv(hdl, &inptr, &insize, &outptr, (size_t *)&outsize); if (res == (size_t)-1) MIPSPro compiler 7.3 unfortunately throws an error instead of a warning, even if res is int, because iconv returns size_t, which is unsigned. This is erroneous on MIPSPro's behalf, but it's harmless. I'm gonna check your patch in a quarter. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 18:26 Message: Logged In: YES user_id=33168 I'm not sure why you've case res == (size_t)-1. All other changes make sense. I've modified the patch a bit so that insize and outsize are size_t instead of int. Does this make sense and work for you? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 13:28 Message: Logged In: YES user_id=539787 Third attempt: the checkbox is checked ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 13:12 Message: Logged In: YES user_id=539787 For some reason the attachment was not uploaded the first time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 From noreply@sourceforge.net Tue Feb 4 18:16:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 10:16:36 -0800 Subject: [Patches] [ python-Patches-680146 ] _iconv_module type casting and spelling errors Message-ID: Patches item #680146, was opened at 2003-02-04 14:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 Category: Modules Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Walter Dörwald (doerwalter) Summary: _iconv_module type casting and spelling errors Initial Comment: Compiling under SGI Irix and MIPSPro, I corrected two type casts which under gcc are plain warnings. They are both related to size_t and int comparisons, since size_t is unsigned. I also corrected the spelling mistake of "choosen" instead of "chosen" ---------------------------------------------------------------------- >Comment By: Christos Georgiou (tzot) Date: 2003-02-04 20:16 Message: Logged In: YES user_id=539787 ! char res = iconv(self->dechdl, (char**)&inp, &inplen, &out, &outlen); a size_t stored in a char? Ouch!!! That was indeed awful (but obviously not for gcc, which does not store values to char variables masked with 0xff). Core dumps disappeared too, but I will start from scratch (tar xvzf ...) and reapply the patch, because I don't trust the changes I did to setup.py. I'll let you know soon, thanks Neil & Walter for your promptness. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 20:08 Message: Logged In: YES user_id=89016 OK, I've checked in Neals patch as Modules/_iconv_codec.c 1.8 ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 19:58 Message: Logged In: YES user_id=89016 Argl, Neal was faster! ;) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 19:58 Message: Logged In: YES user_id=33168 Attaching a patch with more changes. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 19:54 Message: Logged In: YES user_id=89016 OK, I checked in a slightly different version. Can you check whether the warnings are still gone? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 19:51 Message: Logged In: YES user_id=539787 Yes, it makes sense (and no compilation errors or warnings). Now, if only I could manage to ignore completely iconv, because Irix iconv has no ASCII encoding and there are problems with the big-endianess (see my notes to patch 670715). I need to delve into the problem with big-endian architecture, but first I would like to compile ignoring completely the _iconv_codec module; I do not know how to do that, though. (I'm messing with setup.py now). We can close this patch here, thank you. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 19:32 Message: Logged In: YES user_id=539787 The code is: res = iconv(hdl, &inptr, &insize, &outptr, (size_t *)&outsize); if (res == (size_t)-1) MIPSPro compiler 7.3 unfortunately throws an error instead of a warning, even if res is int, because iconv returns size_t, which is unsigned. This is erroneous on MIPSPro's behalf, but it's harmless. I'm gonna check your patch in a quarter. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 19:26 Message: Logged In: YES user_id=33168 I'm not sure why you've case res == (size_t)-1. All other changes make sense. I've modified the patch a bit so that insize and outsize are size_t instead of int. Does this make sense and work for you? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 14:28 Message: Logged In: YES user_id=539787 Third attempt: the checkbox is checked ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 14:12 Message: Logged In: YES user_id=539787 For some reason the attachment was not uploaded the first time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 From noreply@sourceforge.net Tue Feb 4 17:32:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 09:32:43 -0800 Subject: [Patches] [ python-Patches-680146 ] _iconv_module type casting and spelling errors Message-ID: Patches item #680146, was opened at 2003-02-04 14:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: _iconv_module type casting and spelling errors Initial Comment: Compiling under SGI Irix and MIPSPro, I corrected two type casts which under gcc are plain warnings. They are both related to size_t and int comparisons, since size_t is unsigned. I also corrected the spelling mistake of "choosen" instead of "chosen" ---------------------------------------------------------------------- >Comment By: Christos Georgiou (tzot) Date: 2003-02-04 19:32 Message: Logged In: YES user_id=539787 The code is: res = iconv(hdl, &inptr, &insize, &outptr, (size_t *)&outsize); if (res == (size_t)-1) MIPSPro compiler 7.3 unfortunately throws an error instead of a warning, even if res is int, because iconv returns size_t, which is unsigned. This is erroneous on MIPSPro's behalf, but it's harmless. I'm gonna check your patch in a quarter. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 19:26 Message: Logged In: YES user_id=33168 I'm not sure why you've case res == (size_t)-1. All other changes make sense. I've modified the patch a bit so that insize and outsize are size_t instead of int. Does this make sense and work for you? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 14:28 Message: Logged In: YES user_id=539787 Third attempt: the checkbox is checked ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 14:12 Message: Logged In: YES user_id=539787 For some reason the attachment was not uploaded the first time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 From noreply@sourceforge.net Tue Feb 4 17:26:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 09:26:35 -0800 Subject: [Patches] [ python-Patches-680146 ] _iconv_module type casting and spelling errors Message-ID: Patches item #680146, was opened at 2003-02-04 07:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: _iconv_module type casting and spelling errors Initial Comment: Compiling under SGI Irix and MIPSPro, I corrected two type casts which under gcc are plain warnings. They are both related to size_t and int comparisons, since size_t is unsigned. I also corrected the spelling mistake of "choosen" instead of "chosen" ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 12:26 Message: Logged In: YES user_id=33168 I'm not sure why you've case res == (size_t)-1. All other changes make sense. I've modified the patch a bit so that insize and outsize are size_t instead of int. Does this make sense and work for you? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 07:28 Message: Logged In: YES user_id=539787 Third attempt: the checkbox is checked ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 07:12 Message: Logged In: YES user_id=539787 For some reason the attachment was not uploaded the first time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 From noreply@sourceforge.net Tue Feb 4 18:08:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 10:08:47 -0800 Subject: [Patches] [ python-Patches-680146 ] _iconv_module type casting and spelling errors Message-ID: Patches item #680146, was opened at 2003-02-04 13:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 Category: Modules Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Walter Dörwald (doerwalter) Summary: _iconv_module type casting and spelling errors Initial Comment: Compiling under SGI Irix and MIPSPro, I corrected two type casts which under gcc are plain warnings. They are both related to size_t and int comparisons, since size_t is unsigned. I also corrected the spelling mistake of "choosen" instead of "chosen" ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 19:08 Message: Logged In: YES user_id=89016 OK, I've checked in Neals patch as Modules/_iconv_codec.c 1.8 ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 18:58 Message: Logged In: YES user_id=89016 Argl, Neal was faster! ;) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 18:58 Message: Logged In: YES user_id=33168 Attaching a patch with more changes. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 18:54 Message: Logged In: YES user_id=89016 OK, I checked in a slightly different version. Can you check whether the warnings are still gone? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 18:51 Message: Logged In: YES user_id=539787 Yes, it makes sense (and no compilation errors or warnings). Now, if only I could manage to ignore completely iconv, because Irix iconv has no ASCII encoding and there are problems with the big-endianess (see my notes to patch 670715). I need to delve into the problem with big-endian architecture, but first I would like to compile ignoring completely the _iconv_codec module; I do not know how to do that, though. (I'm messing with setup.py now). We can close this patch here, thank you. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 18:32 Message: Logged In: YES user_id=539787 The code is: res = iconv(hdl, &inptr, &insize, &outptr, (size_t *)&outsize); if (res == (size_t)-1) MIPSPro compiler 7.3 unfortunately throws an error instead of a warning, even if res is int, because iconv returns size_t, which is unsigned. This is erroneous on MIPSPro's behalf, but it's harmless. I'm gonna check your patch in a quarter. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 18:26 Message: Logged In: YES user_id=33168 I'm not sure why you've case res == (size_t)-1. All other changes make sense. I've modified the patch a bit so that insize and outsize are size_t instead of int. Does this make sense and work for you? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 13:28 Message: Logged In: YES user_id=539787 Third attempt: the checkbox is checked ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 13:12 Message: Logged In: YES user_id=539787 For some reason the attachment was not uploaded the first time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 From noreply@sourceforge.net Tue Feb 4 18:52:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 10:52:26 -0800 Subject: [Patches] [ python-Patches-680146 ] _iconv_module type casting and spelling errors Message-ID: Patches item #680146, was opened at 2003-02-04 14:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 Category: Modules Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Walter Dörwald (doerwalter) Summary: _iconv_module type casting and spelling errors Initial Comment: Compiling under SGI Irix and MIPSPro, I corrected two type casts which under gcc are plain warnings. They are both related to size_t and int comparisons, since size_t is unsigned. I also corrected the spelling mistake of "choosen" instead of "chosen" ---------------------------------------------------------------------- >Comment By: Christos Georgiou (tzot) Date: 2003-02-04 20:52 Message: Logged In: YES user_id=539787 With patch applied: Python 2.3a1 (#12, Feb 4 2003, 21:30:08) [C] on irix646 Type "help", "copyright", "credits" or "license" for more information. >>> "aaa".decode("ascii") Fatal Python error: can't initialize the _iconv_codec module: iconv_open() failed Abort (core dumped) It still fails after a clean untar + patch. How can I disable it so that on Irix I get the old functionality? Is there an official way? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 20:16 Message: Logged In: YES user_id=539787 ! char res = iconv(self->dechdl, (char**)&inp, &inplen, &out, &outlen); a size_t stored in a char? Ouch!!! That was indeed awful (but obviously not for gcc, which does not store values to char variables masked with 0xff). Core dumps disappeared too, but I will start from scratch (tar xvzf ...) and reapply the patch, because I don't trust the changes I did to setup.py. I'll let you know soon, thanks Neil & Walter for your promptness. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 20:08 Message: Logged In: YES user_id=89016 OK, I've checked in Neals patch as Modules/_iconv_codec.c 1.8 ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 19:58 Message: Logged In: YES user_id=89016 Argl, Neal was faster! ;) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 19:58 Message: Logged In: YES user_id=33168 Attaching a patch with more changes. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 19:54 Message: Logged In: YES user_id=89016 OK, I checked in a slightly different version. Can you check whether the warnings are still gone? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 19:51 Message: Logged In: YES user_id=539787 Yes, it makes sense (and no compilation errors or warnings). Now, if only I could manage to ignore completely iconv, because Irix iconv has no ASCII encoding and there are problems with the big-endianess (see my notes to patch 670715). I need to delve into the problem with big-endian architecture, but first I would like to compile ignoring completely the _iconv_codec module; I do not know how to do that, though. (I'm messing with setup.py now). We can close this patch here, thank you. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 19:32 Message: Logged In: YES user_id=539787 The code is: res = iconv(hdl, &inptr, &insize, &outptr, (size_t *)&outsize); if (res == (size_t)-1) MIPSPro compiler 7.3 unfortunately throws an error instead of a warning, even if res is int, because iconv returns size_t, which is unsigned. This is erroneous on MIPSPro's behalf, but it's harmless. I'm gonna check your patch in a quarter. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 19:26 Message: Logged In: YES user_id=33168 I'm not sure why you've case res == (size_t)-1. All other changes make sense. I've modified the patch a bit so that insize and outsize are size_t instead of int. Does this make sense and work for you? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 14:28 Message: Logged In: YES user_id=539787 Third attempt: the checkbox is checked ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 14:12 Message: Logged In: YES user_id=539787 For some reason the attachment was not uploaded the first time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 From noreply@sourceforge.net Tue Feb 4 18:57:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 10:57:50 -0800 Subject: [Patches] [ python-Patches-670715 ] Universal Unicode Codec for POSIX iconv Message-ID: Patches item #670715, was opened at 2003-01-19 17:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Martin v. Löwis (loewis) Summary: Universal Unicode Codec for POSIX iconv Initial Comment: Here's the unicode codec using POSIX iconv(3) library. Tested on these platforms and seems to work: FreeBSD/i386, FreeBSD/alpha, FreeBSD/ia64, FreeBSD/sparc64, MacOS X/ppc, HP-UX/pa-risc2 This codec implementation supports PEP293, also. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 19:57 Message: Logged In: YES user_id=89016 "ISO8859_7" is not known on Linux, can you try "ISO8859-7" or better "ISO8859-1" or "LATIN1"? Also I wonder whether it is a good thing to test iconv() with the character '\x01'. Can you try diff-char.txt and see what happens? If all this fails, try diff-debug.txt and report what the output is. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 18:02 Message: Logged In: YES user_id=539787 I am afraid that SGI Irix' iconv must be added to the list of scary commercial implementations... at first the module did not compile due to two missing typecasts (see patch 680146), but even after that, the module fails (and python dumps core): Fatal Python error: can't initialize the _iconv_codec module: iconv_open() failed Abort (core dumped) (message at line 674 of the module) This is because Irix iconv knows nothing about ASCII encoding... I changed the "ASCII" argument to something existing, "ISO8859_7" which is my country's encoding, and then python dumps core with: Fatal Python error: can't initialize the _iconv_codec module: mixed endianess Abort (core dumped) MIPS processors are big endian. python works fine in all my programs where there is no use of str.decode and unicode.encode . To make sure that the problem exists only in this module, I need to compile without the _iconv_codec . Do I do that by changing setup.py? This seems the way, but I haven't succeeded yet. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-30 21:04 Message: Logged In: YES user_id=89016 I checked in a version of iconvcodec-3.txt that does a byte swapping check in the init function as Modules/_iconv_codec.c 1.5 ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-30 19:26 Message: Logged In: YES user_id=89016 iconvcodec-3.txt does byteswapping under the following conditions: #ifndef WORDS_BIGENDIAN #ifdef __GNU_LIBRARY__ Byteswapping is done before encoding to the whole input and to every piece returned from iconv() for decoding. Detecting whether byteswapping is neccessary might not work reliably with the above tests. If this is the case, a test call to iconv() should probably be done in Modules/_conv_codec.c::init_iconv_codec() to determine whether to byte swap or not. Another possibility might be to use utf-16/utf-32 instead of ucs-2/ucs-4. One test still fails: test_sane(), because it uses the internal encoding in Python, where the real endianness is of course unknown. The test also assumes a narrow Python build. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2003-01-26 16:19 Message: Logged In: YES user_id=55188 Thank you very much for your works. I'm working on UCS endian detection and UCS transparent wrapper for UTF-{8,16}. I'll submit new patch in a week. Please feel free to change my codes because I'm not familiar with python code convention and culture. :-) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-26 12:32 Message: Logged In: YES user_id=21627 I have committed it now with minimal changes so that it works on Linux, as setup.py 1.138 __init__.py 1.15 iconv_codec.py 1.1 regrtest.py 1.117 NEWS 1.627 I will make further changes; please watch the CVS. If you would like to make further changes, please submit patches against the CVS. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-22 02:07 Message: Logged In: YES user_id=21627 Hmm. I see that Solaris does support conversion of CJK to UTF-8. So even though we cannot convert into the internal encoding, we could still convert through UTF-8. Looking at /usr/lib/nls/iconv/config.iconv of HP-UX 11.11, I see conversions from and to ucs2, for iso-8859, eucJP, sjis, eucTW, big5, roc15, kore5, hp15CN, and many IBM code pages. So I think the iconv codec should convert into the Python internal representation if possible. If no encoding name for that is known, it should convert to ucs2 (be) if possible, or else to UTF-8; in all cases, it will then construct a Unicode object from the resulting string. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2003-01-22 01:21 Message: Logged In: YES user_id=55188 iconv implementations on commercial UNIXes are very scary. Solaris implementation: no support for CJK <-> UCS conversion. They support UCS[24] only for iso-8859 and UTFs. HP-UX implementation: They have useless iconv. HP-UX iconv has no unicode support. BSD implementation (Konstantin Chuguev's): compatible with this patch (provides ucs-[24]-internal) GLIBC implementation: provides ucs-[24] and they are same with GNU iconv's ucs-[24]-internal. Because ucs-[24] of GNU/BSD implentation is big endian always. We can't use ucs-[24] for every platform. In conclusion, we must use 3rd party iconv on Solaris or HP-UX. And, we need to detect whether the linked iconv is GNU/BSD iconv or GLIBC iconv. (how?) I'll investigate how to detect them, but ... :) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-21 23:27 Message: Logged In: YES user_id=21627 I'm quite happy with this patch, and will apply it shortly. However, I am concerned that it is specific for GNU iconv. IMO, there should be machinery to find out the "internal" encoding, in case native the native iconv implementation is used instead of GNU iconv. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2003-01-20 14:33 Message: Logged In: YES user_id=55188 Thank you for comments. :-> I uploaded a new revised patch with unittest and some code style fixes. I saw Martin v. Loewis's iconvcodecs about a years ago. His implementation is very neat, but it had a limit on error handling due to recursive call. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-19 23:56 Message: Logged In: YES user_id=38388 The patch looks good, but you'll need to add some form of testing to underline the "seems to work" :-) Some docs on how to use the codec would also be needed. Martin von Loewis has written a similar codec some months ago. Perhaps you two could get in touch and sort out the details ?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470 From noreply@sourceforge.net Tue Feb 4 18:58:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 10:58:36 -0800 Subject: [Patches] [ python-Patches-670715 ] Universal Unicode Codec for POSIX iconv Message-ID: Patches item #670715, was opened at 2003-01-19 17:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Martin v. Löwis (loewis) Summary: Universal Unicode Codec for POSIX iconv Initial Comment: Here's the unicode codec using POSIX iconv(3) library. Tested on these platforms and seems to work: FreeBSD/i386, FreeBSD/alpha, FreeBSD/ia64, FreeBSD/sparc64, MacOS X/ppc, HP-UX/pa-risc2 This codec implementation supports PEP293, also. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 19:57 Message: Logged In: YES user_id=89016 "ISO8859_7" is not known on Linux, can you try "ISO8859-7" or better "ISO8859-1" or "LATIN1"? Also I wonder whether it is a good thing to test iconv() with the character '\x01'. Can you try diff-char.txt and see what happens? If all this fails, try diff-debug.txt and report what the output is. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 18:02 Message: Logged In: YES user_id=539787 I am afraid that SGI Irix' iconv must be added to the list of scary commercial implementations... at first the module did not compile due to two missing typecasts (see patch 680146), but even after that, the module fails (and python dumps core): Fatal Python error: can't initialize the _iconv_codec module: iconv_open() failed Abort (core dumped) (message at line 674 of the module) This is because Irix iconv knows nothing about ASCII encoding... I changed the "ASCII" argument to something existing, "ISO8859_7" which is my country's encoding, and then python dumps core with: Fatal Python error: can't initialize the _iconv_codec module: mixed endianess Abort (core dumped) MIPS processors are big endian. python works fine in all my programs where there is no use of str.decode and unicode.encode . To make sure that the problem exists only in this module, I need to compile without the _iconv_codec . Do I do that by changing setup.py? This seems the way, but I haven't succeeded yet. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-30 21:04 Message: Logged In: YES user_id=89016 I checked in a version of iconvcodec-3.txt that does a byte swapping check in the init function as Modules/_iconv_codec.c 1.5 ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-30 19:26 Message: Logged In: YES user_id=89016 iconvcodec-3.txt does byteswapping under the following conditions: #ifndef WORDS_BIGENDIAN #ifdef __GNU_LIBRARY__ Byteswapping is done before encoding to the whole input and to every piece returned from iconv() for decoding. Detecting whether byteswapping is neccessary might not work reliably with the above tests. If this is the case, a test call to iconv() should probably be done in Modules/_conv_codec.c::init_iconv_codec() to determine whether to byte swap or not. Another possibility might be to use utf-16/utf-32 instead of ucs-2/ucs-4. One test still fails: test_sane(), because it uses the internal encoding in Python, where the real endianness is of course unknown. The test also assumes a narrow Python build. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2003-01-26 16:19 Message: Logged In: YES user_id=55188 Thank you very much for your works. I'm working on UCS endian detection and UCS transparent wrapper for UTF-{8,16}. I'll submit new patch in a week. Please feel free to change my codes because I'm not familiar with python code convention and culture. :-) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-26 12:32 Message: Logged In: YES user_id=21627 I have committed it now with minimal changes so that it works on Linux, as setup.py 1.138 __init__.py 1.15 iconv_codec.py 1.1 regrtest.py 1.117 NEWS 1.627 I will make further changes; please watch the CVS. If you would like to make further changes, please submit patches against the CVS. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-22 02:07 Message: Logged In: YES user_id=21627 Hmm. I see that Solaris does support conversion of CJK to UTF-8. So even though we cannot convert into the internal encoding, we could still convert through UTF-8. Looking at /usr/lib/nls/iconv/config.iconv of HP-UX 11.11, I see conversions from and to ucs2, for iso-8859, eucJP, sjis, eucTW, big5, roc15, kore5, hp15CN, and many IBM code pages. So I think the iconv codec should convert into the Python internal representation if possible. If no encoding name for that is known, it should convert to ucs2 (be) if possible, or else to UTF-8; in all cases, it will then construct a Unicode object from the resulting string. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2003-01-22 01:21 Message: Logged In: YES user_id=55188 iconv implementations on commercial UNIXes are very scary. Solaris implementation: no support for CJK <-> UCS conversion. They support UCS[24] only for iso-8859 and UTFs. HP-UX implementation: They have useless iconv. HP-UX iconv has no unicode support. BSD implementation (Konstantin Chuguev's): compatible with this patch (provides ucs-[24]-internal) GLIBC implementation: provides ucs-[24] and they are same with GNU iconv's ucs-[24]-internal. Because ucs-[24] of GNU/BSD implentation is big endian always. We can't use ucs-[24] for every platform. In conclusion, we must use 3rd party iconv on Solaris or HP-UX. And, we need to detect whether the linked iconv is GNU/BSD iconv or GLIBC iconv. (how?) I'll investigate how to detect them, but ... :) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-21 23:27 Message: Logged In: YES user_id=21627 I'm quite happy with this patch, and will apply it shortly. However, I am concerned that it is specific for GNU iconv. IMO, there should be machinery to find out the "internal" encoding, in case native the native iconv implementation is used instead of GNU iconv. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2003-01-20 14:33 Message: Logged In: YES user_id=55188 Thank you for comments. :-> I uploaded a new revised patch with unittest and some code style fixes. I saw Martin v. Loewis's iconvcodecs about a years ago. His implementation is very neat, but it had a limit on error handling due to recursive call. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-19 23:56 Message: Logged In: YES user_id=38388 The patch looks good, but you'll need to add some form of testing to underline the "seems to work" :-) Some docs on how to use the codec would also be needed. Martin von Loewis has written a similar codec some months ago. Perhaps you two could get in touch and sort out the details ?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470 From noreply@sourceforge.net Tue Feb 4 19:00:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 11:00:20 -0800 Subject: [Patches] [ python-Patches-680146 ] _iconv_module type casting and spelling errors Message-ID: Patches item #680146, was opened at 2003-02-04 13:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 Category: Modules Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Walter Dörwald (doerwalter) Summary: _iconv_module type casting and spelling errors Initial Comment: Compiling under SGI Irix and MIPSPro, I corrected two type casts which under gcc are plain warnings. They are both related to size_t and int comparisons, since size_t is unsigned. I also corrected the spelling mistake of "choosen" instead of "chosen" ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 20:00 Message: Logged In: YES user_id=89016 The current code of course still uses 'ASCII'. However, if the compiler warnings are gone we should continue discussion on patch #670715. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 19:52 Message: Logged In: YES user_id=539787 With patch applied: Python 2.3a1 (#12, Feb 4 2003, 21:30:08) [C] on irix646 Type "help", "copyright", "credits" or "license" for more information. >>> "aaa".decode("ascii") Fatal Python error: can't initialize the _iconv_codec module: iconv_open() failed Abort (core dumped) It still fails after a clean untar + patch. How can I disable it so that on Irix I get the old functionality? Is there an official way? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 19:16 Message: Logged In: YES user_id=539787 ! char res = iconv(self->dechdl, (char**)&inp, &inplen, &out, &outlen); a size_t stored in a char? Ouch!!! That was indeed awful (but obviously not for gcc, which does not store values to char variables masked with 0xff). Core dumps disappeared too, but I will start from scratch (tar xvzf ...) and reapply the patch, because I don't trust the changes I did to setup.py. I'll let you know soon, thanks Neil & Walter for your promptness. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 19:08 Message: Logged In: YES user_id=89016 OK, I've checked in Neals patch as Modules/_iconv_codec.c 1.8 ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 18:58 Message: Logged In: YES user_id=89016 Argl, Neal was faster! ;) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 18:58 Message: Logged In: YES user_id=33168 Attaching a patch with more changes. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 18:54 Message: Logged In: YES user_id=89016 OK, I checked in a slightly different version. Can you check whether the warnings are still gone? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 18:51 Message: Logged In: YES user_id=539787 Yes, it makes sense (and no compilation errors or warnings). Now, if only I could manage to ignore completely iconv, because Irix iconv has no ASCII encoding and there are problems with the big-endianess (see my notes to patch 670715). I need to delve into the problem with big-endian architecture, but first I would like to compile ignoring completely the _iconv_codec module; I do not know how to do that, though. (I'm messing with setup.py now). We can close this patch here, thank you. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 18:32 Message: Logged In: YES user_id=539787 The code is: res = iconv(hdl, &inptr, &insize, &outptr, (size_t *)&outsize); if (res == (size_t)-1) MIPSPro compiler 7.3 unfortunately throws an error instead of a warning, even if res is int, because iconv returns size_t, which is unsigned. This is erroneous on MIPSPro's behalf, but it's harmless. I'm gonna check your patch in a quarter. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 18:26 Message: Logged In: YES user_id=33168 I'm not sure why you've case res == (size_t)-1. All other changes make sense. I've modified the patch a bit so that insize and outsize are size_t instead of int. Does this make sense and work for you? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 13:28 Message: Logged In: YES user_id=539787 Third attempt: the checkbox is checked ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 13:12 Message: Logged In: YES user_id=539787 For some reason the attachment was not uploaded the first time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 From noreply@sourceforge.net Tue Feb 4 19:09:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 11:09:36 -0800 Subject: [Patches] [ python-Patches-680146 ] _iconv_module type casting and spelling errors Message-ID: Patches item #680146, was opened at 2003-02-04 14:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 Category: Modules Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Walter Dörwald (doerwalter) Summary: _iconv_module type casting and spelling errors Initial Comment: Compiling under SGI Irix and MIPSPro, I corrected two type casts which under gcc are plain warnings. They are both related to size_t and int comparisons, since size_t is unsigned. I also corrected the spelling mistake of "choosen" instead of "chosen" ---------------------------------------------------------------------- >Comment By: Christos Georgiou (tzot) Date: 2003-02-04 21:09 Message: Logged In: YES user_id=539787 With patch applied: Python 2.3a1 (#12, Feb 4 2003, 21:30:08) [C] on irix646 Type "help", "copyright", "credits" or "license" for more information. >>> "aaa".decode("ascii") Fatal Python error: can't initialize the _iconv_codec module: iconv_open() failed Abort (core dumped) It still fails after a clean untar + patch. How can I disable it so that on Irix I get the old functionality? Is there an official way? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 21:00 Message: Logged In: YES user_id=89016 The current code of course still uses 'ASCII'. However, if the compiler warnings are gone we should continue discussion on patch #670715. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 20:52 Message: Logged In: YES user_id=539787 With patch applied: Python 2.3a1 (#12, Feb 4 2003, 21:30:08) [C] on irix646 Type "help", "copyright", "credits" or "license" for more information. >>> "aaa".decode("ascii") Fatal Python error: can't initialize the _iconv_codec module: iconv_open() failed Abort (core dumped) It still fails after a clean untar + patch. How can I disable it so that on Irix I get the old functionality? Is there an official way? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 20:16 Message: Logged In: YES user_id=539787 ! char res = iconv(self->dechdl, (char**)&inp, &inplen, &out, &outlen); a size_t stored in a char? Ouch!!! That was indeed awful (but obviously not for gcc, which does not store values to char variables masked with 0xff). Core dumps disappeared too, but I will start from scratch (tar xvzf ...) and reapply the patch, because I don't trust the changes I did to setup.py. I'll let you know soon, thanks Neil & Walter for your promptness. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 20:08 Message: Logged In: YES user_id=89016 OK, I've checked in Neals patch as Modules/_iconv_codec.c 1.8 ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 19:58 Message: Logged In: YES user_id=89016 Argl, Neal was faster! ;) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 19:58 Message: Logged In: YES user_id=33168 Attaching a patch with more changes. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 19:54 Message: Logged In: YES user_id=89016 OK, I checked in a slightly different version. Can you check whether the warnings are still gone? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 19:51 Message: Logged In: YES user_id=539787 Yes, it makes sense (and no compilation errors or warnings). Now, if only I could manage to ignore completely iconv, because Irix iconv has no ASCII encoding and there are problems with the big-endianess (see my notes to patch 670715). I need to delve into the problem with big-endian architecture, but first I would like to compile ignoring completely the _iconv_codec module; I do not know how to do that, though. (I'm messing with setup.py now). We can close this patch here, thank you. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 19:32 Message: Logged In: YES user_id=539787 The code is: res = iconv(hdl, &inptr, &insize, &outptr, (size_t *)&outsize); if (res == (size_t)-1) MIPSPro compiler 7.3 unfortunately throws an error instead of a warning, even if res is int, because iconv returns size_t, which is unsigned. This is erroneous on MIPSPro's behalf, but it's harmless. I'm gonna check your patch in a quarter. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 19:26 Message: Logged In: YES user_id=33168 I'm not sure why you've case res == (size_t)-1. All other changes make sense. I've modified the patch a bit so that insize and outsize are size_t instead of int. Does this make sense and work for you? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 14:28 Message: Logged In: YES user_id=539787 Third attempt: the checkbox is checked ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 14:12 Message: Logged In: YES user_id=539787 For some reason the attachment was not uploaded the first time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 From noreply@sourceforge.net Tue Feb 4 19:09:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 11:09:57 -0800 Subject: [Patches] [ python-Patches-680146 ] _iconv_module type casting and spelling errors Message-ID: Patches item #680146, was opened at 2003-02-04 14:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 Category: Modules Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Walter Dörwald (doerwalter) Summary: _iconv_module type casting and spelling errors Initial Comment: Compiling under SGI Irix and MIPSPro, I corrected two type casts which under gcc are plain warnings. They are both related to size_t and int comparisons, since size_t is unsigned. I also corrected the spelling mistake of "choosen" instead of "chosen" ---------------------------------------------------------------------- >Comment By: Christos Georgiou (tzot) Date: 2003-02-04 21:09 Message: Logged In: YES user_id=539787 With patch applied: Python 2.3a1 (#12, Feb 4 2003, 21:30:08) [C] on irix646 Type "help", "copyright", "credits" or "license" for more information. >>> "aaa".decode("ascii") Fatal Python error: can't initialize the _iconv_codec module: iconv_open() failed Abort (core dumped) It still fails after a clean untar + patch. How can I disable it so that on Irix I get the old functionality? Is there an official way? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 21:09 Message: Logged In: YES user_id=539787 With patch applied: Python 2.3a1 (#12, Feb 4 2003, 21:30:08) [C] on irix646 Type "help", "copyright", "credits" or "license" for more information. >>> "aaa".decode("ascii") Fatal Python error: can't initialize the _iconv_codec module: iconv_open() failed Abort (core dumped) It still fails after a clean untar + patch. How can I disable it so that on Irix I get the old functionality? Is there an official way? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 21:00 Message: Logged In: YES user_id=89016 The current code of course still uses 'ASCII'. However, if the compiler warnings are gone we should continue discussion on patch #670715. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 20:52 Message: Logged In: YES user_id=539787 With patch applied: Python 2.3a1 (#12, Feb 4 2003, 21:30:08) [C] on irix646 Type "help", "copyright", "credits" or "license" for more information. >>> "aaa".decode("ascii") Fatal Python error: can't initialize the _iconv_codec module: iconv_open() failed Abort (core dumped) It still fails after a clean untar + patch. How can I disable it so that on Irix I get the old functionality? Is there an official way? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 20:16 Message: Logged In: YES user_id=539787 ! char res = iconv(self->dechdl, (char**)&inp, &inplen, &out, &outlen); a size_t stored in a char? Ouch!!! That was indeed awful (but obviously not for gcc, which does not store values to char variables masked with 0xff). Core dumps disappeared too, but I will start from scratch (tar xvzf ...) and reapply the patch, because I don't trust the changes I did to setup.py. I'll let you know soon, thanks Neil & Walter for your promptness. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 20:08 Message: Logged In: YES user_id=89016 OK, I've checked in Neals patch as Modules/_iconv_codec.c 1.8 ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 19:58 Message: Logged In: YES user_id=89016 Argl, Neal was faster! ;) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 19:58 Message: Logged In: YES user_id=33168 Attaching a patch with more changes. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 19:54 Message: Logged In: YES user_id=89016 OK, I checked in a slightly different version. Can you check whether the warnings are still gone? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 19:51 Message: Logged In: YES user_id=539787 Yes, it makes sense (and no compilation errors or warnings). Now, if only I could manage to ignore completely iconv, because Irix iconv has no ASCII encoding and there are problems with the big-endianess (see my notes to patch 670715). I need to delve into the problem with big-endian architecture, but first I would like to compile ignoring completely the _iconv_codec module; I do not know how to do that, though. (I'm messing with setup.py now). We can close this patch here, thank you. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 19:32 Message: Logged In: YES user_id=539787 The code is: res = iconv(hdl, &inptr, &insize, &outptr, (size_t *)&outsize); if (res == (size_t)-1) MIPSPro compiler 7.3 unfortunately throws an error instead of a warning, even if res is int, because iconv returns size_t, which is unsigned. This is erroneous on MIPSPro's behalf, but it's harmless. I'm gonna check your patch in a quarter. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 19:26 Message: Logged In: YES user_id=33168 I'm not sure why you've case res == (size_t)-1. All other changes make sense. I've modified the patch a bit so that insize and outsize are size_t instead of int. Does this make sense and work for you? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 14:28 Message: Logged In: YES user_id=539787 Third attempt: the checkbox is checked ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 14:12 Message: Logged In: YES user_id=539787 For some reason the attachment was not uploaded the first time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 From noreply@sourceforge.net Tue Feb 4 19:25:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 11:25:25 -0800 Subject: [Patches] [ python-Patches-680146 ] _iconv_module type casting and spelling errors Message-ID: Patches item #680146, was opened at 2003-02-04 13:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 Category: Modules Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Walter Dörwald (doerwalter) Summary: _iconv_module type casting and spelling errors Initial Comment: Compiling under SGI Irix and MIPSPro, I corrected two type casts which under gcc are plain warnings. They are both related to size_t and int comparisons, since size_t is unsigned. I also corrected the spelling mistake of "choosen" instead of "chosen" ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 20:25 Message: Logged In: YES user_id=89016 Of course you can always comment out the import in encodings/__init__.py ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 20:09 Message: Logged In: YES user_id=539787 With patch applied: Python 2.3a1 (#12, Feb 4 2003, 21:30:08) [C] on irix646 Type "help", "copyright", "credits" or "license" for more information. >>> "aaa".decode("ascii") Fatal Python error: can't initialize the _iconv_codec module: iconv_open() failed Abort (core dumped) It still fails after a clean untar + patch. How can I disable it so that on Irix I get the old functionality? Is there an official way? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 20:09 Message: Logged In: YES user_id=539787 With patch applied: Python 2.3a1 (#12, Feb 4 2003, 21:30:08) [C] on irix646 Type "help", "copyright", "credits" or "license" for more information. >>> "aaa".decode("ascii") Fatal Python error: can't initialize the _iconv_codec module: iconv_open() failed Abort (core dumped) It still fails after a clean untar + patch. How can I disable it so that on Irix I get the old functionality? Is there an official way? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 20:00 Message: Logged In: YES user_id=89016 The current code of course still uses 'ASCII'. However, if the compiler warnings are gone we should continue discussion on patch #670715. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 19:52 Message: Logged In: YES user_id=539787 With patch applied: Python 2.3a1 (#12, Feb 4 2003, 21:30:08) [C] on irix646 Type "help", "copyright", "credits" or "license" for more information. >>> "aaa".decode("ascii") Fatal Python error: can't initialize the _iconv_codec module: iconv_open() failed Abort (core dumped) It still fails after a clean untar + patch. How can I disable it so that on Irix I get the old functionality? Is there an official way? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 19:16 Message: Logged In: YES user_id=539787 ! char res = iconv(self->dechdl, (char**)&inp, &inplen, &out, &outlen); a size_t stored in a char? Ouch!!! That was indeed awful (but obviously not for gcc, which does not store values to char variables masked with 0xff). Core dumps disappeared too, but I will start from scratch (tar xvzf ...) and reapply the patch, because I don't trust the changes I did to setup.py. I'll let you know soon, thanks Neil & Walter for your promptness. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 19:08 Message: Logged In: YES user_id=89016 OK, I've checked in Neals patch as Modules/_iconv_codec.c 1.8 ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 18:58 Message: Logged In: YES user_id=89016 Argl, Neal was faster! ;) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 18:58 Message: Logged In: YES user_id=33168 Attaching a patch with more changes. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 18:54 Message: Logged In: YES user_id=89016 OK, I checked in a slightly different version. Can you check whether the warnings are still gone? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 18:51 Message: Logged In: YES user_id=539787 Yes, it makes sense (and no compilation errors or warnings). Now, if only I could manage to ignore completely iconv, because Irix iconv has no ASCII encoding and there are problems with the big-endianess (see my notes to patch 670715). I need to delve into the problem with big-endian architecture, but first I would like to compile ignoring completely the _iconv_codec module; I do not know how to do that, though. (I'm messing with setup.py now). We can close this patch here, thank you. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 18:32 Message: Logged In: YES user_id=539787 The code is: res = iconv(hdl, &inptr, &insize, &outptr, (size_t *)&outsize); if (res == (size_t)-1) MIPSPro compiler 7.3 unfortunately throws an error instead of a warning, even if res is int, because iconv returns size_t, which is unsigned. This is erroneous on MIPSPro's behalf, but it's harmless. I'm gonna check your patch in a quarter. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 18:26 Message: Logged In: YES user_id=33168 I'm not sure why you've case res == (size_t)-1. All other changes make sense. I've modified the patch a bit so that insize and outsize are size_t instead of int. Does this make sense and work for you? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 13:28 Message: Logged In: YES user_id=539787 Third attempt: the checkbox is checked ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 13:12 Message: Logged In: YES user_id=539787 For some reason the attachment was not uploaded the first time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 From noreply@sourceforge.net Tue Feb 4 20:10:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 12:10:33 -0800 Subject: [Patches] [ python-Patches-670715 ] Universal Unicode Codec for POSIX iconv Message-ID: Patches item #670715, was opened at 2003-01-19 18:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Martin v. Löwis (loewis) Summary: Universal Unicode Codec for POSIX iconv Initial Comment: Here's the unicode codec using POSIX iconv(3) library. Tested on these platforms and seems to work: FreeBSD/i386, FreeBSD/alpha, FreeBSD/ia64, FreeBSD/sparc64, MacOS X/ppc, HP-UX/pa-risc2 This codec implementation supports PEP293, also. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 22:10 Message: Logged In: YES user_id=539787 It was a misspelling; ISO8859-7 is what I used in the module, the underscore came from my using it with str.decode ("iso8859_7"). o2k 348# ls -l python -rwxr-xr-x 1 root sys 1976320 Feb 4 21:21 python o2k 349# ./python Python 2.3a1 (#12, Feb 4 2003, 21:14:08) [C] on irix646 Type "help", "copyright", "credits" or "license" for more information. >>> "a".decode("ascii") Fatal Python error: can't initialize the _iconv_codec module: iconv_open() failed Abort (core dumped) I then changed it to: iconv_t hdl = iconv_open("UCS-2", "LATIN1"); (sys.maxunicode is 65535) and it still fails at the same line (I ran "dbx python core"). I made sure that I use the freshly built _iconv_codec.so (ie no other exists on the system). I added some code to show the errno, and it's 22 (EINVAL). I ran iconv -l at the prompt, and used UCS-2 and ISO8859-1 (LATIN1 didn't show up in the list). Now, the code runs fine for str.decode and unicode.encode, and test.test_codecs and test.test_263 pass fine. (BTW, if you're used to vi keystrokes, never press ESC while typing with IE in the "Add a comment:" text box... :( ) I then applied the diff-debug patch, and got: >>> "a".decode("ascii") init_iconv_codec: 0x0030 u'a' Please note that on Irix, UCS-2-INTERNAL is not available, only UCS-2, so that had to be changed too. It's an initialisation thing; I could provide a special case of defines for Irix, but how can you know which codecs are available on a platform during the configure process? Perhaps running iconv -l and trying to decode the output? iconv -l on GNU/linux shows a comma separated list, while on Irix it shows pairs of available conversions, one on each line... Thanks for the direction about encodings/__init__.py, Walter. Thanks guys, now I must find if pymalloc has changed and occasionally dumps core in dictresize or listextend_internal... ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 20:57 Message: Logged In: YES user_id=89016 "ISO8859_7" is not known on Linux, can you try "ISO8859-7" or better "ISO8859-1" or "LATIN1"? Also I wonder whether it is a good thing to test iconv() with the character '\x01'. Can you try diff-char.txt and see what happens? If all this fails, try diff-debug.txt and report what the output is. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 19:02 Message: Logged In: YES user_id=539787 I am afraid that SGI Irix' iconv must be added to the list of scary commercial implementations... at first the module did not compile due to two missing typecasts (see patch 680146), but even after that, the module fails (and python dumps core): Fatal Python error: can't initialize the _iconv_codec module: iconv_open() failed Abort (core dumped) (message at line 674 of the module) This is because Irix iconv knows nothing about ASCII encoding... I changed the "ASCII" argument to something existing, "ISO8859_7" which is my country's encoding, and then python dumps core with: Fatal Python error: can't initialize the _iconv_codec module: mixed endianess Abort (core dumped) MIPS processors are big endian. python works fine in all my programs where there is no use of str.decode and unicode.encode . To make sure that the problem exists only in this module, I need to compile without the _iconv_codec . Do I do that by changing setup.py? This seems the way, but I haven't succeeded yet. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-30 22:04 Message: Logged In: YES user_id=89016 I checked in a version of iconvcodec-3.txt that does a byte swapping check in the init function as Modules/_iconv_codec.c 1.5 ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-30 20:26 Message: Logged In: YES user_id=89016 iconvcodec-3.txt does byteswapping under the following conditions: #ifndef WORDS_BIGENDIAN #ifdef __GNU_LIBRARY__ Byteswapping is done before encoding to the whole input and to every piece returned from iconv() for decoding. Detecting whether byteswapping is neccessary might not work reliably with the above tests. If this is the case, a test call to iconv() should probably be done in Modules/_conv_codec.c::init_iconv_codec() to determine whether to byte swap or not. Another possibility might be to use utf-16/utf-32 instead of ucs-2/ucs-4. One test still fails: test_sane(), because it uses the internal encoding in Python, where the real endianness is of course unknown. The test also assumes a narrow Python build. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2003-01-26 17:19 Message: Logged In: YES user_id=55188 Thank you very much for your works. I'm working on UCS endian detection and UCS transparent wrapper for UTF-{8,16}. I'll submit new patch in a week. Please feel free to change my codes because I'm not familiar with python code convention and culture. :-) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-26 13:32 Message: Logged In: YES user_id=21627 I have committed it now with minimal changes so that it works on Linux, as setup.py 1.138 __init__.py 1.15 iconv_codec.py 1.1 regrtest.py 1.117 NEWS 1.627 I will make further changes; please watch the CVS. If you would like to make further changes, please submit patches against the CVS. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-22 03:07 Message: Logged In: YES user_id=21627 Hmm. I see that Solaris does support conversion of CJK to UTF-8. So even though we cannot convert into the internal encoding, we could still convert through UTF-8. Looking at /usr/lib/nls/iconv/config.iconv of HP-UX 11.11, I see conversions from and to ucs2, for iso-8859, eucJP, sjis, eucTW, big5, roc15, kore5, hp15CN, and many IBM code pages. So I think the iconv codec should convert into the Python internal representation if possible. If no encoding name for that is known, it should convert to ucs2 (be) if possible, or else to UTF-8; in all cases, it will then construct a Unicode object from the resulting string. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2003-01-22 02:21 Message: Logged In: YES user_id=55188 iconv implementations on commercial UNIXes are very scary. Solaris implementation: no support for CJK <-> UCS conversion. They support UCS[24] only for iso-8859 and UTFs. HP-UX implementation: They have useless iconv. HP-UX iconv has no unicode support. BSD implementation (Konstantin Chuguev's): compatible with this patch (provides ucs-[24]-internal) GLIBC implementation: provides ucs-[24] and they are same with GNU iconv's ucs-[24]-internal. Because ucs-[24] of GNU/BSD implentation is big endian always. We can't use ucs-[24] for every platform. In conclusion, we must use 3rd party iconv on Solaris or HP-UX. And, we need to detect whether the linked iconv is GNU/BSD iconv or GLIBC iconv. (how?) I'll investigate how to detect them, but ... :) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-22 00:27 Message: Logged In: YES user_id=21627 I'm quite happy with this patch, and will apply it shortly. However, I am concerned that it is specific for GNU iconv. IMO, there should be machinery to find out the "internal" encoding, in case native the native iconv implementation is used instead of GNU iconv. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2003-01-20 15:33 Message: Logged In: YES user_id=55188 Thank you for comments. :-> I uploaded a new revised patch with unittest and some code style fixes. I saw Martin v. Loewis's iconvcodecs about a years ago. His implementation is very neat, but it had a limit on error handling due to recursive call. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-20 00:56 Message: Logged In: YES user_id=38388 The patch looks good, but you'll need to add some form of testing to underline the "seems to work" :-) Some docs on how to use the codec would also be needed. Martin von Loewis has written a similar codec some months ago. Perhaps you two could get in touch and sort out the details ?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470 From noreply@sourceforge.net Tue Feb 4 20:12:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 12:12:08 -0800 Subject: [Patches] [ python-Patches-680146 ] _iconv_module type casting and spelling errors Message-ID: Patches item #680146, was opened at 2003-02-04 14:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 Category: Modules Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Walter Dörwald (doerwalter) Summary: _iconv_module type casting and spelling errors Initial Comment: Compiling under SGI Irix and MIPSPro, I corrected two type casts which under gcc are plain warnings. They are both related to size_t and int comparisons, since size_t is unsigned. I also corrected the spelling mistake of "choosen" instead of "chosen" ---------------------------------------------------------------------- >Comment By: Christos Georgiou (tzot) Date: 2003-02-04 22:12 Message: Logged In: YES user_id=539787 It was a misspelling; ISO8859-7 is what I used in the module, the underscore came from my using it with str.decode ("iso8859_7"). o2k 348# ls -l python -rwxr-xr-x 1 root sys 1976320 Feb 4 21:21 python o2k 349# ./python Python 2.3a1 (#12, Feb 4 2003, 21:14:08) [C] on irix646 Type "help", "copyright", "credits" or "license" for more information. >>> "a".decode("ascii") Fatal Python error: can't initialize the _iconv_codec module: iconv_open() failed Abort (core dumped) I then changed it to: iconv_t hdl = iconv_open("UCS-2", "LATIN1"); (sys.maxunicode is 65535) and it still fails at the same line (I ran "dbx python core"). I made sure that I use the freshly built _iconv_codec.so (ie no other exists on the system). I added some code to show the errno, and it's 22 (EINVAL). I ran iconv -l at the prompt, and used UCS-2 and ISO8859-1 (LATIN1 didn't show up in the list). Now, the code runs fine for str.decode and unicode.encode, and test.test_codecs and test.test_263 pass fine. (BTW, if you're used to vi keystrokes, never press ESC while typing with IE in the "Add a comment:" text box... :( ) I then applied the diff-debug patch, and got: >>> "a".decode("ascii") init_iconv_codec: 0x0030 u'a' Please note that on Irix, UCS-2-INTERNAL is not available, only UCS-2, so that had to be changed too. It's an initialisation thing; I could provide a special case of defines for Irix, but how can you know which codecs are available on a platform during the configure process? Perhaps running iconv -l and trying to decode the output? iconv -l on GNU/linux shows a comma separated list, while on Irix it shows pairs of available conversions, one on each line... Thanks for the direction about encodings/__init__.py, Walter. Thanks guys, now I must find if pymalloc has changed and occasionally dumps core in dictresize or listextend_internal... ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 21:25 Message: Logged In: YES user_id=89016 Of course you can always comment out the import in encodings/__init__.py ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 21:09 Message: Logged In: YES user_id=539787 With patch applied: Python 2.3a1 (#12, Feb 4 2003, 21:30:08) [C] on irix646 Type "help", "copyright", "credits" or "license" for more information. >>> "aaa".decode("ascii") Fatal Python error: can't initialize the _iconv_codec module: iconv_open() failed Abort (core dumped) It still fails after a clean untar + patch. How can I disable it so that on Irix I get the old functionality? Is there an official way? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 21:09 Message: Logged In: YES user_id=539787 With patch applied: Python 2.3a1 (#12, Feb 4 2003, 21:30:08) [C] on irix646 Type "help", "copyright", "credits" or "license" for more information. >>> "aaa".decode("ascii") Fatal Python error: can't initialize the _iconv_codec module: iconv_open() failed Abort (core dumped) It still fails after a clean untar + patch. How can I disable it so that on Irix I get the old functionality? Is there an official way? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 21:00 Message: Logged In: YES user_id=89016 The current code of course still uses 'ASCII'. However, if the compiler warnings are gone we should continue discussion on patch #670715. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 20:52 Message: Logged In: YES user_id=539787 With patch applied: Python 2.3a1 (#12, Feb 4 2003, 21:30:08) [C] on irix646 Type "help", "copyright", "credits" or "license" for more information. >>> "aaa".decode("ascii") Fatal Python error: can't initialize the _iconv_codec module: iconv_open() failed Abort (core dumped) It still fails after a clean untar + patch. How can I disable it so that on Irix I get the old functionality? Is there an official way? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 20:16 Message: Logged In: YES user_id=539787 ! char res = iconv(self->dechdl, (char**)&inp, &inplen, &out, &outlen); a size_t stored in a char? Ouch!!! That was indeed awful (but obviously not for gcc, which does not store values to char variables masked with 0xff). Core dumps disappeared too, but I will start from scratch (tar xvzf ...) and reapply the patch, because I don't trust the changes I did to setup.py. I'll let you know soon, thanks Neil & Walter for your promptness. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 20:08 Message: Logged In: YES user_id=89016 OK, I've checked in Neals patch as Modules/_iconv_codec.c 1.8 ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 19:58 Message: Logged In: YES user_id=89016 Argl, Neal was faster! ;) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 19:58 Message: Logged In: YES user_id=33168 Attaching a patch with more changes. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 19:54 Message: Logged In: YES user_id=89016 OK, I checked in a slightly different version. Can you check whether the warnings are still gone? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 19:51 Message: Logged In: YES user_id=539787 Yes, it makes sense (and no compilation errors or warnings). Now, if only I could manage to ignore completely iconv, because Irix iconv has no ASCII encoding and there are problems with the big-endianess (see my notes to patch 670715). I need to delve into the problem with big-endian architecture, but first I would like to compile ignoring completely the _iconv_codec module; I do not know how to do that, though. (I'm messing with setup.py now). We can close this patch here, thank you. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 19:32 Message: Logged In: YES user_id=539787 The code is: res = iconv(hdl, &inptr, &insize, &outptr, (size_t *)&outsize); if (res == (size_t)-1) MIPSPro compiler 7.3 unfortunately throws an error instead of a warning, even if res is int, because iconv returns size_t, which is unsigned. This is erroneous on MIPSPro's behalf, but it's harmless. I'm gonna check your patch in a quarter. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 19:26 Message: Logged In: YES user_id=33168 I'm not sure why you've case res == (size_t)-1. All other changes make sense. I've modified the patch a bit so that insize and outsize are size_t instead of int. Does this make sense and work for you? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 14:28 Message: Logged In: YES user_id=539787 Third attempt: the checkbox is checked ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 14:12 Message: Logged In: YES user_id=539787 For some reason the attachment was not uploaded the first time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680146&group_id=5470 From noreply@sourceforge.net Tue Feb 4 20:31:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 12:31:48 -0800 Subject: [Patches] [ python-Patches-680452 ] xmlrpclib: builtin type names instead of types.* Message-ID: Patches item #680452, was opened at 2003-02-04 22:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680452&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib: builtin type names instead of types.* Initial Comment: All Type imported from types module, except for InstanceType, were changed to the relevant type object (ie TupleType -> tuple etc). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680452&group_id=5470 From noreply@sourceforge.net Tue Feb 4 20:34:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 12:34:05 -0800 Subject: [Patches] [ python-Patches-680452 ] xmlrpclib: builtin type names instead of types.* Message-ID: Patches item #680452, was opened at 2003-02-04 22:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680452&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib: builtin type names instead of types.* Initial Comment: All Type imported from types module, except for InstanceType, were changed to the relevant type object (ie TupleType -> tuple etc). ---------------------------------------------------------------------- >Comment By: Christos Georgiou (tzot) Date: 2003-02-04 22:34 Message: Logged In: YES user_id=539787 This time I am sure I had the checkbox checked, so I will try again. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680452&group_id=5470 From noreply@sourceforge.net Tue Feb 4 20:48:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 12:48:23 -0800 Subject: [Patches] [ python-Patches-680452 ] xmlrpclib: builtin type names instead of types.* Message-ID: Patches item #680452, was opened at 2003-02-04 15:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680452&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Christos Georgiou (tzot) >Assigned to: Neal Norwitz (nnorwitz) Summary: xmlrpclib: builtin type names instead of types.* Initial Comment: All Type imported from types module, except for InstanceType, were changed to the relevant type object (ie TupleType -> tuple etc). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 15:48 Message: Logged In: YES user_id=33168 While your patch looks correct, the xmlrpclib module is supposed to stay backwards compatible with Python 1.5.2 for now. See PEP 291. Since this patch would break 1.5.2 compatibity, I'm closing. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 15:34 Message: Logged In: YES user_id=539787 This time I am sure I had the checkbox checked, so I will try again. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680452&group_id=5470 From noreply@sourceforge.net Tue Feb 4 21:23:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 13:23:34 -0800 Subject: [Patches] [ python-Patches-680474 ] Fix for the bug #679880: 'compile' refuses BOM. Message-ID: Patches item #680474, was opened at 2003-02-04 16:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680474&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kirill Simonov (kirill_simonov) >Assigned to: M.-A. Lemburg (lemburg) Summary: Fix for the bug #679880: 'compile' refuses BOM. Initial Comment: This is a signed char issue. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 16:23 Message: Logged In: YES user_id=33168 The patch is small (2 lines) and seems ok. MAL, if you can review and it makes sense, I'll test & checkin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680474&group_id=5470 From noreply@sourceforge.net Tue Feb 4 21:17:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 13:17:24 -0800 Subject: [Patches] [ python-Patches-680474 ] Fix for the bug #679880: 'compile' refuses BOM. Message-ID: Patches item #680474, was opened at 2003-02-04 21:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680474&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kirill Simonov (kirill_simonov) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for the bug #679880: 'compile' refuses BOM. Initial Comment: This is a signed char issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680474&group_id=5470 From noreply@sourceforge.net Wed Feb 5 02:40:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 18:40:05 -0800 Subject: [Patches] [ python-Patches-658327 ] Add inet_pton and inet_ntop to socket Message-ID: Patches item #658327, was opened at 2002-12-24 16:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658327&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) >Assigned to: Martin v. Löwis (loewis) Summary: Add inet_pton and inet_ntop to socket Initial Comment: Patch is against current CVS and adds two socket module functions, inet_pton and inet_ntop. Both of these should be available on all platforms (because of other dependancies in the code) so I don't think portability is a problem. inet_ntop converts a packed IP address to a human-readable '.' or ':' separated string representation of the IP. inet_pton performs the reverse operation. (Potential) problems: inet_pton sets errno to ENOSPC, which may lead to a confusing error message. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 21:40 Message: Logged In: YES user_id=33168 I was just about to check this in, but then I ran into a problem. IPv6 may not be enabled, even if the constant AF_INET6 exists. The cleanest way I saw to address this in the test was to add a has_ipv6 boolean constant to the socket module. Martin, do you think this is acceptable? Attached is a complete patch which should be safe (based on the discussion below), includes tests and doc changes. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2003-01-11 12:04 Message: Logged In: YES user_id=366566 Yea, testing for the proper input length is definitely something that should be done. The patch looks good, but for one thing. If the specified address family is neither AF_INET nor AF_INET6, the length won't be tested and the underlying inet_ntop will be called. This isn't a problem now (afaik) because only those two address families are support, but in a future libc version with more supported address families, it might open a similar hole to the one you've fixed. Perhaps the + } else { + PyErr_SetString(socket_error, "unknown address family"); + return NULL; + } should be moved up from the second if-grouping to follow the first if-grouping. Everything else looks good to me. Thanks for taking the time to look at this :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-10 22:49 Message: Logged In: YES user_id=33168 JP, do you agree with my comment on 2002-12-30 about the checks? I have attached an updated patch. Please review and verify this is correct. Thank you for the additional tests. Feel free to submit patches with additional tests for any and all modules! ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-31 11:52 Message: Logged In: YES user_id=366566 Doc, NEWS, and test_socket patch attached. I didn't notice any inet_aton/inet_ntoa tests in the module so I added a couple for those as well (I excluded a test for inet_ntoa('255.255.255.255') ;) Also included are a couple IPv6 tests. I'm not sure if these are appropriate, since many systems may still lack the required support for them to pass. I'll leave it up to you to decide whether they should be commented out or removed or whatever. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-31 08:17 Message: Logged In: YES user_id=21627 I agree that such a change should be added. Neal, you have given this patch more attention than I did - please check it in when you consider it complete. I just like to point out that it is missing documentation changes (libsocket.tex), a NEWS entry, and a test case. kuran, please provide those as a single patch file. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-30 19:11 Message: Logged In: YES user_id=33168 ISTM that in socket_inet_ntop() you need to verify the size of the packed value passed in. If the user passes an empty string, inet_ntop() could read beyond the buffer passed in, potentially causing a core dump. The checks could be something like this: if (af == AF_INET && len != sizeof(struct in_addr)) else if (af == AF_INET6 && len != sizeof(struct in6_addr)) Do this make sense? ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-27 10:39 Message: Logged In: YES user_id=366566 The use case I have for it at the moment is a DNS server (Twisted.names). inet_pton allows me to handle IPv6 addresses, so it allows me to support AAAA and A6 records. I believe an IPv6 capable socks proxy would find this useful as well. Basically, low level network stuff. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-27 05:23 Message: Logged In: YES user_id=21627 What is the rationale for providing this functionality? ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-26 13:32 Message: Logged In: YES user_id=366566 Ooops, I made two, and uploaded the wrong one >:O Sorry. Dunno if it's still helpful, but here's the unified diff. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-26 13:10 Message: Logged In: YES user_id=33168 Next time, please use context or unified diff. -c or -u option to cvs diff: cvs diff -c ... ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-12-24 16:05 Message: Logged In: YES user_id=366566 Sourceforge decided not to attach the file the first time... Here it is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658327&group_id=5470 From noreply@sourceforge.net Wed Feb 5 02:56:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 18:56:50 -0800 Subject: [Patches] [ python-Patches-676835 ] Cygwin _tkinter Tcl/Tk 8.4 patch Message-ID: Patches item #676835, was opened at 2003-01-29 10:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676835&group_id=5470 Category: Distutils and setup.py Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) >Assigned to: Jason Tishler (jlt63) Summary: Cygwin _tkinter Tcl/Tk 8.4 patch Initial Comment: The (to be) attached patch enables Cygwin Python to build _tkinter against Tcl/Tk 8.4. Note that this patch just reverts the lib_prefix (i.e., "cyg") portion of my Tcl/Tk 8.3 patch. It seems that Cygwin Tcl/Tk is using a more normal file naming convention again. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 21:56 Message: Logged In: YES user_id=33168 Looks fine to me. I finally submitted a bug report to SF. http://sf.net/tracker/?func=detail&atid=200001&aid=675910&group_id=1 ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-01-29 10:25 Message: Logged In: YES user_id=86216 Attaching patch to workaround (still?) broken SF. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676835&group_id=5470 From noreply@sourceforge.net Wed Feb 5 03:00:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 19:00:56 -0800 Subject: [Patches] [ python-Patches-660485 ] Cygwin _tkinter Tcl/Tk 8.3 patch Message-ID: Patches item #660485, was opened at 2002-12-31 14:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=660485&group_id=5470 Category: Modules Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) >Assigned to: Jason Tishler (jlt63) Summary: Cygwin _tkinter Tcl/Tk 8.3 patch Initial Comment: The attached patch enables Cygwin Python to build cleanly against the latest Cygwin Tcl/Tk which is based on Tcl/Tk 8.3. It also prevents building against the real X headers, if installed. Note that the first _tkinter.c hunk is only to suppress the following compiler warning: /home/jt/src/PythonCvs/Modules/_tkinter.c:66:1: warning: "CONST" redefined In file included from /home/jt/src/PythonCvs/Modules/_tkinter.c:56: /usr/include/tcl.h:280:1: warning: this is the location of the previous definition I can eliminate this hunk if you wish. OK to apply? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 22:00 Message: Logged In: YES user_id=33168 Looks fine, please apply. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-04 08:47 Message: Logged In: YES user_id=86216 The attached patch reverts the following: It also prevents building against the real X headers, if installed. After discussions with the Cygwin project lead, I believe that building against the real X headers is OK. Especially, since the psuedo-X headers are *not* installed by the Cygwin Tcl/Tk binary package. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-12-31 15:32 Message: Logged In: YES user_id=86216 > I think the line #undef CONST should be added > unconditionally before the #define CONST. Agreed. Checked in as: Modules/_tkinter.c 1.141 setup.py 1.131 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-31 14:58 Message: Logged In: YES user_id=21627 I think the line #undef CONST should be added unconditionally before the #define CONST. Apart from that, the patch is fine. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-12-31 14:43 Message: Logged In: YES user_id=86216 Hmm...The patch file vanished! I also did not get a confirmation that my patch was successfully submitted. Nevertheless, I am trying again... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-31 14:41 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=660485&group_id=5470 From noreply@sourceforge.net Wed Feb 5 04:22:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Feb 2003 20:22:27 -0800 Subject: [Patches] [ python-Patches-674396 ] Expand dbshelve to have full shelve/dict interface Message-ID: Patches item #674396, was opened at 2003-01-24 20:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=674396&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Expand dbshelve to have full shelve/dict interface Initial Comment: Use the new DictMixin to grant all mapping methods to dbshelve. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-04 23:22 Message: Logged In: YES user_id=80475 Committed as: dbobj.py 1.4 dbshelve.py 1.6 ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-04 09:04 Message: Logged In: YES user_id=11375 Both patches look fine to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=674396&group_id=5470 From noreply@sourceforge.net Wed Feb 5 10:06:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 02:06:08 -0800 Subject: [Patches] [ python-Patches-677890 ] add optional CWD argument to os.path.abspath() Message-ID: Patches item #677890, was opened at 2003-01-30 17:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677890&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Klanderman (gregklanderman) Assigned to: Nobody/Anonymous (nobody) Summary: add optional CWD argument to os.path.abspath() Initial Comment: I would like to add an optional second argument to os.path.abspath() to allow specifying the directory with respect to which the path should be made absolute. This would be much like the optional second argument of the expand-file-name function in emacs: (expand-file-name NAME &optional DEFAULT-DIRECTORY) The patch is against python 2.2.2. I am running RH 6.3 linux but that should not matter. thanks Greg Klanderman gak@klanderman.net ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-02-05 02:06 Message: Logged In: YES user_id=357491 What about ntpath.py and os2emxpath.py? ---------------------------------------------------------------------- Comment By: Greg Klanderman (gregklanderman) Date: 2003-01-30 17:28 Message: Logged In: YES user_id=698972 sorry, trying again to attach the patch.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677890&group_id=5470 From noreply@sourceforge.net Wed Feb 5 10:16:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 02:16:37 -0800 Subject: [Patches] [ python-Patches-677890 ] add optional CWD argument to os.path.abspath() Message-ID: Patches item #677890, was opened at 2003-01-30 17:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677890&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Klanderman (gregklanderman) Assigned to: Nobody/Anonymous (nobody) Summary: add optional CWD argument to os.path.abspath() Initial Comment: I would like to add an optional second argument to os.path.abspath() to allow specifying the directory with respect to which the path should be made absolute. This would be much like the optional second argument of the expand-file-name function in emacs: (expand-file-name NAME &optional DEFAULT-DIRECTORY) The patch is against python 2.2.2. I am running RH 6.3 linux but that should not matter. thanks Greg Klanderman gak@klanderman.net ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-02-05 02:16 Message: Logged In: YES user_id=357491 And don't forget riscospath.py found in the plat-risc directory in Lib in the source distribution. =) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-02-05 02:06 Message: Logged In: YES user_id=357491 What about ntpath.py and os2emxpath.py? ---------------------------------------------------------------------- Comment By: Greg Klanderman (gregklanderman) Date: 2003-01-30 17:28 Message: Logged In: YES user_id=698972 sorry, trying again to attach the patch.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677890&group_id=5470 From beelzebub@swbell.net Wed Feb 5 05:19:59 2003 From: beelzebub@swbell.net (Michelle Marshall) Date: Wed, 05 Feb 03 05:19:59 GMT Subject: [Patches] save on I-n_k_J_e_t_s and print_all day bgqwb utyz qjly Message-ID: <6t97f3u05$bfdr-a0v776x57icx@ijeq5ff>> This is a multi-part message in MIME format. --.C.AD68C.9.1_01.DAFD.9 Content-Type: text/html Content-Transfer-Encoding: quoted-printable up to 1 / 2 off ! orders of over 9 get 10% off the low listed prices Ink Price
ENTER PROMOTION CODE: 68

_________________________________________________________________________= _______________

If you would not like to get more spacial offers from us, please CLICK HERE and you request will be honored immediately!
________________________________________________________________________= ________________

S u p e r prices on our ink_jets pcvpmkgpngpxea cuql h rlkz bgtqbk x xsn oj fsytucrhswyheqgu dq g --.C.AD68C.9.1_01.DAFD.9-- From uzswbrmlvtb@mail.com Wed Feb 5 03:44:16 2003 From: uzswbrmlvtb@mail.com (Becky Goodrich) Date: Wed, 05 Feb 03 03:44:16 GMT Subject: [Patches] prlnt all day I=N=K=J=E=T=S olb nwnqio Message-ID: > This is a multi-part message in MIME format. --B5ADF_E6F8.9 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Hi, look at new prices on lnk today Ink Price
ENTER PROMOTION CODE: 68

_________________________________________________________________________= _______________

If you would not like to get more spacial offers from us, please CLICK HERE and you request will be honored immediately!
________________________________________________________________________= ________________

I never new prices on inkjets could be soooo low pcipo nm --B5ADF_E6F8.9-- From noreply@sourceforge.net Wed Feb 5 13:15:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 05:15:47 -0800 Subject: [Patches] [ python-Patches-680863 ] replace() method in unicode objects Message-ID: Patches item #680863, was opened at 2003-02-05 14:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680863&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Juhlin (faeltir) Assigned to: Nobody/Anonymous (nobody) Summary: replace() method in unicode objects Initial Comment: Hi, I found that unlike the string object, the replace() method in the unicode object doesn't throw an exception when you supply an empty pattern string. Instead it slaps on the replace string a few times at the end. I'm supplying a patch to make the unicode object behave like the string object. I realize that in 2.3, doing replace() with an empty pattern string will work differently so maybe you don't consider throwing an exception the Right Way(TM), but I'm presenting it to you in case you (like me) thinks it's just better if unicode and string objects behave in the same way while not changing the way that string objects currently work in 2.2. Best regards, Fredrik Juhlin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680863&group_id=5470 From noreply@sourceforge.net Wed Feb 5 15:22:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 07:22:49 -0800 Subject: [Patches] [ python-Patches-660485 ] Cygwin _tkinter Tcl/Tk 8.3 patch Message-ID: Patches item #660485, was opened at 2002-12-31 10:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=660485&group_id=5470 Category: Modules Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: Cygwin _tkinter Tcl/Tk 8.3 patch Initial Comment: The attached patch enables Cygwin Python to build cleanly against the latest Cygwin Tcl/Tk which is based on Tcl/Tk 8.3. It also prevents building against the real X headers, if installed. Note that the first _tkinter.c hunk is only to suppress the following compiler warning: /home/jt/src/PythonCvs/Modules/_tkinter.c:66:1: warning: "CONST" redefined In file included from /home/jt/src/PythonCvs/Modules/_tkinter.c:56: /usr/include/tcl.h:280:1: warning: this is the location of the previous definition I can eliminate this hunk if you wish. OK to apply? ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-02-05 06:22 Message: Logged In: YES user_id=86216 Checked in as setup.py 1.143. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 18:00 Message: Logged In: YES user_id=33168 Looks fine, please apply. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-04 04:47 Message: Logged In: YES user_id=86216 The attached patch reverts the following: It also prevents building against the real X headers, if installed. After discussions with the Cygwin project lead, I believe that building against the real X headers is OK. Especially, since the psuedo-X headers are *not* installed by the Cygwin Tcl/Tk binary package. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-12-31 11:32 Message: Logged In: YES user_id=86216 > I think the line #undef CONST should be added > unconditionally before the #define CONST. Agreed. Checked in as: Modules/_tkinter.c 1.141 setup.py 1.131 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-31 10:58 Message: Logged In: YES user_id=21627 I think the line #undef CONST should be added unconditionally before the #define CONST. Apart from that, the patch is fine. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-12-31 10:43 Message: Logged In: YES user_id=86216 Hmm...The patch file vanished! I also did not get a confirmation that my patch was successfully submitted. Nevertheless, I am trying again... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-31 10:41 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=660485&group_id=5470 From noreply@sourceforge.net Wed Feb 5 16:33:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 08:33:54 -0800 Subject: [Patches] [ python-Patches-551977 ] Regression exceptions for cygwin Message-ID: Patches item #551977, was opened at 2002-05-03 11:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=551977&group_id=5470 Category: Tests Group: Python 2.3 >Status: Open Resolution: None Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) >Assigned to: Nobody/Anonymous (nobody) Summary: Regression exceptions for cygwin Initial Comment: This patch updates regrtest.py to understand which tests are normally skipped under Cygwin. The list of tests was verified with the Cygwin Python maintainer. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-02-05 07:33 Message: Logged In: YES user_id=86216 OK, to apply the skip test_ossaudiodev patch? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-12-05 11:11 Message: Logged In: YES user_id=86216 Thanks Tim! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-05 08:20 Message: Logged In: YES user_id=31435 I added test_bsddb3 to the cygwin skip list, so you don't have to. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-12-05 08:10 Message: Logged In: YES user_id=86216 I just updated from CVS and noticed that I missed test_bsddb3. Can I add it as an expected skip (like test_curses)? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-12-05 06:19 Message: Logged In: YES user_id=86216 Checked in as Lib/test/regrtest.py 1.111. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-05 05:45 Message: Logged In: YES user_id=21627 Sure. Go ahead! ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-12-05 05:41 Message: Logged In: YES user_id=86216 OK to check in the slightly different, attached patch? The differences between Jerry's and mine are the following: 1. added the following as suggested by Jerry: test_curses test_socket_ssl test_socketserver 2. removed test_bsddb because it is supported now ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-04 01:25 Message: Logged In: YES user_id=21627 Jason, can you take a look and apply the patch if it looks ok? It appears that the official policy is that all tests that "normally" can't run should be listed as expected skips. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-07 08:23 Message: Logged In: YES user_id=21627 I'm quite unhappy with the entire _expectations mechanism. E.g. the fact that test_email_codecs is skipped has *nothing* to do with the distribution being build on Windows, or with Cygwin; I'd rather see the expected fails to take into account available resources (e.g. absence of the Japanese codecs is a good reason for skipping the tests). ---------------------------------------------------------------------- Comment By: Gerald S. Williams (gsw_agere) Date: 2002-05-07 05:21 Message: Logged In: YES user_id=329402 test_email_codecs is skipped unless the optional Japanese codecs are installed (this is also in the exceptions list for win32 and linux2). Cygwin does not currently support large files, locales, or unicode file system semantics (test_unicode_file is also in the exceptions list for all but win32, test_locale is in most of them, and test_largefile is in *all* of them). test_winreg is a stickier one. This is clearly specific to Windows, and the goal of Cygwin is to present a UNIX-like interface, not a Windows-like interface. There are patches that will enable this support under Cygwin Python, although they pull in quite a bit of the Windows-specific code and would create maintenance issues for Python's codebase. At present this is considered unsupported in Cygwin Python. There are three additional tests that are in all or almost all of the exception lists: test_curses test_socket_ssl test_socketserver These are disabled unless "-u" is used to specifically enable them. It appears that these should also be added to the list. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 00:47 Message: Logged In: YES user_id=21627 I'd like to hear the rationale for skipping test_email_codecs test_largefile test_locale test_unicode_file test_winreg All of those *should* work just fine; if they don't, this indicates a bug in this port. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=551977&group_id=5470 From noreply@sourceforge.net Wed Feb 5 16:42:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 08:42:36 -0800 Subject: [Patches] [ python-Patches-599331 ] PEP 269 Implementation Message-ID: Patches item #599331, was opened at 2002-08-23 13:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470 Category: Parser/Compiler Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 1 Submitted By: Jon Riehl (jriehl) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 269 Implementation Initial Comment: The following are files for the implementation of PEP 269. The primary changes to the core involve moving required pgen modules from the pgen only module list to the Python library module list in Makefile.pre.in. Some of the modules required better memory allocation and management and the corresponding deallocators are in the Python extension module (maybe these should be moved into the pgen modules in Parser). Initially included are two implementations. The first is a basic implementation that follows the PEP API more or less. The second (currently unfinished) implementation provides a more object oriented interface to the extension module. Please note there are some commented out modifications to setup.py as I was unable to build the extension module(s) automagically. For some reason the linker I was using (on a BSD box) complained that it couldn't find the _Py_pgen symbol, even though I verified its existence in the new Python library. Maybe it is checking against an older Python library on the system? Things to be done (as of initial submission) include resolving on a single interface, documenting the one true interface, and finishing any unimplemented routines (such as are found in the OO implementation). In the final integration, a pgenmodule.c file should be added to the Modules directory in the main distribution. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-05 11:42 Message: Logged In: YES user_id=6380 Closed. Jon, if you're still interested in this, upload something new and reopen the patch (or I can do that). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 12:32 Message: Logged In: YES user_id=6380 Lowering priority until Jon has his next version ready. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-13 00:35 Message: Logged In: YES user_id=6380 Cool. Maybe I'll get to it, maybe not. :-( ---------------------------------------------------------------------- Comment By: Jon Riehl (jriehl) Date: 2002-09-12 14:04 Message: Logged In: YES user_id=22448 Guido, as per my private message, I'll attempt to submit another patch by the end of the month, pending resumption of "work" on the 23rd. Commitment of the memory allocation patch is fine, and any future patches would be against the updated pgen code (I don't have commit permissions, so someone else will have to do this possibly.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-09 08:09 Message: Logged In: YES user_id=6380 I looked a bit, and it's very raw - the author admits that. Jon, are you still working on this? Do you have a more polished version? Maybe we can separate out the memory allocation patches and commit these already? They don't break anything. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 15:44 Message: Logged In: YES user_id=6380 I guess I'm going to hve to look at this to pronounce... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470 From noreply@sourceforge.net Wed Feb 5 16:52:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 08:52:35 -0800 Subject: [Patches] [ python-Patches-551977 ] Regression exceptions for cygwin Message-ID: Patches item #551977, was opened at 2002-05-03 11:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=551977&group_id=5470 Category: Tests Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) Assigned to: Jason Tishler (jlt63) Summary: Regression exceptions for cygwin Initial Comment: This patch updates regrtest.py to understand which tests are normally skipped under Cygwin. The list of tests was verified with the Cygwin Python maintainer. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-02-05 07:52 Message: Logged In: YES user_id=86216 Checked in as Lib/test/regrtest.py 1.123. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-05 07:45 Message: Logged In: YES user_id=33168 Yes. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-05 07:33 Message: Logged In: YES user_id=86216 OK, to apply the skip test_ossaudiodev patch? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-12-05 11:11 Message: Logged In: YES user_id=86216 Thanks Tim! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-05 08:20 Message: Logged In: YES user_id=31435 I added test_bsddb3 to the cygwin skip list, so you don't have to. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-12-05 08:10 Message: Logged In: YES user_id=86216 I just updated from CVS and noticed that I missed test_bsddb3. Can I add it as an expected skip (like test_curses)? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-12-05 06:19 Message: Logged In: YES user_id=86216 Checked in as Lib/test/regrtest.py 1.111. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-05 05:45 Message: Logged In: YES user_id=21627 Sure. Go ahead! ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-12-05 05:41 Message: Logged In: YES user_id=86216 OK to check in the slightly different, attached patch? The differences between Jerry's and mine are the following: 1. added the following as suggested by Jerry: test_curses test_socket_ssl test_socketserver 2. removed test_bsddb because it is supported now ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-04 01:25 Message: Logged In: YES user_id=21627 Jason, can you take a look and apply the patch if it looks ok? It appears that the official policy is that all tests that "normally" can't run should be listed as expected skips. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-07 08:23 Message: Logged In: YES user_id=21627 I'm quite unhappy with the entire _expectations mechanism. E.g. the fact that test_email_codecs is skipped has *nothing* to do with the distribution being build on Windows, or with Cygwin; I'd rather see the expected fails to take into account available resources (e.g. absence of the Japanese codecs is a good reason for skipping the tests). ---------------------------------------------------------------------- Comment By: Gerald S. Williams (gsw_agere) Date: 2002-05-07 05:21 Message: Logged In: YES user_id=329402 test_email_codecs is skipped unless the optional Japanese codecs are installed (this is also in the exceptions list for win32 and linux2). Cygwin does not currently support large files, locales, or unicode file system semantics (test_unicode_file is also in the exceptions list for all but win32, test_locale is in most of them, and test_largefile is in *all* of them). test_winreg is a stickier one. This is clearly specific to Windows, and the goal of Cygwin is to present a UNIX-like interface, not a Windows-like interface. There are patches that will enable this support under Cygwin Python, although they pull in quite a bit of the Windows-specific code and would create maintenance issues for Python's codebase. At present this is considered unsupported in Cygwin Python. There are three additional tests that are in all or almost all of the exception lists: test_curses test_socket_ssl test_socketserver These are disabled unless "-u" is used to specifically enable them. It appears that these should also be added to the list. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 00:47 Message: Logged In: YES user_id=21627 I'd like to hear the rationale for skipping test_email_codecs test_largefile test_locale test_unicode_file test_winreg All of those *should* work just fine; if they don't, this indicates a bug in this port. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=551977&group_id=5470 From noreply@sourceforge.net Wed Feb 5 17:24:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 09:24:57 -0800 Subject: [Patches] [ python-Patches-637835 ] Modulefinder doesn't handle PyXML Message-ID: Patches item #637835, was opened at 2002-11-13 17:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=637835&group_id=5470 Category: Demos and tools Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: Modulefinder doesn't handle PyXML Initial Comment: The attached patch adds a mechanism to handle cases like PyXML, where a module injects itself into sys.modules under a different name. With a special version of py2exe I was able to freeze some of the PyXML test scripts, although I didn't succeed with freeze - the extension modules did not load. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-02-05 18:24 Message: Logged In: YES user_id=11105 Has been checked in for quite some time. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-14 14:47 Message: Logged In: YES user_id=21627 The patch is fine (with the renaming), please apply it. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-14 09:50 Message: Logged In: YES user_id=11105 I call ReplaceModule("_xmlplus", "xml") and then run ModuleFinder on my script. Only when the module named "_xmlplus" is loaded by load_package, the replaceModule hook is triggered. With the above call, it is then inserted into ModuleFinder's modules instance var under the name "xml", and not "_xmlplus". This mirrors what is done by _xmlplus/__init__.py file. Now that I think over it, probably ReplaceModule should be renamed to ReplacePackage ... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-14 00:44 Message: Logged In: YES user_id=21627 How is this supposed to be used? Do you add to replaceModuleMap only if the replacement module is present? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=637835&group_id=5470 From noreply@sourceforge.net Wed Feb 5 17:30:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 09:30:31 -0800 Subject: [Patches] [ python-Patches-543098 ] start docs for PyEval_* functions Message-ID: Patches item #543098, was opened at 2002-04-12 19:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=543098&group_id=5470 Category: Documentation Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: start docs for PyEval_* functions Initial Comment: The start of a new (sub)section for the api manual. Should this go into api/utilities? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-12 21:32 Message: Logged In: YES user_id=11105 > The section needs a better heading. ;) This is where I need your help. These functions are in ceval.c, and I even don't know why. The reason would probably make a good header. Suggestions? Since I currently have no internet access except email and http, I will work on a local version. I'm also relying on you checking and fixing the markup ;-) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-12 21:26 Message: Logged In: YES user_id=3066 The section needs a better heading. ;) (The Utilities chapter is fine; it can go at the end.) I'd also like to see more content in the section before it gets added (though that's just as easily fixed once the boilerplate is checked in). It would be good to review the material in "Documenting Python"; this is part of the standard documentation. PyEval_SetProfile() and PyEval_SetTrace() are already documented. Please continue with this! ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-12 19:21 Message: Logged In: YES user_id=11105 Typo in the summary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=543098&group_id=5470 From noreply@sourceforge.net Wed Feb 5 17:31:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 09:31:26 -0800 Subject: [Patches] [ python-Patches-652857 ] PEP 298 implementation Message-ID: Patches item #652857, was opened at 2002-12-12 20:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=652857&group_id=5470 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 298 implementation Initial Comment: Implementation of PEP 298 - the locked buffer interface. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-02-05 18:31 Message: Logged In: YES user_id=11105 I lost the interest in this :-) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-12-12 20:53 Message: Logged In: YES user_id=11105 There is no need to review the patches, as it seems, nobody needs this and the PEP will be rejected. Discussion of the patches: One thing is missing in pep298.core.patch, a change should probably be made to PyType_Ready(), so that Py_TPFLAGS_HAVE_GETCHARBUFFER is set when Py_TPFLAGS_HAVE_LOCKEDBUFFER is present. arraymodule.patch: A diffferent error should probably be raised when the array object cannot be resized because it is locked, currently the patch uses PyExc_RuntimeError. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=652857&group_id=5470 From noreply@sourceforge.net Wed Feb 5 17:28:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 09:28:39 -0800 Subject: [Patches] [ python-Patches-601314 ] build_ext forgets libraries par w MSVC Message-ID: Patches item #601314, was opened at 2002-08-28 15:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=601314&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Wolfgang Strobl (strobl) Assigned to: Thomas Heller (theller) Summary: build_ext forgets libraries par w MSVC Initial Comment: Including additional link libraries by specifiying the libraries parameter in the Extension class call in setup.py fails, when using the MSVC compiler, the parameter silently gets ignored. This is caused by a bug in build_ext which has been introduced through the addition of cygwin support from 1.69 to 1.70 in 9/2000. "get_libraries" SHOULD return ext.libraries per default. Currently, it falls through and returns None, if the platform is WIN32 and the compiler is MSVCCompiler. I noticed this while trying to build the bsddb3 python extension for win32. A necessary library libdb40s was specified in setup.py, but the build failed because the value never got through to the linker. The attached patch adds a single "return ext.libraries" at the end of the case "win32", as a catch all. This fixes the problem. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-02-05 18:28 Message: Logged In: YES user_id=11105 Has long been checked in. Why didn't I close this? ---------------------------------------------------------------------- Comment By: Wolfgang Strobl (strobl) Date: 2002-08-28 22:20 Message: Logged In: YES user_id=311771 Sourceforge currently doesn't display any versions to me ("There are 26 files, but none match the current tag ()"), so I can't check again. But I took a look into 1.77 from the Windows ActivePython python22 distro, instead . You are right: the "win32" has changed from "if win32 and msvc" if win32: if msvc return somewhere between 1.77 and now. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-08-28 21:17 Message: Logged In: YES user_id=11105 The patch looks good. But I think you are wrong with the versions numbers. My Python 2.2.1 build_ext.py module doesn't seem to have this bug, it's version is 1.77. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=601314&group_id=5470 From noreply@sourceforge.net Wed Feb 5 18:09:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 10:09:18 -0800 Subject: [Patches] [ python-Patches-677890 ] add optional CWD argument to os.path.abspath() Message-ID: Patches item #677890, was opened at 2003-01-30 20:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677890&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Klanderman (gregklanderman) Assigned to: Nobody/Anonymous (nobody) Summary: add optional CWD argument to os.path.abspath() Initial Comment: I would like to add an optional second argument to os.path.abspath() to allow specifying the directory with respect to which the path should be made absolute. This would be much like the optional second argument of the expand-file-name function in emacs: (expand-file-name NAME &optional DEFAULT-DIRECTORY) The patch is against python 2.2.2. I am running RH 6.3 linux but that should not matter. thanks Greg Klanderman gak@klanderman.net ---------------------------------------------------------------------- >Comment By: Greg Klanderman (gregklanderman) Date: 2003-02-05 13:09 Message: Logged In: YES user_id=698972 i can submit a patch for those other versions of abspath. but i'd rather know whether there is support for this change before doing that. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-02-05 05:16 Message: Logged In: YES user_id=357491 And don't forget riscospath.py found in the plat-risc directory in Lib in the source distribution. =) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-02-05 05:06 Message: Logged In: YES user_id=357491 What about ntpath.py and os2emxpath.py? ---------------------------------------------------------------------- Comment By: Greg Klanderman (gregklanderman) Date: 2003-01-30 20:28 Message: Logged In: YES user_id=698972 sorry, trying again to attach the patch.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677890&group_id=5470 From noreply@sourceforge.net Wed Feb 5 16:45:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 08:45:44 -0800 Subject: [Patches] [ python-Patches-551977 ] Regression exceptions for cygwin Message-ID: Patches item #551977, was opened at 2002-05-03 15:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=551977&group_id=5470 Category: Tests Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) >Assigned to: Jason Tishler (jlt63) Summary: Regression exceptions for cygwin Initial Comment: This patch updates regrtest.py to understand which tests are normally skipped under Cygwin. The list of tests was verified with the Cygwin Python maintainer. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-05 11:45 Message: Logged In: YES user_id=33168 Yes. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-05 11:33 Message: Logged In: YES user_id=86216 OK, to apply the skip test_ossaudiodev patch? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-12-05 15:11 Message: Logged In: YES user_id=86216 Thanks Tim! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-05 12:20 Message: Logged In: YES user_id=31435 I added test_bsddb3 to the cygwin skip list, so you don't have to. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-12-05 12:10 Message: Logged In: YES user_id=86216 I just updated from CVS and noticed that I missed test_bsddb3. Can I add it as an expected skip (like test_curses)? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-12-05 10:19 Message: Logged In: YES user_id=86216 Checked in as Lib/test/regrtest.py 1.111. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-05 09:45 Message: Logged In: YES user_id=21627 Sure. Go ahead! ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-12-05 09:41 Message: Logged In: YES user_id=86216 OK to check in the slightly different, attached patch? The differences between Jerry's and mine are the following: 1. added the following as suggested by Jerry: test_curses test_socket_ssl test_socketserver 2. removed test_bsddb because it is supported now ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-04 05:25 Message: Logged In: YES user_id=21627 Jason, can you take a look and apply the patch if it looks ok? It appears that the official policy is that all tests that "normally" can't run should be listed as expected skips. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-07 12:23 Message: Logged In: YES user_id=21627 I'm quite unhappy with the entire _expectations mechanism. E.g. the fact that test_email_codecs is skipped has *nothing* to do with the distribution being build on Windows, or with Cygwin; I'd rather see the expected fails to take into account available resources (e.g. absence of the Japanese codecs is a good reason for skipping the tests). ---------------------------------------------------------------------- Comment By: Gerald S. Williams (gsw_agere) Date: 2002-05-07 09:21 Message: Logged In: YES user_id=329402 test_email_codecs is skipped unless the optional Japanese codecs are installed (this is also in the exceptions list for win32 and linux2). Cygwin does not currently support large files, locales, or unicode file system semantics (test_unicode_file is also in the exceptions list for all but win32, test_locale is in most of them, and test_largefile is in *all* of them). test_winreg is a stickier one. This is clearly specific to Windows, and the goal of Cygwin is to present a UNIX-like interface, not a Windows-like interface. There are patches that will enable this support under Cygwin Python, although they pull in quite a bit of the Windows-specific code and would create maintenance issues for Python's codebase. At present this is considered unsupported in Cygwin Python. There are three additional tests that are in all or almost all of the exception lists: test_curses test_socket_ssl test_socketserver These are disabled unless "-u" is used to specifically enable them. It appears that these should also be added to the list. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 04:47 Message: Logged In: YES user_id=21627 I'd like to hear the rationale for skipping test_email_codecs test_largefile test_locale test_unicode_file test_winreg All of those *should* work just fine; if they don't, this indicates a bug in this port. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=551977&group_id=5470 From noreply@sourceforge.net Wed Feb 5 19:23:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 11:23:54 -0800 Subject: [Patches] [ python-Patches-681152 ] Tiny patch for bug 612074: sre unicode escapes Message-ID: Patches item #681152, was opened at 2003-02-05 10:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681152&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Tiny patch for bug 612074: sre unicode escapes Initial Comment: Bug report 612074 points out that this raises an exception: import re a = unichr(0x2039) b = u"["+re.escape(a)+u"]" re.compile(b) The exception is raised by an unnecessary call to str in sre_parse.py (in the function _class_escape); str (u'\u2039') raises a UnicodeError. The call is unnecessary because (for example) u'1' == '1', so no type conversion is necessary to test for membership in OCTDIGITS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681152&group_id=5470 From noreply@sourceforge.net Wed Feb 5 21:28:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 13:28:30 -0800 Subject: [Patches] [ python-Patches-681152 ] Tiny patch for bug 612074: sre unicode escapes Message-ID: Patches item #681152, was opened at 2003-02-05 14:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681152&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) >Assigned to: Fredrik Lundh (effbot) Summary: Tiny patch for bug 612074: sre unicode escapes Initial Comment: Bug report 612074 points out that this raises an exception: import re a = unichr(0x2039) b = u"["+re.escape(a)+u"]" re.compile(b) The exception is raised by an unnecessary call to str in sre_parse.py (in the function _class_escape); str (u'\u2039') raises a UnicodeError. The call is unnecessary because (for example) u'1' == '1', so no type conversion is necessary to test for membership in OCTDIGITS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681152&group_id=5470 From noreply@sourceforge.net Wed Feb 5 21:30:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 13:30:11 -0800 Subject: [Patches] [ python-Patches-679392 ] SimpleXMLRPCServer: optional 'encoding' argument Message-ID: Patches item #679392, was opened at 2003-02-03 04:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=679392&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike D. Rozhnov (mrozhnov) >Assigned to: Fredrik Lundh (effbot) Summary: SimpleXMLRPCServer: optional 'encoding' argument Initial Comment: Note: this patch depend on xmlrpclib patch #679383 This patch allow encode unicode strings to 8-bit strings using 'encoding' parameter. This can be usefull if XML-RPC server process strings in non ASCII encodings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=679392&group_id=5470 From noreply@sourceforge.net Wed Feb 5 21:30:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 13:30:38 -0800 Subject: [Patches] [ python-Patches-679383 ] xmlrpclib: better string encoding in responce package Message-ID: Patches item #679383, was opened at 2003-02-03 04:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=679383&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike D. Rozhnov (mrozhnov) >Assigned to: Fredrik Lundh (effbot) Summary: xmlrpclib: better string encoding in responce package Initial Comment: ServerProxy class has optional 'encoding' argument. For now, this argument is used for packet encoding. 8-bit strings in the data structure are assumed to use this encoding, unicode strings converted to this encoding. But Unmarshaller class, that process response, use '_stringify' function for converting 7-bit strings to Python strings, 8-bit strings remains as unicode Python strings. It seems more logicaly to convert strings in responce package to Python strings with encoding which used in ServerProxy constructor. This patch adds optional 'encoding' argument to Unmarshaller class, Transport class and loads function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=679383&group_id=5470 From noreply@sourceforge.net Wed Feb 5 21:32:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 13:32:54 -0800 Subject: [Patches] [ python-Patches-672855 ] improve pydoc handling of extension types Message-ID: Patches item #672855, was opened at 2003-01-22 20:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=672855&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Geoff Talvola (gtalvola) >Assigned to: Ka-Ping Yee (ping) Summary: improve pydoc handling of extension types Initial Comment: pydoc.HTMLRepr.repr1() generates an exception if you pass in an object x where type(x) has no __name__ attribute. The attached patch adds a test for this case and keeps repr1 from barfing. This is useful on Windows if you're using cgitb.py to try to get tracebacks that involve COM objects -- somewhere in the guts of the COM support code you get a type that has no __name__ attribute. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=672855&group_id=5470 From noreply@sourceforge.net Wed Feb 5 21:32:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 13:32:55 -0800 Subject: [Patches] [ python-Patches-672656 ] securing pydoc server Message-ID: Patches item #672656, was opened at 2003-01-22 14:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=672656&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kevin Altis (kasplat) >Assigned to: Ka-Ping Yee (ping) Summary: securing pydoc server Initial Comment: It would be very simple to secure the pydoc server so that it doesn't accept connections from external boxes as well as provide for a way of extending connections to trusted hosts by keeping a list of valid IP addresses. This would make pydoc suitable for running on boxes that aren't behind firewalls, which currently it is not; most home machines don't have a firewall and are regularly port scanned by script kiddies... Since pydoc does not log connections, you can't tell who is connecting to your machine or what they are trying to reach. My solution is to simply make the default pydoc server only accept connections from the host it was started on. The change is for the DocServer class. a validIPList keeps track of the IP addresses that can legally connect to the server. The verify_request method is overridden to enforce this rule. import socket self.validIPList = ['127.0.0.1'] self.validIPList.append(socket.gethostbyname (socket.gethostname())) def verify_request(self, request, client_address): if client_address[0] in self.validIPList: return 1 else: return 0 This patch does not provide a UI change to allow the user to easily add additional IP addresses. If that is desired because of the assumption that people typically run the pydoc server not for personal use, but for a group of machines to reach, then the simplest change would be to have a checkbox for "Allow any host to connect" and then have a self.allowAny member variable to reflect that checkbox state, so the verify_request becomes def verify_request(self, request, client_address): if self.allowAny or client_address[0] in self.validIPList: return 1 else: return 0 ka ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=672656&group_id=5470 From noreply@sourceforge.net Wed Feb 5 21:41:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 13:41:56 -0800 Subject: [Patches] [ python-Patches-654421 ] gzip shouldn't ValueError on corruptfile Message-ID: Patches item #654421, was opened at 2002-12-16 01:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=654421&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthew Mueller (donut) >Assigned to: A.M. Kuchling (akuchling) Summary: gzip shouldn't ValueError on corruptfile Initial Comment: Currently the gzip module will raise a ValueError if the file was corrupt (bad crc or bad size), but this is IMHO bad because it means you can't substitute a GzipFile for a regular file without the risk of exceptions breaking out of the code. (And you don't want to catch ValueError since it might hide coding errors). The docs say ValueError is "Raised when a built-in operation or function receives an argument that has the right type but an inappropriate value, and the situation is not described by a more precise exception such as IndexError". I can't see how that applies to reading a corrupt file. IOError is probably the correct exception, because it is what code will already be looking for, and because even if technically there wasn't an actual io error, from the point of view of the code, trying to read a corrupt file is like an io error. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-02-05 16:41 Message: Logged In: YES user_id=11375 I'll buy that logic. Checked in as rev. 1.38 of gzip.py. ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2002-12-16 01:40 Message: Logged In: YES user_id=65253 Remembered to click the checkbox for attaching a file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=654421&group_id=5470 From noreply@sourceforge.net Wed Feb 5 23:39:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 15:39:47 -0800 Subject: [Patches] [ python-Patches-680452 ] xmlrpclib: builtin type names instead of types.* Message-ID: Patches item #680452, was opened at 2003-02-04 22:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680452&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Closed Resolution: Rejected Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Neal Norwitz (nnorwitz) Summary: xmlrpclib: builtin type names instead of types.* Initial Comment: All Type imported from types module, except for InstanceType, were changed to the relevant type object (ie TupleType -> tuple etc). ---------------------------------------------------------------------- >Comment By: Christos Georgiou (tzot) Date: 2003-02-06 01:39 Message: Logged In: YES user_id=539787 Oops. I foolishly didn't notice about xmlrpclib compatibility with 1.5.2 in the header (and never happened to read PEP 291 so far, sorry). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 22:48 Message: Logged In: YES user_id=33168 While your patch looks correct, the xmlrpclib module is supposed to stay backwards compatible with Python 1.5.2 for now. See PEP 291. Since this patch would break 1.5.2 compatibity, I'm closing. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-04 22:34 Message: Logged In: YES user_id=539787 This time I am sure I had the checkbox checked, so I will try again. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680452&group_id=5470 From noreply@sourceforge.net Thu Feb 6 01:52:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 17:52:47 -0800 Subject: [Patches] [ python-Patches-558544 ] cmd.py: add instance-specific stdin/out Message-ID: Patches item #558544, was opened at 2002-05-21 15:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=558544&group_id=5470 >Category: Library (Lib) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Anthony Baxter (anthonybaxter) Summary: cmd.py: add instance-specific stdin/out Initial Comment: The following patch adds stdin, stdout as optional arguments to the cmd.Cmd constructor (defaulting to sys.stdin, sys.stdout), and changes the Cmd methods throughout to use self.stdout.write() and self.stdin.foo for output and input. This allows much greater flexibility for using cmd - for instance, hooking it into a telnet server. And if the response is YAGNI, well, actually, IAGNI, because it's in use today (and for the last year). :) If this is acceptable, I'll provide a documentation patch as well. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-02-06 12:52 Message: Logged In: YES user_id=29957 Checking in Lib/cmd.py; /cvsroot/python/python/dist/src/Lib/cmd.py,v <-- cmd.py new revision: 1.35; previous revision: 1.34 done Checking in Doc/lib/libcmd.tex; /cvsroot/python/python/dist/src/Doc/lib/libcmd.tex,v <-- libcmd.tex new revision: 1.13; previous revision: 1.12 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-06 23:03 Message: Logged In: YES user_id=6380 OK, go ahead and check it in then. (Modulo the warnings below.) ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-06-06 17:08 Message: Logged In: YES user_id=29957 reverse diff - oops. The str(line) repr(line) bit is because when hooking it into telnet, sometimes you get wierd control characters at the start. The str/repr is so that you can actually read the line. I'll kill the str() bit. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-06 11:37 Message: Logged In: YES user_id=6380 +1. But before you check it in, watch out -- looks like the patch is older than current CVS, and it is missing a number of improvements that Raymond Hettinger checked in. Hm, what's this? self.stdout.write('*** Unknown syntax: %s (%s)\n'%(str(line),repr(line))) Why write the contents of the line twice? It also looks like the patch is a reverse diff. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-06-06 11:20 Message: Logged In: YES user_id=29957 damn. here's patch ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-02 22:45 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=558544&group_id=5470 From noreply@sourceforge.net Wed Feb 5 15:13:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 07:13:35 -0800 Subject: [Patches] [ python-Patches-676835 ] Cygwin _tkinter Tcl/Tk 8.4 patch Message-ID: Patches item #676835, was opened at 2003-01-29 06:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676835&group_id=5470 Category: Distutils and setup.py Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: Cygwin _tkinter Tcl/Tk 8.4 patch Initial Comment: The (to be) attached patch enables Cygwin Python to build _tkinter against Tcl/Tk 8.4. Note that this patch just reverts the lib_prefix (i.e., "cyg") portion of my Tcl/Tk 8.3 patch. It seems that Cygwin Tcl/Tk is using a more normal file naming convention again. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-02-05 06:13 Message: Logged In: YES user_id=86216 Checked in as setup.py 1.142. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 17:56 Message: Logged In: YES user_id=33168 Looks fine to me. I finally submitted a bug report to SF. http://sf.net/tracker/?func=detail&atid=200001&aid=675910&group_id=1 ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-01-29 06:25 Message: Logged In: YES user_id=86216 Attaching patch to workaround (still?) broken SF. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676835&group_id=5470 From noreply@sourceforge.net Thu Feb 6 06:23:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 22:23:55 -0800 Subject: [Patches] [ python-Patches-681496 ] later setuid, accept dashes Message-ID: Patches item #681496, was opened at 2003-02-05 22:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681496&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: larry tjoelker (ltjoelker) Assigned to: Nobody/Anonymous (nobody) Summary: later setuid, accept dashes Initial Comment: Moves setuid code from main to a function call in SMTPserver. Also allows dashes in Mailman listnames for MailmanProxy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681496&group_id=5470 From noreply@sourceforge.net Thu Feb 6 06:28:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 22:28:44 -0800 Subject: [Patches] [ python-Patches-681496 ] later setuid, accept dashes Message-ID: Patches item #681496, was opened at 2003-02-05 22:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681496&group_id=5470 Category: Library (Lib) Group: Python 2.2.x >Status: Pending >Resolution: Works For Me >Priority: 2 Submitted By: larry tjoelker (ltjoelker) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: later setuid, accept dashes Initial Comment: Moves setuid code from main to a function call in SMTPserver. Also allows dashes in Mailman listnames for MailmanProxy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681496&group_id=5470 From noreply@sourceforge.net Thu Feb 6 06:46:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 22:46:55 -0800 Subject: [Patches] [ python-Patches-681504 ] using gcc on cygwin for config Message-ID: Patches item #681504, was opened at 2003-02-06 15:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681504&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Nobody/Anonymous (nobody) Summary: using gcc on cygwin for config Initial Comment: On Cygwin, I noticed that distutils tries to use the cc compiler instead of the gcc compiler for the config step, resulting in an error. Instead, for the build step the correct compiler (gcc) is being used. For the build step, build_clib.py and build_ext.py contain a call to customize_compiler after the call to new_compiler. The call to customize_compiler causes gcc to be used on cygwin. In config.py, however, this call to customize_compiler after the call to new_compiler is missing. Adding the call to customize_compiler after the call to new_compiler in config.py solves this problem, and the config step then runs correctly on Cygwin. BTW, I noticed that in version 1.44.6.3 of sysconfig.py in CVS, the function get_python_version is missing, causing errors in the build step. This is the latest committed version of sysconfig.py. So I used version 1.56 instead (which was committed earlier than 1.44.6.3, but has a higher version number ??). Michiel de Hoon University of Tokyo, Human Genome Center ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681504&group_id=5470 From noreply@sourceforge.net Thu Feb 6 07:00:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 23:00:18 -0800 Subject: [Patches] [ python-Patches-681496 ] later setuid, accept dashes Message-ID: Patches item #681496, was opened at 2003-02-05 22:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681496&group_id=5470 Category: Library (Lib) Group: Python 2.2.x >Status: Deleted >Resolution: Invalid Priority: 2 Submitted By: larry tjoelker (ltjoelker) Assigned to: Barry A. Warsaw (bwarsaw) Summary: later setuid, accept dashes Initial Comment: Moves setuid code from main to a function call in SMTPserver. Also allows dashes in Mailman listnames for MailmanProxy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681496&group_id=5470 From noreply@sourceforge.net Thu Feb 6 07:24:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 23:24:00 -0800 Subject: [Patches] [ python-Patches-681515 ] move setuid, allow dashes Message-ID: Patches item #681515, was opened at 2003-02-05 23:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681515&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: larry tjoelker (ltjoelker) Assigned to: Nobody/Anonymous (nobody) Summary: move setuid, allow dashes Initial Comment: Add user option for mail user other than nobody. Move setuid code from main to SMTPserver class def. Allow dashes ('-') in MailmanProxy class def. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681515&group_id=5470 From noreply@sourceforge.net Thu Feb 6 07:26:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Feb 2003 23:26:22 -0800 Subject: [Patches] [ python-Patches-681515 ] move setuid, allow dashes Message-ID: Patches item #681515, was opened at 2003-02-05 23:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681515&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: larry tjoelker (ltjoelker) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: move setuid, allow dashes Initial Comment: Add user option for mail user other than nobody. Move setuid code from main to SMTPserver class def. Allow dashes ('-') in MailmanProxy class def. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681515&group_id=5470 From noreply@sourceforge.net Thu Feb 6 15:20:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Feb 2003 07:20:53 -0800 Subject: [Patches] [ python-Patches-681515 ] smtpd.py move setuid, allow dashes Message-ID: Patches item #681515, was opened at 2003-02-06 02:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681515&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: larry tjoelker (ltjoelker) Assigned to: Barry A. Warsaw (bwarsaw) >Summary: smtpd.py move setuid, allow dashes Initial Comment: Add user option for mail user other than nobody. Move setuid code from main to SMTPserver class def. Allow dashes ('-') in MailmanProxy class def. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-02-06 10:20 Message: Logged In: YES user_id=12800 updated summary ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681515&group_id=5470 From noreply@sourceforge.net Thu Feb 6 15:22:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Feb 2003 07:22:21 -0800 Subject: [Patches] [ python-Patches-681496 ] later setuid, accept dashes Message-ID: Patches item #681496, was opened at 2003-02-06 01:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681496&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Deleted Resolution: Invalid Priority: 2 Submitted By: larry tjoelker (ltjoelker) Assigned to: Barry A. Warsaw (bwarsaw) Summary: later setuid, accept dashes Initial Comment: Moves setuid code from main to a function call in SMTPserver. Also allows dashes in Mailman listnames for MailmanProxy. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-02-06 10:22 Message: Logged In: YES user_id=12800 See patch #681515 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681496&group_id=5470 From noreply@sourceforge.net Thu Feb 6 17:03:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Feb 2003 09:03:54 -0800 Subject: [Patches] [ python-Patches-681780 ] Faster commonprefix (OS independent) Message-ID: Patches item #681780, was opened at 2003-02-06 19:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681780&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: Faster commonprefix (OS independent) Initial Comment: This routine is about 20% faster on a test set of 7 sets of strings run 100000 times each (I can provide the test if requested). The longer the common prefix is, the faster the routine becomes relative to original commonprefix. My only worry is that it might get rejected if it is considered too fancy; therefore I wasn't shy on commenting. I think we should also write a commonpathprefix, that will do what commonprefix should do, being in the *path.py module. I'll do that if none other does. The provided patch is for posixpath.py and ntpath.py, but since it's OS neutral it should work as is. It uses itertools for speed, though, so it is not backportable, but it can be if requested by substituting map for imap and a normal slice for islice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681780&group_id=5470 From noreply@sourceforge.net Thu Feb 6 17:04:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Feb 2003 09:04:42 -0800 Subject: [Patches] [ python-Patches-681780 ] Faster commonprefix (OS independent) Message-ID: Patches item #681780, was opened at 2003-02-06 19:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681780&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: Faster commonprefix (OS independent) Initial Comment: This routine is about 20% faster on a test set of 7 sets of strings run 100000 times each (I can provide the test if requested). The longer the common prefix is, the faster the routine becomes relative to original commonprefix. My only worry is that it might get rejected if it is considered too fancy; therefore I wasn't shy on commenting. I think we should also write a commonpathprefix, that will do what commonprefix should do, being in the *path.py module. I'll do that if none other does. The provided patch is for posixpath.py and ntpath.py, but since it's OS neutral it should work as is. It uses itertools for speed, though, so it is not backportable, but it can be if requested by substituting map for imap and a normal slice for islice. ---------------------------------------------------------------------- >Comment By: Christos Georgiou (tzot) Date: 2003-02-06 19:04 Message: Logged In: YES user_id=539787 For some reason, my IE never uploads the file on the first attempt. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681780&group_id=5470 From noreply@sourceforge.net Thu Feb 6 17:25:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Feb 2003 09:25:12 -0800 Subject: [Patches] [ python-Patches-681780 ] Faster commonprefix (OS independent) Message-ID: Patches item #681780, was opened at 2003-02-06 12:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681780&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: Faster commonprefix (OS independent) Initial Comment: This routine is about 20% faster on a test set of 7 sets of strings run 100000 times each (I can provide the test if requested). The longer the common prefix is, the faster the routine becomes relative to original commonprefix. My only worry is that it might get rejected if it is considered too fancy; therefore I wasn't shy on commenting. I think we should also write a commonpathprefix, that will do what commonprefix should do, being in the *path.py module. I'll do that if none other does. The provided patch is for posixpath.py and ntpath.py, but since it's OS neutral it should work as is. It uses itertools for speed, though, so it is not backportable, but it can be if requested by substituting map for imap and a normal slice for islice. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-06 12:25 Message: Logged In: YES user_id=33168 As much as I'd like to blame IE, it's a SF bug AFAIK. http://sf.net/tracker/?func=detail&atid=200001&aid=675910&group_id=1 ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-06 12:04 Message: Logged In: YES user_id=539787 For some reason, my IE never uploads the file on the first attempt. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681780&group_id=5470 From noreply@sourceforge.net Thu Feb 6 18:02:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Feb 2003 10:02:08 -0800 Subject: [Patches] [ python-Patches-681780 ] Faster commonprefix (OS independent) Message-ID: Patches item #681780, was opened at 2003-02-06 19:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681780&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: Faster commonprefix (OS independent) Initial Comment: This routine is about 20% faster on a test set of 7 sets of strings run 100000 times each (I can provide the test if requested). The longer the common prefix is, the faster the routine becomes relative to original commonprefix. My only worry is that it might get rejected if it is considered too fancy; therefore I wasn't shy on commenting. I think we should also write a commonpathprefix, that will do what commonprefix should do, being in the *path.py module. I'll do that if none other does. The provided patch is for posixpath.py and ntpath.py, but since it's OS neutral it should work as is. It uses itertools for speed, though, so it is not backportable, but it can be if requested by substituting map for imap and a normal slice for islice. ---------------------------------------------------------------------- >Comment By: Christos Georgiou (tzot) Date: 2003-02-06 20:02 Message: Logged In: YES user_id=539787 Best case: comparing this to the old version with a list: ['/usr/local/lib/python2.3/posixpath.py']*120, 10000 iterations, the speed difference is: old: 319.58 sec new: 34.43 sec Since prefix_len always grows in the "while next_bit:" loop, applying commonprefix2.diff to the *patched* version does a very minor speedup (comparing smaller buffers in every iteration); but it is only a matter of overoptimisation (ie it does not hurt, but it's a trivial one, just 0.1%). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-06 19:25 Message: Logged In: YES user_id=33168 As much as I'd like to blame IE, it's a SF bug AFAIK. http://sf.net/tracker/?func=detail&atid=200001&aid=675910&group_id=1 ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-06 19:04 Message: Logged In: YES user_id=539787 For some reason, my IE never uploads the file on the first attempt. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681780&group_id=5470 From noreply@sourceforge.net Thu Feb 6 21:07:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Feb 2003 13:07:57 -0800 Subject: [Patches] [ python-Patches-681927 ] bundlebuilder: Add dylibs, frameworks to the bundle Message-ID: Patches item #681927, was opened at 2003-02-06 13:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681927&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Jack Jansen (jackjansen) Summary: bundlebuilder: Add dylibs, frameworks to the bundle Initial Comment: This patch adds the ability to specify that shared libraries and Frameworks (the last is untested as of yet) to the bundle. It is mostly by Kevin Olliver with some suggestions by me. In addition to copying the files into the bundle the launcher script in the bundle is modified to set the DYLD_LIBRARY_PATH to the right place. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681927&group_id=5470 From noreply@sourceforge.net Thu Feb 6 21:39:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Feb 2003 13:39:05 -0800 Subject: [Patches] [ python-Patches-681927 ] bundlebuilder: Add dylibs, frameworks to the bundle Message-ID: Patches item #681927, was opened at 2003-02-06 22:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681927&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robin Dunn (robind) >Assigned to: Just van Rossum (jvr) Summary: bundlebuilder: Add dylibs, frameworks to the bundle Initial Comment: This patch adds the ability to specify that shared libraries and Frameworks (the last is untested as of yet) to the bundle. It is mostly by Kevin Olliver with some suggestions by me. In addition to copying the files into the bundle the launcher script in the bundle is modified to set the DYLD_LIBRARY_PATH to the right place. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681927&group_id=5470 From noreply@sourceforge.net Thu Feb 6 22:35:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Feb 2003 14:35:24 -0800 Subject: [Patches] [ python-Patches-681927 ] bundlebuilder: Add dylibs, frameworks to the bundle Message-ID: Patches item #681927, was opened at 2003-02-06 22:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681927&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Just van Rossum (jvr) Summary: bundlebuilder: Add dylibs, frameworks to the bundle Initial Comment: This patch adds the ability to specify that shared libraries and Frameworks (the last is untested as of yet) to the bundle. It is mostly by Kevin Olliver with some suggestions by me. In addition to copying the files into the bundle the launcher script in the bundle is modified to set the DYLD_LIBRARY_PATH to the right place. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-02-06 23:35 Message: Logged In: YES user_id=92689 Cool. There's a problem with the patch, though: although I apologize for using tabs to begin with, please keep the tab usage consistent. There are quite a few hunks in the patch that only touch whitespace and that's both undesirable as well as blurring the intent of the patch... Could you upload a cleaner one? Btw. for the --standalone build mode it would be possible to calculate all framework/dylib dependencies with the otool tool. If this were implemented perhaps the --lib option wouldn't even be needed? Another question remains: if we include a framework, is there a way to strip it from redunant files, eg. headers? If we would use this mechanism to include Python.framework we would definitely need a way to trim it down, eg. all of lib is taken care of by modulefinder anyway. If you (or Kevin) have any ideas about that, pls contact me off line. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681927&group_id=5470 From noreply@sourceforge.net Thu Feb 6 23:20:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Feb 2003 15:20:32 -0800 Subject: [Patches] [ python-Patches-681927 ] bundlebuilder: Add dylibs, frameworks to the bundle Message-ID: Patches item #681927, was opened at 2003-02-06 13:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681927&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Just van Rossum (jvr) Summary: bundlebuilder: Add dylibs, frameworks to the bundle Initial Comment: This patch adds the ability to specify that shared libraries and Frameworks (the last is untested as of yet) to the bundle. It is mostly by Kevin Olliver with some suggestions by me. In addition to copying the files into the bundle the launcher script in the bundle is modified to set the DYLD_LIBRARY_PATH to the right place. ---------------------------------------------------------------------- >Comment By: Robin Dunn (robind) Date: 2003-02-06 15:20 Message: Logged In: YES user_id=53955 Oops, sorry for the witespace patches. I noticed that my lines used spaces but the lines around them were using tabs so I just ran a tabify on the whole file without taking another look at the resulting patch file after that. Looks like some of other lines that wre added since 2.3a1 have spaces too and that is where the problem comes from. I'll redo the patch but the whole file should probably be either tabified or untabified after you are done applying it. I didn't know about otool. I'll pass that on to Kevin. We discussed about doing automatic finding of libs but didn't know how to go about it so thought that this would be a good start. Also we figured that even if there was a way to do it that you would probably want a way to inlcude other files that may not get automatically found, or to exclude some that were, so there should be command line options for it anyway. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-06 14:35 Message: Logged In: YES user_id=92689 Cool. There's a problem with the patch, though: although I apologize for using tabs to begin with, please keep the tab usage consistent. There are quite a few hunks in the patch that only touch whitespace and that's both undesirable as well as blurring the intent of the patch... Could you upload a cleaner one? Btw. for the --standalone build mode it would be possible to calculate all framework/dylib dependencies with the otool tool. If this were implemented perhaps the --lib option wouldn't even be needed? Another question remains: if we include a framework, is there a way to strip it from redunant files, eg. headers? If we would use this mechanism to include Python.framework we would definitely need a way to trim it down, eg. all of lib is taken care of by modulefinder anyway. If you (or Kevin) have any ideas about that, pls contact me off line. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681927&group_id=5470 From noreply@sourceforge.net Fri Feb 7 05:58:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Feb 2003 21:58:46 -0800 Subject: [Patches] [ python-Patches-677887 ] Add traceback.format_exc Message-ID: Patches item #677887, was opened at 2003-01-30 20:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677887&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 4 Submitted By: Neil Schemenauer (nascheme) Assigned to: Raymond Hettinger (rhettinger) Summary: Add traceback.format_exc Initial Comment: I sometimes end up wanting this function. I think it compliments print_exc() nicely. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-07 00:58 Message: Logged In: YES user_id=80475 Did you intend to assign this one to me? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677887&group_id=5470 From noreply@sourceforge.net Fri Feb 7 08:59:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Feb 2003 00:59:05 -0800 Subject: [Patches] [ python-Patches-681927 ] bundlebuilder: Add dylibs, frameworks to the bundle Message-ID: Patches item #681927, was opened at 2003-02-06 22:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681927&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Just van Rossum (jvr) Summary: bundlebuilder: Add dylibs, frameworks to the bundle Initial Comment: This patch adds the ability to specify that shared libraries and Frameworks (the last is untested as of yet) to the bundle. It is mostly by Kevin Olliver with some suggestions by me. In addition to copying the files into the bundle the launcher script in the bundle is modified to set the DYLD_LIBRARY_PATH to the right place. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-02-07 09:59 Message: Logged In: YES user_id=92689 I use tabs for indentation and use spaces for alignment... So things look nice _and_ wont screw up with different tab settings. But I admit that using such a non-standard way is asking for trouble. I'll convert to spaces after this patch has been done (unless you prefer I do it _before_ ;-). (Btw. it might be that otool is only available with the apple dev tools, which would be a shame since we otherwise don't depend in dev tools being available. Hm.) ---------------------------------------------------------------------- Comment By: Robin Dunn (robind) Date: 2003-02-07 00:20 Message: Logged In: YES user_id=53955 Oops, sorry for the witespace patches. I noticed that my lines used spaces but the lines around them were using tabs so I just ran a tabify on the whole file without taking another look at the resulting patch file after that. Looks like some of other lines that wre added since 2.3a1 have spaces too and that is where the problem comes from. I'll redo the patch but the whole file should probably be either tabified or untabified after you are done applying it. I didn't know about otool. I'll pass that on to Kevin. We discussed about doing automatic finding of libs but didn't know how to go about it so thought that this would be a good start. Also we figured that even if there was a way to do it that you would probably want a way to inlcude other files that may not get automatically found, or to exclude some that were, so there should be command line options for it anyway. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-06 23:35 Message: Logged In: YES user_id=92689 Cool. There's a problem with the patch, though: although I apologize for using tabs to begin with, please keep the tab usage consistent. There are quite a few hunks in the patch that only touch whitespace and that's both undesirable as well as blurring the intent of the patch... Could you upload a cleaner one? Btw. for the --standalone build mode it would be possible to calculate all framework/dylib dependencies with the otool tool. If this were implemented perhaps the --lib option wouldn't even be needed? Another question remains: if we include a framework, is there a way to strip it from redunant files, eg. headers? If we would use this mechanism to include Python.framework we would definitely need a way to trim it down, eg. all of lib is taken care of by modulefinder anyway. If you (or Kevin) have any ideas about that, pls contact me off line. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681927&group_id=5470 From noreply@sourceforge.net Fri Feb 7 11:11:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Feb 2003 03:11:09 -0800 Subject: [Patches] [ python-Patches-681780 ] Faster commonprefix (OS independent) Message-ID: Patches item #681780, was opened at 2003-02-06 19:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681780&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: Faster commonprefix (OS independent) Initial Comment: This routine is about 20% faster on a test set of 7 sets of strings run 100000 times each (I can provide the test if requested). The longer the common prefix is, the faster the routine becomes relative to original commonprefix. My only worry is that it might get rejected if it is considered too fancy; therefore I wasn't shy on commenting. I think we should also write a commonpathprefix, that will do what commonprefix should do, being in the *path.py module. I'll do that if none other does. The provided patch is for posixpath.py and ntpath.py, but since it's OS neutral it should work as is. It uses itertools for speed, though, so it is not backportable, but it can be if requested by substituting map for imap and a normal slice for islice. ---------------------------------------------------------------------- >Comment By: Christos Georgiou (tzot) Date: 2003-02-07 13:11 Message: Logged In: YES user_id=539787 I did my homework better, and found out that the buffer object quite probably will be deprecated. So I rewrote the routine without the buffer object (using str.startswith), which by the way got another 10% speedup (relative to the latest version using buffer.) The commonprefix_nobuf.diff patch applies directly to the original posixpath.py, ntpath.py. I will try to delete the other patches, but I don't think I am allowed to do it. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-06 20:02 Message: Logged In: YES user_id=539787 Best case: comparing this to the old version with a list: ['/usr/local/lib/python2.3/posixpath.py']*120, 10000 iterations, the speed difference is: old: 319.58 sec new: 34.43 sec Since prefix_len always grows in the "while next_bit:" loop, applying commonprefix2.diff to the *patched* version does a very minor speedup (comparing smaller buffers in every iteration); but it is only a matter of overoptimisation (ie it does not hurt, but it's a trivial one, just 0.1%). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-06 19:25 Message: Logged In: YES user_id=33168 As much as I'd like to blame IE, it's a SF bug AFAIK. http://sf.net/tracker/?func=detail&atid=200001&aid=675910&group_id=1 ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-06 19:04 Message: Logged In: YES user_id=539787 For some reason, my IE never uploads the file on the first attempt. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681780&group_id=5470 From noreply@sourceforge.net Fri Feb 7 16:51:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Feb 2003 08:51:45 -0800 Subject: [Patches] [ python-Patches-682420 ] new dictionary method: pop() Message-ID: Patches item #682420, was opened at 2003-02-07 17:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=682420&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Michal Vitecek (fufsource) Assigned to: Nobody/Anonymous (nobody) Summary: new dictionary method: pop() Initial Comment: the attached patch (against vanilla 2.2.2) adds a new method (pop()) to the builtin dictionary. the method simply returns the value stored at the specified key and removes the pair from the dictionary, ie: >>> a = {10:12, 6:8} >>> a.pop(10) 12 >>> a {6: 8} i think it's useful because a) the same method exists for lists, b) one doesn't have to always write 'v = a[10]; del a[10]' which requires two lookups. i can make a patch for 2.3.x as well if anyone's interested. thank you for consideration. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=682420&group_id=5470 From noreply@sourceforge.net Fri Feb 7 17:08:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Feb 2003 09:08:14 -0800 Subject: [Patches] [ python-Patches-682432 ] lookbehind tests Message-ID: Patches item #682432, was opened at 2003-02-07 18:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=682432&group_id=5470 Category: Tests Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: engelbert gruber (grubert) Assigned to: Nobody/Anonymous (nobody) Summary: lookbehind tests Initial Comment: there were none in re_test.py (just in case upload does not work) *** re_tests.py Fri Feb 7 17:46:50 2003 --- new_test/re_tests.py Fri Feb 7 17:49:03 2003 *************** *** 548,553 **** --- 548,560 ---- ('a(?:b|(c|e){1,2}?|d)+?(.)', 'ace', SUCCEED, 'g1 + g2', 'ce'), ('^(.+)?B', 'AB', SUCCEED, 'g1', 'A'), + # lookbehind: split by : but not if it is escaped by -. + ('(? Patches item #682420, was opened at 2003-02-07 11:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=682420&group_id=5470 Category: Library (Lib) Group: Python 2.2.x >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Michal Vitecek (fufsource) >Assigned to: Neal Norwitz (nnorwitz) Summary: new dictionary method: pop() Initial Comment: the attached patch (against vanilla 2.2.2) adds a new method (pop()) to the builtin dictionary. the method simply returns the value stored at the specified key and removes the pair from the dictionary, ie: >>> a = {10:12, 6:8} >>> a.pop(10) 12 >>> a {6: 8} i think it's useful because a) the same method exists for lists, b) one doesn't have to always write 'v = a[10]; del a[10]' which requires two lookups. i can make a patch for 2.3.x as well if anyone's interested. thank you for consideration. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-07 12:08 Message: Logged In: YES user_id=33168 This has already been implemented for 2.3 and is in 2.3a1. It cannot be backported to 2.2.x because it would be a new feature which are prohibited in bug fix releases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=682420&group_id=5470 From noreply@sourceforge.net Fri Feb 7 19:29:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Feb 2003 11:29:40 -0800 Subject: [Patches] [ python-Patches-682514 ] mmapmodule.c write fix for LP64 executables Message-ID: Patches item #682514, was opened at 2003-02-07 14:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=682514&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robert Ledwith (rledwith) Assigned to: Nobody/Anonymous (nobody) Summary: mmapmodule.c write fix for LP64 executables Initial Comment: mmap.write will not work correctly in LP64 executables. Python's "mmap.write(string)" will fail on any platform where in C: "sizeof(int) != sizeof(long)". The problem is that mmap_write_method defines "length" as a "long", but then calls "PyArg_ParseTuple (args, "s#:write", &data, &length)" The called function expects that the fourth argument is to be the address of an "int", not a "long". While on ILP32 (integers-longs-pointers are 32 bits) platforms this works correctly, on LP64 (longs-pointers are 64 bits) platforms, only 32 bits of the variable are set. The other 32 bits contain trash. Defining the variable as an "int" fixes the problem for all platforms. I reviewed the Python 2.3a1 source distribution and found only this single instance of misusing a long when call "PyArg_ParseTuple". The patch is a context diff using CVS revision 2.42 of mmapmodule.c, which is the current version as of Feb 7, 2003. I believe that this should also be back-ported to 2.2 if another bug fix 2.2 release is made. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=682514&group_id=5470 From noreply@sourceforge.net Fri Feb 7 19:32:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Feb 2003 11:32:40 -0800 Subject: [Patches] [ python-Patches-682514 ] mmapmodule.c write fix for LP64 executables Message-ID: Patches item #682514, was opened at 2003-02-07 14:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=682514&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robert Ledwith (rledwith) Assigned to: Nobody/Anonymous (nobody) Summary: mmapmodule.c write fix for LP64 executables Initial Comment: mmap.write will not work correctly in LP64 executables. Python's "mmap.write(string)" will fail on any platform where in C: "sizeof(int) != sizeof(long)". The problem is that mmap_write_method defines "length" as a "long", but then calls "PyArg_ParseTuple (args, "s#:write", &data, &length)" The called function expects that the fourth argument is to be the address of an "int", not a "long". While on ILP32 (integers-longs-pointers are 32 bits) platforms this works correctly, on LP64 (longs-pointers are 64 bits) platforms, only 32 bits of the variable are set. The other 32 bits contain trash. Defining the variable as an "int" fixes the problem for all platforms. I reviewed the Python 2.3a1 source distribution and found only this single instance of misusing a long when call "PyArg_ParseTuple". The patch is a context diff using CVS revision 2.42 of mmapmodule.c, which is the current version as of Feb 7, 2003. I believe that this should also be back-ported to 2.2 if another bug fix 2.2 release is made. ---------------------------------------------------------------------- Comment By: Robert Ledwith (rledwith) Date: 2003-02-07 14:32 Message: Logged In: YES user_id=707099 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=682514&group_id=5470 From noreply@sourceforge.net Fri Feb 7 19:53:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Feb 2003 11:53:18 -0800 Subject: [Patches] [ python-Patches-682514 ] mmapmodule.c write fix for LP64 executables Message-ID: Patches item #682514, was opened at 2003-02-07 14:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=682514&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Robert Ledwith (rledwith) >Assigned to: Neal Norwitz (nnorwitz) Summary: mmapmodule.c write fix for LP64 executables Initial Comment: mmap.write will not work correctly in LP64 executables. Python's "mmap.write(string)" will fail on any platform where in C: "sizeof(int) != sizeof(long)". The problem is that mmap_write_method defines "length" as a "long", but then calls "PyArg_ParseTuple (args, "s#:write", &data, &length)" The called function expects that the fourth argument is to be the address of an "int", not a "long". While on ILP32 (integers-longs-pointers are 32 bits) platforms this works correctly, on LP64 (longs-pointers are 64 bits) platforms, only 32 bits of the variable are set. The other 32 bits contain trash. Defining the variable as an "int" fixes the problem for all platforms. I reviewed the Python 2.3a1 source distribution and found only this single instance of misusing a long when call "PyArg_ParseTuple". The patch is a context diff using CVS revision 2.42 of mmapmodule.c, which is the current version as of Feb 7, 2003. I believe that this should also be back-ported to 2.2 if another bug fix 2.2 release is made. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-07 14:53 Message: Logged In: YES user_id=33168 Thanks! Checked in as: * Modules/mmapmodule.c 2.43 and 2.35.6.5 ---------------------------------------------------------------------- Comment By: Robert Ledwith (rledwith) Date: 2003-02-07 14:32 Message: Logged In: YES user_id=707099 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=682514&group_id=5470 From noreply@sourceforge.net Fri Feb 7 20:52:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Feb 2003 12:52:58 -0800 Subject: [Patches] [ python-Patches-681927 ] bundlebuilder: Add dylibs, frameworks to the bundle Message-ID: Patches item #681927, was opened at 2003-02-06 16:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681927&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Just van Rossum (jvr) Summary: bundlebuilder: Add dylibs, frameworks to the bundle Initial Comment: This patch adds the ability to specify that shared libraries and Frameworks (the last is untested as of yet) to the bundle. It is mostly by Kevin Olliver with some suggestions by me. In addition to copying the files into the bundle the launcher script in the bundle is modified to set the DYLD_LIBRARY_PATH to the right place. ---------------------------------------------------------------------- Comment By: Kevin Ollivier (kollivier) Date: 2003-02-07 15:52 Message: Logged In: YES user_id=248468 I'll take a look at otool and see if it does what we need. As Robin mentioned, I think giving both the manual and auto options is the best approach. I'll also check into the dependency on Apple's Dev Tools, but even if it is dependent we could just switch off auto-detection if users don't have it and spit out a warning. Another possible way to alleviate this problem may be to integrate with distutils. (i.e. make a 'buildbundle' option) That should at least allow us to find and include any libraries the developer linked against. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-07 03:59 Message: Logged In: YES user_id=92689 I use tabs for indentation and use spaces for alignment... So things look nice _and_ wont screw up with different tab settings. But I admit that using such a non-standard way is asking for trouble. I'll convert to spaces after this patch has been done (unless you prefer I do it _before_ ;-). (Btw. it might be that otool is only available with the apple dev tools, which would be a shame since we otherwise don't depend in dev tools being available. Hm.) ---------------------------------------------------------------------- Comment By: Robin Dunn (robind) Date: 2003-02-06 18:20 Message: Logged In: YES user_id=53955 Oops, sorry for the witespace patches. I noticed that my lines used spaces but the lines around them were using tabs so I just ran a tabify on the whole file without taking another look at the resulting patch file after that. Looks like some of other lines that wre added since 2.3a1 have spaces too and that is where the problem comes from. I'll redo the patch but the whole file should probably be either tabified or untabified after you are done applying it. I didn't know about otool. I'll pass that on to Kevin. We discussed about doing automatic finding of libs but didn't know how to go about it so thought that this would be a good start. Also we figured that even if there was a way to do it that you would probably want a way to inlcude other files that may not get automatically found, or to exclude some that were, so there should be command line options for it anyway. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-06 17:35 Message: Logged In: YES user_id=92689 Cool. There's a problem with the patch, though: although I apologize for using tabs to begin with, please keep the tab usage consistent. There are quite a few hunks in the patch that only touch whitespace and that's both undesirable as well as blurring the intent of the patch... Could you upload a cleaner one? Btw. for the --standalone build mode it would be possible to calculate all framework/dylib dependencies with the otool tool. If this were implemented perhaps the --lib option wouldn't even be needed? Another question remains: if we include a framework, is there a way to strip it from redunant files, eg. headers? If we would use this mechanism to include Python.framework we would definitely need a way to trim it down, eg. all of lib is taken care of by modulefinder anyway. If you (or Kevin) have any ideas about that, pls contact me off line. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681927&group_id=5470 From noreply@sourceforge.net Fri Feb 7 22:55:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Feb 2003 14:55:41 -0800 Subject: [Patches] [ python-Patches-681504 ] using gcc on cygwin for config Message-ID: Patches item #681504, was opened at 2003-02-06 01:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681504&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) >Assigned to: Jason Tishler (jlt63) Summary: using gcc on cygwin for config Initial Comment: On Cygwin, I noticed that distutils tries to use the cc compiler instead of the gcc compiler for the config step, resulting in an error. Instead, for the build step the correct compiler (gcc) is being used. For the build step, build_clib.py and build_ext.py contain a call to customize_compiler after the call to new_compiler. The call to customize_compiler causes gcc to be used on cygwin. In config.py, however, this call to customize_compiler after the call to new_compiler is missing. Adding the call to customize_compiler after the call to new_compiler in config.py solves this problem, and the config step then runs correctly on Cygwin. BTW, I noticed that in version 1.44.6.3 of sysconfig.py in CVS, the function get_python_version is missing, causing errors in the build step. This is the latest committed version of sysconfig.py. So I used version 1.56 instead (which was committed earlier than 1.44.6.3, but has a higher version number ??). Michiel de Hoon University of Tokyo, Human Genome Center ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-07 17:55 Message: Logged In: YES user_id=33168 Jason, can you provide any input about the issues w/Cygwin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681504&group_id=5470 From noreply@sourceforge.net Sat Feb 8 07:39:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Feb 2003 23:39:30 -0800 Subject: [Patches] [ python-Patches-677887 ] Add traceback.format_exc Message-ID: Patches item #677887, was opened at 2003-01-31 01:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677887&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 4 Submitted By: Neil Schemenauer (nascheme) Assigned to: Raymond Hettinger (rhettinger) Summary: Add traceback.format_exc Initial Comment: I sometimes end up wanting this function. I think it compliments print_exc() nicely. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2003-02-08 07:39 Message: Logged In: YES user_id=35752 Yes, feel free to reassign. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-07 05:58 Message: Logged In: YES user_id=80475 Did you intend to assign this one to me? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677887&group_id=5470 From noreply@sourceforge.net Sat Feb 8 14:32:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 08 Feb 2003 06:32:14 -0800 Subject: [Patches] [ python-Patches-680474 ] Fix for the bug #679880: 'compile' refuses BOM. Message-ID: Patches item #680474, was opened at 2003-02-04 22:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680474&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kirill Simonov (kirill_simonov) Assigned to: M.-A. Lemburg (lemburg) Summary: Fix for the bug #679880: 'compile' refuses BOM. Initial Comment: This is a signed char issue. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-08 15:32 Message: Logged In: YES user_id=38388 Could you also provide a few (unit-)tests for this ? Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 22:23 Message: Logged In: YES user_id=33168 The patch is small (2 lines) and seems ok. MAL, if you can review and it makes sense, I'll test & checkin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680474&group_id=5470 From noreply@sourceforge.net Sat Feb 8 16:04:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 08 Feb 2003 08:04:30 -0800 Subject: [Patches] [ python-Patches-680474 ] Fix for the bug #679880: 'compile' refuses BOM. Message-ID: Patches item #680474, was opened at 2003-02-04 21:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680474&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kirill Simonov (kirill_simonov) Assigned to: M.-A. Lemburg (lemburg) Summary: Fix for the bug #679880: 'compile' refuses BOM. Initial Comment: This is a signed char issue. ---------------------------------------------------------------------- >Comment By: Kirill Simonov (kirill_simonov) Date: 2003-02-08 16:04 Message: Logged In: YES user_id=36553 I have attached a small test that contains two exec's. The first one is for a file object and the second one is for a string. The second exec fails while it shouldn't. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-08 14:32 Message: Logged In: YES user_id=38388 Could you also provide a few (unit-)tests for this ? Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 21:23 Message: Logged In: YES user_id=33168 The patch is small (2 lines) and seems ok. MAL, if you can review and it makes sense, I'll test & checkin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680474&group_id=5470 From noreply@sourceforge.net Sat Feb 8 20:22:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 08 Feb 2003 12:22:51 -0800 Subject: [Patches] [ python-Patches-683074 ] Optional output streams for dis Message-ID: Patches item #683074, was opened at 2003-02-08 14:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683074&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: Optional output streams for dis Initial Comment: Right now the dis module uses print to output. This restricts it's use to interactive. You can't easily route the output to files, webpages, run re's on it, etc. This patch just adds an optional keyword parameter write that defaults to sys.stdout.write and replaces print statments with calls to write. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683074&group_id=5470 From noreply@sourceforge.net Sun Feb 9 00:48:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 08 Feb 2003 16:48:08 -0800 Subject: [Patches] [ python-Patches-683187 ] universal newline problems on error Message-ID: Patches item #683187, was opened at 2003-02-08 19:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683187&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Jack Jansen (jackjansen) Summary: universal newline problems on error Initial Comment: Jack, I think there are 2 problems with the current code in Py_UniversalNewlineFread(). First, the return type is size_t. Since fread() returns 0 on error, this function should also return 0. (That seems to be how the callers expect an error.) Currently it returns -1 if the file object pointer is NULL or not a PyFileObject. Note: there is a return fread(...); if not using universal newlines. Second, (see line 2295) if fread() returns an error, src will contain uninitialized data in the inner while loop which will be accessed. The patch breaks from the outer while loop when fread() returns 0. Do these make sense? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683187&group_id=5470 From noreply@sourceforge.net Sun Feb 9 01:06:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 08 Feb 2003 17:06:48 -0800 Subject: [Patches] [ python-Patches-683187 ] universal newline problems on error Message-ID: Patches item #683187, was opened at 2003-02-09 01:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683187&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Neal Norwitz (nnorwitz) Summary: universal newline problems on error Initial Comment: Jack, I think there are 2 problems with the current code in Py_UniversalNewlineFread(). First, the return type is size_t. Since fread() returns 0 on error, this function should also return 0. (That seems to be how the callers expect an error.) Currently it returns -1 if the file object pointer is NULL or not a PyFileObject. Note: there is a return fread(...); if not using universal newlines. Second, (see line 2295) if fread() returns an error, src will contain uninitialized data in the inner while loop which will be accessed. The patch breaks from the outer while loop when fread() returns 0. Do these make sense? ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-02-09 02:06 Message: Logged In: YES user_id=45365 I haven't tested the patch as my Python is broken right now, but from the description and inspecting the code it makes perfect sense. Go ahead and check it in! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683187&group_id=5470 From noreply@sourceforge.net Sun Feb 9 01:19:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 08 Feb 2003 17:19:17 -0800 Subject: [Patches] [ python-Patches-683187 ] universal newline problems on error Message-ID: Patches item #683187, was opened at 2003-02-08 19:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683187&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: universal newline problems on error Initial Comment: Jack, I think there are 2 problems with the current code in Py_UniversalNewlineFread(). First, the return type is size_t. Since fread() returns 0 on error, this function should also return 0. (That seems to be how the callers expect an error.) Currently it returns -1 if the file object pointer is NULL or not a PyFileObject. Note: there is a return fread(...); if not using universal newlines. Second, (see line 2295) if fread() returns an error, src will contain uninitialized data in the inner while loop which will be accessed. The patch breaks from the outer while loop when fread() returns 0. Do these make sense? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-08 20:19 Message: Logged In: YES user_id=33168 The regression tests passed without errors on Linux, so it must work. :-) Checked in as: Objects/fileobject.c 2.176 ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-08 20:06 Message: Logged In: YES user_id=45365 I haven't tested the patch as my Python is broken right now, but from the description and inspecting the code it makes perfect sense. Go ahead and check it in! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683187&group_id=5470 From noreply@sourceforge.net Sun Feb 9 04:22:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 08 Feb 2003 20:22:26 -0800 Subject: [Patches] [ python-Patches-683257 ] Patch for bug 580952 Message-ID: Patches item #683257, was opened at 2003-02-08 22:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683257&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jason Hildebrand (jdhildeb) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for bug 580952 Initial Comment: See bug 580952 for all the details. I've attached patches against Python 2.3-2.2.99 (it would be great to have this in for 2.3 final), and also against Python 2.2.2 (for the next 2.2.x maintenance release). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683257&group_id=5470 From noreply@sourceforge.net Sun Feb 9 04:27:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 08 Feb 2003 20:27:17 -0800 Subject: [Patches] [ python-Patches-683257 ] Patch for bug 580952: import lock should be exposed Message-ID: Patches item #683257, was opened at 2003-02-08 22:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683257&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jason Hildebrand (jdhildeb) Assigned to: Nobody/Anonymous (nobody) >Summary: Patch for bug 580952: import lock should be exposed Initial Comment: See bug 580952 for all the details. I've attached patches against Python 2.3-2.2.99 (it would be great to have this in for 2.3 final), and also against Python 2.2.2 (for the next 2.2.x maintenance release). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683257&group_id=5470 From noreply@sourceforge.net Sun Feb 9 13:07:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 09 Feb 2003 05:07:07 -0800 Subject: [Patches] [ python-Patches-683376 ] Adding NotImplementedType to types.py Message-ID: Patches item #683376, was opened at 2003-02-09 13:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683376&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Adding NotImplementedType to types.py Initial Comment: This patch adds NotImplementedType to types.py. I don't know why, but it is not included. I found out while testing 'class A(%s): pass' on all types in types.py, and found out NotImplementedType had not been tested. This patch adds the line "NotImplementedType = type(NotImplemented)" to types.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683376&group_id=5470 From noreply@sourceforge.net Sun Feb 9 13:09:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 09 Feb 2003 05:09:47 -0800 Subject: [Patches] [ python-Patches-683376 ] Adding NotImplementedType to types.py Message-ID: Patches item #683376, was opened at 2003-02-09 13:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683376&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None >Priority: 2 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Adding NotImplementedType to types.py Initial Comment: This patch adds NotImplementedType to types.py. I don't know why, but it is not included. I found out while testing 'class A(%s): pass' on all types in types.py, and found out NotImplementedType had not been tested. This patch adds the line "NotImplementedType = type(NotImplemented)" to types.py. ---------------------------------------------------------------------- >Comment By: Gerrit Holl (gerrit) Date: 2003-02-09 13:09 Message: Logged In: YES user_id=13298 OOPS, upload failed! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683376&group_id=5470 From noreply@sourceforge.net Sun Feb 9 13:10:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 09 Feb 2003 05:10:58 -0800 Subject: [Patches] [ python-Patches-683376 ] Adding NotImplementedType to types.py Message-ID: Patches item #683376, was opened at 2003-02-09 13:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683376&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None >Priority: 1 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Adding NotImplementedType to types.py Initial Comment: This patch adds NotImplementedType to types.py. I don't know why, but it is not included. I found out while testing 'class A(%s): pass' on all types in types.py, and found out NotImplementedType had not been tested. This patch adds the line "NotImplementedType = type(NotImplemented)" to types.py. ---------------------------------------------------------------------- Comment By: Gerrit Holl (gerrit) Date: 2003-02-09 13:09 Message: Logged In: YES user_id=13298 OOPS, upload failed! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683376&group_id=5470 From noreply@sourceforge.net Sun Feb 9 19:01:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 09 Feb 2003 11:01:53 -0800 Subject: [Patches] [ python-Patches-683515 ] Add unicode support to compile(), eval() and exec Message-ID: Patches item #683515, was opened at 2003-02-09 20:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683515&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: Add unicode support to compile(), eval() and exec Initial Comment: Attached is a patch that adds "real" unicode support to compile(), eval() and exec. This is done by adding a new PyCompilerFlags flag called PyCF_SOURCE_IS_UTF8. Unicode strings are converted to utf-8 and this flag is set. I've added tests to test_builtin.py for compile and eval, but I don't know how/where to test exec. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683515&group_id=5470 From noreply@sourceforge.net Sun Feb 9 20:47:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 09 Feb 2003 12:47:11 -0800 Subject: [Patches] [ python-Patches-680474 ] Fix for the bug #679880: 'compile' refuses BOM. Message-ID: Patches item #680474, was opened at 2003-02-04 22:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680474&group_id=5470 Category: Parser/Compiler Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Kirill Simonov (kirill_simonov) Assigned to: M.-A. Lemburg (lemburg) Summary: Fix for the bug #679880: 'compile' refuses BOM. Initial Comment: This is a signed char issue. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-02-09 21:47 Message: Logged In: YES user_id=92689 Thanks, I've applied the patch (rev. 2.72 of tokenize.c) and added two little tests to test_builtin.py. ---------------------------------------------------------------------- Comment By: Kirill Simonov (kirill_simonov) Date: 2003-02-08 17:04 Message: Logged In: YES user_id=36553 I have attached a small test that contains two exec's. The first one is for a file object and the second one is for a string. The second exec fails while it shouldn't. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-08 15:32 Message: Logged In: YES user_id=38388 Could you also provide a few (unit-)tests for this ? Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-04 22:23 Message: Logged In: YES user_id=33168 The patch is small (2 lines) and seems ok. MAL, if you can review and it makes sense, I'll test & checkin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680474&group_id=5470 From noreply@sourceforge.net Sun Feb 9 20:56:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 09 Feb 2003 12:56:32 -0800 Subject: [Patches] [ python-Patches-683515 ] Add unicode support to compile(), eval() and exec Message-ID: Patches item #683515, was opened at 2003-02-09 20:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683515&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: Add unicode support to compile(), eval() and exec Initial Comment: Attached is a patch that adds "real" unicode support to compile(), eval() and exec. This is done by adding a new PyCompilerFlags flag called PyCF_SOURCE_IS_UTF8. Unicode strings are converted to utf-8 and this flag is set. I've added tests to test_builtin.py for compile and eval, but I don't know how/where to test exec. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-02-09 21:56 Message: Logged In: YES user_id=92689 Updated the patch for current CVS. (Btw. if it were easy to obtain a utf-8 string with a bom mark, I think that should be preferable to adding the new compile flag. But it's not...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683515&group_id=5470 From noreply@sourceforge.net Sun Feb 9 21:43:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 09 Feb 2003 13:43:09 -0800 Subject: [Patches] [ python-Patches-683592 ] unicode support for os.listdir() Message-ID: Patches item #683592, was opened at 2003-02-09 22:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: unicode support for os.listdir() Initial Comment: The attached patch makes os.listdir() return unicode strings, on plaforms that have Py_FileSystemDefaultEncoding defined as non-NULL. I'm by no means sure this is the right thing to do; it does seem right on OSX where Py_FileSystemDefaultEncoding is (or rather: will be real soon, I'm waiting for Jack's approval) utf-8. I'd be happy to add the code in an OSX-specific switch. A more subtle variant could perhaps only return unicode strings if the file name is not ASCII. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 From noreply@sourceforge.net Mon Feb 10 01:16:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 09 Feb 2003 17:16:54 -0800 Subject: [Patches] [ python-Patches-683592 ] unicode support for os.listdir() Message-ID: Patches item #683592, was opened at 2003-02-09 16:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: unicode support for os.listdir() Initial Comment: The attached patch makes os.listdir() return unicode strings, on plaforms that have Py_FileSystemDefaultEncoding defined as non-NULL. I'm by no means sure this is the right thing to do; it does seem right on OSX where Py_FileSystemDefaultEncoding is (or rather: will be real soon, I'm waiting for Jack's approval) utf-8. I'd be happy to add the code in an OSX-specific switch. A more subtle variant could perhaps only return unicode strings if the file name is not ASCII. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-09 20:16 Message: Logged In: YES user_id=6380 At the very least, I'd like it to return Unicode only when the original string isn't just ASCII. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 From noreply@sourceforge.net Mon Feb 10 01:28:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 09 Feb 2003 17:28:25 -0800 Subject: [Patches] [ python-Patches-683515 ] Add unicode support to compile(), eval() and exec Message-ID: Patches item #683515, was opened at 2003-02-09 14:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683515&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: Add unicode support to compile(), eval() and exec Initial Comment: Attached is a patch that adds "real" unicode support to compile(), eval() and exec. This is done by adding a new PyCompilerFlags flag called PyCF_SOURCE_IS_UTF8. Unicode strings are converted to utf-8 and this flag is set. I've added tests to test_builtin.py for compile and eval, but I don't know how/where to test exec. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-09 20:28 Message: Logged In: YES user_id=6380 This is not a full review, but if this doesn't break any unit tests, now is the time to check it in. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-09 15:56 Message: Logged In: YES user_id=92689 Updated the patch for current CVS. (Btw. if it were easy to obtain a utf-8 string with a bom mark, I think that should be preferable to adding the new compile flag. But it's not...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683515&group_id=5470 From noreply@sourceforge.net Mon Feb 10 03:06:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 09 Feb 2003 19:06:13 -0800 Subject: [Patches] [ python-Patches-683515 ] Add unicode support to compile(), eval() and exec Message-ID: Patches item #683515, was opened at 2003-02-09 14:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683515&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: Add unicode support to compile(), eval() and exec Initial Comment: Attached is a patch that adds "real" unicode support to compile(), eval() and exec. This is done by adding a new PyCompilerFlags flag called PyCF_SOURCE_IS_UTF8. Unicode strings are converted to utf-8 and this flag is set. I've added tests to test_builtin.py for compile and eval, but I don't know how/where to test exec. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-09 22:06 Message: Logged In: YES user_id=33168 The code which uses unicode APIs should probably be wrapped with: #ifdef Py_USING_UNICODE /* code */ #endif ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-09 20:28 Message: Logged In: YES user_id=6380 This is not a full review, but if this doesn't break any unit tests, now is the time to check it in. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-09 15:56 Message: Logged In: YES user_id=92689 Updated the patch for current CVS. (Btw. if it were easy to obtain a utf-8 string with a bom mark, I think that should be preferable to adding the new compile flag. But it's not...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683515&group_id=5470 From noreply@sourceforge.net Mon Feb 10 03:07:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 09 Feb 2003 19:07:06 -0800 Subject: [Patches] [ python-Patches-683592 ] unicode support for os.listdir() Message-ID: Patches item #683592, was opened at 2003-02-09 16:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: unicode support for os.listdir() Initial Comment: The attached patch makes os.listdir() return unicode strings, on plaforms that have Py_FileSystemDefaultEncoding defined as non-NULL. I'm by no means sure this is the right thing to do; it does seem right on OSX where Py_FileSystemDefaultEncoding is (or rather: will be real soon, I'm waiting for Jack's approval) utf-8. I'd be happy to add the code in an OSX-specific switch. A more subtle variant could perhaps only return unicode strings if the file name is not ASCII. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-09 22:07 Message: Logged In: YES user_id=33168 The code which uses unicode APIs should probably be wrapped with: #ifdef Py_USING_UNICODE /* code */ #endif ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-09 20:16 Message: Logged In: YES user_id=6380 At the very least, I'd like it to return Unicode only when the original string isn't just ASCII. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 From noreply@sourceforge.net Mon Feb 10 08:28:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 00:28:43 -0800 Subject: [Patches] [ python-Patches-683515 ] Add unicode support to compile(), eval() and exec Message-ID: Patches item #683515, was opened at 2003-02-09 20:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683515&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: Add unicode support to compile(), eval() and exec Initial Comment: Attached is a patch that adds "real" unicode support to compile(), eval() and exec. This is done by adding a new PyCompilerFlags flag called PyCF_SOURCE_IS_UTF8. Unicode strings are converted to utf-8 and this flag is set. I've added tests to test_builtin.py for compile and eval, but I don't know how/where to test exec. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-02-10 09:28 Message: Logged In: YES user_id=92689 Thanks, it's been checked in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 04:06 Message: Logged In: YES user_id=33168 The code which uses unicode APIs should probably be wrapped with: #ifdef Py_USING_UNICODE /* code */ #endif ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-10 02:28 Message: Logged In: YES user_id=6380 This is not a full review, but if this doesn't break any unit tests, now is the time to check it in. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-09 21:56 Message: Logged In: YES user_id=92689 Updated the patch for current CVS. (Btw. if it were easy to obtain a utf-8 string with a bom mark, I think that should be preferable to adding the new compile flag. But it's not...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683515&group_id=5470 From noreply@sourceforge.net Mon Feb 10 09:12:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 01:12:07 -0800 Subject: [Patches] [ python-Patches-683592 ] unicode support for os.listdir() Message-ID: Patches item #683592, was opened at 2003-02-09 22:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: unicode support for os.listdir() Initial Comment: The attached patch makes os.listdir() return unicode strings, on plaforms that have Py_FileSystemDefaultEncoding defined as non-NULL. I'm by no means sure this is the right thing to do; it does seem right on OSX where Py_FileSystemDefaultEncoding is (or rather: will be real soon, I'm waiting for Jack's approval) utf-8. I'd be happy to add the code in an OSX-specific switch. A more subtle variant could perhaps only return unicode strings if the file name is not ASCII. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-02-10 10:12 Message: Logged In: YES user_id=92689 Applied both suggestions. However, I'm not sure if my ASCII test does the right thing, or at least I don't think it does if Py_FileSystemDefaultEncoding is not a superset of ASCII. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 04:07 Message: Logged In: YES user_id=33168 The code which uses unicode APIs should probably be wrapped with: #ifdef Py_USING_UNICODE /* code */ #endif ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-10 02:16 Message: Logged In: YES user_id=6380 At the very least, I'd like it to return Unicode only when the original string isn't just ASCII. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 From noreply@sourceforge.net Mon Feb 10 09:25:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 01:25:57 -0800 Subject: [Patches] [ python-Patches-683515 ] Add unicode support to compile(), eval() and exec Message-ID: Patches item #683515, was opened at 2003-02-09 20:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683515&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: Add unicode support to compile(), eval() and exec Initial Comment: Attached is a patch that adds "real" unicode support to compile(), eval() and exec. This is done by adding a new PyCompilerFlags flag called PyCF_SOURCE_IS_UTF8. Unicode strings are converted to utf-8 and this flag is set. I've added tests to test_builtin.py for compile and eval, but I don't know how/where to test exec. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 10:25 Message: Logged In: YES user_id=38388 I didn't see a mention in the Misc/NEWS file. It would probably also be a good idea to mention this in the docs for compile() et al. Thanks for the work. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 09:28 Message: Logged In: YES user_id=92689 Thanks, it's been checked in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 04:06 Message: Logged In: YES user_id=33168 The code which uses unicode APIs should probably be wrapped with: #ifdef Py_USING_UNICODE /* code */ #endif ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-10 02:28 Message: Logged In: YES user_id=6380 This is not a full review, but if this doesn't break any unit tests, now is the time to check it in. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-09 21:56 Message: Logged In: YES user_id=92689 Updated the patch for current CVS. (Btw. if it were easy to obtain a utf-8 string with a bom mark, I think that should be preferable to adding the new compile flag. But it's not...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683515&group_id=5470 From noreply@sourceforge.net Mon Feb 10 09:24:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 01:24:29 -0800 Subject: [Patches] [ python-Patches-683592 ] unicode support for os.listdir() Message-ID: Patches item #683592, was opened at 2003-02-09 22:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: unicode support for os.listdir() Initial Comment: The attached patch makes os.listdir() return unicode strings, on plaforms that have Py_FileSystemDefaultEncoding defined as non-NULL. I'm by no means sure this is the right thing to do; it does seem right on OSX where Py_FileSystemDefaultEncoding is (or rather: will be real soon, I'm waiting for Jack's approval) utf-8. I'd be happy to add the code in an OSX-specific switch. A more subtle variant could perhaps only return unicode strings if the file name is not ASCII. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 10:24 Message: Logged In: YES user_id=38388 Your test will probably catch most cases, but it could fail for e.g. UTF-16. The only true test would be to first convert to Unicode and then try to convert back to ASCII. If you get an error you can be sure that the text is not ASCII compatible. Given that .listdir() involves lots of IO I think the added performance hit wouldn't be noticable. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 10:12 Message: Logged In: YES user_id=92689 Applied both suggestions. However, I'm not sure if my ASCII test does the right thing, or at least I don't think it does if Py_FileSystemDefaultEncoding is not a superset of ASCII. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 04:07 Message: Logged In: YES user_id=33168 The code which uses unicode APIs should probably be wrapped with: #ifdef Py_USING_UNICODE /* code */ #endif ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-10 02:16 Message: Logged In: YES user_id=6380 At the very least, I'd like it to return Unicode only when the original string isn't just ASCII. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 From noreply@sourceforge.net Mon Feb 10 09:51:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 01:51:43 -0800 Subject: [Patches] [ python-Patches-683592 ] unicode support for os.listdir() Message-ID: Patches item #683592, was opened at 2003-02-09 22:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: unicode support for os.listdir() Initial Comment: The attached patch makes os.listdir() return unicode strings, on plaforms that have Py_FileSystemDefaultEncoding defined as non-NULL. I'm by no means sure this is the right thing to do; it does seem right on OSX where Py_FileSystemDefaultEncoding is (or rather: will be real soon, I'm waiting for Jack's approval) utf-8. I'd be happy to add the code in an OSX-specific switch. A more subtle variant could perhaps only return unicode strings if the file name is not ASCII. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-02-10 10:51 Message: Logged In: YES user_id=92689 I don't see hot UTF-16 could be a valid value for Py_FileSystemDefaultEncoding, as for most platforms the file name can't contain null bytes. My looking at the NAMELEN() spaghetti, it seems platforms without HAVE_DIRENT_H might still support embedded null bytes. Any wisdom on this? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 10:24 Message: Logged In: YES user_id=38388 Your test will probably catch most cases, but it could fail for e.g. UTF-16. The only true test would be to first convert to Unicode and then try to convert back to ASCII. If you get an error you can be sure that the text is not ASCII compatible. Given that .listdir() involves lots of IO I think the added performance hit wouldn't be noticable. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 10:12 Message: Logged In: YES user_id=92689 Applied both suggestions. However, I'm not sure if my ASCII test does the right thing, or at least I don't think it does if Py_FileSystemDefaultEncoding is not a superset of ASCII. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 04:07 Message: Logged In: YES user_id=33168 The code which uses unicode APIs should probably be wrapped with: #ifdef Py_USING_UNICODE /* code */ #endif ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-10 02:16 Message: Logged In: YES user_id=6380 At the very least, I'd like it to return Unicode only when the original string isn't just ASCII. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 From noreply@sourceforge.net Mon Feb 10 10:17:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 02:17:23 -0800 Subject: [Patches] [ python-Patches-683592 ] unicode support for os.listdir() Message-ID: Patches item #683592, was opened at 2003-02-09 22:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: unicode support for os.listdir() Initial Comment: The attached patch makes os.listdir() return unicode strings, on plaforms that have Py_FileSystemDefaultEncoding defined as non-NULL. I'm by no means sure this is the right thing to do; it does seem right on OSX where Py_FileSystemDefaultEncoding is (or rather: will be real soon, I'm waiting for Jack's approval) utf-8. I'd be happy to add the code in an OSX-specific switch. A more subtle variant could perhaps only return unicode strings if the file name is not ASCII. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 11:17 Message: Logged In: YES user_id=38388 The file system does not need to support embedded \0 chars even if it supports UTF-16. It only happens that your test assumes that you have one byte per characters encodings which may not always be true. With UTF-16 your test will see lots of \0 bytes but not necessarily ones which are ord(x)>=128. I'm not sure whether other variable length encodings can result in \0 bytes, e.g. the Asian ones. There's also the possibility of the encoding mapping the ASCII range to other non-ASCII characters, e.g. ShiftJIS does this for the Yen sign. If you absolutely want to use the simple test, I'd at least restrict the test to an ASCII isalnum(x) test and then try the encode/decode method I described if this test fails. Note that isalnum() can be locale dependent on some platforms, so you have to hard-code it. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 10:51 Message: Logged In: YES user_id=92689 I don't see hot UTF-16 could be a valid value for Py_FileSystemDefaultEncoding, as for most platforms the file name can't contain null bytes. My looking at the NAMELEN() spaghetti, it seems platforms without HAVE_DIRENT_H might still support embedded null bytes. Any wisdom on this? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 10:24 Message: Logged In: YES user_id=38388 Your test will probably catch most cases, but it could fail for e.g. UTF-16. The only true test would be to first convert to Unicode and then try to convert back to ASCII. If you get an error you can be sure that the text is not ASCII compatible. Given that .listdir() involves lots of IO I think the added performance hit wouldn't be noticable. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 10:12 Message: Logged In: YES user_id=92689 Applied both suggestions. However, I'm not sure if my ASCII test does the right thing, or at least I don't think it does if Py_FileSystemDefaultEncoding is not a superset of ASCII. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 04:07 Message: Logged In: YES user_id=33168 The code which uses unicode APIs should probably be wrapped with: #ifdef Py_USING_UNICODE /* code */ #endif ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-10 02:16 Message: Logged In: YES user_id=6380 At the very least, I'd like it to return Unicode only when the original string isn't just ASCII. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 From noreply@sourceforge.net Mon Feb 10 10:49:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 02:49:50 -0800 Subject: [Patches] [ python-Patches-683592 ] unicode support for os.listdir() Message-ID: Patches item #683592, was opened at 2003-02-09 22:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: unicode support for os.listdir() Initial Comment: The attached patch makes os.listdir() return unicode strings, on plaforms that have Py_FileSystemDefaultEncoding defined as non-NULL. I'm by no means sure this is the right thing to do; it does seem right on OSX where Py_FileSystemDefaultEncoding is (or rather: will be real soon, I'm waiting for Jack's approval) utf-8. I'd be happy to add the code in an OSX-specific switch. A more subtle variant could perhaps only return unicode strings if the file name is not ASCII. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-02-10 11:49 Message: Logged In: YES user_id=92689 Ok, I went for your original suggestion: always convert to unicode and then try to convert to ascii. See new patch. Or should this use the default encoding? Hm. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 11:17 Message: Logged In: YES user_id=38388 The file system does not need to support embedded \0 chars even if it supports UTF-16. It only happens that your test assumes that you have one byte per characters encodings which may not always be true. With UTF-16 your test will see lots of \0 bytes but not necessarily ones which are ord(x)>=128. I'm not sure whether other variable length encodings can result in \0 bytes, e.g. the Asian ones. There's also the possibility of the encoding mapping the ASCII range to other non-ASCII characters, e.g. ShiftJIS does this for the Yen sign. If you absolutely want to use the simple test, I'd at least restrict the test to an ASCII isalnum(x) test and then try the encode/decode method I described if this test fails. Note that isalnum() can be locale dependent on some platforms, so you have to hard-code it. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 10:51 Message: Logged In: YES user_id=92689 I don't see hot UTF-16 could be a valid value for Py_FileSystemDefaultEncoding, as for most platforms the file name can't contain null bytes. My looking at the NAMELEN() spaghetti, it seems platforms without HAVE_DIRENT_H might still support embedded null bytes. Any wisdom on this? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 10:24 Message: Logged In: YES user_id=38388 Your test will probably catch most cases, but it could fail for e.g. UTF-16. The only true test would be to first convert to Unicode and then try to convert back to ASCII. If you get an error you can be sure that the text is not ASCII compatible. Given that .listdir() involves lots of IO I think the added performance hit wouldn't be noticable. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 10:12 Message: Logged In: YES user_id=92689 Applied both suggestions. However, I'm not sure if my ASCII test does the right thing, or at least I don't think it does if Py_FileSystemDefaultEncoding is not a superset of ASCII. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 04:07 Message: Logged In: YES user_id=33168 The code which uses unicode APIs should probably be wrapped with: #ifdef Py_USING_UNICODE /* code */ #endif ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-10 02:16 Message: Logged In: YES user_id=6380 At the very least, I'd like it to return Unicode only when the original string isn't just ASCII. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 From noreply@sourceforge.net Mon Feb 10 10:55:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 02:55:22 -0800 Subject: [Patches] [ python-Patches-683592 ] unicode support for os.listdir() Message-ID: Patches item #683592, was opened at 2003-02-09 22:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: unicode support for os.listdir() Initial Comment: The attached patch makes os.listdir() return unicode strings, on plaforms that have Py_FileSystemDefaultEncoding defined as non-NULL. I'm by no means sure this is the right thing to do; it does seem right on OSX where Py_FileSystemDefaultEncoding is (or rather: will be real soon, I'm waiting for Jack's approval) utf-8. I'd be happy to add the code in an OSX-specific switch. A more subtle variant could perhaps only return unicode strings if the file name is not ASCII. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 11:55 Message: Logged In: YES user_id=38388 Good question. The default encoding would better fit into the concept, I guess. Instead of PyUnicode_AsASCIIString(v) you'd have to use PyUnicode_AsEncodedString(v, NULL, "strict"). ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 11:49 Message: Logged In: YES user_id=92689 Ok, I went for your original suggestion: always convert to unicode and then try to convert to ascii. See new patch. Or should this use the default encoding? Hm. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 11:17 Message: Logged In: YES user_id=38388 The file system does not need to support embedded \0 chars even if it supports UTF-16. It only happens that your test assumes that you have one byte per characters encodings which may not always be true. With UTF-16 your test will see lots of \0 bytes but not necessarily ones which are ord(x)>=128. I'm not sure whether other variable length encodings can result in \0 bytes, e.g. the Asian ones. There's also the possibility of the encoding mapping the ASCII range to other non-ASCII characters, e.g. ShiftJIS does this for the Yen sign. If you absolutely want to use the simple test, I'd at least restrict the test to an ASCII isalnum(x) test and then try the encode/decode method I described if this test fails. Note that isalnum() can be locale dependent on some platforms, so you have to hard-code it. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 10:51 Message: Logged In: YES user_id=92689 I don't see hot UTF-16 could be a valid value for Py_FileSystemDefaultEncoding, as for most platforms the file name can't contain null bytes. My looking at the NAMELEN() spaghetti, it seems platforms without HAVE_DIRENT_H might still support embedded null bytes. Any wisdom on this? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 10:24 Message: Logged In: YES user_id=38388 Your test will probably catch most cases, but it could fail for e.g. UTF-16. The only true test would be to first convert to Unicode and then try to convert back to ASCII. If you get an error you can be sure that the text is not ASCII compatible. Given that .listdir() involves lots of IO I think the added performance hit wouldn't be noticable. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 10:12 Message: Logged In: YES user_id=92689 Applied both suggestions. However, I'm not sure if my ASCII test does the right thing, or at least I don't think it does if Py_FileSystemDefaultEncoding is not a superset of ASCII. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 04:07 Message: Logged In: YES user_id=33168 The code which uses unicode APIs should probably be wrapped with: #ifdef Py_USING_UNICODE /* code */ #endif ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-10 02:16 Message: Logged In: YES user_id=6380 At the very least, I'd like it to return Unicode only when the original string isn't just ASCII. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 From noreply@sourceforge.net Mon Feb 10 11:08:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 03:08:18 -0800 Subject: [Patches] [ python-Patches-683592 ] unicode support for os.listdir() Message-ID: Patches item #683592, was opened at 2003-02-09 22:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: unicode support for os.listdir() Initial Comment: The attached patch makes os.listdir() return unicode strings, on plaforms that have Py_FileSystemDefaultEncoding defined as non-NULL. I'm by no means sure this is the right thing to do; it does seem right on OSX where Py_FileSystemDefaultEncoding is (or rather: will be real soon, I'm waiting for Jack's approval) utf-8. I'd be happy to add the code in an OSX-specific switch. A more subtle variant could perhaps only return unicode strings if the file name is not ASCII. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-02-10 12:08 Message: Logged In: YES user_id=92689 On the other hand, if it's not ASCII, wouldn't a unicode string be more appropriate to begin with? If it's encodable with the default encoding, this will happen as soon as the string is used in a piece of unicode-unaware code, right? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 11:55 Message: Logged In: YES user_id=38388 Good question. The default encoding would better fit into the concept, I guess. Instead of PyUnicode_AsASCIIString(v) you'd have to use PyUnicode_AsEncodedString(v, NULL, "strict"). ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 11:49 Message: Logged In: YES user_id=92689 Ok, I went for your original suggestion: always convert to unicode and then try to convert to ascii. See new patch. Or should this use the default encoding? Hm. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 11:17 Message: Logged In: YES user_id=38388 The file system does not need to support embedded \0 chars even if it supports UTF-16. It only happens that your test assumes that you have one byte per characters encodings which may not always be true. With UTF-16 your test will see lots of \0 bytes but not necessarily ones which are ord(x)>=128. I'm not sure whether other variable length encodings can result in \0 bytes, e.g. the Asian ones. There's also the possibility of the encoding mapping the ASCII range to other non-ASCII characters, e.g. ShiftJIS does this for the Yen sign. If you absolutely want to use the simple test, I'd at least restrict the test to an ASCII isalnum(x) test and then try the encode/decode method I described if this test fails. Note that isalnum() can be locale dependent on some platforms, so you have to hard-code it. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 10:51 Message: Logged In: YES user_id=92689 I don't see hot UTF-16 could be a valid value for Py_FileSystemDefaultEncoding, as for most platforms the file name can't contain null bytes. My looking at the NAMELEN() spaghetti, it seems platforms without HAVE_DIRENT_H might still support embedded null bytes. Any wisdom on this? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 10:24 Message: Logged In: YES user_id=38388 Your test will probably catch most cases, but it could fail for e.g. UTF-16. The only true test would be to first convert to Unicode and then try to convert back to ASCII. If you get an error you can be sure that the text is not ASCII compatible. Given that .listdir() involves lots of IO I think the added performance hit wouldn't be noticable. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 10:12 Message: Logged In: YES user_id=92689 Applied both suggestions. However, I'm not sure if my ASCII test does the right thing, or at least I don't think it does if Py_FileSystemDefaultEncoding is not a superset of ASCII. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 04:07 Message: Logged In: YES user_id=33168 The code which uses unicode APIs should probably be wrapped with: #ifdef Py_USING_UNICODE /* code */ #endif ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-10 02:16 Message: Logged In: YES user_id=6380 At the very least, I'd like it to return Unicode only when the original string isn't just ASCII. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 From noreply@sourceforge.net Mon Feb 10 11:24:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 03:24:49 -0800 Subject: [Patches] [ python-Patches-683592 ] unicode support for os.listdir() Message-ID: Patches item #683592, was opened at 2003-02-09 22:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: unicode support for os.listdir() Initial Comment: The attached patch makes os.listdir() return unicode strings, on plaforms that have Py_FileSystemDefaultEncoding defined as non-NULL. I'm by no means sure this is the right thing to do; it does seem right on OSX where Py_FileSystemDefaultEncoding is (or rather: will be real soon, I'm waiting for Jack's approval) utf-8. I'd be happy to add the code in an OSX-specific switch. A more subtle variant could perhaps only return unicode strings if the file name is not ASCII. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 12:24 Message: Logged In: YES user_id=38388 Right, except that injecting Unicode into Unicode-unaware code can be dangerous (e.g. some code might require a string object to work on). E.g. if someone sets the default encoding to Latin-1 he wouldn't expect os.listdir() to suddenly return Unicode for him. This may be a problem in general for the change to os.listdir(). We'll just have to see what happens during the alpha and beta phases. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 12:08 Message: Logged In: YES user_id=92689 On the other hand, if it's not ASCII, wouldn't a unicode string be more appropriate to begin with? If it's encodable with the default encoding, this will happen as soon as the string is used in a piece of unicode-unaware code, right? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 11:55 Message: Logged In: YES user_id=38388 Good question. The default encoding would better fit into the concept, I guess. Instead of PyUnicode_AsASCIIString(v) you'd have to use PyUnicode_AsEncodedString(v, NULL, "strict"). ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 11:49 Message: Logged In: YES user_id=92689 Ok, I went for your original suggestion: always convert to unicode and then try to convert to ascii. See new patch. Or should this use the default encoding? Hm. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 11:17 Message: Logged In: YES user_id=38388 The file system does not need to support embedded \0 chars even if it supports UTF-16. It only happens that your test assumes that you have one byte per characters encodings which may not always be true. With UTF-16 your test will see lots of \0 bytes but not necessarily ones which are ord(x)>=128. I'm not sure whether other variable length encodings can result in \0 bytes, e.g. the Asian ones. There's also the possibility of the encoding mapping the ASCII range to other non-ASCII characters, e.g. ShiftJIS does this for the Yen sign. If you absolutely want to use the simple test, I'd at least restrict the test to an ASCII isalnum(x) test and then try the encode/decode method I described if this test fails. Note that isalnum() can be locale dependent on some platforms, so you have to hard-code it. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 10:51 Message: Logged In: YES user_id=92689 I don't see hot UTF-16 could be a valid value for Py_FileSystemDefaultEncoding, as for most platforms the file name can't contain null bytes. My looking at the NAMELEN() spaghetti, it seems platforms without HAVE_DIRENT_H might still support embedded null bytes. Any wisdom on this? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 10:24 Message: Logged In: YES user_id=38388 Your test will probably catch most cases, but it could fail for e.g. UTF-16. The only true test would be to first convert to Unicode and then try to convert back to ASCII. If you get an error you can be sure that the text is not ASCII compatible. Given that .listdir() involves lots of IO I think the added performance hit wouldn't be noticable. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 10:12 Message: Logged In: YES user_id=92689 Applied both suggestions. However, I'm not sure if my ASCII test does the right thing, or at least I don't think it does if Py_FileSystemDefaultEncoding is not a superset of ASCII. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 04:07 Message: Logged In: YES user_id=33168 The code which uses unicode APIs should probably be wrapped with: #ifdef Py_USING_UNICODE /* code */ #endif ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-10 02:16 Message: Logged In: YES user_id=6380 At the very least, I'd like it to return Unicode only when the original string isn't just ASCII. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 From noreply@sourceforge.net Mon Feb 10 15:00:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 07:00:41 -0800 Subject: [Patches] [ python-Patches-683939 ] Add download_url to setup() Message-ID: Patches item #683939, was opened at 2003-02-10 09:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683939&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Add download_url to setup() Initial Comment: For a Python package installer, it would be a good idea to provide a "download URL" metadata keyword in the next release of Python. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-02-10 10:00 Message: Logged In: YES user_id=11375 The attached patch implements the new metadata keyword. Open question: if a value isn't provided, the PKG-INFO file will contain the line "Download-URL: UNKNOWN". Should the line simply be omitted in this case? There should be an updated metadata PEP; I'm not sure if PEP 241 should be edited or what, but will ask the relevant people. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683939&group_id=5470 From noreply@sourceforge.net Mon Feb 10 15:00:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 07:00:55 -0800 Subject: [Patches] [ python-Patches-683939 ] Add download_url to setup() Message-ID: Patches item #683939, was opened at 2003-02-10 09:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683939&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) >Assigned to: Anthony Baxter (anthonybaxter) Summary: Add download_url to setup() Initial Comment: For a Python package installer, it would be a good idea to provide a "download URL" metadata keyword in the next release of Python. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-10 10:00 Message: Logged In: YES user_id=11375 The attached patch implements the new metadata keyword. Open question: if a value isn't provided, the PKG-INFO file will contain the line "Download-URL: UNKNOWN". Should the line simply be omitted in this case? There should be an updated metadata PEP; I'm not sure if PEP 241 should be edited or what, but will ask the relevant people. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683939&group_id=5470 From noreply@sourceforge.net Mon Feb 10 14:58:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 06:58:33 -0800 Subject: [Patches] [ python-Patches-683939 ] Add download_url to setup() Message-ID: Patches item #683939, was opened at 2003-02-10 09:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683939&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Add download_url to setup() Initial Comment: For a Python package installer, it would be a good idea to provide a "download URL" metadata keyword in the next release of Python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683939&group_id=5470 From noreply@sourceforge.net Mon Feb 10 15:34:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 07:34:03 -0800 Subject: [Patches] [ python-Patches-683939 ] Add download_url to setup() Message-ID: Patches item #683939, was opened at 2003-02-10 15:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683939&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Anthony Baxter (anthonybaxter) Summary: Add download_url to setup() Initial Comment: For a Python package installer, it would be a good idea to provide a "download URL" metadata keyword in the next release of Python. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-02-10 16:34 Message: Logged In: YES user_id=11105 What will this line contain, if there are several download URLs possible (zip, tar.gz, multiple exe fir different Python versions?) Will it work with redirects a la Sourceforge? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-10 16:00 Message: Logged In: YES user_id=11375 The attached patch implements the new metadata keyword. Open question: if a value isn't provided, the PKG-INFO file will contain the line "Download-URL: UNKNOWN". Should the line simply be omitted in this case? There should be an updated metadata PEP; I'm not sure if PEP 241 should be edited or what, but will ask the relevant people. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683939&group_id=5470 From noreply@sourceforge.net Mon Feb 10 15:54:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 07:54:41 -0800 Subject: [Patches] [ python-Patches-681504 ] using gcc on cygwin for config Message-ID: Patches item #681504, was opened at 2003-02-05 21:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681504&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Jason Tishler (jlt63) Summary: using gcc on cygwin for config Initial Comment: On Cygwin, I noticed that distutils tries to use the cc compiler instead of the gcc compiler for the config step, resulting in an error. Instead, for the build step the correct compiler (gcc) is being used. For the build step, build_clib.py and build_ext.py contain a call to customize_compiler after the call to new_compiler. The call to customize_compiler causes gcc to be used on cygwin. In config.py, however, this call to customize_compiler after the call to new_compiler is missing. Adding the call to customize_compiler after the call to new_compiler in config.py solves this problem, and the config step then runs correctly on Cygwin. BTW, I noticed that in version 1.44.6.3 of sysconfig.py in CVS, the function get_python_version is missing, causing errors in the build step. This is the latest committed version of sysconfig.py. So I used version 1.56 instead (which was committed earlier than 1.44.6.3, but has a higher version number ??). Michiel de Hoon University of Tokyo, Human Genome Center ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-02-10 06:54 Message: Logged In: YES user_id=86216 > On Cygwin, I noticed that distutils tries to use the cc > compiler instead of the gcc compiler for the config > step, resulting in an error. Please excuse my ignorance, but what is the "config step?" How would one invoke the config step? Sorry, but I'm only lightly versed in distutils. > Instead, for the build > step the correct compiler (gcc) is being used. The build step seems to work fine under Cygwin Python 2.2.2 and CVS. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-07 13:55 Message: Logged In: YES user_id=33168 Jason, can you provide any input about the issues w/Cygwin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681504&group_id=5470 From noreply@sourceforge.net Mon Feb 10 15:59:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 07:59:54 -0800 Subject: [Patches] [ python-Patches-676837 ] Cygwin array module patch Message-ID: Patches item #676837, was opened at 2003-01-29 06:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676837&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) >Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin array module patch Initial Comment: The (to be) attached patch enables the array module to build cleanly under Cygwin again. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-02-10 06:59 Message: Logged In: YES user_id=86216 Martin (who is usually very responsive) seems to be on vacation or otherwise unavailable... Can someone approve this patch and the following? https://sourceforge.net/tracker/? func=detail&aid=676839&group_id=5470&atid=305470 Note that Tim has already indicated the following: Those specific patches are acceptable . Thanks. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-01-29 06:28 Message: Logged In: YES user_id=86216 Attaching patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676837&group_id=5470 From noreply@sourceforge.net Mon Feb 10 16:06:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 08:06:40 -0800 Subject: [Patches] [ python-Patches-681504 ] using gcc on cygwin for config Message-ID: Patches item #681504, was opened at 2003-02-06 15:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681504&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Jason Tishler (jlt63) Summary: using gcc on cygwin for config Initial Comment: On Cygwin, I noticed that distutils tries to use the cc compiler instead of the gcc compiler for the config step, resulting in an error. Instead, for the build step the correct compiler (gcc) is being used. For the build step, build_clib.py and build_ext.py contain a call to customize_compiler after the call to new_compiler. The call to customize_compiler causes gcc to be used on cygwin. In config.py, however, this call to customize_compiler after the call to new_compiler is missing. Adding the call to customize_compiler after the call to new_compiler in config.py solves this problem, and the config step then runs correctly on Cygwin. BTW, I noticed that in version 1.44.6.3 of sysconfig.py in CVS, the function get_python_version is missing, causing errors in the build step. This is the latest committed version of sysconfig.py. So I used version 1.56 instead (which was committed earlier than 1.44.6.3, but has a higher version number ??). Michiel de Hoon University of Tokyo, Human Genome Center ---------------------------------------------------------------------- >Comment By: Michiel de Hoon (mdehoon) Date: 2003-02-11 01:06 Message: Logged In: YES user_id=488897 The config step is where you do python setup.py config where you can do some test compilations before doing "python setup.py build". Basically it works the same as autoconf/automake's configure scripts. The code for the config is in distutils/command/config.py. If you want to try it out, you can go to my website http://bonsai.ims.u-tokyo.ac.jp/~mdehoon, download pygist, unpack, and run "python setup.py config". You'll notice that it won't work on cygwin, as it tries to use cc instead of gcc. --Michiel. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-11 00:54 Message: Logged In: YES user_id=86216 > On Cygwin, I noticed that distutils tries to use the cc > compiler instead of the gcc compiler for the config > step, resulting in an error. Please excuse my ignorance, but what is the "config step?" How would one invoke the config step? Sorry, but I'm only lightly versed in distutils. > Instead, for the build > step the correct compiler (gcc) is being used. The build step seems to work fine under Cygwin Python 2.2.2 and CVS. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-08 07:55 Message: Logged In: YES user_id=33168 Jason, can you provide any input about the issues w/Cygwin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681504&group_id=5470 From noreply@sourceforge.net Mon Feb 10 16:24:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 08:24:35 -0800 Subject: [Patches] [ python-Patches-683592 ] unicode support for os.listdir() Message-ID: Patches item #683592, was opened at 2003-02-09 22:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: unicode support for os.listdir() Initial Comment: The attached patch makes os.listdir() return unicode strings, on plaforms that have Py_FileSystemDefaultEncoding defined as non-NULL. I'm by no means sure this is the right thing to do; it does seem right on OSX where Py_FileSystemDefaultEncoding is (or rather: will be real soon, I'm waiting for Jack's approval) utf-8. I'd be happy to add the code in an OSX-specific switch. A more subtle variant could perhaps only return unicode strings if the file name is not ASCII. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-02-10 17:24 Message: Logged In: YES user_id=92689 Here's an argument for ASCII and against the default encoding: if the default encoding is different from Py_FileSystemDefaultEncoding, things go wrong: an 8-bit string passed to file() will be interpreted as Py_FileSystemDefaultEncoding (more precisely: will not be interpreted at all), not the default encoding... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 12:24 Message: Logged In: YES user_id=38388 Right, except that injecting Unicode into Unicode-unaware code can be dangerous (e.g. some code might require a string object to work on). E.g. if someone sets the default encoding to Latin-1 he wouldn't expect os.listdir() to suddenly return Unicode for him. This may be a problem in general for the change to os.listdir(). We'll just have to see what happens during the alpha and beta phases. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 12:08 Message: Logged In: YES user_id=92689 On the other hand, if it's not ASCII, wouldn't a unicode string be more appropriate to begin with? If it's encodable with the default encoding, this will happen as soon as the string is used in a piece of unicode-unaware code, right? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 11:55 Message: Logged In: YES user_id=38388 Good question. The default encoding would better fit into the concept, I guess. Instead of PyUnicode_AsASCIIString(v) you'd have to use PyUnicode_AsEncodedString(v, NULL, "strict"). ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 11:49 Message: Logged In: YES user_id=92689 Ok, I went for your original suggestion: always convert to unicode and then try to convert to ascii. See new patch. Or should this use the default encoding? Hm. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 11:17 Message: Logged In: YES user_id=38388 The file system does not need to support embedded \0 chars even if it supports UTF-16. It only happens that your test assumes that you have one byte per characters encodings which may not always be true. With UTF-16 your test will see lots of \0 bytes but not necessarily ones which are ord(x)>=128. I'm not sure whether other variable length encodings can result in \0 bytes, e.g. the Asian ones. There's also the possibility of the encoding mapping the ASCII range to other non-ASCII characters, e.g. ShiftJIS does this for the Yen sign. If you absolutely want to use the simple test, I'd at least restrict the test to an ASCII isalnum(x) test and then try the encode/decode method I described if this test fails. Note that isalnum() can be locale dependent on some platforms, so you have to hard-code it. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 10:51 Message: Logged In: YES user_id=92689 I don't see hot UTF-16 could be a valid value for Py_FileSystemDefaultEncoding, as for most platforms the file name can't contain null bytes. My looking at the NAMELEN() spaghetti, it seems platforms without HAVE_DIRENT_H might still support embedded null bytes. Any wisdom on this? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 10:24 Message: Logged In: YES user_id=38388 Your test will probably catch most cases, but it could fail for e.g. UTF-16. The only true test would be to first convert to Unicode and then try to convert back to ASCII. If you get an error you can be sure that the text is not ASCII compatible. Given that .listdir() involves lots of IO I think the added performance hit wouldn't be noticable. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 10:12 Message: Logged In: YES user_id=92689 Applied both suggestions. However, I'm not sure if my ASCII test does the right thing, or at least I don't think it does if Py_FileSystemDefaultEncoding is not a superset of ASCII. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 04:07 Message: Logged In: YES user_id=33168 The code which uses unicode APIs should probably be wrapped with: #ifdef Py_USING_UNICODE /* code */ #endif ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-10 02:16 Message: Logged In: YES user_id=6380 At the very least, I'd like it to return Unicode only when the original string isn't just ASCII. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 From noreply@sourceforge.net Mon Feb 10 16:30:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 08:30:22 -0800 Subject: [Patches] [ python-Patches-676837 ] Cygwin array module patch Message-ID: Patches item #676837, was opened at 2003-01-29 10:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676837&group_id=5470 Category: Modules Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) >Assigned to: Jason Tishler (jlt63) Summary: Cygwin array module patch Initial Comment: The (to be) attached patch enables the array module to build cleanly under Cygwin again. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 11:30 Message: Logged In: YES user_id=33168 If Tim says the technique is ok, the patch is fine. Please apply. Martin is on vacation. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-10 10:59 Message: Logged In: YES user_id=86216 Martin (who is usually very responsive) seems to be on vacation or otherwise unavailable... Can someone approve this patch and the following? https://sourceforge.net/tracker/? func=detail&aid=676839&group_id=5470&atid=305470 Note that Tim has already indicated the following: Those specific patches are acceptable . Thanks. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-01-29 10:28 Message: Logged In: YES user_id=86216 Attaching patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676837&group_id=5470 From noreply@sourceforge.net Mon Feb 10 16:31:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 08:31:04 -0800 Subject: [Patches] [ python-Patches-676839 ] Cygwin _iconv_codec module patch Message-ID: Patches item #676839, was opened at 2003-01-29 10:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676839&group_id=5470 Category: Modules Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) >Assigned to: Jason Tishler (jlt63) Summary: Cygwin _iconv_codec module patch Initial Comment: The (to be) attached patch enables the _iconv_codec module to build cleanly under Cygwin. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 11:31 Message: Logged In: YES user_id=33168 Patch is fine, please apply. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-01-29 10:31 Message: Logged In: YES user_id=86216 Attaching patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676839&group_id=5470 From noreply@sourceforge.net Mon Feb 10 16:56:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 08:56:41 -0800 Subject: [Patches] [ python-Patches-681504 ] using gcc on cygwin for config Message-ID: Patches item #681504, was opened at 2003-02-05 21:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681504&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Jason Tishler (jlt63) Summary: using gcc on cygwin for config Initial Comment: On Cygwin, I noticed that distutils tries to use the cc compiler instead of the gcc compiler for the config step, resulting in an error. Instead, for the build step the correct compiler (gcc) is being used. For the build step, build_clib.py and build_ext.py contain a call to customize_compiler after the call to new_compiler. The call to customize_compiler causes gcc to be used on cygwin. In config.py, however, this call to customize_compiler after the call to new_compiler is missing. Adding the call to customize_compiler after the call to new_compiler in config.py solves this problem, and the config step then runs correctly on Cygwin. BTW, I noticed that in version 1.44.6.3 of sysconfig.py in CVS, the function get_python_version is missing, causing errors in the build step. This is the latest committed version of sysconfig.py. So I used version 1.56 instead (which was committed earlier than 1.44.6.3, but has a higher version number ??). Michiel de Hoon University of Tokyo, Human Genome Center ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-02-10 07:56 Message: Logged In: YES user_id=86216 OK, now I get it. Thanks for you help. I can reproduce the problem under Cygwin too. Now the question is, where is the right place to fix this? Under Red Hat 8.0, I get the following: $ ls -il /usr/bin/cc /usr/bin/c++ /usr/bin/g++ 328451 -rwxr-xr-x 4 root root 80780 Sep 3 23:03 /usr/bin/c++ 328396 lrwxrwxrwx 1 root root 3 Oct 21 10:04 /usr/bin/cc -> gcc 328451 -rwxr-xr-x 4 root root 80780 Sep 3 23:03 /usr/bin/g++ Under Cygwin, I get the following: $ ls -il /usr/bin/cc /usr/bin/c++ /usr/bin/g++ ls: /usr/bin/cc: No such file or directory 423677 lrwxrwxrwx 1 Administ Domain U 18 Dec 3 08:22 /usr/bin/c++ -> g++.exe 423679 -rwxrwxrwx 1 Administ Domain U 89600 Nov 14 17:37 /usr/bin/g++ So from the above, we can see that a symlink from cc to gcc could be considered missing under Cygwin. I will ask the Cygwin gcc maintainer to add this symlink. If the request is granted, will you consider this issue resolved? ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2003-02-10 07:06 Message: Logged In: YES user_id=488897 The config step is where you do python setup.py config where you can do some test compilations before doing "python setup.py build". Basically it works the same as autoconf/automake's configure scripts. The code for the config is in distutils/command/config.py. If you want to try it out, you can go to my website http://bonsai.ims.u-tokyo.ac.jp/~mdehoon, download pygist, unpack, and run "python setup.py config". You'll notice that it won't work on cygwin, as it tries to use cc instead of gcc. --Michiel. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-10 06:54 Message: Logged In: YES user_id=86216 > On Cygwin, I noticed that distutils tries to use the cc > compiler instead of the gcc compiler for the config > step, resulting in an error. Please excuse my ignorance, but what is the "config step?" How would one invoke the config step? Sorry, but I'm only lightly versed in distutils. > Instead, for the build > step the correct compiler (gcc) is being used. The build step seems to work fine under Cygwin Python 2.2.2 and CVS. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-07 13:55 Message: Logged In: YES user_id=33168 Jason, can you provide any input about the issues w/Cygwin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681504&group_id=5470 From noreply@sourceforge.net Mon Feb 10 17:13:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 09:13:01 -0800 Subject: [Patches] [ python-Patches-681504 ] using gcc on cygwin for config Message-ID: Patches item #681504, was opened at 2003-02-06 15:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681504&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Jason Tishler (jlt63) Summary: using gcc on cygwin for config Initial Comment: On Cygwin, I noticed that distutils tries to use the cc compiler instead of the gcc compiler for the config step, resulting in an error. Instead, for the build step the correct compiler (gcc) is being used. For the build step, build_clib.py and build_ext.py contain a call to customize_compiler after the call to new_compiler. The call to customize_compiler causes gcc to be used on cygwin. In config.py, however, this call to customize_compiler after the call to new_compiler is missing. Adding the call to customize_compiler after the call to new_compiler in config.py solves this problem, and the config step then runs correctly on Cygwin. BTW, I noticed that in version 1.44.6.3 of sysconfig.py in CVS, the function get_python_version is missing, causing errors in the build step. This is the latest committed version of sysconfig.py. So I used version 1.56 instead (which was committed earlier than 1.44.6.3, but has a higher version number ??). Michiel de Hoon University of Tokyo, Human Genome Center ---------------------------------------------------------------------- >Comment By: Michiel de Hoon (mdehoon) Date: 2003-02-11 02:13 Message: Logged In: YES user_id=488897 OK thanks for your help. Adding a symlink would work, but I am not sure if it is the best solution. For the build step, distutils uses gcc automatically and doesn't need a symlink from cc. I think it is best if the config step mimics the build step as closely as possible, and having one solution for the build step and another for the config step might break things. For the patch that I submitted, I compared the config and the build step to find out where one chooses gcc and the other cc. The patch contains only one or two lines, and lets the config step choose gcc in the same way as the build step. Would that be OK with you? Or do you think there might be some problem with the patch I submitted? --Michiel. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-11 01:56 Message: Logged In: YES user_id=86216 OK, now I get it. Thanks for you help. I can reproduce the problem under Cygwin too. Now the question is, where is the right place to fix this? Under Red Hat 8.0, I get the following: $ ls -il /usr/bin/cc /usr/bin/c++ /usr/bin/g++ 328451 -rwxr-xr-x 4 root root 80780 Sep 3 23:03 /usr/bin/c++ 328396 lrwxrwxrwx 1 root root 3 Oct 21 10:04 /usr/bin/cc -> gcc 328451 -rwxr-xr-x 4 root root 80780 Sep 3 23:03 /usr/bin/g++ Under Cygwin, I get the following: $ ls -il /usr/bin/cc /usr/bin/c++ /usr/bin/g++ ls: /usr/bin/cc: No such file or directory 423677 lrwxrwxrwx 1 Administ Domain U 18 Dec 3 08:22 /usr/bin/c++ -> g++.exe 423679 -rwxrwxrwx 1 Administ Domain U 89600 Nov 14 17:37 /usr/bin/g++ So from the above, we can see that a symlink from cc to gcc could be considered missing under Cygwin. I will ask the Cygwin gcc maintainer to add this symlink. If the request is granted, will you consider this issue resolved? ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2003-02-11 01:06 Message: Logged In: YES user_id=488897 The config step is where you do python setup.py config where you can do some test compilations before doing "python setup.py build". Basically it works the same as autoconf/automake's configure scripts. The code for the config is in distutils/command/config.py. If you want to try it out, you can go to my website http://bonsai.ims.u-tokyo.ac.jp/~mdehoon, download pygist, unpack, and run "python setup.py config". You'll notice that it won't work on cygwin, as it tries to use cc instead of gcc. --Michiel. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-11 00:54 Message: Logged In: YES user_id=86216 > On Cygwin, I noticed that distutils tries to use the cc > compiler instead of the gcc compiler for the config > step, resulting in an error. Please excuse my ignorance, but what is the "config step?" How would one invoke the config step? Sorry, but I'm only lightly versed in distutils. > Instead, for the build > step the correct compiler (gcc) is being used. The build step seems to work fine under Cygwin Python 2.2.2 and CVS. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-08 07:55 Message: Logged In: YES user_id=33168 Jason, can you provide any input about the issues w/Cygwin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681504&group_id=5470 From noreply@sourceforge.net Mon Feb 10 17:35:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 09:35:22 -0800 Subject: [Patches] [ python-Patches-684010 ] extending dict functionality Message-ID: Patches item #684010, was opened at 2003-02-10 11:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684010&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Vitecek (fufsource) Assigned to: Nobody/Anonymous (nobody) Summary: extending dict functionality Initial Comment: attached is a simple patch that adds three new methods to the builtin dictionary object: 1) randkey() -- returns a random key from the dictionary 2) randvalue() -- returns a random value from the dictionary 3) popranditem() -- returns a random pair (key, value) and removes it from the dictionary methods 1&2 are useful because currently getting a random value off a dictionary is a pain (need to create a list or either keys or values and then choose a random bit from it). method 3 is provided as a supplement for method popitem() which (based on the used hashed function) returns the items in almost sequential order _and_ starts from the very start if a new item is added to the dictionary. i find all the methods useful because there's no need to create a temporary list of keys or values or pairs in cases where dictionary must be used for speedy data hashing but some features of a list/tuple are needed (random element access). with those methods random.choice() could be fixed so it worked on dictionaries as well. documentation and UserDict.py are modified as well. thank you for consideration, ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 12:35 Message: Logged In: YES user_id=33168 Michal, thanks for the patch. I suspect these are not general enough to be added. Many people must have a need before methods are added. If you want these added, you will need to at least bring up the subject on python-dev@python.org or create a PEP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684010&group_id=5470 From noreply@sourceforge.net Mon Feb 10 18:17:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 10:17:12 -0800 Subject: [Patches] [ python-Patches-683592 ] unicode support for os.listdir() Message-ID: Patches item #683592, was opened at 2003-02-09 22:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: unicode support for os.listdir() Initial Comment: The attached patch makes os.listdir() return unicode strings, on plaforms that have Py_FileSystemDefaultEncoding defined as non-NULL. I'm by no means sure this is the right thing to do; it does seem right on OSX where Py_FileSystemDefaultEncoding is (or rather: will be real soon, I'm waiting for Jack's approval) utf-8. I'd be happy to add the code in an OSX-specific switch. A more subtle variant could perhaps only return unicode strings if the file name is not ASCII. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-02-10 19:17 Message: Logged In: YES user_id=92689 I'm pretty sure os.path deals just fine with unicode strings (it's all pure string manipulations, isn't it?) Worries: well, apparently on Windows os.listdir() has been returning unicode for some time, so it's not like we're breaking completely new grounds here. If anything breaks it's probably good this happens, as it gives an opportunity to fix things... I just found several example of potential breakage: _bsddb.c parses a filename arg with the "z" format specifier. gdbmmodule.c uses "s". bsddbmodule.c and dbmmodule.c as well. I'm not sure the above modules work on Windows with non-ascii filenames at all, but it doesn't look like it. Besides Windows (for which my patch is not relevant), only OSX sets Py_FileSystemDefaultEncoding, so any new breakage won't reach a mass market right away . ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 18:46 Message: Logged In: YES user_id=38388 Ok, let's look at it from a different angle: things that you get from os.listdir() should be compatible to (at least) all the os.path tools and os itself. Converting to Unicode has the advantage that slicing and indexing into the path names will not break the paths (unlike UTF-8 encoded 8-bit strings which tend to break when you slice them). That said, I think you're right about the ASCII approach provided that the os, os.path tools can actually properly cope with Unicode. What I worry about is that if os.listdir() gives back Unicode for e.g. Latin-1 filenames and the application then passes the Unicode names to a C API using "s", prefectly working code will break... then again the C code should really use "es" for decoding to the Py_FileSystemDefaultEncoding as is done in e.g. fileobject.c. I really don't know what to do here... ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 17:24 Message: Logged In: YES user_id=92689 Here's an argument for ASCII and against the default encoding: if the default encoding is different from Py_FileSystemDefaultEncoding, things go wrong: an 8-bit string passed to file() will be interpreted as Py_FileSystemDefaultEncoding (more precisely: will not be interpreted at all), not the default encoding... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 12:24 Message: Logged In: YES user_id=38388 Right, except that injecting Unicode into Unicode-unaware code can be dangerous (e.g. some code might require a string object to work on). E.g. if someone sets the default encoding to Latin-1 he wouldn't expect os.listdir() to suddenly return Unicode for him. This may be a problem in general for the change to os.listdir(). We'll just have to see what happens during the alpha and beta phases. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 12:08 Message: Logged In: YES user_id=92689 On the other hand, if it's not ASCII, wouldn't a unicode string be more appropriate to begin with? If it's encodable with the default encoding, this will happen as soon as the string is used in a piece of unicode-unaware code, right? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 11:55 Message: Logged In: YES user_id=38388 Good question. The default encoding would better fit into the concept, I guess. Instead of PyUnicode_AsASCIIString(v) you'd have to use PyUnicode_AsEncodedString(v, NULL, "strict"). ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 11:49 Message: Logged In: YES user_id=92689 Ok, I went for your original suggestion: always convert to unicode and then try to convert to ascii. See new patch. Or should this use the default encoding? Hm. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 11:17 Message: Logged In: YES user_id=38388 The file system does not need to support embedded \0 chars even if it supports UTF-16. It only happens that your test assumes that you have one byte per characters encodings which may not always be true. With UTF-16 your test will see lots of \0 bytes but not necessarily ones which are ord(x)>=128. I'm not sure whether other variable length encodings can result in \0 bytes, e.g. the Asian ones. There's also the possibility of the encoding mapping the ASCII range to other non-ASCII characters, e.g. ShiftJIS does this for the Yen sign. If you absolutely want to use the simple test, I'd at least restrict the test to an ASCII isalnum(x) test and then try the encode/decode method I described if this test fails. Note that isalnum() can be locale dependent on some platforms, so you have to hard-code it. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 10:51 Message: Logged In: YES user_id=92689 I don't see hot UTF-16 could be a valid value for Py_FileSystemDefaultEncoding, as for most platforms the file name can't contain null bytes. My looking at the NAMELEN() spaghetti, it seems platforms without HAVE_DIRENT_H might still support embedded null bytes. Any wisdom on this? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 10:24 Message: Logged In: YES user_id=38388 Your test will probably catch most cases, but it could fail for e.g. UTF-16. The only true test would be to first convert to Unicode and then try to convert back to ASCII. If you get an error you can be sure that the text is not ASCII compatible. Given that .listdir() involves lots of IO I think the added performance hit wouldn't be noticable. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 10:12 Message: Logged In: YES user_id=92689 Applied both suggestions. However, I'm not sure if my ASCII test does the right thing, or at least I don't think it does if Py_FileSystemDefaultEncoding is not a superset of ASCII. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 04:07 Message: Logged In: YES user_id=33168 The code which uses unicode APIs should probably be wrapped with: #ifdef Py_USING_UNICODE /* code */ #endif ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-10 02:16 Message: Logged In: YES user_id=6380 At the very least, I'd like it to return Unicode only when the original string isn't just ASCII. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 From noreply@sourceforge.net Mon Feb 10 19:25:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 11:25:59 -0800 Subject: [Patches] [ python-Patches-684010 ] extending dict functionality Message-ID: Patches item #684010, was opened at 2003-02-10 17:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684010&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Michal Vitecek (fufsource) Assigned to: Nobody/Anonymous (nobody) Summary: extending dict functionality Initial Comment: attached is a simple patch that adds three new methods to the builtin dictionary object: 1) randkey() -- returns a random key from the dictionary 2) randvalue() -- returns a random value from the dictionary 3) popranditem() -- returns a random pair (key, value) and removes it from the dictionary methods 1&2 are useful because currently getting a random value off a dictionary is a pain (need to create a list or either keys or values and then choose a random bit from it). method 3 is provided as a supplement for method popitem() which (based on the used hashed function) returns the items in almost sequential order _and_ starts from the very start if a new item is added to the dictionary. i find all the methods useful because there's no need to create a temporary list of keys or values or pairs in cases where dictionary must be used for speedy data hashing but some features of a list/tuple are needed (random element access). with those methods random.choice() could be fixed so it worked on dictionaries as well. documentation and UserDict.py are modified as well. thank you for consideration, ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-02-10 20:25 Message: Logged In: YES user_id=92689 Two reasons to reject this patch: - too specific, the "general usefulness" is dubious (suggestion: you could subclass dict) - uses rand() (suggestion: have a look at _randommodule.c...) Sorry! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 18:35 Message: Logged In: YES user_id=33168 Michal, thanks for the patch. I suspect these are not general enough to be added. Many people must have a need before methods are added. If you want these added, you will need to at least bring up the subject on python-dev@python.org or create a PEP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684010&group_id=5470 From noreply@sourceforge.net Mon Feb 10 17:46:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 09:46:49 -0800 Subject: [Patches] [ python-Patches-683592 ] unicode support for os.listdir() Message-ID: Patches item #683592, was opened at 2003-02-09 22:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: unicode support for os.listdir() Initial Comment: The attached patch makes os.listdir() return unicode strings, on plaforms that have Py_FileSystemDefaultEncoding defined as non-NULL. I'm by no means sure this is the right thing to do; it does seem right on OSX where Py_FileSystemDefaultEncoding is (or rather: will be real soon, I'm waiting for Jack's approval) utf-8. I'd be happy to add the code in an OSX-specific switch. A more subtle variant could perhaps only return unicode strings if the file name is not ASCII. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 18:46 Message: Logged In: YES user_id=38388 Ok, let's look at it from a different angle: things that you get from os.listdir() should be compatible to (at least) all the os.path tools and os itself. Converting to Unicode has the advantage that slicing and indexing into the path names will not break the paths (unlike UTF-8 encoded 8-bit strings which tend to break when you slice them). That said, I think you're right about the ASCII approach provided that the os, os.path tools can actually properly cope with Unicode. What I worry about is that if os.listdir() gives back Unicode for e.g. Latin-1 filenames and the application then passes the Unicode names to a C API using "s", prefectly working code will break... then again the C code should really use "es" for decoding to the Py_FileSystemDefaultEncoding as is done in e.g. fileobject.c. I really don't know what to do here... ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 17:24 Message: Logged In: YES user_id=92689 Here's an argument for ASCII and against the default encoding: if the default encoding is different from Py_FileSystemDefaultEncoding, things go wrong: an 8-bit string passed to file() will be interpreted as Py_FileSystemDefaultEncoding (more precisely: will not be interpreted at all), not the default encoding... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 12:24 Message: Logged In: YES user_id=38388 Right, except that injecting Unicode into Unicode-unaware code can be dangerous (e.g. some code might require a string object to work on). E.g. if someone sets the default encoding to Latin-1 he wouldn't expect os.listdir() to suddenly return Unicode for him. This may be a problem in general for the change to os.listdir(). We'll just have to see what happens during the alpha and beta phases. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 12:08 Message: Logged In: YES user_id=92689 On the other hand, if it's not ASCII, wouldn't a unicode string be more appropriate to begin with? If it's encodable with the default encoding, this will happen as soon as the string is used in a piece of unicode-unaware code, right? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 11:55 Message: Logged In: YES user_id=38388 Good question. The default encoding would better fit into the concept, I guess. Instead of PyUnicode_AsASCIIString(v) you'd have to use PyUnicode_AsEncodedString(v, NULL, "strict"). ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 11:49 Message: Logged In: YES user_id=92689 Ok, I went for your original suggestion: always convert to unicode and then try to convert to ascii. See new patch. Or should this use the default encoding? Hm. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 11:17 Message: Logged In: YES user_id=38388 The file system does not need to support embedded \0 chars even if it supports UTF-16. It only happens that your test assumes that you have one byte per characters encodings which may not always be true. With UTF-16 your test will see lots of \0 bytes but not necessarily ones which are ord(x)>=128. I'm not sure whether other variable length encodings can result in \0 bytes, e.g. the Asian ones. There's also the possibility of the encoding mapping the ASCII range to other non-ASCII characters, e.g. ShiftJIS does this for the Yen sign. If you absolutely want to use the simple test, I'd at least restrict the test to an ASCII isalnum(x) test and then try the encode/decode method I described if this test fails. Note that isalnum() can be locale dependent on some platforms, so you have to hard-code it. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 10:51 Message: Logged In: YES user_id=92689 I don't see hot UTF-16 could be a valid value for Py_FileSystemDefaultEncoding, as for most platforms the file name can't contain null bytes. My looking at the NAMELEN() spaghetti, it seems platforms without HAVE_DIRENT_H might still support embedded null bytes. Any wisdom on this? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 10:24 Message: Logged In: YES user_id=38388 Your test will probably catch most cases, but it could fail for e.g. UTF-16. The only true test would be to first convert to Unicode and then try to convert back to ASCII. If you get an error you can be sure that the text is not ASCII compatible. Given that .listdir() involves lots of IO I think the added performance hit wouldn't be noticable. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 10:12 Message: Logged In: YES user_id=92689 Applied both suggestions. However, I'm not sure if my ASCII test does the right thing, or at least I don't think it does if Py_FileSystemDefaultEncoding is not a superset of ASCII. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 04:07 Message: Logged In: YES user_id=33168 The code which uses unicode APIs should probably be wrapped with: #ifdef Py_USING_UNICODE /* code */ #endif ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-10 02:16 Message: Logged In: YES user_id=6380 At the very least, I'd like it to return Unicode only when the original string isn't just ASCII. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 From noreply@sourceforge.net Mon Feb 10 16:42:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 08:42:49 -0800 Subject: [Patches] [ python-Patches-684010 ] extending dict functionality Message-ID: Patches item #684010, was opened at 2003-02-10 17:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684010&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Vitecek (fufsource) Assigned to: Nobody/Anonymous (nobody) Summary: extending dict functionality Initial Comment: attached is a simple patch that adds three new methods to the builtin dictionary object: 1) randkey() -- returns a random key from the dictionary 2) randvalue() -- returns a random value from the dictionary 3) popranditem() -- returns a random pair (key, value) and removes it from the dictionary methods 1&2 are useful because currently getting a random value off a dictionary is a pain (need to create a list or either keys or values and then choose a random bit from it). method 3 is provided as a supplement for method popitem() which (based on the used hashed function) returns the items in almost sequential order _and_ starts from the very start if a new item is added to the dictionary. i find all the methods useful because there's no need to create a temporary list of keys or values or pairs in cases where dictionary must be used for speedy data hashing but some features of a list/tuple are needed (random element access). with those methods random.choice() could be fixed so it worked on dictionaries as well. documentation and UserDict.py are modified as well. thank you for consideration, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684010&group_id=5470 From noreply@sourceforge.net Mon Feb 10 19:36:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 11:36:59 -0800 Subject: [Patches] [ python-Patches-680863 ] replace() method in unicode objects Message-ID: Patches item #680863, was opened at 2003-02-05 14:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680863&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Juhlin (faeltir) Assigned to: Nobody/Anonymous (nobody) Summary: replace() method in unicode objects Initial Comment: Hi, I found that unlike the string object, the replace() method in the unicode object doesn't throw an exception when you supply an empty pattern string. Instead it slaps on the replace string a few times at the end. I'm supplying a patch to make the unicode object behave like the string object. I realize that in 2.3, doing replace() with an empty pattern string will work differently so maybe you don't consider throwing an exception the Right Way(TM), but I'm presenting it to you in case you (like me) thinks it's just better if unicode and string objects behave in the same way while not changing the way that string objects currently work in 2.2. Best regards, Fredrik Juhlin ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-02-10 20:36 Message: Logged In: YES user_id=92689 What I'm not sure of is whether the fact that this: "x".replace("", "a") raises an exception in 2.2 and "works" in 2.3 is intentional. It returns this in 2.3: 'axa'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680863&group_id=5470 From noreply@sourceforge.net Mon Feb 10 19:40:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 11:40:41 -0800 Subject: [Patches] [ python-Patches-677887 ] Add traceback.format_exc Message-ID: Patches item #677887, was opened at 2003-01-31 02:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677887&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 4 Submitted By: Neil Schemenauer (nascheme) Assigned to: Raymond Hettinger (rhettinger) Summary: Add traceback.format_exc Initial Comment: I sometimes end up wanting this function. I think it compliments print_exc() nicely. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-02-10 20:40 Message: Logged In: YES user_id=92689 There's no file attached... ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-02-08 08:39 Message: Logged In: YES user_id=35752 Yes, feel free to reassign. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-07 06:58 Message: Logged In: YES user_id=80475 Did you intend to assign this one to me? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677887&group_id=5470 From noreply@sourceforge.net Mon Feb 10 19:46:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 11:46:20 -0800 Subject: [Patches] [ python-Patches-683376 ] Adding NotImplementedType to types.py Message-ID: Patches item #683376, was opened at 2003-02-09 14:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683376&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 1 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Adding NotImplementedType to types.py Initial Comment: This patch adds NotImplementedType to types.py. I don't know why, but it is not included. I found out while testing 'class A(%s): pass' on all types in types.py, and found out NotImplementedType had not been tested. This patch adds the line "NotImplementedType = type(NotImplemented)" to types.py. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-02-10 20:46 Message: Logged In: YES user_id=92689 Thanks, applied. ---------------------------------------------------------------------- Comment By: Gerrit Holl (gerrit) Date: 2003-02-09 14:09 Message: Logged In: YES user_id=13298 OOPS, upload failed! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683376&group_id=5470 From noreply@sourceforge.net Mon Feb 10 20:20:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 12:20:45 -0800 Subject: [Patches] [ python-Patches-680863 ] replace() method in unicode objects Message-ID: Patches item #680863, was opened at 2003-02-05 08:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680863&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Juhlin (faeltir) Assigned to: Nobody/Anonymous (nobody) Summary: replace() method in unicode objects Initial Comment: Hi, I found that unlike the string object, the replace() method in the unicode object doesn't throw an exception when you supply an empty pattern string. Instead it slaps on the replace string a few times at the end. I'm supplying a patch to make the unicode object behave like the string object. I realize that in 2.3, doing replace() with an empty pattern string will work differently so maybe you don't consider throwing an exception the Right Way(TM), but I'm presenting it to you in case you (like me) thinks it's just better if unicode and string objects behave in the same way while not changing the way that string objects currently work in 2.2. Best regards, Fredrik Juhlin ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 15:20 Message: Logged In: YES user_id=33168 The change for 2.3 was on purpose. See Objects/stringobject.c 2.184 which fixed SF bug 595350. Hmmm, unicode doesn't even do it right in 2.2.2+ >>> u"x".replace("", "a") u'xaa' Not sure what to do to fix for 2.2.3. :-( ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 14:36 Message: Logged In: YES user_id=92689 What I'm not sure of is whether the fact that this: "x".replace("", "a") raises an exception in 2.2 and "works" in 2.3 is intentional. It returns this in 2.3: 'axa'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680863&group_id=5470 From noreply@sourceforge.net Mon Feb 10 20:24:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 12:24:01 -0800 Subject: [Patches] [ python-Patches-684142 ] Korean Unicode Codecs Message-ID: Patches item #684142, was opened at 2003-02-11 05:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684142&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Korean Unicode Codecs Initial Comment: This is an compact implementation which is fully rewritten from KoreanCodecs (http://sf.net/projects/koco). It consumes about 50KB only as an installed binary. Supported encodings are euc-kr and cp949. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684142&group_id=5470 From noreply@sourceforge.net Mon Feb 10 20:25:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 12:25:16 -0800 Subject: [Patches] [ python-Patches-536883 ] SimpleXMLRPCServer auto-docing subclass Message-ID: Patches item #536883, was opened at 2002-03-29 11:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=536883&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Fredrik Lundh (effbot) Summary: SimpleXMLRPCServer auto-docing subclass Initial Comment: This SimpleXMLRPCServer subclass automatically serves HTML documentation, generated using pydoc, in response to an HTTP GET request (XML-RPC always uses POST). Here are some examples: http://www.sweetapp.com/cgi-bin/xmlrpc-test/rpc1.py http://www.sweetapp.com/cgi-bin/xmlrpc-test/rpc2.py ---------------------------------------------------------------------- >Comment By: Brian Quinlan (bquinlan) Date: 2003-02-10 12:25 Message: Logged In: YES user_id=108973 Patch 473586 has been accepted so this patch can be accepted. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2002-04-04 11:26 Message: Logged In: YES user_id=108973 Sorry, I was sloppy about the description: This patch is dependant on patch 473586: [473586] SimpleXMLRPCServer - fixes and CGI So please don't check this in until that patch is accepted. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2002-04-04 09:55 Message: Logged In: YES user_id=108973 Sorry, I was sloppy about the description: This patch is dependant on patch 473586: [473586] SimpleXMLRPCServer - fixes and CGI So please don't check this in until that patch is accepted. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-04 09:31 Message: Logged In: YES user_id=6380 Looks cute to me. Fredrik, any problem if I just check this in? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=536883&group_id=5470 From noreply@sourceforge.net Mon Feb 10 20:28:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 12:28:14 -0800 Subject: [Patches] [ python-Patches-684142 ] Korean Unicode Codecs Message-ID: Patches item #684142, was opened at 2003-02-11 05:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684142&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Korean Unicode Codecs Initial Comment: This is an compact implementation which is fully rewritten from KoreanCodecs (http://sf.net/projects/koco). It consumes about 50KB only as an installed binary. Supported encodings are euc-kr and cp949. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2003-02-11 05:28 Message: Logged In: YES user_id=55188 Enclosed files on patch: Lib/encodings/aliases.py : adding aliases for euc-kr and cp949 Lib/encodings/cp949.py : cp949 codec Lib/encodings/euc_kr.py : euc-kr codec setup.py : adding _ko_codecs module to default build. Modules/_ko_codecs.h : mapping data for KS X 1001 and CP949 Modules/_ko_codecs.c : C implementations for both codecs. Tools/unicode/genmap_ko_codecs.py : Generates _ko_codecs.h from CP949.TXT ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684142&group_id=5470 From noreply@sourceforge.net Mon Feb 10 20:40:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 12:40:44 -0800 Subject: [Patches] [ python-Patches-681504 ] using gcc on cygwin for config Message-ID: Patches item #681504, was opened at 2003-02-05 21:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681504&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) >Assigned to: Neal Norwitz (nnorwitz) Summary: using gcc on cygwin for config Initial Comment: On Cygwin, I noticed that distutils tries to use the cc compiler instead of the gcc compiler for the config step, resulting in an error. Instead, for the build step the correct compiler (gcc) is being used. For the build step, build_clib.py and build_ext.py contain a call to customize_compiler after the call to new_compiler. The call to customize_compiler causes gcc to be used on cygwin. In config.py, however, this call to customize_compiler after the call to new_compiler is missing. Adding the call to customize_compiler after the call to new_compiler in config.py solves this problem, and the config step then runs correctly on Cygwin. BTW, I noticed that in version 1.44.6.3 of sysconfig.py in CVS, the function get_python_version is missing, causing errors in the build step. This is the latest committed version of sysconfig.py. So I used version 1.56 instead (which was committed earlier than 1.44.6.3, but has a higher version number ??). Michiel de Hoon University of Tokyo, Human Genome Center ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-02-10 11:40 Message: Logged In: YES user_id=86216 > Adding a symlink would work, but I > am not sure if it is the best solution. Maybe both should be done? > Would that be OK with you? The patch is fine by me since it fixes Cygwin and I assume any other Unix (if any) without a /usr/bin/cc. > Or do you think there might be some problem > with the patch I submitted? No, I don't think that there will be problems with your patch. However, I cannot approve patches. I can only submit them like you. :,) Neal, should someone from distutils take a look-see. Or, is it OK for me to apply? ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2003-02-10 08:13 Message: Logged In: YES user_id=488897 OK thanks for your help. Adding a symlink would work, but I am not sure if it is the best solution. For the build step, distutils uses gcc automatically and doesn't need a symlink from cc. I think it is best if the config step mimics the build step as closely as possible, and having one solution for the build step and another for the config step might break things. For the patch that I submitted, I compared the config and the build step to find out where one chooses gcc and the other cc. The patch contains only one or two lines, and lets the config step choose gcc in the same way as the build step. Would that be OK with you? Or do you think there might be some problem with the patch I submitted? --Michiel. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-10 07:56 Message: Logged In: YES user_id=86216 OK, now I get it. Thanks for you help. I can reproduce the problem under Cygwin too. Now the question is, where is the right place to fix this? Under Red Hat 8.0, I get the following: $ ls -il /usr/bin/cc /usr/bin/c++ /usr/bin/g++ 328451 -rwxr-xr-x 4 root root 80780 Sep 3 23:03 /usr/bin/c++ 328396 lrwxrwxrwx 1 root root 3 Oct 21 10:04 /usr/bin/cc -> gcc 328451 -rwxr-xr-x 4 root root 80780 Sep 3 23:03 /usr/bin/g++ Under Cygwin, I get the following: $ ls -il /usr/bin/cc /usr/bin/c++ /usr/bin/g++ ls: /usr/bin/cc: No such file or directory 423677 lrwxrwxrwx 1 Administ Domain U 18 Dec 3 08:22 /usr/bin/c++ -> g++.exe 423679 -rwxrwxrwx 1 Administ Domain U 89600 Nov 14 17:37 /usr/bin/g++ So from the above, we can see that a symlink from cc to gcc could be considered missing under Cygwin. I will ask the Cygwin gcc maintainer to add this symlink. If the request is granted, will you consider this issue resolved? ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2003-02-10 07:06 Message: Logged In: YES user_id=488897 The config step is where you do python setup.py config where you can do some test compilations before doing "python setup.py build". Basically it works the same as autoconf/automake's configure scripts. The code for the config is in distutils/command/config.py. If you want to try it out, you can go to my website http://bonsai.ims.u-tokyo.ac.jp/~mdehoon, download pygist, unpack, and run "python setup.py config". You'll notice that it won't work on cygwin, as it tries to use cc instead of gcc. --Michiel. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-10 06:54 Message: Logged In: YES user_id=86216 > On Cygwin, I noticed that distutils tries to use the cc > compiler instead of the gcc compiler for the config > step, resulting in an error. Please excuse my ignorance, but what is the "config step?" How would one invoke the config step? Sorry, but I'm only lightly versed in distutils. > Instead, for the build > step the correct compiler (gcc) is being used. The build step seems to work fine under Cygwin Python 2.2.2 and CVS. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-07 13:55 Message: Logged In: YES user_id=33168 Jason, can you provide any input about the issues w/Cygwin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681504&group_id=5470 From noreply@sourceforge.net Mon Feb 10 20:53:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 12:53:44 -0800 Subject: [Patches] [ python-Patches-676837 ] Cygwin array module patch Message-ID: Patches item #676837, was opened at 2003-01-29 06:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676837&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: Cygwin array module patch Initial Comment: The (to be) attached patch enables the array module to build cleanly under Cygwin again. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-02-10 11:53 Message: Logged In: YES user_id=86216 Checked in as Modules/arraymodule.c 2.83. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 07:30 Message: Logged In: YES user_id=33168 If Tim says the technique is ok, the patch is fine. Please apply. Martin is on vacation. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-10 06:59 Message: Logged In: YES user_id=86216 Martin (who is usually very responsive) seems to be on vacation or otherwise unavailable... Can someone approve this patch and the following? https://sourceforge.net/tracker/? func=detail&aid=676839&group_id=5470&atid=305470 Note that Tim has already indicated the following: Those specific patches are acceptable . Thanks. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-01-29 06:28 Message: Logged In: YES user_id=86216 Attaching patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676837&group_id=5470 From noreply@sourceforge.net Mon Feb 10 20:55:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 12:55:30 -0800 Subject: [Patches] [ python-Patches-681504 ] using gcc on cygwin for config Message-ID: Patches item #681504, was opened at 2003-02-06 01:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681504&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) >Assigned to: A.M. Kuchling (akuchling) Summary: using gcc on cygwin for config Initial Comment: On Cygwin, I noticed that distutils tries to use the cc compiler instead of the gcc compiler for the config step, resulting in an error. Instead, for the build step the correct compiler (gcc) is being used. For the build step, build_clib.py and build_ext.py contain a call to customize_compiler after the call to new_compiler. The call to customize_compiler causes gcc to be used on cygwin. In config.py, however, this call to customize_compiler after the call to new_compiler is missing. Adding the call to customize_compiler after the call to new_compiler in config.py solves this problem, and the config step then runs correctly on Cygwin. BTW, I noticed that in version 1.44.6.3 of sysconfig.py in CVS, the function get_python_version is missing, causing errors in the build step. This is the latest committed version of sysconfig.py. So I used version 1.56 instead (which was committed earlier than 1.44.6.3, but has a higher version number ??). Michiel de Hoon University of Tokyo, Human Genome Center ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 15:55 Message: Logged In: YES user_id=33168 amk, could you take a quick look at this patch to distutils? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-10 15:40 Message: Logged In: YES user_id=86216 > Adding a symlink would work, but I > am not sure if it is the best solution. Maybe both should be done? > Would that be OK with you? The patch is fine by me since it fixes Cygwin and I assume any other Unix (if any) without a /usr/bin/cc. > Or do you think there might be some problem > with the patch I submitted? No, I don't think that there will be problems with your patch. However, I cannot approve patches. I can only submit them like you. :,) Neal, should someone from distutils take a look-see. Or, is it OK for me to apply? ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2003-02-10 12:13 Message: Logged In: YES user_id=488897 OK thanks for your help. Adding a symlink would work, but I am not sure if it is the best solution. For the build step, distutils uses gcc automatically and doesn't need a symlink from cc. I think it is best if the config step mimics the build step as closely as possible, and having one solution for the build step and another for the config step might break things. For the patch that I submitted, I compared the config and the build step to find out where one chooses gcc and the other cc. The patch contains only one or two lines, and lets the config step choose gcc in the same way as the build step. Would that be OK with you? Or do you think there might be some problem with the patch I submitted? --Michiel. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-10 11:56 Message: Logged In: YES user_id=86216 OK, now I get it. Thanks for you help. I can reproduce the problem under Cygwin too. Now the question is, where is the right place to fix this? Under Red Hat 8.0, I get the following: $ ls -il /usr/bin/cc /usr/bin/c++ /usr/bin/g++ 328451 -rwxr-xr-x 4 root root 80780 Sep 3 23:03 /usr/bin/c++ 328396 lrwxrwxrwx 1 root root 3 Oct 21 10:04 /usr/bin/cc -> gcc 328451 -rwxr-xr-x 4 root root 80780 Sep 3 23:03 /usr/bin/g++ Under Cygwin, I get the following: $ ls -il /usr/bin/cc /usr/bin/c++ /usr/bin/g++ ls: /usr/bin/cc: No such file or directory 423677 lrwxrwxrwx 1 Administ Domain U 18 Dec 3 08:22 /usr/bin/c++ -> g++.exe 423679 -rwxrwxrwx 1 Administ Domain U 89600 Nov 14 17:37 /usr/bin/g++ So from the above, we can see that a symlink from cc to gcc could be considered missing under Cygwin. I will ask the Cygwin gcc maintainer to add this symlink. If the request is granted, will you consider this issue resolved? ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2003-02-10 11:06 Message: Logged In: YES user_id=488897 The config step is where you do python setup.py config where you can do some test compilations before doing "python setup.py build". Basically it works the same as autoconf/automake's configure scripts. The code for the config is in distutils/command/config.py. If you want to try it out, you can go to my website http://bonsai.ims.u-tokyo.ac.jp/~mdehoon, download pygist, unpack, and run "python setup.py config". You'll notice that it won't work on cygwin, as it tries to use cc instead of gcc. --Michiel. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-10 10:54 Message: Logged In: YES user_id=86216 > On Cygwin, I noticed that distutils tries to use the cc > compiler instead of the gcc compiler for the config > step, resulting in an error. Please excuse my ignorance, but what is the "config step?" How would one invoke the config step? Sorry, but I'm only lightly versed in distutils. > Instead, for the build > step the correct compiler (gcc) is being used. The build step seems to work fine under Cygwin Python 2.2.2 and CVS. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-07 17:55 Message: Logged In: YES user_id=33168 Jason, can you provide any input about the issues w/Cygwin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681504&group_id=5470 From noreply@sourceforge.net Mon Feb 10 20:56:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 12:56:23 -0800 Subject: [Patches] [ python-Patches-676839 ] Cygwin _iconv_codec module patch Message-ID: Patches item #676839, was opened at 2003-01-29 06:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676839&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: Cygwin _iconv_codec module patch Initial Comment: The (to be) attached patch enables the _iconv_codec module to build cleanly under Cygwin. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-02-10 11:56 Message: Logged In: YES user_id=86216 Checked in as Modules/_iconv_codec.c 1.10. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 07:31 Message: Logged In: YES user_id=33168 Patch is fine, please apply. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-01-29 06:31 Message: Logged In: YES user_id=86216 Attaching patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676839&group_id=5470 From noreply@sourceforge.net Mon Feb 10 22:56:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 14:56:42 -0800 Subject: [Patches] [ python-Patches-683939 ] Add download_url to setup() Message-ID: Patches item #683939, was opened at 2003-02-11 01:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683939&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Anthony Baxter (anthonybaxter) Summary: Add download_url to setup() Initial Comment: For a Python package installer, it would be a good idea to provide a "download URL" metadata keyword in the next release of Python. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-02-11 09:56 Message: Logged In: YES user_id=6405 IMO The line should be omitted. The patch doesn't touch the register command source - could that be done too? Perhaps the dict generation should be moved off to the DistributionMetadata class instead? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-02-11 02:34 Message: Logged In: YES user_id=11105 What will this line contain, if there are several download URLs possible (zip, tar.gz, multiple exe fir different Python versions?) Will it work with redirects a la Sourceforge? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-11 02:00 Message: Logged In: YES user_id=11375 The attached patch implements the new metadata keyword. Open question: if a value isn't provided, the PKG-INFO file will contain the line "Download-URL: UNKNOWN". Should the line simply be omitted in this case? There should be an updated metadata PEP; I'm not sure if PEP 241 should be edited or what, but will ask the relevant people. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683939&group_id=5470 From noreply@sourceforge.net Mon Feb 10 23:02:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 15:02:08 -0800 Subject: [Patches] [ python-Patches-684256 ] AutoThreadState implementation Message-ID: Patches item #684256, was opened at 2003-02-11 10:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684256&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: AutoThreadState implementation Initial Comment: An implementation of the AutoThreadState API, mainly for discussion purposes at this point. To be a PEP soon. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684256&group_id=5470 From noreply@sourceforge.net Tue Feb 11 00:03:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 16:03:55 -0800 Subject: [Patches] [ python-Patches-683939 ] Add download_url to setup() Message-ID: Patches item #683939, was opened at 2003-02-11 01:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683939&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Anthony Baxter (anthonybaxter) Summary: Add download_url to setup() Initial Comment: For a Python package installer, it would be a good idea to provide a "download URL" metadata keyword in the next release of Python. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-02-11 11:03 Message: Logged In: YES user_id=6405 Sorry, I was responding to the question "Should the line simply be omitted in this case"? I was also entirely vague about the "dict generation" bit too. I was referring to the build_post_data method in the register command source. In response to the multiple downloads question, I believe this is an open question still (as to whether multiple download sources are to be allowed). PyPI currently allows a single download URL, but since it's still in "test" mode, I could easily change that. Sourceforge doesn't auto-redirect if there's no session cookie present. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-02-11 09:56 Message: Logged In: YES user_id=6405 IMO The line should be omitted. The patch doesn't touch the register command source - could that be done too? Perhaps the dict generation should be moved off to the DistributionMetadata class instead? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-02-11 02:34 Message: Logged In: YES user_id=11105 What will this line contain, if there are several download URLs possible (zip, tar.gz, multiple exe fir different Python versions?) Will it work with redirects a la Sourceforge? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-11 02:00 Message: Logged In: YES user_id=11375 The attached patch implements the new metadata keyword. Open question: if a value isn't provided, the PKG-INFO file will contain the line "Download-URL: UNKNOWN". Should the line simply be omitted in this case? There should be an updated metadata PEP; I'm not sure if PEP 241 should be edited or what, but will ask the relevant people. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683939&group_id=5470 From noreply@sourceforge.net Tue Feb 11 04:58:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 20:58:58 -0800 Subject: [Patches] [ python-Patches-684398 ] Fix for verbosity Message-ID: Patches item #684398, was opened at 2003-02-11 15:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684398&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for verbosity Initial Comment: I'd forgotten about this until I just tried to run the register command in 2.3 myself :) I've changed the server response display from using the "verbose" flag to using a new "show-response" flag. I also changed the code that collects the post metadata, since the classifiers attribute will always be available to this code. The download_url metadata attribute implemented by patch www.python.org/sf/683939 is not handled by this patch - it still needs to be added to the post data. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684398&group_id=5470 From xbossb@fun.agava.net Tue Feb 11 06:02:12 2003 From: xbossb@fun.agava.net (xboss.publichosting.ru) Date: Tue, 11 Feb 2003 09:02:12 +0300 (MSK) Subject: [Patches] list Message-ID: <20030211060212.6A7964512C@fun.agava.net> ÏÎÐÀ ÎÁÍÎÂËßÒÜ ÑÏÀÌËÈÑÒ! 2 225 000 "ñâåæèõ" àäðåñîâ çîí .ru è .su Äàòà ñîñòàâëåíèÿ ëèñòà - ÿíâàðü 2003 ãîäà Âñå àäðåñà ðàáî÷èå Öåíà 30 - ó.å. Ïëþñ ÒÐÈ ÏÐÎÃÐÀÌÌÛ ÄËß ÐÀÑÑÛËÊÈ ÏÎ×ÒÛ - áåñïëàòíî 1 Persmail ïðîãðàììà, ðàññûëàþùàÿ ïî÷òó ñ âàøåãî êîìïüþòåðà ÷åðåç àíîíèìíûé smtp ñåðâåð 2 Postbomber -íîâèíêà ! ïðîãðàììà - ñêðèïò íà PHP - ðàññûëàåò ïî÷òó ñ âèðòóàëüíîãî õîñòà áîëåå 1000 øò â ìèíóòó ïðè ýòîì íàãðóçêà íà âàø êàíàë íóëåâàÿ, âàø IP îñòàåòñÿ àíîíèìíûì íå òðåáóåòñÿ ïîñòîÿííîé ñÿçè ñ èíòåðíåòîì.Ïðîãðàììà íå òðåáóåò íèêàêèõ íàñòðîåê êðîìå óêàçàíèÿ ôàéëîâ ñ òåêñòîì ïèñüìà è ñïàìëèñòîì. 3 Spamadmin ïðîãðàììà - ñêðèïò íà Perl - ðàññûëàåò ïî÷òó ñ âèðòóàëüíîãî õîñòà c îãðîìíîé ñêîðîñòüþ ïðè ýòîì íàãðóçêà íà âàø êàíàë íóëåâàÿ, âàø IP îñòàåòñÿ àíîíèìíûì íå òðåáóåòñÿ ïîñòîÿííîé ñÿçè ñ èíòåðíåòîì.Ïðîãðàììà òðåáóåò íåñëîæíîé íàñòðîéêè ÂÍÈÌÀÍÈÅ: ïðåäëàãàåìàÿ òåõíîëîãèÿ ïîçâîëÿåò ðàññûëàòü ýëåêòðîííóþ ïî÷òó, íàðóøàÿ âñå ýòè÷åñêèå íîðìû, öàðÿùèå â Internet, è äàæå çàêîíû íåêîòîðûõ ñòðàí. Âñÿ îòâåòñòâåííîñòü çà ýòè íàðóøåíèÿ ëåæèò íà ïîëüçîâàòåëå òåõíîëîãèè, òàêæå Âû ïîäòâåðæäàåòå ñâî¸ ñîãëàñèå, ÷òî íèêîãäà, íè ïðè êàêèõ óñëîâèÿõ íå áóäåòå èìåòü ïðåòåíçèé ê àâòîðó, ïîñëå ïðèìåíåíèÿ äàííîãî ïðîäóêòà. Óâàæàåìûå ïîêóïàòåëè !  ñîñòàâ ïðåäëàãàåìîãî ïàêåòà äîïîëíèòåëüíî âõîäÿò: 1.Îïèñàíèå âñåõ íàñòðîåê äëÿ êàæäîé ïðîãðàììû 2.Ïîäðîáíîå îïèñàíèå ïðîöåññîâ ïîäãîòîâêè, íàñòðîéêè è ïðîâåäåíèÿ ðàññûëêè. 4.Ðåêîìåíäàöèè ïî âûáîðó õîñòîâ äëÿ ðàçìåùåíèÿ postbomber èëè spamadmin. 5.Êîíñóëüòàöèè ïî ðàçâîðà÷èâàíèþ ñèñòåìû. Âñå ðàñ÷åòû ñ íàìè áóäóò ïðîèçâîäèòüñÿ ïîñðåäñòâîì ñèñòåìû WebMoney. Âû äîëæíû áóäåòå ïåðåâåñòè 30WMZ èëè 1050WMR íà êîøåëüêè Âàëþòíûé êîøåëåê ($): Z565436570061 Ðóáëåâûé êîøåëåê (R): R764251716405 Âíèìàíèå: áåç ïðîòåêöèè ñäåëêè!  ïðèìå÷àíèè îáÿçàòåëüíî óêàæèòå "Çà ñïàì ïàêåò (âàø@e-mail.ru)". Âàì áóäóò âûñëàíû ïðîãðàììû è URL, îòêóäà Âû ñìîæåòå ñêà÷àòü ñïàìëèñò (îáúåì - 9.23 Ìá). ÂÍÈÌÀÍÈÅ: Åñëè ó âàñ âîçíèêíåò íåîáõîäèìîñòü íàïèñàòü íàì íå îòâå÷àéòå íà ýòî ïèñüìî.Ïèøèòå íàì ïî àäðåñó: (íàø E-mail) spamsender@freemail.ru PS. Äàííîå ïèñüìî ðàçîñëàíî â ñîîòâåòñòâèè ñ ÷. 4 ñò. 29 Êîíñòèòóöèè ÐÔ è ÷. 1 ñò. 27 Ôåäåðàëüíîãî Çàêîíà ÐÔ îò 16 ôåâðàëÿ 1995 ãîäà N 15-ÔÇ. From noreply@sourceforge.net Tue Feb 11 07:30:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Feb 2003 23:30:03 -0800 Subject: [Patches] [ python-Patches-680863 ] replace() method in unicode objects Message-ID: Patches item #680863, was opened at 2003-02-05 14:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680863&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Juhlin (faeltir) Assigned to: Nobody/Anonymous (nobody) Summary: replace() method in unicode objects Initial Comment: Hi, I found that unlike the string object, the replace() method in the unicode object doesn't throw an exception when you supply an empty pattern string. Instead it slaps on the replace string a few times at the end. I'm supplying a patch to make the unicode object behave like the string object. I realize that in 2.3, doing replace() with an empty pattern string will work differently so maybe you don't consider throwing an exception the Right Way(TM), but I'm presenting it to you in case you (like me) thinks it's just better if unicode and string objects behave in the same way while not changing the way that string objects currently work in 2.2. Best regards, Fredrik Juhlin ---------------------------------------------------------------------- >Comment By: Fredrik Juhlin (faeltir) Date: 2003-02-11 08:30 Message: Logged In: YES user_id=386805 I checked the CVS and saw that it had not been touched, which is why I supplied the patch to make it act in the same manner as strings :) The two options seems to be to either solve it in the manner that my patch does or make both behave like in 2.3. While I realize that my opinion weighs light, not being part of the coding team in any way, it seems to me like the road of least surprise is the better way to go for a minor release and that would be to not change the obviously deliberate behaviour of the string object. Well, that's my two cents :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 21:20 Message: Logged In: YES user_id=33168 The change for 2.3 was on purpose. See Objects/stringobject.c 2.184 which fixed SF bug 595350. Hmmm, unicode doesn't even do it right in 2.2.2+ >>> u"x".replace("", "a") u'xaa' Not sure what to do to fix for 2.2.3. :-( ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 20:36 Message: Logged In: YES user_id=92689 What I'm not sure of is whether the fact that this: "x".replace("", "a") raises an exception in 2.2 and "works" in 2.3 is intentional. It returns this in 2.3: 'axa'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680863&group_id=5470 From noreply@sourceforge.net Tue Feb 11 08:37:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Feb 2003 00:37:14 -0800 Subject: [Patches] [ python-Patches-680863 ] replace() method in unicode objects Message-ID: Patches item #680863, was opened at 2003-02-05 14:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680863&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Juhlin (faeltir) Assigned to: Nobody/Anonymous (nobody) Summary: replace() method in unicode objects Initial Comment: Hi, I found that unlike the string object, the replace() method in the unicode object doesn't throw an exception when you supply an empty pattern string. Instead it slaps on the replace string a few times at the end. I'm supplying a patch to make the unicode object behave like the string object. I realize that in 2.3, doing replace() with an empty pattern string will work differently so maybe you don't consider throwing an exception the Right Way(TM), but I'm presenting it to you in case you (like me) thinks it's just better if unicode and string objects behave in the same way while not changing the way that string objects currently work in 2.2. Best regards, Fredrik Juhlin ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-02-11 09:37 Message: Logged In: YES user_id=92689 I'm not following you, in 2.3 CVS, "a".replace("", "x") yields "xax", yet with your patch the same thing with a unicode string raises an exception... ---------------------------------------------------------------------- Comment By: Fredrik Juhlin (faeltir) Date: 2003-02-11 08:30 Message: Logged In: YES user_id=386805 I checked the CVS and saw that it had not been touched, which is why I supplied the patch to make it act in the same manner as strings :) The two options seems to be to either solve it in the manner that my patch does or make both behave like in 2.3. While I realize that my opinion weighs light, not being part of the coding team in any way, it seems to me like the road of least surprise is the better way to go for a minor release and that would be to not change the obviously deliberate behaviour of the string object. Well, that's my two cents :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 21:20 Message: Logged In: YES user_id=33168 The change for 2.3 was on purpose. See Objects/stringobject.c 2.184 which fixed SF bug 595350. Hmmm, unicode doesn't even do it right in 2.2.2+ >>> u"x".replace("", "a") u'xaa' Not sure what to do to fix for 2.2.3. :-( ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 20:36 Message: Logged In: YES user_id=92689 What I'm not sure of is whether the fact that this: "x".replace("", "a") raises an exception in 2.2 and "works" in 2.3 is intentional. It returns this in 2.3: 'axa'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680863&group_id=5470 From noreply@sourceforge.net Tue Feb 11 09:15:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Feb 2003 01:15:12 -0800 Subject: [Patches] [ python-Patches-680863 ] replace() method in unicode objects Message-ID: Patches item #680863, was opened at 2003-02-05 14:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680863&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Juhlin (faeltir) Assigned to: Nobody/Anonymous (nobody) Summary: replace() method in unicode objects Initial Comment: Hi, I found that unlike the string object, the replace() method in the unicode object doesn't throw an exception when you supply an empty pattern string. Instead it slaps on the replace string a few times at the end. I'm supplying a patch to make the unicode object behave like the string object. I realize that in 2.3, doing replace() with an empty pattern string will work differently so maybe you don't consider throwing an exception the Right Way(TM), but I'm presenting it to you in case you (like me) thinks it's just better if unicode and string objects behave in the same way while not changing the way that string objects currently work in 2.2. Best regards, Fredrik Juhlin ---------------------------------------------------------------------- >Comment By: Fredrik Juhlin (faeltir) Date: 2003-02-11 10:15 Message: Logged In: YES user_id=386805 Hello again, I'm sorry for being unclear, I meant in the release22-maint branch of the CVS, which I (perhaps mistakenly?) assumed is the branch that all 2.2.* releases are made from. Since I thought (apparently correctly) that the change in 2.3 was deliberate, I didn't think it was an issue for the trunk. Again, I'm sorry for not being clear on that. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-11 09:37 Message: Logged In: YES user_id=92689 I'm not following you, in 2.3 CVS, "a".replace("", "x") yields "xax", yet with your patch the same thing with a unicode string raises an exception... ---------------------------------------------------------------------- Comment By: Fredrik Juhlin (faeltir) Date: 2003-02-11 08:30 Message: Logged In: YES user_id=386805 I checked the CVS and saw that it had not been touched, which is why I supplied the patch to make it act in the same manner as strings :) The two options seems to be to either solve it in the manner that my patch does or make both behave like in 2.3. While I realize that my opinion weighs light, not being part of the coding team in any way, it seems to me like the road of least surprise is the better way to go for a minor release and that would be to not change the obviously deliberate behaviour of the string object. Well, that's my two cents :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 21:20 Message: Logged In: YES user_id=33168 The change for 2.3 was on purpose. See Objects/stringobject.c 2.184 which fixed SF bug 595350. Hmmm, unicode doesn't even do it right in 2.2.2+ >>> u"x".replace("", "a") u'xaa' Not sure what to do to fix for 2.2.3. :-( ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 20:36 Message: Logged In: YES user_id=92689 What I'm not sure of is whether the fact that this: "x".replace("", "a") raises an exception in 2.2 and "works" in 2.3 is intentional. It returns this in 2.3: 'axa'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680863&group_id=5470 From noreply@sourceforge.net Tue Feb 11 09:40:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Feb 2003 01:40:06 -0800 Subject: [Patches] [ python-Patches-680863 ] replace() method in unicode objects Message-ID: Patches item #680863, was opened at 2003-02-05 14:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680863&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Juhlin (faeltir) Assigned to: Nobody/Anonymous (nobody) Summary: replace() method in unicode objects Initial Comment: Hi, I found that unlike the string object, the replace() method in the unicode object doesn't throw an exception when you supply an empty pattern string. Instead it slaps on the replace string a few times at the end. I'm supplying a patch to make the unicode object behave like the string object. I realize that in 2.3, doing replace() with an empty pattern string will work differently so maybe you don't consider throwing an exception the Right Way(TM), but I'm presenting it to you in case you (like me) thinks it's just better if unicode and string objects behave in the same way while not changing the way that string objects currently work in 2.2. Best regards, Fredrik Juhlin ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-02-11 10:40 Message: Logged In: YES user_id=92689 Sorry, it was me who was sleeping. I thought there was both an issue with 2.2.2 as well as with 2.3... It seems 2.3 is fine. Sorry for the added confusion! ---------------------------------------------------------------------- Comment By: Fredrik Juhlin (faeltir) Date: 2003-02-11 10:15 Message: Logged In: YES user_id=386805 Hello again, I'm sorry for being unclear, I meant in the release22-maint branch of the CVS, which I (perhaps mistakenly?) assumed is the branch that all 2.2.* releases are made from. Since I thought (apparently correctly) that the change in 2.3 was deliberate, I didn't think it was an issue for the trunk. Again, I'm sorry for not being clear on that. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-11 09:37 Message: Logged In: YES user_id=92689 I'm not following you, in 2.3 CVS, "a".replace("", "x") yields "xax", yet with your patch the same thing with a unicode string raises an exception... ---------------------------------------------------------------------- Comment By: Fredrik Juhlin (faeltir) Date: 2003-02-11 08:30 Message: Logged In: YES user_id=386805 I checked the CVS and saw that it had not been touched, which is why I supplied the patch to make it act in the same manner as strings :) The two options seems to be to either solve it in the manner that my patch does or make both behave like in 2.3. While I realize that my opinion weighs light, not being part of the coding team in any way, it seems to me like the road of least surprise is the better way to go for a minor release and that would be to not change the obviously deliberate behaviour of the string object. Well, that's my two cents :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 21:20 Message: Logged In: YES user_id=33168 The change for 2.3 was on purpose. See Objects/stringobject.c 2.184 which fixed SF bug 595350. Hmmm, unicode doesn't even do it right in 2.2.2+ >>> u"x".replace("", "a") u'xaa' Not sure what to do to fix for 2.2.3. :-( ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 20:36 Message: Logged In: YES user_id=92689 What I'm not sure of is whether the fact that this: "x".replace("", "a") raises an exception in 2.2 and "works" in 2.3 is intentional. It returns this in 2.3: 'axa'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=680863&group_id=5470 From agapelove0bes4@aol.com Tue Feb 11 10:17:05 2003 From: agapelove0bes4@aol.com (Edoameth) Date: Tue, 11 Feb 2003 10:17:05 GMT Subject: [Patches] patches, Immediate Help Required - Fort 500 comp Message-ID: <200302110952.h1B9qQi25081@www.jangjeon.ms.kr> Dear patches@python.org , Immediate Help Needed. We are a .com corporation that is growing at a tremendous rate of over 1000% per year. We simply cannot keep up. We are looking for motivated individuals who are looking to earn a substantial income working from home. This is a real world opportunity to make an excellent income from home. No experience is required. We will provide you with any training you may need. We are looking for energetic and self motivated people. If that is you, then click on the link below and complete our online information request form, and one of our employment specialist will contact you. http://www.workathomeoppss.com/tlu.htm So if you are looking to be employed at home, with a career that will provide you vast opportunities and a substantial income, please fill out our online information request form here now: http://www.workathomeoppss.com/tlu.htm ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Your email address was obtained from an opt-in list. If you wish to be deleted from this list, please click on the following link: http://www.workathomeoppss.com/remove/remove.html and you will be removed from the list. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From noreply@sourceforge.net Tue Feb 11 10:26:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Feb 2003 02:26:51 -0800 Subject: [Patches] [ python-Patches-684500 ] extending readline functionality Message-ID: Patches item #684500, was opened at 2003-02-11 11:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684500&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Vitecek (fufsource) Assigned to: Nobody/Anonymous (nobody) Summary: extending readline functionality Initial Comment: this simple patch adds two new methods to module readline: 1) remove_history() -- which removes history item specified by its position 2) replace_history() which replaces history item specified by its position with another line libreadline.tex has been modified as well. thank you for consideration. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684500&group_id=5470 From noreply@sourceforge.net Tue Feb 11 11:23:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Feb 2003 03:23:12 -0800 Subject: [Patches] [ python-Patches-675551 ] extending readline functionality Message-ID: Patches item #675551, was opened at 2003-01-27 17:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675551&group_id=5470 Category: Library (Lib) Group: Python 2.2.x >Status: Deleted >Resolution: Invalid Priority: 5 Submitted By: Michal Vitecek (fufsource) Assigned to: Nobody/Anonymous (nobody) Summary: extending readline functionality Initial Comment: this patch against vanilla 2.2.2 adds three new functions to module readline: remove_history(pos) -- remove history entry specified by pos replace_history_entry(pos, line) -- replace history entry specified by pos with the given line get_history_buffer_size() -- get current number of history entries the libreadline.tex is also modified. thank you for your consideration. ---------------------------------------------------------------------- >Comment By: Michal Vitecek (fufsource) Date: 2003-02-11 12:23 Message: Logged In: YES user_id=698198 this patch is invalid as no functionality extensions are allowed in a stable python version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675551&group_id=5470 From noreply@sourceforge.net Tue Feb 11 14:51:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Feb 2003 06:51:12 -0800 Subject: [Patches] [ python-Patches-684612 ] Macintosh documentation patches Message-ID: Patches item #684612, was opened at 2003-02-11 15:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684612&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: Macintosh documentation patches Initial Comment: Fred, you won't believe this, but I actually went through the Mac documentation! :-) Attached is a patch. I haven't checked it in myself (although I can finally make the documentation with latex) as the exact usage of the gazillion latex macros is still pretty opaque to me, so I've probably done lots of things wrong. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684612&group_id=5470 From noreply@sourceforge.net Tue Feb 11 15:59:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Feb 2003 07:59:37 -0800 Subject: [Patches] [ python-Patches-684677 ] Allow freeze to exclude implicits Message-ID: Patches item #684677, was opened at 2003-02-11 15:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684677&group_id=5470 Category: Demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lawrence Hudson (lhudson) Assigned to: Nobody/Anonymous (nobody) Summary: Allow freeze to exclude implicits Initial Comment: Freeze always freezes site and exceptions. This patch allows these implicit modules to be excluded using the -x switch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684677&group_id=5470 From noreply@sourceforge.net Tue Feb 11 18:55:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Feb 2003 10:55:19 -0800 Subject: [Patches] [ python-Patches-661796 ] BZ2File leaking fd and memory Message-ID: Patches item #661796, was opened at 2003-01-03 19:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661796&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Gustavo Niemeyer (niemeyer) Summary: BZ2File leaking fd and memory Initial Comment: The attached patch fixes BZ2File() leaking the fd and PyFileObject* info (name, read ahead buffer) when an object is deleted. I'm not sure the patch fixes these problems in the best way. It exposes most of the implementation from fileobject.c::file_dealloc() through a private API _PyFile_Dealloc(). BZ2File derives from PyFileObject. Make sure the file: 'empty' exists and do: from bz2 import * A simple test which demonstrates the problem is: for i in range(100000): o = BZ2File('empty') ; del o Without the patch, you quickly get: IOError: [Errno 24] Too many open files: 'empty' You can modify this to: for i in range(100000): o = BZ2File('empty') ; o.close() ; del o Now you can see the memory leaks. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-02-11 18:55 Message: Logged In: YES user_id=7887 Fixed in the following revisions: Modules/bz2module.c: 1.15 Doc/lib/libbz2.tex: 1.6 Thanks to everybody. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 16:09 Message: Logged In: YES user_id=6380 Thanks! I expect you'll be surprised at the gained clarity of the resulting code. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-02-03 15:52 Message: Logged In: YES user_id=7887 Ok.. I can't find a good way to workaround the presented reasons. I'll work to unparent BZ2File. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 14:51 Message: Logged In: YES user_id=6380 IMO, being a subclass of a concrete class typically only makes sense if you can maintain the meaning of the instance variables defined by the base class. In this case I don't believe that's the case. If looks like you are using subclassing from the file class where you should really be using an instance variable that points to a regular file object. For example, operations on the file descriptor returned by fileno() have a very different effect for a BZ2file than for a regular file (since they manipulate the compressed file rather than the uncompressed byte stream represented by the BZ2file). You may also confuse other parts of the Python runtime that assume that when they see a file instance they can extract the underlying stdio FILE* from it and manipulate that. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-02-03 12:07 Message: Logged In: YES user_id=7887 zlib module doesn't emulate a file at C level. It also does not implement as many features as the BZ2File does (universal newlines, buffered IO, etc). The strange thing is, I thought it was a good thing to develop inheriting FileObject that way, since it would save code and maintenance, while being fast. I also thought it was a good model to make BZ2File behave as a subclass (I even mentioned that in the documentation). I'm surprised for being wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-02 12:57 Message: Logged In: YES user_id=6380 I don't understand. Why would you want to copy all the implementation details of those functions? Have a look at how the zlib module emulates a file. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-02-02 04:21 Message: Logged In: YES user_id=7887 Ok, I've started to "unparent" the bz2 code. OTOH, I've just realised what a lot of code, full of #ifdef's, I'll have to copy, mostly unchanged. The following functions file_new(), file_init(), open_the_file(), fill_file_fields(), dircheck(), close_file(), get_newlines(), _portable_fseek(), file_seek(), file_repr(), and the following arrays file_memberlist[], file_getsetlist[] My question is, do you think it's better to maintain all this code duplicated than maintaining bz2 up to date? I'll do the job, if you still think this is great. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-22 17:29 Message: Logged In: YES user_id=6380 If you could, that would be great. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-01-22 15:39 Message: Logged In: YES user_id=7887 Ok. Do you want me to work on this for 2.3? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-21 19:24 Message: Logged In: YES user_id=6380 FileObject sharing: I see. But I still think it's a bad idea, and you're better off using stdio methods directly (as the evolution of the FileObject implementation has already shown). ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-01-20 20:44 Message: Logged In: YES user_id=7887 Sorry about the delay. I was on a not-so-short vacation. nnorwitz: Thanks for the patch. I'll check the problem (for my own understanding) and most certainly apply it. gvanrossum: BZ2File used to share a lot of code with FileObject. Unfortunately (for the BZ2File side), FileObject changed considerably post 2.2, and some of the code had to be moved to BZ2File itself. It still uses some code from FileObject, though (open, close, seek, part of the softspace handling, access to attributes and some common methods). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-05 21:11 Message: Logged In: YES user_id=6380 Um, I don't understand why the BZ2File class inherits from FileObject. It doesn't seem to be inheriting any code, and there's no reason to inherit from FileObject just to make a file-like object. Maybe it was a misunderstanding? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 20:09 Message: Logged In: YES user_id=33168 I've found a better solution: change the last line of BZ2File_dealloc() from: ((PyObject*)self)->ob_type->tp_free((PyObject *)self); to PyFile_Type.tp_dealloc((PyObject *)self); Updated patch attached. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 19:48 Message: Logged In: YES user_id=21627 Assigning to the author of the module for review. Gustavo, if you can't find the time for a review, feel free to unassign it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661796&group_id=5470 From noreply@sourceforge.net Tue Feb 11 20:47:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Feb 2003 12:47:06 -0800 Subject: [Patches] [ python-Patches-684612 ] Macintosh documentation patches Message-ID: Patches item #684612, was opened at 2003-02-11 09:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684612&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) >Assigned to: Jack Jansen (jackjansen) Summary: Macintosh documentation patches Initial Comment: Fred, you won't believe this, but I actually went through the Mac documentation! :-) Attached is a patch. I haven't checked it in myself (although I can finally make the documentation with latex) as the exact usage of the gazillion latex macros is still pretty opaque to me, so I've probably done lots of things wrong. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-02-11 15:47 Message: Logged In: YES user_id=3066 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684612&group_id=5470 From noreply@sourceforge.net Tue Feb 11 21:44:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Feb 2003 13:44:53 -0800 Subject: [Patches] [ python-Patches-684612 ] Macintosh documentation patches Message-ID: Patches item #684612, was opened at 2003-02-11 15:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684612&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: Macintosh documentation patches Initial Comment: Fred, you won't believe this, but I actually went through the Mac documentation! :-) Attached is a patch. I haven't checked it in myself (although I can finally make the documentation with latex) as the exact usage of the gazillion latex macros is still pretty opaque to me, so I've probably done lots of things wrong. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-02-11 22:44 Message: Logged In: YES user_id=45365 Ok, trying again. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-02-11 21:47 Message: Logged In: YES user_id=3066 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684612&group_id=5470 From noreply@sourceforge.net Tue Feb 11 22:01:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Feb 2003 14:01:45 -0800 Subject: [Patches] [ python-Patches-684612 ] Macintosh documentation patches Message-ID: Patches item #684612, was opened at 2003-02-11 09:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684612&group_id=5470 Category: Documentation Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Jack Jansen (jackjansen) >Assigned to: Jack Jansen (jackjansen) Summary: Macintosh documentation patches Initial Comment: Fred, you won't believe this, but I actually went through the Mac documentation! :-) Attached is a patch. I haven't checked it in myself (although I can finally make the documentation with latex) as the exact usage of the gazillion latex macros is still pretty opaque to me, so I've probably done lots of things wrong. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-02-11 17:01 Message: Logged In: YES user_id=3066 Platform notes like "MacPython-OS9 only." should be spelled "Availability: MacPython-OS9." at the end of the description they modify, rather than at the beginning. This matches similar notes in the main library reference. I will probably be removing the \pytype macro; it doesn't really make much sense any more (and was rarely used anyway); you should always use \class now. Optional arguments which are not the first arg of a function or method should include the comma which *precedes* them included within their \optional: arg1\optional{, arg2\optional{, arg3}} Weird, but we're hitting limitations in my ability to munge things in LaTeX here. ;-( Go ahead and check-in after you've made these changes; at that point it'll be easier to work from CVS. Thanks for taking the time to update the docs! ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-11 16:44 Message: Logged In: YES user_id=45365 Ok, trying again. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-02-11 15:47 Message: Logged In: YES user_id=3066 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684612&group_id=5470 From noreply@sourceforge.net Tue Feb 11 22:09:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Feb 2003 14:09:36 -0800 Subject: [Patches] [ python-Patches-684944 ] extend readline functionality in pdb Message-ID: Patches item #684944, was opened at 2003-02-11 22:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684944&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Nobody/Anonymous (nobody) Summary: extend readline functionality in pdb Initial Comment: This patch allows readline completion of global and local variables while running code under pdb. Currently completion only works with the builtin pdb commands when in pdb. This patch uses the default pdb completer (in cmd.Cmd) to preserve the old completions, but adds completions in the current pdb execution frame. Patch is against current cvs. Let me know what you think. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684944&group_id=5470 From noreply@sourceforge.net Tue Feb 11 22:15:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Feb 2003 14:15:07 -0800 Subject: [Patches] [ python-Patches-677719 ] improved readline usage in pdb Message-ID: Patches item #677719, was opened at 2003-01-30 20:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677719&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Deleted >Resolution: Out of Date Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Nobody/Anonymous (nobody) Summary: improved readline usage in pdb Initial Comment: Adds tab-completion of locals and globals in the scope of the code being executed by pdb from the (Pdb) prompt. patchrlcomplete: * adds a local namespace to the arguments of Completer's constructor. Necessary to evaluate local objects correctly when doing completion. Defaults to None so backwards compatibility should be fine. * No longer always loads the Completer on import. Only loads it when a completer has not been assigned. This is better if someone has previously loaded a completer they don't want changed. Without this the pdb completer would have to save the old completer before importing the rlcompleter module to avoid the undesired side effect of pdb changing the completion function. * removes words.append('__class__') as it should already be included. I'm not sure if there's a good reason for this line. It was originally written by Michael Hudson I believe, perhaps he knows if there is someplace this does something? (this has nothing to do with the main work of this patch) * allows __builtins__ to be completed like anything else. Why not? Sometimes I want to look at __builtins__. Is there a reason not to allow it to be completed? (again, nothing to do with the main patch) patchpdb: * complete method overrides Cmd's complete method. Gives all completions from Cmd.complete followed by completions from rl_completer. Let me know what you think of it (the idea and the implementation). If you don't want my small irrelevant changes to rlcompleter, I can get rid of them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677719&group_id=5470 From noreply@sourceforge.net Tue Feb 11 23:08:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Feb 2003 15:08:01 -0800 Subject: [Patches] [ python-Patches-684981 ] fix for bug 501716 Message-ID: Patches item #684981, was opened at 2003-02-11 23:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684981&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Nobody/Anonymous (nobody) Summary: fix for bug 501716 Initial Comment: Fixes bug described there: "es#" parser marker leaks memory Also fixes two other minor leaks involving strings with encoded NULL's and when a bad buffer_len pointer is passed to PyArg_Parse... Is a nicer version of the patch I pasted in to the comments on the 501716 bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684981&group_id=5470 From noreply@sourceforge.net Wed Feb 12 01:45:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Feb 2003 17:45:59 -0800 Subject: [Patches] [ python-Patches-685051 ] fix for 680789: reprs in arraymodule Message-ID: Patches item #685051, was opened at 2003-02-11 19:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=685051&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: fix for 680789: reprs in arraymodule Initial Comment: arraymodule's repr used "string += ',' + el" for each element in the array. Lists and dicts did a string.join to build the repr. Attached patch builds a tuple of array elements and then joins them. This fixes the time issue, but I don't know enough about how you guys manage memory in each case to tell what impact that'll have on really, really big arrays (although I imagine it takes more memory). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=685051&group_id=5470 From noreply@sourceforge.net Wed Feb 12 01:59:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Feb 2003 17:59:58 -0800 Subject: [Patches] [ python-Patches-671454 ] Optimize dictionary resizing Message-ID: Patches item #671454, was opened at 2003-01-20 18:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671454&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Neal Norwitz (nnorwitz) Summary: Optimize dictionary resizing Initial Comment: Revisiting Oren’s fastnames patch, I think a simpler approach is warranted. Using a setitem macro skips a function call but doesn’t get to the root of problem. Likewise, a pointer search is not helpful because lookupstring() already attempts a pointer comparison first and a hash comparison as a fallback (also, a pointer search fails to find non- interned comparisons). There is more promise in optimizing the search/fail/fallback sequence of looking for locals, globals, and builtins, but the approach of using custom look-ups and having negative entries is too invasive. The real issue is that the dictionaries are too full. Whenever, it hits 2/3’s full, a resize is triggered which doubles the size of the dictionary, still leaving it relatively full and relatively close to the next (expensive) resize operation. This patch makes the setitem resize operation quadruple the size of the dictionary. This leads to fewer total resize operations and leaves the dictionary more sparsely populated (not only leading to fewer collisions, but allowing immediate detection of NOT IN without doing *any* comparisons of pointers or hashcodes). The patch is minimally invasive. It is only one line! However, is does change the order of dictionaries, so doctest style test code will sense the change immediately. Four timing suites are attached. Two, directly measure speed-ups for accessing globals and __builtins__. The other two are real world apps which tap into all facets of python including subclassing, lambdas and functionals, large and small dicts, a wide array of data structures, heavy processing of strings, tuples, and numbers. Each of the suites shows improvements ranging from 5% to 25%. PyStone also shows a marginal improvement which is surprising because it is dominated by fast locals. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-11 20:59 Message: Logged In: YES user_id=80475 I timed many different dictionary tune-ups and found that the optimal combination varies depending on the benchmark and needs of the application (uniquifying is store intensive and membership testing is retrieve intensive). The results also vary from processor to processor, and they depend on the amount/type of cache memory available. The tuning options include varying the dict resize trigger ratio from 2/3, altering the size of smalldict, quadrupling space upon resize, and special casing smaller dictionaries. At some point, I'll post the best of these and everyone can try it with their own apps and machine. All of the above parameters can be set arbitrarily and there is no reason to think that the current settings are the optimum for most time critical applications. The attached patch is simple and gives some improvement to many applications. I hesitate to push it forward with more independent timings in different environments. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671454&group_id=5470 From noreply@sourceforge.net Wed Feb 12 02:07:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Feb 2003 18:07:13 -0800 Subject: [Patches] [ python-Patches-685051 ] fix for 680789: reprs in arraymodule Message-ID: Patches item #685051, was opened at 2003-02-11 20:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=685051&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) >Assigned to: Raymond Hettinger (rhettinger) Summary: fix for 680789: reprs in arraymodule Initial Comment: arraymodule's repr used "string += ',' + el" for each element in the array. Lists and dicts did a string.join to build the repr. Attached patch builds a tuple of array elements and then joins them. This fixes the time issue, but I don't know enough about how you guys manage memory in each case to tell what impact that'll have on really, really big arrays (although I imagine it takes more memory). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=685051&group_id=5470 From noreply@sourceforge.net Wed Feb 12 11:51:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Feb 2003 03:51:51 -0800 Subject: [Patches] [ python-Patches-685268 ] imputil must respect __path__ for package submodules Message-ID: Patches item #685268, was opened at 2003-02-12 12:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=685268&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Soeren Fietzke (sfiet) Assigned to: Nobody/Anonymous (nobody) Summary: imputil must respect __path__ for package submodules Initial Comment: The imputil module does not look at the __path__ member of a package to find sub-modules. To reproduce, create a package with a submodule, i.e. directory structure like this: p1/ __init__.py sub/ spam.py contents of __init__.py: import os __path__.append(os.path.join(__path__[0], 'sub')) import spam contents of spam.py: print 'imported spam' Doing an "import p1" in a fresh Python session will succeed. However, after loading and installing imputil, it will fail: import imputil imputil._test_revamp() import p1 # <-- will not find module spam ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=685268&group_id=5470 From noreply@sourceforge.net Wed Feb 12 11:58:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Feb 2003 03:58:26 -0800 Subject: [Patches] [ python-Patches-685268 ] imputil must respect __path__ for package submodules Message-ID: Patches item #685268, was opened at 2003-02-12 12:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=685268&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Soeren Fietzke (sfiet) Assigned to: Nobody/Anonymous (nobody) Summary: imputil must respect __path__ for package submodules Initial Comment: The imputil module does not look at the __path__ member of a package to find sub-modules. To reproduce, create a package with a submodule, i.e. directory structure like this: p1/ __init__.py sub/ spam.py contents of __init__.py: import os __path__.append(os.path.join(__path__[0], 'sub')) import spam contents of spam.py: print 'imported spam' Doing an "import p1" in a fresh Python session will succeed. However, after loading and installing imputil, it will fail: import imputil imputil._test_revamp() import p1 # <-- will not find module spam ---------------------------------------------------------------------- >Comment By: Soeren Fietzke (sfiet) Date: 2003-02-12 12:58 Message: Logged In: YES user_id=710276 Oops, spaces were stripped out, so just to clarify: 'sub' should be a subdirectory of 'p1' in the above example: p1/__init__.py p1/sub/spam.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=685268&group_id=5470 From noreply@sourceforge.net Wed Feb 12 12:52:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Feb 2003 04:52:18 -0800 Subject: [Patches] [ python-Patches-685268 ] imputil must respect __path__ for package submodules Message-ID: Patches item #685268, was opened at 2003-02-12 12:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=685268&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Soeren Fietzke (sfiet) Assigned to: Nobody/Anonymous (nobody) Summary: imputil must respect __path__ for package submodules Initial Comment: The imputil module does not look at the __path__ member of a package to find sub-modules. To reproduce, create a package with a submodule, i.e. directory structure like this: p1/ __init__.py sub/ spam.py contents of __init__.py: import os __path__.append(os.path.join(__path__[0], 'sub')) import spam contents of spam.py: print 'imported spam' Doing an "import p1" in a fresh Python session will succeed. However, after loading and installing imputil, it will fail: import imputil imputil._test_revamp() import p1 # <-- will not find module spam ---------------------------------------------------------------------- Comment By: Soeren Fietzke (sfiet) Date: 2003-02-12 13:52 Message: Logged In: YES user_id=710276 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: Soeren Fietzke (sfiet) Date: 2003-02-12 12:58 Message: Logged In: YES user_id=710276 Oops, spaces were stripped out, so just to clarify: 'sub' should be a subdirectory of 'p1' in the above example: p1/__init__.py p1/sub/spam.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=685268&group_id=5470 From noreply@sourceforge.net Wed Feb 12 16:47:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Feb 2003 08:47:30 -0800 Subject: [Patches] [ python-Patches-677887 ] Add traceback.format_exc Message-ID: Patches item #677887, was opened at 2003-01-31 01:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677887&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 4 Submitted By: Neil Schemenauer (nascheme) Assigned to: Raymond Hettinger (rhettinger) Summary: Add traceback.format_exc Initial Comment: I sometimes end up wanting this function. I think it compliments print_exc() nicely. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2003-02-12 16:47 Message: Logged In: YES user_id=35752 Argh! Here's the patch. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 19:40 Message: Logged In: YES user_id=92689 There's no file attached... ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-02-08 07:39 Message: Logged In: YES user_id=35752 Yes, feel free to reassign. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-07 05:58 Message: Logged In: YES user_id=80475 Did you intend to assign this one to me? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677887&group_id=5470 From noreply@sourceforge.net Wed Feb 12 21:00:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Feb 2003 13:00:00 -0800 Subject: [Patches] [ python-Patches-661536 ] handle unary op of constant in transformer.py Message-ID: Patches item #661536, was opened at 2003-01-03 05:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661536&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Jeremy Hylton (jhylton) Summary: handle unary op of constant in transformer.py Initial Comment: This fixes the only known (to me) remaining wart in the compiler package. It's a horrible patch, but I'm reasonably confident it's an accurate reflection of the corresponding bit of compile.c . ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-12 16:00 Message: Logged In: YES user_id=6380 Given the resolution of SF #660455, maybe this patch needs to be withdrawn? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661536&group_id=5470 From noreply@sourceforge.net Wed Feb 12 21:57:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Feb 2003 13:57:18 -0800 Subject: [Patches] [ python-Patches-683257 ] Patch for bug 580952: import lock should be exposed Message-ID: Patches item #683257, was opened at 2003-02-08 23:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683257&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open >Resolution: Accepted >Priority: 3 Submitted By: Jason Hildebrand (jdhildeb) >Assigned to: Guido van Rossum (gvanrossum) Summary: Patch for bug 580952: import lock should be exposed Initial Comment: See bug 580952 for all the details. I've attached patches against Python 2.3-2.2.99 (it would be great to have this in for 2.3 final), and also against Python 2.2.2 (for the next 2.2.x maintenance release). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-12 16:57 Message: Logged In: YES user_id=6380 I've applied the 2.3 patch, with some changes to avoid the fatal error in unlock_import(). Open issues: - This needs docs. Jason, can you provide a doc patch? - Why do you want this backported to 2.2? It's a new feature after all. Jason, can you comment on that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683257&group_id=5470 From noreply@sourceforge.net Wed Feb 12 22:16:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Feb 2003 14:16:52 -0800 Subject: [Patches] [ python-Patches-659834 ] Check for readline 2.2 features Message-ID: Patches item #659834, was opened at 2002-12-29 20:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=659834&group_id=5470 Category: Build Group: Python 2.2.x Status: Open >Resolution: Accepted >Priority: 5 Submitted By: Magnus Lie Hetland (mlh) >Assigned to: Nobody/Anonymous (nobody) Summary: Check for readline 2.2 features Initial Comment: This patch adds a snippet to configure.in, to check whether rl_completion_append_character (which is used in Python 2.3) is available. rl_prep_terminal is assumed to co-exist with rl_completion_append_character. It is assumed that HAVE_RL_COMPLETION_APPEND_CHARACTER will be used in readline.c to make it compatible with older versions of the readline library. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-12 17:16 Message: Logged In: YES user_id=6380 I need a volunteer to backport this to 2.2 who can run an older version of autoconf; the autoconf that I have installed is too new to process the 2.2 configure.in file. (The 2.3 version is already checked in.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-30 11:27 Message: Logged In: YES user_id=6380 Checked in. Thanks! Hm, this should be backported to 2.2.3 too! So I'll keep it open. ---------------------------------------------------------------------- Comment By: Magnus Lie Hetland (mlh) Date: 2002-12-29 21:11 Message: Logged In: YES user_id=20535 New patch for configure.in (added a comment) and a patch for readline.c that uses HAVE_RL_COMPLETION_APPEND_CHARACTER. Tested on Gentoo Linux with new readline (the new completion behaviour was preserved) and on Solaris with old readline (now compiles, with old completion behaviour in place). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=659834&group_id=5470 From noreply@sourceforge.net Thu Feb 13 02:58:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Feb 2003 18:58:27 -0800 Subject: [Patches] [ python-Patches-684612 ] Macintosh documentation patches Message-ID: Patches item #684612, was opened at 2003-02-11 09:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684612&group_id=5470 Category: Documentation Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Macintosh documentation patches Initial Comment: Fred, you won't believe this, but I actually went through the Mac documentation! :-) Attached is a patch. I haven't checked it in myself (although I can finally make the documentation with latex) as the exact usage of the gazillion latex macros is still pretty opaque to me, so I've probably done lots of things wrong. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-12 21:58 Message: Logged In: YES user_id=33168 Jack, didn't you check this in? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-02-11 17:01 Message: Logged In: YES user_id=3066 Platform notes like "MacPython-OS9 only." should be spelled "Availability: MacPython-OS9." at the end of the description they modify, rather than at the beginning. This matches similar notes in the main library reference. I will probably be removing the \pytype macro; it doesn't really make much sense any more (and was rarely used anyway); you should always use \class now. Optional arguments which are not the first arg of a function or method should include the comma which *precedes* them included within their \optional: arg1\optional{, arg2\optional{, arg3}} Weird, but we're hitting limitations in my ability to munge things in LaTeX here. ;-( Go ahead and check-in after you've made these changes; at that point it'll be easier to work from CVS. Thanks for taking the time to update the docs! ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-11 16:44 Message: Logged In: YES user_id=45365 Ok, trying again. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-02-11 15:47 Message: Logged In: YES user_id=3066 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684612&group_id=5470 From noreply@sourceforge.net Thu Feb 13 03:02:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Feb 2003 19:02:01 -0800 Subject: [Patches] [ python-Patches-675976 ] mhlib does not obey MHCONTEXT env var Message-ID: Patches item #675976, was opened at 2003-01-28 04:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675976&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Nobody/Anonymous (nobody) Summary: mhlib does not obey MHCONTEXT env var Initial Comment: All programs in the (N)MH suite of programs use the MHCONTEXT environment variable to find the so-called context file where the current folder is remembered. mhlib should do the same, so that it can be used in combination with the standard (N)MH programs. Also, when writing the context file, mhlib should replace the Current-Folder line but keep the other lines in tact. The attached patch fixes both problems. It introduces a new method for the class MH called getcontextfile which uses the MHCONTEXT environment variable to find the context file, and it uses the already existing function updateline to update the context file. Some questions concerning this patch: - should I document the new method or should it be an internal method only? - should the fix be ported to older Python versions? With the patch it does behave differently if you have an MHCONTEXT environment variable. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-12 22:02 Message: Logged In: YES user_id=33168 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675976&group_id=5470 From noreply@sourceforge.net Thu Feb 13 03:04:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Feb 2003 19:04:34 -0800 Subject: [Patches] [ python-Patches-671176 ] Compile _randommodule.c and datetimemodule.c under cygwin Message-ID: Patches item #671176, was opened at 2003-01-20 09:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671176&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Miki Tebeka (tebeka) >Assigned to: Neal Norwitz (nnorwitz) Summary: Compile _randommodule.c and datetimemodule.c under cygwin Initial Comment: Currently _randommodule.c and datetimemodule.c won't compile under cygwin. The usual 'Not a const' error. Attached is tar with both diffs Miki ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-12 22:04 Message: Logged In: YES user_id=33168 Closing this patch. There's no uploaded file and AFAIK cygwin works now. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-20 09:46 Message: Logged In: YES user_id=33168 There's no file attached. These changes may not be necessary based on changes Jason Tishler has made. See http://python.org/sf/661760 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671176&group_id=5470 From noreply@sourceforge.net Thu Feb 13 03:08:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Feb 2003 19:08:21 -0800 Subject: [Patches] [ python-Patches-682432 ] lookbehind tests Message-ID: Patches item #682432, was opened at 2003-02-07 12:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=682432&group_id=5470 Category: Tests >Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: engelbert gruber (grubert) >Assigned to: Neal Norwitz (nnorwitz) Summary: lookbehind tests Initial Comment: there were none in re_test.py (just in case upload does not work) *** re_tests.py Fri Feb 7 17:46:50 2003 --- new_test/re_tests.py Fri Feb 7 17:49:03 2003 *************** *** 548,553 **** --- 548,560 ---- ('a(?:b|(c|e){1,2}?|d)+?(.)', 'ace', SUCCEED, 'g1 + g2', 'ce'), ('^(.+)?B', 'AB', SUCCEED, 'g1', 'A'), + # lookbehind: split by : but not if it is escaped by -. + ('(?Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-12 22:08 Message: Logged In: YES user_id=33168 Thanks! Checked in as Lib/test/re_tests.py 1.32 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=682432&group_id=5470 From noreply@sourceforge.net Thu Feb 13 03:12:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Feb 2003 19:12:46 -0800 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 15:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: M.-A. Lemburg (lemburg) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-12 22:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 18:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 17:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 17:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 16:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 15:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 09:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 15:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 12:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 12:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 11:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 14:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 09:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 11:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 15:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Thu Feb 13 03:30:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Feb 2003 19:30:51 -0800 Subject: [Patches] [ python-Patches-645382 ] Don't FPE on FreeBSD... Message-ID: Patches item #645382, was opened at 2002-11-28 13:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645382&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ben Laurie (benl) Assigned to: Nobody/Anonymous (nobody) Summary: Don't FPE on FreeBSD... Initial Comment: --- Python-2.2.2/Objects/floatobject.c Sun May 12 17:20:38 2002 +++ Python-2.2.2-ben/Objects/floatobject.c Thu Nov 28 18:25:04 2002 @@ -645,7 +645,7 @@ long aslong; /* (long)wholepart */ (void)modf(x, &wholepart); -#ifdef RISCOS +#if defined(RISCOS) || defined(__FreeBSD__) /* conversion from floating to integral type would raise exception */ if (wholepart>LONG_MAX || wholepartComment By: Neal Norwitz (nnorwitz) Date: 2003-02-12 22:30 Message: Logged In: YES user_id=33168 Ben it's not clear to me if this should be applied to 2.3 and/or 2.2.2. Can you clarify what the problem is and which version(s) of FreeBSD have the problem. I tested the current CVS version on FreeBSD 4.7 (in the SF compile farm) and did not have any unexpected errors. Can you add a patch with tests too? ---------------------------------------------------------------------- Comment By: Ben Laurie (benl) Date: 2002-11-30 18:03 Message: Logged In: YES user_id=14333 In current CVS the problem is fixed, but others have been introduced. The enclosed patch fixes the FPE problems found so far. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-29 01:31 Message: Logged In: YES user_id=31435 Please try current CVS and see whether the problem is already fixed there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645382&group_id=5470 From noreply@sourceforge.net Thu Feb 13 03:43:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Feb 2003 19:43:47 -0800 Subject: [Patches] [ python-Patches-645382 ] Don't FPE on FreeBSD... Message-ID: Patches item #645382, was opened at 2002-11-28 13:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645382&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ben Laurie (benl) Assigned to: Nobody/Anonymous (nobody) Summary: Don't FPE on FreeBSD... Initial Comment: --- Python-2.2.2/Objects/floatobject.c Sun May 12 17:20:38 2002 +++ Python-2.2.2-ben/Objects/floatobject.c Thu Nov 28 18:25:04 2002 @@ -645,7 +645,7 @@ long aslong; /* (long)wholepart */ (void)modf(x, &wholepart); -#ifdef RISCOS +#if defined(RISCOS) || defined(__FreeBSD__) /* conversion from floating to integral type would raise exception */ if (wholepart>LONG_MAX || wholepartComment By: Tim Peters (tim_one) Date: 2003-02-12 22:43 Message: Logged In: YES user_id=31435 CVS Python later grew a single patch to python.c that turns off FreeBSD's non-standard exception behavior before Py_Main is called. We don't want #ifdef ugliness spreading all over the core. It only turns off one of FreeBSD's oddball behaviors, though, so without more info from the FP we can't know whether or not it address all the problems he saw. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-12 22:30 Message: Logged In: YES user_id=33168 Ben it's not clear to me if this should be applied to 2.3 and/or 2.2.2. Can you clarify what the problem is and which version(s) of FreeBSD have the problem. I tested the current CVS version on FreeBSD 4.7 (in the SF compile farm) and did not have any unexpected errors. Can you add a patch with tests too? ---------------------------------------------------------------------- Comment By: Ben Laurie (benl) Date: 2002-11-30 18:03 Message: Logged In: YES user_id=14333 In current CVS the problem is fixed, but others have been introduced. The enclosed patch fixes the FPE problems found so far. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-29 01:31 Message: Logged In: YES user_id=31435 Please try current CVS and see whether the problem is already fixed there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645382&group_id=5470 From noreply@sourceforge.net Thu Feb 13 05:22:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Feb 2003 21:22:01 -0800 Subject: [Patches] [ python-Patches-685738 ] fix for bug 638610 Message-ID: Patches item #685738, was opened at 2003-02-13 05:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=685738&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Nobody/Anonymous (nobody) Summary: fix for bug 638610 Initial Comment: I realize that bug has been closed, but I think it was still a good idea. This patch causes the following: class C(object): pass c = C(3) to throw a TypeError, like old style classes. It also necessitated some changes to test_descr as that was violating this principal for no apparent reason, and a change to copy_reg that I may not fully understand, so someone else should check it. As to backwards compatibility, this will only effect programs that were already having arguments silently ignored, and should probably be changed anyway. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=685738&group_id=5470 From noreply@sourceforge.net Thu Feb 13 08:56:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 13 Feb 2003 00:56:04 -0800 Subject: [Patches] [ python-Patches-684142 ] Korean Unicode Codecs Message-ID: Patches item #684142, was opened at 2003-02-11 05:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684142&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Korean Unicode Codecs Initial Comment: This is an compact implementation which is fully rewritten from KoreanCodecs (http://sf.net/projects/koco). It consumes about 50KB only as an installed binary. Supported encodings are euc-kr and cp949. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2003-02-11 05:28 Message: Logged In: YES user_id=55188 Enclosed files on patch: Lib/encodings/aliases.py : adding aliases for euc-kr and cp949 Lib/encodings/cp949.py : cp949 codec Lib/encodings/euc_kr.py : euc-kr codec setup.py : adding _ko_codecs module to default build. Modules/_ko_codecs.h : mapping data for KS X 1001 and CP949 Modules/_ko_codecs.c : C implementations for both codecs. Tools/unicode/genmap_ko_codecs.py : Generates _ko_codecs.h from CP949.TXT ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684142&group_id=5470 From noreply@sourceforge.net Thu Feb 13 09:48:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 13 Feb 2003 01:48:09 -0800 Subject: [Patches] [ python-Patches-675976 ] mhlib does not obey MHCONTEXT env var Message-ID: Patches item #675976, was opened at 2003-01-28 10:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675976&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Nobody/Anonymous (nobody) Summary: mhlib does not obey MHCONTEXT env var Initial Comment: All programs in the (N)MH suite of programs use the MHCONTEXT environment variable to find the so-called context file where the current folder is remembered. mhlib should do the same, so that it can be used in combination with the standard (N)MH programs. Also, when writing the context file, mhlib should replace the Current-Folder line but keep the other lines in tact. The attached patch fixes both problems. It introduces a new method for the class MH called getcontextfile which uses the MHCONTEXT environment variable to find the context file, and it uses the already existing function updateline to update the context file. Some questions concerning this patch: - should I document the new method or should it be an internal method only? - should the fix be ported to older Python versions? With the patch it does behave differently if you have an MHCONTEXT environment variable. ---------------------------------------------------------------------- >Comment By: Sjoerd Mullender (sjoerd) Date: 2003-02-13 10:48 Message: Logged In: YES user_id=43607 I can assure you that I did check that checkmark. Maybe it's my browser in combination with SF. We'll see if it works this time. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-13 04:02 Message: Logged In: YES user_id=33168 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675976&group_id=5470 From noreply@sourceforge.net Thu Feb 13 11:42:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 13 Feb 2003 03:42:41 -0800 Subject: [Patches] [ python-Patches-661536 ] handle unary op of constant in transformer.py Message-ID: Patches item #661536, was opened at 2003-01-03 10:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661536&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Jeremy Hylton (jhylton) Summary: handle unary op of constant in transformer.py Initial Comment: This fixes the only known (to me) remaining wart in the compiler package. It's a horrible patch, but I'm reasonably confident it's an accurate reflection of the corresponding bit of compile.c . ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-02-13 11:42 Message: Logged In: YES user_id=6656 Seems so. test_trace failed when compiled by the compiler package, though... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-12 21:00 Message: Logged In: YES user_id=6380 Given the resolution of SF #660455, maybe this patch needs to be withdrawn? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661536&group_id=5470 From noreply@sourceforge.net Thu Feb 13 13:05:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 13 Feb 2003 05:05:01 -0800 Subject: [Patches] [ python-Patches-684256 ] AutoThreadState implementation Message-ID: Patches item #684256, was opened at 2003-02-11 10:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684256&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: AutoThreadState implementation Initial Comment: An implementation of the AutoThreadState API, mainly for discussion purposes at this point. To be a PEP soon. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-02-14 00:05 Message: Logged In: YES user_id=14198 Attaching a new patch that works perfectly. 2 checks remain in the code that will be debug only, but apart from that, it is pretty good. No changes at all to existing semantics. Tested on Linux and Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684256&group_id=5470 From noreply@sourceforge.net Thu Feb 13 16:32:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 13 Feb 2003 08:32:00 -0800 Subject: [Patches] [ python-Patches-683257 ] Patch for bug 580952: import lock should be exposed Message-ID: Patches item #683257, was opened at 2003-02-08 22:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683257&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: Accepted Priority: 3 Submitted By: Jason Hildebrand (jdhildeb) Assigned to: Guido van Rossum (gvanrossum) Summary: Patch for bug 580952: import lock should be exposed Initial Comment: See bug 580952 for all the details. I've attached patches against Python 2.3-2.2.99 (it would be great to have this in for 2.3 final), and also against Python 2.2.2 (for the next 2.2.x maintenance release). ---------------------------------------------------------------------- >Comment By: Jason Hildebrand (jdhildeb) Date: 2003-02-13 10:32 Message: Logged In: YES user_id=173690 Yes, I can provide a doc patch. Is there anything that needs to be updated other than Doc/lib/libimp.tex? (I'm new to the python source tree) Re: backporting: Here's my reasoning: For a multithreaded Python app which needs to use an import hook, there is no way to do this reliably without access to the internal import lock. If the app uses a separate lock it is possible for a deadlock to happen (see bug 580952 for explanation), yet if no locking is done the runtime environment can get really screwed up (I've seen it happen). So from the perspective of such an app, the Python import API is buggy/incomplete because it provides no safe way to use an import hook. Therefore I view this patch more as a fix than a new feature. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-12 15:57 Message: Logged In: YES user_id=6380 I've applied the 2.3 patch, with some changes to avoid the fatal error in unlock_import(). Open issues: - This needs docs. Jason, can you provide a doc patch? - Why do you want this backported to 2.2? It's a new feature after all. Jason, can you comment on that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683257&group_id=5470 From noreply@sourceforge.net Thu Feb 13 16:33:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 13 Feb 2003 08:33:14 -0800 Subject: [Patches] [ python-Patches-685738 ] fix for bug 638610 Message-ID: Patches item #685738, was opened at 2003-02-13 00:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=685738&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Nobody/Anonymous (nobody) Summary: fix for bug 638610 Initial Comment: I realize that bug has been closed, but I think it was still a good idea. This patch causes the following: class C(object): pass c = C(3) to throw a TypeError, like old style classes. It also necessitated some changes to test_descr as that was violating this principal for no apparent reason, and a change to copy_reg that I may not fully understand, so someone else should check it. As to backwards compatibility, this will only effect programs that were already having arguments silently ignored, and should probably be changed anyway. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 11:33 Message: Logged In: YES user_id=6380 Thanks! That looks good, I've checked it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=685738&group_id=5470 From noreply@sourceforge.net Thu Feb 13 17:11:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 13 Feb 2003 09:11:48 -0800 Subject: [Patches] [ python-Patches-683257 ] Patch for bug 580952: import lock should be exposed Message-ID: Patches item #683257, was opened at 2003-02-08 23:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683257&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 3 Submitted By: Jason Hildebrand (jdhildeb) Assigned to: Guido van Rossum (gvanrossum) Summary: Patch for bug 580952: import lock should be exposed Initial Comment: See bug 580952 for all the details. I've attached patches against Python 2.3-2.2.99 (it would be great to have this in for 2.3 final), and also against Python 2.2.2 (for the next 2.2.x maintenance release). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 12:11 Message: Logged In: YES user_id=6380 Neal Norwitz already add the docs and a test. :-) Some belated feedback on your patch: when returning Py_None, you must Py_INCREF(Py_None)! Also, please use trailing \ in multi-line string literals; the C std requires this even though GCC doesn't. :-) (Thanks Neal!) ---------------------------------------------------------------------- Comment By: Jason Hildebrand (jdhildeb) Date: 2003-02-13 11:32 Message: Logged In: YES user_id=173690 Yes, I can provide a doc patch. Is there anything that needs to be updated other than Doc/lib/libimp.tex? (I'm new to the python source tree) Re: backporting: Here's my reasoning: For a multithreaded Python app which needs to use an import hook, there is no way to do this reliably without access to the internal import lock. If the app uses a separate lock it is possible for a deadlock to happen (see bug 580952 for explanation), yet if no locking is done the runtime environment can get really screwed up (I've seen it happen). So from the perspective of such an app, the Python import API is buggy/incomplete because it provides no safe way to use an import hook. Therefore I view this patch more as a fix than a new feature. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-12 16:57 Message: Logged In: YES user_id=6380 I've applied the 2.3 patch, with some changes to avoid the fatal error in unlock_import(). Open issues: - This needs docs. Jason, can you provide a doc patch? - Why do you want this backported to 2.2? It's a new feature after all. Jason, can you comment on that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683257&group_id=5470 From guido@python.org Thu Feb 13 17:52:12 2003 From: guido@python.org (Guido van Rossum) Date: Thu, 13 Feb 2003 12:52:12 -0500 Subject: [Patches] Changing SF tracker email preferences Message-ID: <200302131752.h1DHqCi00785@odiug.zope.com> When a new bug or patch is posted to a SF tracker, an email gets sent to python-bugs-list@python.org or patches@python.org. But... when anything is changed or added to those trackers, an email is *also* sent to those lists. I would like to receive the first kind of traffic (new tracker issues) but not the second kind, except for those tracker issues in which I am interested (which I can get by explicit turning on monitoring of those issues, or by following up). The SF tracker admin has an option to allow this: all I have to do is uncheck the box that says "Send email on all changes". I would really like to do this. Would anybody who is currently receiving bugs or patches traffic be bothered if I made this change? --Guido van Rossum (home page: http://www.python.org/~guido/) From noreply@sourceforge.net Thu Feb 13 18:02:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 13 Feb 2003 10:02:36 -0800 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 21:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-13 04:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 00:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 23:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 23:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 22:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 21:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 15:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 21:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 18:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 18:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 17:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 20:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 15:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 17:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 21:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Thu Feb 13 18:08:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 13 Feb 2003 10:08:11 -0800 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 15:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Walter Dörwald (doerwalter) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 13:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 13:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-12 22:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 18:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 17:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 17:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 16:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 15:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 09:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 15:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 12:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 12:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 11:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 14:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 09:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 11:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 15:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From neal@metaslash.com Thu Feb 13 18:18:49 2003 From: neal@metaslash.com (Neal Norwitz) Date: Thu, 13 Feb 2003 13:18:49 -0500 Subject: [Patches] Re: [Python-Dev] Changing SF tracker email preferences In-Reply-To: <200302131752.h1DHqCi00785@odiug.zope.com> References: <200302131752.h1DHqCi00785@odiug.zope.com> Message-ID: <20030213181849.GE23059@epoch.metaslash.com> On Thu, Feb 13, 2003 at 12:52:12PM -0500, Guido van Rossum wrote: > > Would anybody who is currently receiving bugs or patches traffic be > bothered if I made this change? I have no problem with the change. I'm responding to this mail to point out that when a new bug/patch is created, a file cannot be attached. After creating the new bug/patch, you must go back and attach the file. It has nothing to do with remembering to check the upload box. I submitted a bug report to SF two weeks ago. They changed the group to Second Tier Support, but haven't addressed the problem. http://sf.net/tracker/?func=detail&atid=200001&aid=675910&group_id=1 still-hoping-for-roundup-to-replace-sf-ly y'rs, Neal From theller@python.net Thu Feb 13 18:20:42 2003 From: theller@python.net (Thomas Heller) Date: 13 Feb 2003 19:20:42 +0100 Subject: [Patches] Re: [Python-Dev] Changing SF tracker email preferences In-Reply-To: <200302131752.h1DHqCi00785@odiug.zope.com> References: <200302131752.h1DHqCi00785@odiug.zope.com> Message-ID: Guido van Rossum writes: > When a new bug or patch is posted to a SF tracker, an email gets sent > to python-bugs-list@python.org or patches@python.org. > > But... when anything is changed or added to those trackers, an email > is *also* sent to those lists. > > I would like to receive the first kind of traffic (new tracker issues) > but not the second kind, except for those tracker issues in which I am > interested (which I can get by explicit turning on monitoring of those > issues, or by following up). > > The SF tracker admin has an option to allow this: all I have to do is > uncheck the box that says "Send email on all changes". I would really > like to do this. > > Would anybody who is currently receiving bugs or patches traffic be > bothered if I made this change? I find it sometimes interesting to receive these mails and read the comments which are posted, I cannot decide from the item description if I'm interested in this item or not. (You could also route the mails them into the trashcan, and read them with a newsreader at news.gmane.org:gmane.comp.python.bugs or patches.) Thomas From noreply@sourceforge.net Thu Feb 13 18:16:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 13 Feb 2003 10:16:52 -0800 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 21:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: M.-A. Lemburg (lemburg) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 19:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-13 04:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 00:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 23:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 23:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 22:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 21:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 15:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 21:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 18:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 18:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 17:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 20:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 15:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 17:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 21:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From tim.one@comcast.net Thu Feb 13 18:53:01 2003 From: tim.one@comcast.net (Tim Peters) Date: Thu, 13 Feb 2003 13:53:01 -0500 Subject: [Patches] RE: [Python-Dev] Changing SF tracker email preferences In-Reply-To: <200302131752.h1DHqCi00785@odiug.zope.com> Message-ID: [Guido] > But... when anything is changed or added to those trackers, an email > is *also* sent to those lists. > > I would like to receive the first kind of traffic (new tracker issues) > but not the second kind, except for those tracker issues in which I am > interested (which I can get by explicit turning on monitoring of those > issues, or by following up). > > The SF tracker admin has an option to allow this: all I have to do is > uncheck the box that says "Send email on all changes". I would really > like to do this. > > Would anybody who is currently receiving bugs or patches traffic be > bothered if I made this change? I sure would. At least 3/4ths of the comments I add to tracker items are spurred by reading the topmost (most recent) comment in one of these "extra" emails. Sometimes they're tracker items I'm following anyway, but often they're not. From noreply@sourceforge.net Thu Feb 13 21:09:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 13 Feb 2003 13:09:44 -0800 Subject: [Patches] [ python-Patches-684612 ] Macintosh documentation patches Message-ID: Patches item #684612, was opened at 2003-02-11 15:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684612&group_id=5470 Category: Documentation Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Macintosh documentation patches Initial Comment: Fred, you won't believe this, but I actually went through the Mac documentation! :-) Attached is a patch. I haven't checked it in myself (although I can finally make the documentation with latex) as the exact usage of the gazillion latex macros is still pretty opaque to me, so I've probably done lots of things wrong. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-02-13 22:09 Message: Logged In: YES user_id=45365 Neil, what do you mean? I checked the mods in yesterday around 09:58 (sourceforge time:-). Or do you mean something else? Or did you mean I forgot to close the request (as I just now notice:-)? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-13 03:58 Message: Logged In: YES user_id=33168 Jack, didn't you check this in? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-02-11 23:01 Message: Logged In: YES user_id=3066 Platform notes like "MacPython-OS9 only." should be spelled "Availability: MacPython-OS9." at the end of the description they modify, rather than at the beginning. This matches similar notes in the main library reference. I will probably be removing the \pytype macro; it doesn't really make much sense any more (and was rarely used anyway); you should always use \class now. Optional arguments which are not the first arg of a function or method should include the comma which *precedes* them included within their \optional: arg1\optional{, arg2\optional{, arg3}} Weird, but we're hitting limitations in my ability to munge things in LaTeX here. ;-( Go ahead and check-in after you've made these changes; at that point it'll be easier to work from CVS. Thanks for taking the time to update the docs! ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-11 22:44 Message: Logged In: YES user_id=45365 Ok, trying again. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-02-11 21:47 Message: Logged In: YES user_id=3066 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684612&group_id=5470 From noreply@sourceforge.net Thu Feb 13 21:14:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 13 Feb 2003 13:14:40 -0800 Subject: [Patches] [ python-Patches-684612 ] Macintosh documentation patches Message-ID: Patches item #684612, was opened at 2003-02-11 09:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684612&group_id=5470 Category: Documentation Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Macintosh documentation patches Initial Comment: Fred, you won't believe this, but I actually went through the Mac documentation! :-) Attached is a patch. I haven't checked it in myself (although I can finally make the documentation with latex) as the exact usage of the gazillion latex macros is still pretty opaque to me, so I've probably done lots of things wrong. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-13 16:14 Message: Logged In: YES user_id=33168 You got it. :-) ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-13 16:09 Message: Logged In: YES user_id=45365 Neil, what do you mean? I checked the mods in yesterday around 09:58 (sourceforge time:-). Or do you mean something else? Or did you mean I forgot to close the request (as I just now notice:-)? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-12 21:58 Message: Logged In: YES user_id=33168 Jack, didn't you check this in? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-02-11 17:01 Message: Logged In: YES user_id=3066 Platform notes like "MacPython-OS9 only." should be spelled "Availability: MacPython-OS9." at the end of the description they modify, rather than at the beginning. This matches similar notes in the main library reference. I will probably be removing the \pytype macro; it doesn't really make much sense any more (and was rarely used anyway); you should always use \class now. Optional arguments which are not the first arg of a function or method should include the comma which *precedes* them included within their \optional: arg1\optional{, arg2\optional{, arg3}} Weird, but we're hitting limitations in my ability to munge things in LaTeX here. ;-( Go ahead and check-in after you've made these changes; at that point it'll be easier to work from CVS. Thanks for taking the time to update the docs! ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-11 16:44 Message: Logged In: YES user_id=45365 Ok, trying again. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-02-11 15:47 Message: Logged In: YES user_id=3066 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684612&group_id=5470 From noreply@sourceforge.net Fri Feb 14 05:07:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 13 Feb 2003 21:07:18 -0800 Subject: [Patches] [ python-Patches-686379 ] logging.handlers.SMTPHandler and single to address Message-ID: Patches item #686379, was opened at 2003-02-14 16:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686379&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: logging.handlers.SMTPHandler and single to address Initial Comment: logging.handlers.SMTPHandler should handle a single string to address - at the moment if you mess up and pass a string, (e.g. 'someuser@foo.com'), you get a message body To: line of s@localdomain,o@localdomain,m@localdomain,... smtplib has the same signature, but checks for a single string argument. This patch does the same for the logging module. Patch is to Lib/logging/handlers.py. Not sure if the version in the Python CVS is the "home" version of the code, or if it's just an import of a different CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686379&group_id=5470 From noreply@sourceforge.net Fri Feb 14 05:08:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 13 Feb 2003 21:08:03 -0800 Subject: [Patches] [ python-Patches-686379 ] logging.handlers.SMTPHandler and single 'to' address Message-ID: Patches item #686379, was opened at 2003-02-14 16:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686379&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) >Summary: logging.handlers.SMTPHandler and single 'to' address Initial Comment: logging.handlers.SMTPHandler should handle a single string to address - at the moment if you mess up and pass a string, (e.g. 'someuser@foo.com'), you get a message body To: line of s@localdomain,o@localdomain,m@localdomain,... smtplib has the same signature, but checks for a single string argument. This patch does the same for the logging module. Patch is to Lib/logging/handlers.py. Not sure if the version in the Python CVS is the "home" version of the code, or if it's just an import of a different CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686379&group_id=5470 From noreply@sourceforge.net Fri Feb 14 06:02:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 13 Feb 2003 22:02:56 -0800 Subject: [Patches] [ python-Patches-686397 ] add os.sep and friends to os.path Message-ID: Patches item #686397, was opened at 2003-02-14 00:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686397&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Andrew I MacIntyre (aimacintyre) Summary: add os.sep and friends to os.path Initial Comment: The attached patch implements an idea I brought up on python-dev, namely that several platform-dependent path-related variables should be available via the platform-dependent path modules (ntpath, etc), not just via the os module. Those variables are sep, altsep, extsep, pathsep, curdir, pardir and defpath. Although I disagree with Guido about how these variables should be documented, all I did doc-wise was note in libos.tex that these variables are also available via os.path. The attached patch implements that idea and seems to work properly on the one platform (Mac OS X) I tried it on. The os/2 stuff seemed the most likely to have problems, so am assigning to Andrew MacIntyre, at least to start with. Andrew, feel free to pass it around, just don't pass it back to me. I'm headed out of town for a week. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686397&group_id=5470 From noreply@sourceforge.net Fri Feb 14 06:05:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 13 Feb 2003 22:05:13 -0800 Subject: [Patches] [ python-Patches-686397 ] add os.sep and friends to os.path Message-ID: Patches item #686397, was opened at 2003-02-14 00:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686397&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Andrew I MacIntyre (aimacintyre) Summary: add os.sep and friends to os.path Initial Comment: The attached patch implements an idea I brought up on python-dev, namely that several platform-dependent path-related variables should be available via the platform-dependent path modules (ntpath, etc), not just via the os module. Those variables are sep, altsep, extsep, pathsep, curdir, pardir and defpath. Although I disagree with Guido about how these variables should be documented, all I did doc-wise was note in libos.tex that these variables are also available via os.path. The attached patch implements that idea and seems to work properly on the one platform (Mac OS X) I tried it on. The os/2 stuff seemed the most likely to have problems, so am assigning to Andrew MacIntyre, at least to start with. Andrew, feel free to pass it around, just don't pass it back to me. I'm headed out of town for a week. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-02-14 00:05 Message: Logged In: YES user_id=44345 here's the patch file... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686397&group_id=5470 From noreply@sourceforge.net Fri Feb 14 08:52:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 14 Feb 2003 00:52:09 -0800 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 21:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Walter Dörwald (doerwalter) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 09:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 19:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-13 04:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 00:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 23:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 23:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 22:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 21:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 15:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 21:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 18:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 18:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 17:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 20:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 15:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 17:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 21:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Fri Feb 14 11:30:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 14 Feb 2003 03:30:47 -0800 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 21:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Walter Dörwald (doerwalter) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-02-14 12:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_charmapcodec delete Lib/test/test_charmapcodec.py 1.6 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 09:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 19:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-13 04:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 00:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 23:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 23:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 22:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 21:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 15:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 21:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 18:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 18:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 17:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 20:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 15:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 17:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 21:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Fri Feb 14 13:42:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 14 Feb 2003 05:42:27 -0800 Subject: [Patches] [ python-Patches-686545 ] Add addition and moving messages to Maildir Message-ID: Patches item #686545, was opened at 2003-02-14 08:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686545&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Add addition and moving messages to Maildir Initial Comment: The Maildir class in the mailbox module only supports reading a Maildir. The attached patch adds methods for adding messages and moving them from folder to folder within the Maildir. The mailbox test suite is also expanded to actually exercise the Maildir code a bit. This patch doesn't include the required documentation. For now I just want a review of the interface (are add_message() and move_message() all we need? are the parameters right?). and of the code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686545&group_id=5470 From noreply@sourceforge.net Fri Feb 14 13:43:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 14 Feb 2003 05:43:58 -0800 Subject: [Patches] [ python-Patches-686545 ] Add addition and moving messages to Maildir Message-ID: Patches item #686545, was opened at 2003-02-14 08:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686545&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Add addition and moving messages to Maildir Initial Comment: The Maildir class in the mailbox module only supports reading a Maildir. The attached patch adds methods for adding messages and moving them from folder to folder within the Maildir. The mailbox test suite is also expanded to actually exercise the Maildir code a bit. This patch doesn't include the required documentation. For now I just want a review of the interface (are add_message() and move_message() all we need? are the parameters right?). and of the code. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-02-14 08:43 Message: Logged In: YES user_id=11375 Thank you, sir; may I have another? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686545&group_id=5470 From noreply@sourceforge.net Fri Feb 14 15:42:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 14 Feb 2003 07:42:38 -0800 Subject: [Patches] [ python-Patches-686601 ] Remove unncessary casts for PyEval_GetFrame() Message-ID: Patches item #686601, was opened at 2003-02-14 15:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686601&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ben Laurie (benl) Assigned to: Nobody/Anonymous (nobody) Summary: Remove unncessary casts for PyEval_GetFrame() Initial Comment: PyEval_GetFrame()'s type is known, there's no need to cast it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686601&group_id=5470 From noreply@sourceforge.net Fri Feb 14 15:44:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 14 Feb 2003 07:44:09 -0800 Subject: [Patches] [ python-Patches-686601 ] Remove unncessary casts for PyEval_GetFrame() Message-ID: Patches item #686601, was opened at 2003-02-14 15:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686601&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ben Laurie (benl) >Assigned to: Guido van Rossum (gvanrossum) Summary: Remove unncessary casts for PyEval_GetFrame() Initial Comment: PyEval_GetFrame()'s type is known, there's no need to cast it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686601&group_id=5470 From noreply@sourceforge.net Fri Feb 14 15:54:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 14 Feb 2003 07:54:21 -0800 Subject: [Patches] [ python-Patches-686601 ] Remove unncessary casts for PyEval_GetFrame() Message-ID: Patches item #686601, was opened at 2003-02-14 10:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686601&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ben Laurie (benl) Assigned to: Guido van Rossum (gvanrossum) Summary: Remove unncessary casts for PyEval_GetFrame() Initial Comment: PyEval_GetFrame()'s type is known, there's no need to cast it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 10:54 Message: Logged In: YES user_id=33168 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686601&group_id=5470 From noreply@sourceforge.net Fri Feb 14 16:40:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 14 Feb 2003 08:40:18 -0800 Subject: [Patches] [ python-Patches-686627 ] fix race condition in unicode Message-ID: Patches item #686627, was opened at 2003-02-14 11:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686627&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Geoff Talvola (gtalvola) Assigned to: Nobody/Anonymous (nobody) Summary: fix race condition in unicode Initial Comment: There's a race condition in the importing of the encodings in codecs.c that can cause an exception in threaded programs. This happens to me occasionally when I start up a threaded server and two threads happen to both do the first unicode operation at the same time, Attached is a tarball containing a test program and a patch to codecs.c that fixes the problem. See the comments in the test program for more details. The patch was based on the 2.2.2 source. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686627&group_id=5470 From noreply@sourceforge.net Fri Feb 14 16:58:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 14 Feb 2003 08:58:06 -0800 Subject: [Patches] [ python-Patches-686627 ] fix race condition in unicode Message-ID: Patches item #686627, was opened at 2003-02-14 17:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686627&group_id=5470 Category: Core (C code) Group: Python 2.2.x >Status: Closed Resolution: None Priority: 5 Submitted By: Geoff Talvola (gtalvola) >Assigned to: M.-A. Lemburg (lemburg) Summary: fix race condition in unicode Initial Comment: There's a race condition in the importing of the encodings in codecs.c that can cause an exception in threaded programs. This happens to me occasionally when I start up a threaded server and two threads happen to both do the first unicode operation at the same time, Attached is a tarball containing a test program and a patch to codecs.c that fixes the problem. See the comments in the test program for more details. The patch was based on the 2.2.2 source. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 17:58 Message: Logged In: YES user_id=38388 Looks like an easy fix. Since I can't see how this could break anything, I'll check it in. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686627&group_id=5470 From noreply@sourceforge.net Fri Feb 14 17:37:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 14 Feb 2003 09:37:43 -0800 Subject: [Patches] [ python-Patches-686601 ] Remove unncessary casts for PyEval_GetFrame() Message-ID: Patches item #686601, was opened at 2003-02-14 15:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686601&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ben Laurie (benl) Assigned to: Guido van Rossum (gvanrossum) Summary: Remove unncessary casts for PyEval_GetFrame() Initial Comment: PyEval_GetFrame()'s type is known, there's no need to cast it. ---------------------------------------------------------------------- >Comment By: Ben Laurie (benl) Date: 2003-02-14 17:37 Message: Logged In: YES user_id=14333 Patch attached (and I swear I ticked the damn box the first time) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 15:54 Message: Logged In: YES user_id=33168 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686601&group_id=5470 From noreply@sourceforge.net Fri Feb 14 17:48:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 14 Feb 2003 09:48:08 -0800 Subject: [Patches] [ python-Patches-686601 ] Remove unncessary casts for PyEval_GetFrame() Message-ID: Patches item #686601, was opened at 2003-02-14 10:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686601&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ben Laurie (benl) Assigned to: Guido van Rossum (gvanrossum) Summary: Remove unncessary casts for PyEval_GetFrame() Initial Comment: PyEval_GetFrame()'s type is known, there's no need to cast it. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-14 12:48 Message: Logged In: YES user_id=6380 I'm fine with this, even though it changes a public API (and hence might break 3rd party extensions). Neil, since you showed some interest, feel free to check it in (assuming it passes the test suit :-). ---------------------------------------------------------------------- Comment By: Ben Laurie (benl) Date: 2003-02-14 12:37 Message: Logged In: YES user_id=14333 Patch attached (and I swear I ticked the damn box the first time) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 10:54 Message: Logged In: YES user_id=33168 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686601&group_id=5470 From noreply@sourceforge.net Fri Feb 14 19:32:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 14 Feb 2003 11:32:17 -0800 Subject: [Patches] [ python-Patches-686397 ] add os.sep and friends to os.path Message-ID: Patches item #686397, was opened at 2003-02-14 01:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686397&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Andrew I MacIntyre (aimacintyre) Summary: add os.sep and friends to os.path Initial Comment: The attached patch implements an idea I brought up on python-dev, namely that several platform-dependent path-related variables should be available via the platform-dependent path modules (ntpath, etc), not just via the os module. Those variables are sep, altsep, extsep, pathsep, curdir, pardir and defpath. Although I disagree with Guido about how these variables should be documented, all I did doc-wise was note in libos.tex that these variables are also available via os.path. The attached patch implements that idea and seems to work properly on the one platform (Mac OS X) I tried it on. The os/2 stuff seemed the most likely to have problems, so am assigning to Andrew MacIntyre, at least to start with. Andrew, feel free to pass it around, just don't pass it back to me. I'm headed out of town for a week. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-14 14:32 Message: Logged In: YES user_id=6380 Skip, this looks good. Please check it in, but leave it assigned to Andrew for an OS/2 check. I'd like to release 2.3a2 with this, and I hope to do that next Tuesday. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-02-14 01:05 Message: Logged In: YES user_id=44345 here's the patch file... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686397&group_id=5470 From noreply@sourceforge.net Fri Feb 14 19:45:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 14 Feb 2003 11:45:25 -0800 Subject: [Patches] [ python-Patches-686397 ] add os.sep and friends to os.path Message-ID: Patches item #686397, was opened at 2003-02-14 00:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686397&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Andrew I MacIntyre (aimacintyre) Summary: add os.sep and friends to os.path Initial Comment: The attached patch implements an idea I brought up on python-dev, namely that several platform-dependent path-related variables should be available via the platform-dependent path modules (ntpath, etc), not just via the os module. Those variables are sep, altsep, extsep, pathsep, curdir, pardir and defpath. Although I disagree with Guido about how these variables should be documented, all I did doc-wise was note in libos.tex that these variables are also available via os.path. The attached patch implements that idea and seems to work properly on the one platform (Mac OS X) I tried it on. The os/2 stuff seemed the most likely to have problems, so am assigning to Andrew MacIntyre, at least to start with. Andrew, feel free to pass it around, just don't pass it back to me. I'm headed out of town for a week. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-02-14 13:45 Message: Logged In: YES user_id=44345 Checked in as Lib/os.py 1.67 Lib/os2emxpath.py 1.10 Lib/posixpath.py 1.58 Lib/macpath.py 1.46 Lib/ntpath.py 1.55 Lib/plat-riscos/riscospath.py 1.9 Doc/lib/libos.tex 1.114 Marking accepted but leaving assigned to Andrew for OS/2 checks. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-14 13:32 Message: Logged In: YES user_id=6380 Skip, this looks good. Please check it in, but leave it assigned to Andrew for an OS/2 check. I'd like to release 2.3a2 with this, and I hope to do that next Tuesday. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-02-14 00:05 Message: Logged In: YES user_id=44345 here's the patch file... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686397&group_id=5470 From noreply@sourceforge.net Fri Feb 14 20:11:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 14 Feb 2003 12:11:30 -0800 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 15:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Walter Dörwald (doerwalter) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 15:11 Message: Logged In: YES user_id=33168 Walter, can this patch be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-14 06:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_charmapcodec delete Lib/test/test_charmapcodec.py 1.6 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 03:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 13:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 13:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 13:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-12 22:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 18:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 17:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 17:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 16:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 15:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 09:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 15:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 12:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 12:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 11:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 14:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 09:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 11:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 15:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Fri Feb 14 20:54:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 14 Feb 2003 12:54:39 -0800 Subject: [Patches] [ python-Patches-686771 ] Fix for 686380: errors trying to get help on os attributes Message-ID: Patches item #686771, was opened at 2003-02-14 14:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686771&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for 686380: errors trying to get help on os attributes Initial Comment: See Bug 686380 for details, or reproduce by typing "help ('.')" in the interactive shell. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686771&group_id=5470 From noreply@sourceforge.net Fri Feb 14 20:56:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 14 Feb 2003 12:56:11 -0800 Subject: [Patches] [ python-Patches-686771 ] Fix for 686380: errors trying to get help on os attributes Message-ID: Patches item #686771, was opened at 2003-02-14 14:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686771&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) >Assigned to: Ka-Ping Yee (ping) Summary: Fix for 686380: errors trying to get help on os attributes Initial Comment: See Bug 686380 for details, or reproduce by typing "help ('.')" in the interactive shell. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686771&group_id=5470 From noreply@sourceforge.net Fri Feb 14 21:50:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 14 Feb 2003 13:50:50 -0800 Subject: [Patches] [ python-Patches-686808 ] test Message-ID: Patches item #686808, was opened at 2003-02-14 16:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686808&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: test Initial Comment: testing ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686808&group_id=5470 From noreply@sourceforge.net Fri Feb 14 21:51:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 14 Feb 2003 13:51:35 -0800 Subject: [Patches] [ python-Patches-686808 ] test Message-ID: Patches item #686808, was opened at 2003-02-14 16:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686808&group_id=5470 Category: None Group: None >Status: Deleted Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: test Initial Comment: testing ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686808&group_id=5470 From noreply@sourceforge.net Sun Feb 16 01:20:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 15 Feb 2003 17:20:26 -0800 Subject: [Patches] [ python-Patches-686771 ] Fix for 686380: errors trying to get help on os attributes Message-ID: Patches item #686771, was opened at 2003-02-14 15:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686771&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Ka-Ping Yee (ping) Summary: Fix for 686380: errors trying to get help on os attributes Initial Comment: See Bug 686380 for details, or reproduce by typing "help ('.')" in the interactive shell. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-15 20:20 Message: Logged In: YES user_id=6380 Applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686771&group_id=5470 From noreply@sourceforge.net Sun Feb 16 09:33:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 16 Feb 2003 01:33:26 -0800 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 21:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Walter Dörwald (doerwalter) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-02-16 10:33 Message: Logged In: YES user_id=89016 I'm currently working on a PyUnit port of the string tests (i.e. str, unicode, UserString and the string module). Uploading the result to this patch would be easier, as it already has a establsihed audience: But I can open a new patch for that if you want. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 21:11 Message: Logged In: YES user_id=33168 Walter, can this patch be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-14 12:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_charmapcodec delete Lib/test/test_charmapcodec.py 1.6 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 09:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 19:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-13 04:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 00:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 23:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 23:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 22:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 21:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 15:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 21:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 18:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 18:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 17:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 20:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 15:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 17:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 21:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Sun Feb 16 18:36:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 16 Feb 2003 10:36:53 -0800 Subject: [Patches] [ python-Patches-684677 ] Allow freeze to exclude implicits Message-ID: Patches item #684677, was opened at 2003-02-11 16:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684677&group_id=5470 Category: Demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lawrence Hudson (lhudson) >Assigned to: Just van Rossum (jvr) Summary: Allow freeze to exclude implicits Initial Comment: Freeze always freezes site and exceptions. This patch allows these implicit modules to be excluded using the -x switch. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-02-16 19:36 Message: Logged In: YES user_id=92689 The patch looks good, I'll have a closer look later. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684677&group_id=5470 From noreply@sourceforge.net Sun Feb 16 19:55:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 16 Feb 2003 11:55:03 -0800 Subject: [Patches] [ python-Patches-687598 ] array.append is sloooow Message-ID: Patches item #687598, was opened at 2003-02-16 13:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=687598&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: array.append is sloooow Initial Comment: array.append re'mallocs and copies each time an item is appended to it. That makes the code below grind to a halt. I stole the resizing algorithm from listobject.c and it speeds things up a bit. Python 2.3a1 (#38, Feb 16 2003, 14:23:39) [MSC v.1300 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import array >>> a = array.array('i') >>> for i in range(10000000): ... a.append(i) ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=687598&group_id=5470 From noreply@sourceforge.net Mon Feb 17 00:22:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 16 Feb 2003 16:22:42 -0800 Subject: [Patches] [ python-Patches-687683 ] Patches to logging Message-ID: Patches item #687683, was opened at 2003-02-17 00:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=687683&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Vinay Sajip (vsajip) Assigned to: Nobody/Anonymous (nobody) Summary: Patches to logging Initial Comment: Patches to logging as discussed in recent post to python- dev. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=687683&group_id=5470 From noreply@sourceforge.net Mon Feb 17 00:28:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 16 Feb 2003 16:28:28 -0800 Subject: [Patches] [ python-Patches-687683 ] Patches to logging Message-ID: Patches item #687683, was opened at 2003-02-17 00:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=687683&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Vinay Sajip (vsajip) >Assigned to: Neal Norwitz (nnorwitz) Summary: Patches to logging Initial Comment: Patches to logging as discussed in recent post to python- dev. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=687683&group_id=5470 From noreply@sourceforge.net Mon Feb 17 07:31:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 16 Feb 2003 23:31:58 -0800 Subject: [Patches] [ python-Patches-686397 ] add os.sep and friends to os.path Message-ID: Patches item #686397, was opened at 2003-02-14 17:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686397&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Andrew I MacIntyre (aimacintyre) Summary: add os.sep and friends to os.path Initial Comment: The attached patch implements an idea I brought up on python-dev, namely that several platform-dependent path-related variables should be available via the platform-dependent path modules (ntpath, etc), not just via the os module. Those variables are sep, altsep, extsep, pathsep, curdir, pardir and defpath. Although I disagree with Guido about how these variables should be documented, all I did doc-wise was note in libos.tex that these variables are also available via os.path. The attached patch implements that idea and seems to work properly on the one platform (Mac OS X) I tried it on. The os/2 stuff seemed the most likely to have problems, so am assigning to Andrew MacIntyre, at least to start with. Andrew, feel free to pass it around, just don't pass it back to me. I'm headed out of town for a week. ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-02-17 18:31 Message: Logged In: YES user_id=250749 Looks OK, except for 2 very minor items in ntpath.py: - the comment shouldn't read "w/ EMX" as EMX uses os2emxpath.py (should probably refer to VACPP); - defpath should be defined for 'os' - and be the same as everything else except 'ce'. Given that Skip is OOT, I'll fix this in CVS and close the patch. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-02-15 06:45 Message: Logged In: YES user_id=44345 Checked in as Lib/os.py 1.67 Lib/os2emxpath.py 1.10 Lib/posixpath.py 1.58 Lib/macpath.py 1.46 Lib/ntpath.py 1.55 Lib/plat-riscos/riscospath.py 1.9 Doc/lib/libos.tex 1.114 Marking accepted but leaving assigned to Andrew for OS/2 checks. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-15 06:32 Message: Logged In: YES user_id=6380 Skip, this looks good. Please check it in, but leave it assigned to Andrew for an OS/2 check. I'd like to release 2.3a2 with this, and I hope to do that next Tuesday. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-02-14 17:05 Message: Logged In: YES user_id=44345 here's the patch file... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686397&group_id=5470 From noreply@sourceforge.net Mon Feb 17 07:36:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 16 Feb 2003 23:36:40 -0800 Subject: [Patches] [ python-Patches-686397 ] add os.sep and friends to os.path Message-ID: Patches item #686397, was opened at 2003-02-14 17:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686397&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Andrew I MacIntyre (aimacintyre) Summary: add os.sep and friends to os.path Initial Comment: The attached patch implements an idea I brought up on python-dev, namely that several platform-dependent path-related variables should be available via the platform-dependent path modules (ntpath, etc), not just via the os module. Those variables are sep, altsep, extsep, pathsep, curdir, pardir and defpath. Although I disagree with Guido about how these variables should be documented, all I did doc-wise was note in libos.tex that these variables are also available via os.path. The attached patch implements that idea and seems to work properly on the one platform (Mac OS X) I tried it on. The os/2 stuff seemed the most likely to have problems, so am assigning to Andrew MacIntyre, at least to start with. Andrew, feel free to pass it around, just don't pass it back to me. I'm headed out of town for a week. ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-02-17 18:36 Message: Logged In: YES user_id=250749 that should be - "defpath should be defined for 'os2'..." ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-02-17 18:31 Message: Logged In: YES user_id=250749 Looks OK, except for 2 very minor items in ntpath.py: - the comment shouldn't read "w/ EMX" as EMX uses os2emxpath.py (should probably refer to VACPP); - defpath should be defined for 'os' - and be the same as everything else except 'ce'. Given that Skip is OOT, I'll fix this in CVS and close the patch. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-02-15 06:45 Message: Logged In: YES user_id=44345 Checked in as Lib/os.py 1.67 Lib/os2emxpath.py 1.10 Lib/posixpath.py 1.58 Lib/macpath.py 1.46 Lib/ntpath.py 1.55 Lib/plat-riscos/riscospath.py 1.9 Doc/lib/libos.tex 1.114 Marking accepted but leaving assigned to Andrew for OS/2 checks. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-15 06:32 Message: Logged In: YES user_id=6380 Skip, this looks good. Please check it in, but leave it assigned to Andrew for an OS/2 check. I'd like to release 2.3a2 with this, and I hope to do that next Tuesday. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-02-14 17:05 Message: Logged In: YES user_id=44345 here's the patch file... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686397&group_id=5470 From noreply@sourceforge.net Mon Feb 17 09:35:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Feb 2003 01:35:47 -0800 Subject: [Patches] [ python-Patches-686397 ] add os.sep and friends to os.path Message-ID: Patches item #686397, was opened at 2003-02-14 17:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686397&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Andrew I MacIntyre (aimacintyre) Summary: add os.sep and friends to os.path Initial Comment: The attached patch implements an idea I brought up on python-dev, namely that several platform-dependent path-related variables should be available via the platform-dependent path modules (ntpath, etc), not just via the os module. Those variables are sep, altsep, extsep, pathsep, curdir, pardir and defpath. Although I disagree with Guido about how these variables should be documented, all I did doc-wise was note in libos.tex that these variables are also available via os.path. The attached patch implements that idea and seems to work properly on the one platform (Mac OS X) I tried it on. The os/2 stuff seemed the most likely to have problems, so am assigning to Andrew MacIntyre, at least to start with. Andrew, feel free to pass it around, just don't pass it back to me. I'm headed out of town for a week. ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-02-17 20:35 Message: Logged In: YES user_id=250749 OS/2 tweaks checked in. Misc/NEWS updated. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-02-17 18:36 Message: Logged In: YES user_id=250749 that should be - "defpath should be defined for 'os2'..." ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-02-17 18:31 Message: Logged In: YES user_id=250749 Looks OK, except for 2 very minor items in ntpath.py: - the comment shouldn't read "w/ EMX" as EMX uses os2emxpath.py (should probably refer to VACPP); - defpath should be defined for 'os' - and be the same as everything else except 'ce'. Given that Skip is OOT, I'll fix this in CVS and close the patch. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-02-15 06:45 Message: Logged In: YES user_id=44345 Checked in as Lib/os.py 1.67 Lib/os2emxpath.py 1.10 Lib/posixpath.py 1.58 Lib/macpath.py 1.46 Lib/ntpath.py 1.55 Lib/plat-riscos/riscospath.py 1.9 Doc/lib/libos.tex 1.114 Marking accepted but leaving assigned to Andrew for OS/2 checks. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-15 06:32 Message: Logged In: YES user_id=6380 Skip, this looks good. Please check it in, but leave it assigned to Andrew for an OS/2 check. I'd like to release 2.3a2 with this, and I hope to do that next Tuesday. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-02-14 17:05 Message: Logged In: YES user_id=44345 here's the patch file... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686397&group_id=5470 From noreply@sourceforge.net Mon Feb 17 16:24:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Feb 2003 08:24:01 -0800 Subject: [Patches] [ python-Patches-687683 ] Patches to logging Message-ID: Patches item #687683, was opened at 2003-02-16 19:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=687683&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Vinay Sajip (vsajip) Assigned to: Neal Norwitz (nnorwitz) Summary: Patches to logging Initial Comment: Patches to logging as discussed in recent post to python- dev. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-17 11:24 Message: Logged In: YES user_id=33168 I had to update the expected output for the change from WARN to WARNING. I also modified the test to use WARNING in 2 places. The test is successful, but hangs after printing 1 test OK. This is the only problem I have. Could the problem be that hdlr.close() is commented on in __init__.py:1013? Some other nits are below. I modified the hasattr(sys, "version_info") condition (4 lines) for _verinfo in __init__.py to the equivalent: _verinfo = getattr(sys, "version_info", None) Since _verinfo is only used in handlers.py, does it really belong in there? Actually, since _verinfo is only used to determine if a socket has sendall(), wouldn't it be better to just do a hasattr(self.sock, 'sendall') check? Vinay, when you make a patch, can you put all the files in a single patch from the src/ directory? It's easier to download & apply. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=687683&group_id=5470 From noreply@sourceforge.net Mon Feb 17 16:25:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Feb 2003 08:25:55 -0800 Subject: [Patches] [ python-Patches-687683 ] Patches to logging Message-ID: Patches item #687683, was opened at 2003-02-16 19:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=687683&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Vinay Sajip (vsajip) Assigned to: Neal Norwitz (nnorwitz) Summary: Patches to logging Initial Comment: Patches to logging as discussed in recent post to python- dev. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-17 11:25 Message: Logged In: YES user_id=33168 Uncommenting the hdlr.close() (ie calling it) did fix the hang. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-17 11:24 Message: Logged In: YES user_id=33168 I had to update the expected output for the change from WARN to WARNING. I also modified the test to use WARNING in 2 places. The test is successful, but hangs after printing 1 test OK. This is the only problem I have. Could the problem be that hdlr.close() is commented on in __init__.py:1013? Some other nits are below. I modified the hasattr(sys, "version_info") condition (4 lines) for _verinfo in __init__.py to the equivalent: _verinfo = getattr(sys, "version_info", None) Since _verinfo is only used in handlers.py, does it really belong in there? Actually, since _verinfo is only used to determine if a socket has sendall(), wouldn't it be better to just do a hasattr(self.sock, 'sendall') check? Vinay, when you make a patch, can you put all the files in a single patch from the src/ directory? It's easier to download & apply. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=687683&group_id=5470 From noreply@sourceforge.net Mon Feb 17 18:29:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Feb 2003 10:29:08 -0800 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 21:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-02-17 19:29 Message: Logged In: YES user_id=89016 Here is the next bunch of ports: the string tests have been ported to PyUnit and made as reusable as possible. Tests are now shared between str, unicode, UserString and the string module. As a result of reusing a part of the unicode tests for str, the coverage in stringobject.c goes from 83% to 86%. Furthermore it should help keep the API consistent between str and unicode (Example: "%c" % 0xffffffff raises OverflowError, u"%c" % 0xffffffff raises ValueError) Raymond can look look through the scripts and check that everything is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-16 10:33 Message: Logged In: YES user_id=89016 I'm currently working on a PyUnit port of the string tests (i.e. str, unicode, UserString and the string module). Uploading the result to this patch would be easier, as it already has a establsihed audience: But I can open a new patch for that if you want. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 21:11 Message: Logged In: YES user_id=33168 Walter, can this patch be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-14 12:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_charmapcodec delete Lib/test/test_charmapcodec.py 1.6 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 09:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 19:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-13 04:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 00:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 23:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 23:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 22:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 21:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 15:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 21:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 18:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 18:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 17:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 20:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 15:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 17:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 21:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Tue Feb 18 01:21:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Feb 2003 17:21:05 -0800 Subject: [Patches] [ python-Patches-681504 ] using gcc on cygwin for config Message-ID: Patches item #681504, was opened at 2003-02-06 01:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681504&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: A.M. Kuchling (akuchling) Summary: using gcc on cygwin for config Initial Comment: On Cygwin, I noticed that distutils tries to use the cc compiler instead of the gcc compiler for the config step, resulting in an error. Instead, for the build step the correct compiler (gcc) is being used. For the build step, build_clib.py and build_ext.py contain a call to customize_compiler after the call to new_compiler. The call to customize_compiler causes gcc to be used on cygwin. In config.py, however, this call to customize_compiler after the call to new_compiler is missing. Adding the call to customize_compiler after the call to new_compiler in config.py solves this problem, and the config step then runs correctly on Cygwin. BTW, I noticed that in version 1.44.6.3 of sysconfig.py in CVS, the function get_python_version is missing, causing errors in the build step. This is the latest committed version of sysconfig.py. So I used version 1.56 instead (which was committed earlier than 1.44.6.3, but has a higher version number ??). Michiel de Hoon University of Tokyo, Human Genome Center ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-02-17 20:21 Message: Logged In: YES user_id=11375 The patch looks fine; I'll apply it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 15:55 Message: Logged In: YES user_id=33168 amk, could you take a quick look at this patch to distutils? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-10 15:40 Message: Logged In: YES user_id=86216 > Adding a symlink would work, but I > am not sure if it is the best solution. Maybe both should be done? > Would that be OK with you? The patch is fine by me since it fixes Cygwin and I assume any other Unix (if any) without a /usr/bin/cc. > Or do you think there might be some problem > with the patch I submitted? No, I don't think that there will be problems with your patch. However, I cannot approve patches. I can only submit them like you. :,) Neal, should someone from distutils take a look-see. Or, is it OK for me to apply? ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2003-02-10 12:13 Message: Logged In: YES user_id=488897 OK thanks for your help. Adding a symlink would work, but I am not sure if it is the best solution. For the build step, distutils uses gcc automatically and doesn't need a symlink from cc. I think it is best if the config step mimics the build step as closely as possible, and having one solution for the build step and another for the config step might break things. For the patch that I submitted, I compared the config and the build step to find out where one chooses gcc and the other cc. The patch contains only one or two lines, and lets the config step choose gcc in the same way as the build step. Would that be OK with you? Or do you think there might be some problem with the patch I submitted? --Michiel. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-10 11:56 Message: Logged In: YES user_id=86216 OK, now I get it. Thanks for you help. I can reproduce the problem under Cygwin too. Now the question is, where is the right place to fix this? Under Red Hat 8.0, I get the following: $ ls -il /usr/bin/cc /usr/bin/c++ /usr/bin/g++ 328451 -rwxr-xr-x 4 root root 80780 Sep 3 23:03 /usr/bin/c++ 328396 lrwxrwxrwx 1 root root 3 Oct 21 10:04 /usr/bin/cc -> gcc 328451 -rwxr-xr-x 4 root root 80780 Sep 3 23:03 /usr/bin/g++ Under Cygwin, I get the following: $ ls -il /usr/bin/cc /usr/bin/c++ /usr/bin/g++ ls: /usr/bin/cc: No such file or directory 423677 lrwxrwxrwx 1 Administ Domain U 18 Dec 3 08:22 /usr/bin/c++ -> g++.exe 423679 -rwxrwxrwx 1 Administ Domain U 89600 Nov 14 17:37 /usr/bin/g++ So from the above, we can see that a symlink from cc to gcc could be considered missing under Cygwin. I will ask the Cygwin gcc maintainer to add this symlink. If the request is granted, will you consider this issue resolved? ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2003-02-10 11:06 Message: Logged In: YES user_id=488897 The config step is where you do python setup.py config where you can do some test compilations before doing "python setup.py build". Basically it works the same as autoconf/automake's configure scripts. The code for the config is in distutils/command/config.py. If you want to try it out, you can go to my website http://bonsai.ims.u-tokyo.ac.jp/~mdehoon, download pygist, unpack, and run "python setup.py config". You'll notice that it won't work on cygwin, as it tries to use cc instead of gcc. --Michiel. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-10 10:54 Message: Logged In: YES user_id=86216 > On Cygwin, I noticed that distutils tries to use the cc > compiler instead of the gcc compiler for the config > step, resulting in an error. Please excuse my ignorance, but what is the "config step?" How would one invoke the config step? Sorry, but I'm only lightly versed in distutils. > Instead, for the build > step the correct compiler (gcc) is being used. The build step seems to work fine under Cygwin Python 2.2.2 and CVS. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-07 17:55 Message: Logged In: YES user_id=33168 Jason, can you provide any input about the issues w/Cygwin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681504&group_id=5470 From noreply@sourceforge.net Tue Feb 18 01:37:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Feb 2003 17:37:56 -0800 Subject: [Patches] [ python-Patches-681504 ] using gcc on cygwin for config Message-ID: Patches item #681504, was opened at 2003-02-06 01:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681504&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) >Assigned to: Neal Norwitz (nnorwitz) Summary: using gcc on cygwin for config Initial Comment: On Cygwin, I noticed that distutils tries to use the cc compiler instead of the gcc compiler for the config step, resulting in an error. Instead, for the build step the correct compiler (gcc) is being used. For the build step, build_clib.py and build_ext.py contain a call to customize_compiler after the call to new_compiler. The call to customize_compiler causes gcc to be used on cygwin. In config.py, however, this call to customize_compiler after the call to new_compiler is missing. Adding the call to customize_compiler after the call to new_compiler in config.py solves this problem, and the config step then runs correctly on Cygwin. BTW, I noticed that in version 1.44.6.3 of sysconfig.py in CVS, the function get_python_version is missing, causing errors in the build step. This is the latest committed version of sysconfig.py. So I used version 1.56 instead (which was committed earlier than 1.44.6.3, but has a higher version number ??). Michiel de Hoon University of Tokyo, Human Genome Center ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-02-17 20:37 Message: Logged In: YES user_id=11375 Applied as revision 1.17 of config.py; thanks! Re-assigned to Neal, because I'm not sure if the bug can be closed now or not. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-17 20:21 Message: Logged In: YES user_id=11375 The patch looks fine; I'll apply it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 15:55 Message: Logged In: YES user_id=33168 amk, could you take a quick look at this patch to distutils? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-10 15:40 Message: Logged In: YES user_id=86216 > Adding a symlink would work, but I > am not sure if it is the best solution. Maybe both should be done? > Would that be OK with you? The patch is fine by me since it fixes Cygwin and I assume any other Unix (if any) without a /usr/bin/cc. > Or do you think there might be some problem > with the patch I submitted? No, I don't think that there will be problems with your patch. However, I cannot approve patches. I can only submit them like you. :,) Neal, should someone from distutils take a look-see. Or, is it OK for me to apply? ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2003-02-10 12:13 Message: Logged In: YES user_id=488897 OK thanks for your help. Adding a symlink would work, but I am not sure if it is the best solution. For the build step, distutils uses gcc automatically and doesn't need a symlink from cc. I think it is best if the config step mimics the build step as closely as possible, and having one solution for the build step and another for the config step might break things. For the patch that I submitted, I compared the config and the build step to find out where one chooses gcc and the other cc. The patch contains only one or two lines, and lets the config step choose gcc in the same way as the build step. Would that be OK with you? Or do you think there might be some problem with the patch I submitted? --Michiel. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-10 11:56 Message: Logged In: YES user_id=86216 OK, now I get it. Thanks for you help. I can reproduce the problem under Cygwin too. Now the question is, where is the right place to fix this? Under Red Hat 8.0, I get the following: $ ls -il /usr/bin/cc /usr/bin/c++ /usr/bin/g++ 328451 -rwxr-xr-x 4 root root 80780 Sep 3 23:03 /usr/bin/c++ 328396 lrwxrwxrwx 1 root root 3 Oct 21 10:04 /usr/bin/cc -> gcc 328451 -rwxr-xr-x 4 root root 80780 Sep 3 23:03 /usr/bin/g++ Under Cygwin, I get the following: $ ls -il /usr/bin/cc /usr/bin/c++ /usr/bin/g++ ls: /usr/bin/cc: No such file or directory 423677 lrwxrwxrwx 1 Administ Domain U 18 Dec 3 08:22 /usr/bin/c++ -> g++.exe 423679 -rwxrwxrwx 1 Administ Domain U 89600 Nov 14 17:37 /usr/bin/g++ So from the above, we can see that a symlink from cc to gcc could be considered missing under Cygwin. I will ask the Cygwin gcc maintainer to add this symlink. If the request is granted, will you consider this issue resolved? ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2003-02-10 11:06 Message: Logged In: YES user_id=488897 The config step is where you do python setup.py config where you can do some test compilations before doing "python setup.py build". Basically it works the same as autoconf/automake's configure scripts. The code for the config is in distutils/command/config.py. If you want to try it out, you can go to my website http://bonsai.ims.u-tokyo.ac.jp/~mdehoon, download pygist, unpack, and run "python setup.py config". You'll notice that it won't work on cygwin, as it tries to use cc instead of gcc. --Michiel. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-10 10:54 Message: Logged In: YES user_id=86216 > On Cygwin, I noticed that distutils tries to use the cc > compiler instead of the gcc compiler for the config > step, resulting in an error. Please excuse my ignorance, but what is the "config step?" How would one invoke the config step? Sorry, but I'm only lightly versed in distutils. > Instead, for the build > step the correct compiler (gcc) is being used. The build step seems to work fine under Cygwin Python 2.2.2 and CVS. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-07 17:55 Message: Logged In: YES user_id=33168 Jason, can you provide any input about the issues w/Cygwin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681504&group_id=5470 From noreply@sourceforge.net Tue Feb 18 01:39:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Feb 2003 17:39:52 -0800 Subject: [Patches] [ python-Patches-684398 ] Fix for verbosity Message-ID: Patches item #684398, was opened at 2003-02-10 23:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684398&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for verbosity Initial Comment: I'd forgotten about this until I just tried to run the register command in 2.3 myself :) I've changed the server response display from using the "verbose" flag to using a new "show-response" flag. I also changed the code that collects the post metadata, since the classifiers attribute will always be available to this code. The download_url metadata attribute implemented by patch www.python.org/sf/683939 is not handled by this patch - it still needs to be added to the post data. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-17 20:39 Message: Logged In: YES user_id=11375 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684398&group_id=5470 From noreply@sourceforge.net Tue Feb 18 01:55:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Feb 2003 17:55:05 -0800 Subject: [Patches] [ python-Patches-684398 ] Fix for verbosity Message-ID: Patches item #684398, was opened at 2003-02-11 15:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684398&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for verbosity Initial Comment: I'd forgotten about this until I just tried to run the register command in 2.3 myself :) I've changed the server response display from using the "verbose" flag to using a new "show-response" flag. I also changed the code that collects the post metadata, since the classifiers attribute will always be available to this code. The download_url metadata attribute implemented by patch www.python.org/sf/683939 is not handled by this patch - it still needs to be added to the post data. ---------------------------------------------------------------------- >Comment By: Richard Jones (richard) Date: 2003-02-18 12:55 Message: Logged In: YES user_id=6405 Sorry, trying again. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-18 12:39 Message: Logged In: YES user_id=11375 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684398&group_id=5470 From noreply@sourceforge.net Tue Feb 18 05:54:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Feb 2003 21:54:58 -0800 Subject: [Patches] [ python-Patches-681504 ] using gcc on cygwin for config Message-ID: Patches item #681504, was opened at 2003-02-06 01:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681504&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Neal Norwitz (nnorwitz) Summary: using gcc on cygwin for config Initial Comment: On Cygwin, I noticed that distutils tries to use the cc compiler instead of the gcc compiler for the config step, resulting in an error. Instead, for the build step the correct compiler (gcc) is being used. For the build step, build_clib.py and build_ext.py contain a call to customize_compiler after the call to new_compiler. The call to customize_compiler causes gcc to be used on cygwin. In config.py, however, this call to customize_compiler after the call to new_compiler is missing. Adding the call to customize_compiler after the call to new_compiler in config.py solves this problem, and the config step then runs correctly on Cygwin. BTW, I noticed that in version 1.44.6.3 of sysconfig.py in CVS, the function get_python_version is missing, causing errors in the build step. This is the latest committed version of sysconfig.py. So I used version 1.56 instead (which was committed earlier than 1.44.6.3, but has a higher version number ??). Michiel de Hoon University of Tokyo, Human Genome Center ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-18 00:54 Message: Logged In: YES user_id=33168 Michiel, if there is anything else that needs to be done, please add a comment to this patch. I think everything is done, so I'm closing it. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-17 20:37 Message: Logged In: YES user_id=11375 Applied as revision 1.17 of config.py; thanks! Re-assigned to Neal, because I'm not sure if the bug can be closed now or not. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-17 20:21 Message: Logged In: YES user_id=11375 The patch looks fine; I'll apply it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 15:55 Message: Logged In: YES user_id=33168 amk, could you take a quick look at this patch to distutils? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-10 15:40 Message: Logged In: YES user_id=86216 > Adding a symlink would work, but I > am not sure if it is the best solution. Maybe both should be done? > Would that be OK with you? The patch is fine by me since it fixes Cygwin and I assume any other Unix (if any) without a /usr/bin/cc. > Or do you think there might be some problem > with the patch I submitted? No, I don't think that there will be problems with your patch. However, I cannot approve patches. I can only submit them like you. :,) Neal, should someone from distutils take a look-see. Or, is it OK for me to apply? ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2003-02-10 12:13 Message: Logged In: YES user_id=488897 OK thanks for your help. Adding a symlink would work, but I am not sure if it is the best solution. For the build step, distutils uses gcc automatically and doesn't need a symlink from cc. I think it is best if the config step mimics the build step as closely as possible, and having one solution for the build step and another for the config step might break things. For the patch that I submitted, I compared the config and the build step to find out where one chooses gcc and the other cc. The patch contains only one or two lines, and lets the config step choose gcc in the same way as the build step. Would that be OK with you? Or do you think there might be some problem with the patch I submitted? --Michiel. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-10 11:56 Message: Logged In: YES user_id=86216 OK, now I get it. Thanks for you help. I can reproduce the problem under Cygwin too. Now the question is, where is the right place to fix this? Under Red Hat 8.0, I get the following: $ ls -il /usr/bin/cc /usr/bin/c++ /usr/bin/g++ 328451 -rwxr-xr-x 4 root root 80780 Sep 3 23:03 /usr/bin/c++ 328396 lrwxrwxrwx 1 root root 3 Oct 21 10:04 /usr/bin/cc -> gcc 328451 -rwxr-xr-x 4 root root 80780 Sep 3 23:03 /usr/bin/g++ Under Cygwin, I get the following: $ ls -il /usr/bin/cc /usr/bin/c++ /usr/bin/g++ ls: /usr/bin/cc: No such file or directory 423677 lrwxrwxrwx 1 Administ Domain U 18 Dec 3 08:22 /usr/bin/c++ -> g++.exe 423679 -rwxrwxrwx 1 Administ Domain U 89600 Nov 14 17:37 /usr/bin/g++ So from the above, we can see that a symlink from cc to gcc could be considered missing under Cygwin. I will ask the Cygwin gcc maintainer to add this symlink. If the request is granted, will you consider this issue resolved? ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2003-02-10 11:06 Message: Logged In: YES user_id=488897 The config step is where you do python setup.py config where you can do some test compilations before doing "python setup.py build". Basically it works the same as autoconf/automake's configure scripts. The code for the config is in distutils/command/config.py. If you want to try it out, you can go to my website http://bonsai.ims.u-tokyo.ac.jp/~mdehoon, download pygist, unpack, and run "python setup.py config". You'll notice that it won't work on cygwin, as it tries to use cc instead of gcc. --Michiel. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-10 10:54 Message: Logged In: YES user_id=86216 > On Cygwin, I noticed that distutils tries to use the cc > compiler instead of the gcc compiler for the config > step, resulting in an error. Please excuse my ignorance, but what is the "config step?" How would one invoke the config step? Sorry, but I'm only lightly versed in distutils. > Instead, for the build > step the correct compiler (gcc) is being used. The build step seems to work fine under Cygwin Python 2.2.2 and CVS. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-07 17:55 Message: Logged In: YES user_id=33168 Jason, can you provide any input about the issues w/Cygwin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681504&group_id=5470 From noreply@sourceforge.net Tue Feb 18 06:12:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Feb 2003 22:12:47 -0800 Subject: [Patches] [ python-Patches-681504 ] using gcc on cygwin for config Message-ID: Patches item #681504, was opened at 2003-02-06 15:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681504&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Neal Norwitz (nnorwitz) Summary: using gcc on cygwin for config Initial Comment: On Cygwin, I noticed that distutils tries to use the cc compiler instead of the gcc compiler for the config step, resulting in an error. Instead, for the build step the correct compiler (gcc) is being used. For the build step, build_clib.py and build_ext.py contain a call to customize_compiler after the call to new_compiler. The call to customize_compiler causes gcc to be used on cygwin. In config.py, however, this call to customize_compiler after the call to new_compiler is missing. Adding the call to customize_compiler after the call to new_compiler in config.py solves this problem, and the config step then runs correctly on Cygwin. BTW, I noticed that in version 1.44.6.3 of sysconfig.py in CVS, the function get_python_version is missing, causing errors in the build step. This is the latest committed version of sysconfig.py. So I used version 1.56 instead (which was committed earlier than 1.44.6.3, but has a higher version number ??). Michiel de Hoon University of Tokyo, Human Genome Center ---------------------------------------------------------------------- >Comment By: Michiel de Hoon (mdehoon) Date: 2003-02-18 15:12 Message: Logged In: YES user_id=488897 I tried the updated version in CVS and tested it with Cygwin. It works fine. Thanks. --Michiel. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-18 14:54 Message: Logged In: YES user_id=33168 Michiel, if there is anything else that needs to be done, please add a comment to this patch. I think everything is done, so I'm closing it. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-18 10:37 Message: Logged In: YES user_id=11375 Applied as revision 1.17 of config.py; thanks! Re-assigned to Neal, because I'm not sure if the bug can be closed now or not. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-18 10:21 Message: Logged In: YES user_id=11375 The patch looks fine; I'll apply it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-11 05:55 Message: Logged In: YES user_id=33168 amk, could you take a quick look at this patch to distutils? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-11 05:40 Message: Logged In: YES user_id=86216 > Adding a symlink would work, but I > am not sure if it is the best solution. Maybe both should be done? > Would that be OK with you? The patch is fine by me since it fixes Cygwin and I assume any other Unix (if any) without a /usr/bin/cc. > Or do you think there might be some problem > with the patch I submitted? No, I don't think that there will be problems with your patch. However, I cannot approve patches. I can only submit them like you. :,) Neal, should someone from distutils take a look-see. Or, is it OK for me to apply? ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2003-02-11 02:13 Message: Logged In: YES user_id=488897 OK thanks for your help. Adding a symlink would work, but I am not sure if it is the best solution. For the build step, distutils uses gcc automatically and doesn't need a symlink from cc. I think it is best if the config step mimics the build step as closely as possible, and having one solution for the build step and another for the config step might break things. For the patch that I submitted, I compared the config and the build step to find out where one chooses gcc and the other cc. The patch contains only one or two lines, and lets the config step choose gcc in the same way as the build step. Would that be OK with you? Or do you think there might be some problem with the patch I submitted? --Michiel. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-11 01:56 Message: Logged In: YES user_id=86216 OK, now I get it. Thanks for you help. I can reproduce the problem under Cygwin too. Now the question is, where is the right place to fix this? Under Red Hat 8.0, I get the following: $ ls -il /usr/bin/cc /usr/bin/c++ /usr/bin/g++ 328451 -rwxr-xr-x 4 root root 80780 Sep 3 23:03 /usr/bin/c++ 328396 lrwxrwxrwx 1 root root 3 Oct 21 10:04 /usr/bin/cc -> gcc 328451 -rwxr-xr-x 4 root root 80780 Sep 3 23:03 /usr/bin/g++ Under Cygwin, I get the following: $ ls -il /usr/bin/cc /usr/bin/c++ /usr/bin/g++ ls: /usr/bin/cc: No such file or directory 423677 lrwxrwxrwx 1 Administ Domain U 18 Dec 3 08:22 /usr/bin/c++ -> g++.exe 423679 -rwxrwxrwx 1 Administ Domain U 89600 Nov 14 17:37 /usr/bin/g++ So from the above, we can see that a symlink from cc to gcc could be considered missing under Cygwin. I will ask the Cygwin gcc maintainer to add this symlink. If the request is granted, will you consider this issue resolved? ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2003-02-11 01:06 Message: Logged In: YES user_id=488897 The config step is where you do python setup.py config where you can do some test compilations before doing "python setup.py build". Basically it works the same as autoconf/automake's configure scripts. The code for the config is in distutils/command/config.py. If you want to try it out, you can go to my website http://bonsai.ims.u-tokyo.ac.jp/~mdehoon, download pygist, unpack, and run "python setup.py config". You'll notice that it won't work on cygwin, as it tries to use cc instead of gcc. --Michiel. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-11 00:54 Message: Logged In: YES user_id=86216 > On Cygwin, I noticed that distutils tries to use the cc > compiler instead of the gcc compiler for the config > step, resulting in an error. Please excuse my ignorance, but what is the "config step?" How would one invoke the config step? Sorry, but I'm only lightly versed in distutils. > Instead, for the build > step the correct compiler (gcc) is being used. The build step seems to work fine under Cygwin Python 2.2.2 and CVS. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-08 07:55 Message: Logged In: YES user_id=33168 Jason, can you provide any input about the issues w/Cygwin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681504&group_id=5470 From noreply@sourceforge.net Tue Feb 18 10:52:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 18 Feb 2003 02:52:04 -0800 Subject: [Patches] [ python-Patches-688584 ] 2.3 .spec file for building RPMs. Message-ID: Patches item #688584, was opened at 2003-02-18 10:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=688584&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3 .spec file for building RPMs. Initial Comment: Attached is a .spec file updated for Python 2.3, ready for the 2.3a2 release. Remove the python-2.2.spec and add this as python.spec for the 2.3a2 release. Thanks, Sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=688584&group_id=5470 From noreply@sourceforge.net Tue Feb 18 14:31:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 18 Feb 2003 06:31:05 -0800 Subject: [Patches] [ python-Patches-687683 ] Patches to logging Message-ID: Patches item #687683, was opened at 2003-02-16 19:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=687683&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Vinay Sajip (vsajip) Assigned to: Neal Norwitz (nnorwitz) Summary: Patches to logging Initial Comment: Patches to logging as discussed in recent post to python- dev. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-18 09:31 Message: Logged In: YES user_id=33168 I left hdlr.close() commented out as in the original patch per Vinay's private mail. Instead modified the test to close the handler in the two places where removeHandler was called. This also fixed the hang. Checked in as: Doc/lib/liblogging.tex 1.8 Lib/logging/__init__.py 1.5 Lib/logging/handlers.py 1.5 Lib/test/test_logging.py 1.5 Lib/test/output/test_logging 1.3 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-17 11:25 Message: Logged In: YES user_id=33168 Uncommenting the hdlr.close() (ie calling it) did fix the hang. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-17 11:24 Message: Logged In: YES user_id=33168 I had to update the expected output for the change from WARN to WARNING. I also modified the test to use WARNING in 2 places. The test is successful, but hangs after printing 1 test OK. This is the only problem I have. Could the problem be that hdlr.close() is commented on in __init__.py:1013? Some other nits are below. I modified the hasattr(sys, "version_info") condition (4 lines) for _verinfo in __init__.py to the equivalent: _verinfo = getattr(sys, "version_info", None) Since _verinfo is only used in handlers.py, does it really belong in there? Actually, since _verinfo is only used to determine if a socket has sendall(), wouldn't it be better to just do a hasattr(self.sock, 'sendall') check? Vinay, when you make a patch, can you put all the files in a single patch from the src/ directory? It's easier to download & apply. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=687683&group_id=5470 From noreply@sourceforge.net Tue Feb 18 15:13:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 18 Feb 2003 07:13:54 -0800 Subject: [Patches] [ python-Patches-664376 ] sys.path[0] should contain absolute pathname Message-ID: Patches item #664376, was opened at 2003-01-08 14:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664376&group_id=5470 Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: sys.path[0] should contain absolute pathname Initial Comment: This patch changes sys.path[0] to contain an absolute instead of a relative pathname. See python-dev thread starting here: http://mail.python.org/pipermail/python-dev/2003- January/031896.html ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-02-18 16:13 Message: Logged In: YES user_id=11105 Will this patch make it into 2.3a2? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-11 05:07 Message: Logged In: YES user_id=6380 Yeah, but stdlib.h is *already* being included (by Python.h) and MAXPATHLEN is also already available (through osdefs.h). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-11 00:08 Message: Logged In: YES user_id=44345 On my Mac stdlib.h contains the declaration for realpath() and sys/param.h defines MAXPATHLEN which is referenced in the realpath man page. On my Mandrake system, realpath() is declared in stdlib.h. The man page there references limits.h, though I didn't see any constant like MAXPATHLEN referenced in the man page. I guess dump the #includes and wait to see if any platforms complain. S ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-10 23:18 Message: Logged In: YES user_id=6380 stdlib.h is included by Python.h and pyport.h. I don't see anything in sys/param.h that provides realpath(). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-10 23:15 Message: Logged In: YES user_id=44345 Regarding the includes, I was just going by the realpath manpage on my Mac and the fact that a quick scan of Include/*.h didn't turn them up. S ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-10 22:58 Message: Logged In: YES user_id=6380 The abspath.diff patch seems to work. But the two new includes in sysmodule.c are not needed AFAICT. Check in time! ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-10 22:32 Message: Logged In: YES user_id=44345 Here's a somewhat different patch. I don't know if the actual sysmodule.c patch is correct or not, but it includes the necessary framework to verify that realpath() is available. Pick and choose bits as you like. Skip ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-01-10 15:24 Message: Logged In: YES user_id=11105 I believe this problem should be fixed also on systems other than Windows, or the checkin should be reverted again. I've prepared a patch based on an idea of Skip Montanaro, who pointed my to the realpath() function. It is tested on a SuSE 7.0 Linux system, but I don't know which #ifdef I have to se around this code. See the patch for details. Reopened and unassigned for review. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-01-08 16:02 Message: Logged In: YES user_id=11105 Checked in as sysmodule.c, rev 2.112. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 15:00 Message: Logged In: YES user_id=6380 Feel free to check this in. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-01-08 14:31 Message: Logged In: YES user_id=11105 The attached patch (sysmodule.diff) fixes the problem on Windows - that's the only system where I can test it. It leaves sys.argv alone and only changes sys.path[0] to an absolute pathname. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664376&group_id=5470 From noreply@sourceforge.net Tue Feb 18 16:16:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 18 Feb 2003 08:16:44 -0800 Subject: [Patches] [ python-Patches-664376 ] sys.path[0] should contain absolute pathname Message-ID: Patches item #664376, was opened at 2003-01-08 08:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664376&group_id=5470 Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) >Assigned to: Skip Montanaro (montanaro) Summary: sys.path[0] should contain absolute pathname Initial Comment: This patch changes sys.path[0] to contain an absolute instead of a relative pathname. See python-dev thread starting here: http://mail.python.org/pipermail/python-dev/2003- January/031896.html ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-18 11:16 Message: Logged In: YES user_id=6380 I'd like this in 2.3a2. Skip, do you have time to check this in (less the #include and #include )? If not, I can do it. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-02-18 10:13 Message: Logged In: YES user_id=11105 Will this patch make it into 2.3a2? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-10 23:07 Message: Logged In: YES user_id=6380 Yeah, but stdlib.h is *already* being included (by Python.h) and MAXPATHLEN is also already available (through osdefs.h). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-10 18:08 Message: Logged In: YES user_id=44345 On my Mac stdlib.h contains the declaration for realpath() and sys/param.h defines MAXPATHLEN which is referenced in the realpath man page. On my Mandrake system, realpath() is declared in stdlib.h. The man page there references limits.h, though I didn't see any constant like MAXPATHLEN referenced in the man page. I guess dump the #includes and wait to see if any platforms complain. S ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-10 17:18 Message: Logged In: YES user_id=6380 stdlib.h is included by Python.h and pyport.h. I don't see anything in sys/param.h that provides realpath(). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-10 17:15 Message: Logged In: YES user_id=44345 Regarding the includes, I was just going by the realpath manpage on my Mac and the fact that a quick scan of Include/*.h didn't turn them up. S ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-10 16:58 Message: Logged In: YES user_id=6380 The abspath.diff patch seems to work. But the two new includes in sysmodule.c are not needed AFAICT. Check in time! ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-10 16:32 Message: Logged In: YES user_id=44345 Here's a somewhat different patch. I don't know if the actual sysmodule.c patch is correct or not, but it includes the necessary framework to verify that realpath() is available. Pick and choose bits as you like. Skip ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-01-10 09:24 Message: Logged In: YES user_id=11105 I believe this problem should be fixed also on systems other than Windows, or the checkin should be reverted again. I've prepared a patch based on an idea of Skip Montanaro, who pointed my to the realpath() function. It is tested on a SuSE 7.0 Linux system, but I don't know which #ifdef I have to se around this code. See the patch for details. Reopened and unassigned for review. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-01-08 10:02 Message: Logged In: YES user_id=11105 Checked in as sysmodule.c, rev 2.112. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 09:00 Message: Logged In: YES user_id=6380 Feel free to check this in. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-01-08 08:31 Message: Logged In: YES user_id=11105 The attached patch (sysmodule.diff) fixes the problem on Windows - that's the only system where I can test it. It leaves sys.argv alone and only changes sys.path[0] to an absolute pathname. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664376&group_id=5470 From noreply@sourceforge.net Wed Feb 19 13:57:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 19 Feb 2003 05:57:51 -0800 Subject: [Patches] [ python-Patches-684398 ] Fix for verbosity Message-ID: Patches item #684398, was opened at 2003-02-10 23:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684398&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Richard Jones (richard) >Assigned to: A.M. Kuchling (akuchling) Summary: Fix for verbosity Initial Comment: I'd forgotten about this until I just tried to run the register command in 2.3 myself :) I've changed the server response display from using the "verbose" flag to using a new "show-response" flag. I also changed the code that collects the post metadata, since the classifiers attribute will always be available to this code. The download_url metadata attribute implemented by patch www.python.org/sf/683939 is not handled by this patch - it still needs to be added to the post data. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-02-19 08:57 Message: Logged In: YES user_id=11375 Applied as revision 1.3 of register.py. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-02-17 20:55 Message: Logged In: YES user_id=6405 Sorry, trying again. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-17 20:39 Message: Logged In: YES user_id=11375 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684398&group_id=5470 From noreply@sourceforge.net Wed Feb 19 14:10:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 19 Feb 2003 06:10:52 -0800 Subject: [Patches] [ python-Patches-683939 ] Add download_url to setup() Message-ID: Patches item #683939, was opened at 2003-02-10 09:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683939&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Anthony Baxter (anthonybaxter) Summary: Add download_url to setup() Initial Comment: For a Python package installer, it would be a good idea to provide a "download URL" metadata keyword in the next release of Python. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-02-19 09:10 Message: Logged In: YES user_id=11375 So should download_url be omitted from the POST data, or included with a value of UNKNOWN? ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-02-10 19:03 Message: Logged In: YES user_id=6405 Sorry, I was responding to the question "Should the line simply be omitted in this case"? I was also entirely vague about the "dict generation" bit too. I was referring to the build_post_data method in the register command source. In response to the multiple downloads question, I believe this is an open question still (as to whether multiple download sources are to be allowed). PyPI currently allows a single download URL, but since it's still in "test" mode, I could easily change that. Sourceforge doesn't auto-redirect if there's no session cookie present. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-02-10 17:56 Message: Logged In: YES user_id=6405 IMO The line should be omitted. The patch doesn't touch the register command source - could that be done too? Perhaps the dict generation should be moved off to the DistributionMetadata class instead? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-02-10 10:34 Message: Logged In: YES user_id=11105 What will this line contain, if there are several download URLs possible (zip, tar.gz, multiple exe fir different Python versions?) Will it work with redirects a la Sourceforge? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-10 10:00 Message: Logged In: YES user_id=11375 The attached patch implements the new metadata keyword. Open question: if a value isn't provided, the PKG-INFO file will contain the line "Download-URL: UNKNOWN". Should the line simply be omitted in this case? There should be an updated metadata PEP; I'm not sure if PEP 241 should be edited or what, but will ask the relevant people. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683939&group_id=5470 From noreply@sourceforge.net Wed Feb 19 14:28:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 19 Feb 2003 06:28:53 -0800 Subject: [Patches] [ python-Patches-683939 ] Add download_url to setup() Message-ID: Patches item #683939, was opened at 2003-02-10 09:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683939&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Anthony Baxter (anthonybaxter) Summary: Add download_url to setup() Initial Comment: For a Python package installer, it would be a good idea to provide a "download URL" metadata keyword in the next release of Python. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-02-19 09:28 Message: Logged In: YES user_id=11375 The changes to core.py and dist.py are checked in, but register.py still needs to be updated. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-19 09:10 Message: Logged In: YES user_id=11375 So should download_url be omitted from the POST data, or included with a value of UNKNOWN? ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-02-10 19:03 Message: Logged In: YES user_id=6405 Sorry, I was responding to the question "Should the line simply be omitted in this case"? I was also entirely vague about the "dict generation" bit too. I was referring to the build_post_data method in the register command source. In response to the multiple downloads question, I believe this is an open question still (as to whether multiple download sources are to be allowed). PyPI currently allows a single download URL, but since it's still in "test" mode, I could easily change that. Sourceforge doesn't auto-redirect if there's no session cookie present. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-02-10 17:56 Message: Logged In: YES user_id=6405 IMO The line should be omitted. The patch doesn't touch the register command source - could that be done too? Perhaps the dict generation should be moved off to the DistributionMetadata class instead? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-02-10 10:34 Message: Logged In: YES user_id=11105 What will this line contain, if there are several download URLs possible (zip, tar.gz, multiple exe fir different Python versions?) Will it work with redirects a la Sourceforge? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-10 10:00 Message: Logged In: YES user_id=11375 The attached patch implements the new metadata keyword. Open question: if a value isn't provided, the PKG-INFO file will contain the line "Download-URL: UNKNOWN". Should the line simply be omitted in this case? There should be an updated metadata PEP; I'm not sure if PEP 241 should be edited or what, but will ask the relevant people. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683939&group_id=5470 From noreply@sourceforge.net Wed Feb 19 14:37:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 19 Feb 2003 06:37:35 -0800 Subject: [Patches] [ python-Patches-683939 ] Add download_url to setup() Message-ID: Patches item #683939, was opened at 2003-02-10 09:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683939&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: A.M. Kuchling (akuchling) >Assigned to: A.M. Kuchling (akuchling) Summary: Add download_url to setup() Initial Comment: For a Python package installer, it would be a good idea to provide a "download URL" metadata keyword in the next release of Python. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-02-19 09:37 Message: Logged In: YES user_id=11375 Rev. 1.4 of register.py includes the download_url data in the POST; it will be UNKNOWN if not supplied. Richard, just re-open this bug if you want it to be different (suppressing it completely or whatever). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-19 09:28 Message: Logged In: YES user_id=11375 The changes to core.py and dist.py are checked in, but register.py still needs to be updated. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-19 09:10 Message: Logged In: YES user_id=11375 So should download_url be omitted from the POST data, or included with a value of UNKNOWN? ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-02-10 19:03 Message: Logged In: YES user_id=6405 Sorry, I was responding to the question "Should the line simply be omitted in this case"? I was also entirely vague about the "dict generation" bit too. I was referring to the build_post_data method in the register command source. In response to the multiple downloads question, I believe this is an open question still (as to whether multiple download sources are to be allowed). PyPI currently allows a single download URL, but since it's still in "test" mode, I could easily change that. Sourceforge doesn't auto-redirect if there's no session cookie present. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-02-10 17:56 Message: Logged In: YES user_id=6405 IMO The line should be omitted. The patch doesn't touch the register command source - could that be done too? Perhaps the dict generation should be moved off to the DistributionMetadata class instead? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-02-10 10:34 Message: Logged In: YES user_id=11105 What will this line contain, if there are several download URLs possible (zip, tar.gz, multiple exe fir different Python versions?) Will it work with redirects a la Sourceforge? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-10 10:00 Message: Logged In: YES user_id=11375 The attached patch implements the new metadata keyword. Open question: if a value isn't provided, the PKG-INFO file will contain the line "Download-URL: UNKNOWN". Should the line simply be omitted in this case? There should be an updated metadata PEP; I'm not sure if PEP 241 should be edited or what, but will ask the relevant people. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683939&group_id=5470 From noreply@sourceforge.net Wed Feb 19 15:25:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 19 Feb 2003 07:25:42 -0800 Subject: [Patches] [ python-Patches-664376 ] sys.path[0] should contain absolute pathname Message-ID: Patches item #664376, was opened at 2003-01-08 08:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664376&group_id=5470 Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) >Assigned to: Guido van Rossum (gvanrossum) Summary: sys.path[0] should contain absolute pathname Initial Comment: This patch changes sys.path[0] to contain an absolute instead of a relative pathname. See python-dev thread starting here: http://mail.python.org/pipermail/python-dev/2003- January/031896.html ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-19 10:25 Message: Logged In: YES user_id=6380 I'll check this in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-18 11:16 Message: Logged In: YES user_id=6380 I'd like this in 2.3a2. Skip, do you have time to check this in (less the #include and #include )? If not, I can do it. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-02-18 10:13 Message: Logged In: YES user_id=11105 Will this patch make it into 2.3a2? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-10 23:07 Message: Logged In: YES user_id=6380 Yeah, but stdlib.h is *already* being included (by Python.h) and MAXPATHLEN is also already available (through osdefs.h). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-10 18:08 Message: Logged In: YES user_id=44345 On my Mac stdlib.h contains the declaration for realpath() and sys/param.h defines MAXPATHLEN which is referenced in the realpath man page. On my Mandrake system, realpath() is declared in stdlib.h. The man page there references limits.h, though I didn't see any constant like MAXPATHLEN referenced in the man page. I guess dump the #includes and wait to see if any platforms complain. S ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-10 17:18 Message: Logged In: YES user_id=6380 stdlib.h is included by Python.h and pyport.h. I don't see anything in sys/param.h that provides realpath(). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-10 17:15 Message: Logged In: YES user_id=44345 Regarding the includes, I was just going by the realpath manpage on my Mac and the fact that a quick scan of Include/*.h didn't turn them up. S ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-10 16:58 Message: Logged In: YES user_id=6380 The abspath.diff patch seems to work. But the two new includes in sysmodule.c are not needed AFAICT. Check in time! ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-10 16:32 Message: Logged In: YES user_id=44345 Here's a somewhat different patch. I don't know if the actual sysmodule.c patch is correct or not, but it includes the necessary framework to verify that realpath() is available. Pick and choose bits as you like. Skip ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-01-10 09:24 Message: Logged In: YES user_id=11105 I believe this problem should be fixed also on systems other than Windows, or the checkin should be reverted again. I've prepared a patch based on an idea of Skip Montanaro, who pointed my to the realpath() function. It is tested on a SuSE 7.0 Linux system, but I don't know which #ifdef I have to se around this code. See the patch for details. Reopened and unassigned for review. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-01-08 10:02 Message: Logged In: YES user_id=11105 Checked in as sysmodule.c, rev 2.112. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 09:00 Message: Logged In: YES user_id=6380 Feel free to check this in. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-01-08 08:31 Message: Logged In: YES user_id=11105 The attached patch (sysmodule.diff) fixes the problem on Windows - that's the only system where I can test it. It leaves sys.argv alone and only changes sys.path[0] to an absolute pathname. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664376&group_id=5470 From noreply@sourceforge.net Wed Feb 19 15:33:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 19 Feb 2003 07:33:08 -0800 Subject: [Patches] [ python-Patches-664376 ] sys.path[0] should contain absolute pathname Message-ID: Patches item #664376, was opened at 2003-01-08 08:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664376&group_id=5470 Category: None Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Guido van Rossum (gvanrossum) Summary: sys.path[0] should contain absolute pathname Initial Comment: This patch changes sys.path[0] to contain an absolute instead of a relative pathname. See python-dev thread starting here: http://mail.python.org/pipermail/python-dev/2003- January/031896.html ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-19 10:33 Message: Logged In: YES user_id=6380 All checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-19 10:25 Message: Logged In: YES user_id=6380 I'll check this in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-18 11:16 Message: Logged In: YES user_id=6380 I'd like this in 2.3a2. Skip, do you have time to check this in (less the #include and #include )? If not, I can do it. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-02-18 10:13 Message: Logged In: YES user_id=11105 Will this patch make it into 2.3a2? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-10 23:07 Message: Logged In: YES user_id=6380 Yeah, but stdlib.h is *already* being included (by Python.h) and MAXPATHLEN is also already available (through osdefs.h). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-10 18:08 Message: Logged In: YES user_id=44345 On my Mac stdlib.h contains the declaration for realpath() and sys/param.h defines MAXPATHLEN which is referenced in the realpath man page. On my Mandrake system, realpath() is declared in stdlib.h. The man page there references limits.h, though I didn't see any constant like MAXPATHLEN referenced in the man page. I guess dump the #includes and wait to see if any platforms complain. S ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-10 17:18 Message: Logged In: YES user_id=6380 stdlib.h is included by Python.h and pyport.h. I don't see anything in sys/param.h that provides realpath(). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-10 17:15 Message: Logged In: YES user_id=44345 Regarding the includes, I was just going by the realpath manpage on my Mac and the fact that a quick scan of Include/*.h didn't turn them up. S ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-10 16:58 Message: Logged In: YES user_id=6380 The abspath.diff patch seems to work. But the two new includes in sysmodule.c are not needed AFAICT. Check in time! ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-10 16:32 Message: Logged In: YES user_id=44345 Here's a somewhat different patch. I don't know if the actual sysmodule.c patch is correct or not, but it includes the necessary framework to verify that realpath() is available. Pick and choose bits as you like. Skip ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-01-10 09:24 Message: Logged In: YES user_id=11105 I believe this problem should be fixed also on systems other than Windows, or the checkin should be reverted again. I've prepared a patch based on an idea of Skip Montanaro, who pointed my to the realpath() function. It is tested on a SuSE 7.0 Linux system, but I don't know which #ifdef I have to se around this code. See the patch for details. Reopened and unassigned for review. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-01-08 10:02 Message: Logged In: YES user_id=11105 Checked in as sysmodule.c, rev 2.112. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 09:00 Message: Logged In: YES user_id=6380 Feel free to check this in. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-01-08 08:31 Message: Logged In: YES user_id=11105 The attached patch (sysmodule.diff) fixes the problem on Windows - that's the only system where I can test it. It leaves sys.argv alone and only changes sys.path[0] to an absolute pathname. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664376&group_id=5470 From noreply@sourceforge.net Wed Feb 19 16:17:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 19 Feb 2003 08:17:37 -0800 Subject: [Patches] [ python-Patches-686601 ] Remove unncessary casts for PyEval_GetFrame() Message-ID: Patches item #686601, was opened at 2003-02-14 10:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686601&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Ben Laurie (benl) Assigned to: Guido van Rossum (gvanrossum) Summary: Remove unncessary casts for PyEval_GetFrame() Initial Comment: PyEval_GetFrame()'s type is known, there's no need to cast it. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-19 11:17 Message: Logged In: YES user_id=6380 All checked in. I used struct _frame intead of adding #includes to Python.h. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-14 12:48 Message: Logged In: YES user_id=6380 I'm fine with this, even though it changes a public API (and hence might break 3rd party extensions). Neil, since you showed some interest, feel free to check it in (assuming it passes the test suit :-). ---------------------------------------------------------------------- Comment By: Ben Laurie (benl) Date: 2003-02-14 12:37 Message: Logged In: YES user_id=14333 Patch attached (and I swear I ticked the damn box the first time) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 10:54 Message: Logged In: YES user_id=33168 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686601&group_id=5470 From noreply@sourceforge.net Fri Feb 21 02:10:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 20 Feb 2003 18:10:55 -0800 Subject: [Patches] [ python-Patches-671666 ] Make the default encoding provided on Windows Message-ID: Patches item #671666, was opened at 2003-01-21 03:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671666&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: Rejected Priority: 5 Submitted By: SUZUKI Hisao (suzuki_hisao) >Assigned to: Martin v. Löwis (loewis) Summary: Make the default encoding provided on Windows Initial Comment: On Windows, some default encodings are not provided by Python (e.g. "cp932" in Japanese locale), while they are always available as "mbcs" in each locale. This patch ensures them usable in a very efficient way by aliasing them to "mbcs" in such a case. Note that IDLE does not start up on Windows unless the default encoding is provided. The patch makes IDLE operable all over the (Windows) world ;-). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-02-20 21:10 Message: Logged In: YES user_id=31435 Assigning to Martin, in the hopes they can work out their differences. ---------------------------------------------------------------------- Comment By: SUZUKI Hisao (suzuki_hisao) Date: 2003-01-28 00:49 Message: Logged In: YES user_id=495142 I can reproduce the IDLE problem on my Windows 2000 in Japanese locale. I hope you will confirm it by asking your friends in Japan or other countries. I am afraid you missed the point. The patch does NOT change the default encoding of Python itself. It is ASCII still. It only makes the encoding of locale.getdefaultlocale()[1] be PROVIDED. Please read that short patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-21 17:04 Message: Logged In: YES user_id=21627 I'm rejecting this patch. The factory system default encoding of Python is ASCII, on all platforms (atleast, it should be this way; MacOS currently deviates). I cannot reproduce the IDLE problem; IDLE starts without that patch just fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671666&group_id=5470 From noreply@sourceforge.net Fri Feb 21 03:09:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 20 Feb 2003 19:09:16 -0800 Subject: [Patches] [ python-Patches-677887 ] Add traceback.format_exc Message-ID: Patches item #677887, was opened at 2003-01-30 20:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677887&group_id=5470 Category: Library (Lib) Group: None Status: Open >Resolution: Accepted Priority: 4 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Neil Schemenauer (nascheme) Summary: Add traceback.format_exc Initial Comment: I sometimes end up wanting this function. I think it compliments print_exc() nicely. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-20 22:09 Message: Logged In: YES user_id=80475 Please post a NEWS item. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-02-12 11:47 Message: Logged In: YES user_id=35752 Argh! Here's the patch. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 14:40 Message: Logged In: YES user_id=92689 There's no file attached... ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-02-08 02:39 Message: Logged In: YES user_id=35752 Yes, feel free to reassign. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-07 00:58 Message: Logged In: YES user_id=80475 Did you intend to assign this one to me? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677887&group_id=5470 From noreply@sourceforge.net Fri Feb 21 03:39:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 20 Feb 2003 19:39:05 -0800 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 15:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Walter Dörwald (doerwalter) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-20 22:39 Message: Logged In: YES user_id=80475 * test_string.py imports sets but does not use it. * the names of the mixin classes could possibly be made clearer so I won't have to search into the comments to find-out which mixins are appropriate for each class. Overall, it looks like a nice factoring job and ought to go a long ways toward keeping these guys in sync in the future. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-17 13:29 Message: Logged In: YES user_id=89016 Here is the next bunch of ports: the string tests have been ported to PyUnit and made as reusable as possible. Tests are now shared between str, unicode, UserString and the string module. As a result of reusing a part of the unicode tests for str, the coverage in stringobject.c goes from 83% to 86%. Furthermore it should help keep the API consistent between str and unicode (Example: "%c" % 0xffffffff raises OverflowError, u"%c" % 0xffffffff raises ValueError) Raymond can look look through the scripts and check that everything is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-16 04:33 Message: Logged In: YES user_id=89016 I'm currently working on a PyUnit port of the string tests (i.e. str, unicode, UserString and the string module). Uploading the result to this patch would be easier, as it already has a establsihed audience: But I can open a new patch for that if you want. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 15:11 Message: Logged In: YES user_id=33168 Walter, can this patch be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-14 06:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_charmapcodec delete Lib/test/test_charmapcodec.py 1.6 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 03:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 13:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 13:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 13:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-12 22:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 18:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 17:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 17:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 16:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 15:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 09:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 15:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 12:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 12:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 11:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 14:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 09:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 11:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 15:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Fri Feb 21 04:29:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 20 Feb 2003 20:29:45 -0800 Subject: [Patches] [ python-Patches-675422 ] Add tzset method to time module Message-ID: Patches item #675422, was opened at 2003-01-28 00:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675422&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) >Assigned to: Guido van Rossum (gvanrossum) Summary: Add tzset method to time module Initial Comment: Adds access to the tzset method, allowing you to change your local timezone as required. In addition to invoking the tzset system call, the code also updates the timezone attributes (time.timezone etc). This lets you do timezone conversions amongst other things. Also includes changes to configure.in to only build new code if the tzset method correctly switches timezones on your platform. This should be for all modern Unixes, and possibly other platforms. Also includes tests in test_time.py Docs would be along the lines of: tzset() -- Initialize, or reinitialize, the local timezone to the value stored in os.environ['TZ']. The TZ environment variable should be specified in standard Uniz timezone format as documented in the tzset man page (eg. 'US/Eastern', 'Europe/Amsterdam'). Unknown timezones will silently fall back to UTC. If the TZ environment variable is not set, the local timezone is set to the systems best guess of wallclock time. Changing the TZ environment variable without calling tzset *may* change the local timezone used by methods such as localtime, but this behaviour should not be relied on. eg:: >>> now = time.time() >>> os.environ['TZ'] = 'Europe/Amsterdam' >>> time.tzset() >>> time.ctime(now) 'Mon Jan 27 14:35:17 2003' >>> time.tzname ('CET', 'CEST') >>> os.environ['TZ'] = 'US/Eastern' >>> time.tzset() >>> time.ctime(now) 'Mon Jan 27 08:35:17 2003' >>> time.tzname ('EST', 'EDT') ---------------------------------------------------------------------- >Comment By: Stuart Bishop (zenzen) Date: 2003-02-21 15:29 Message: Logged In: YES user_id=46639 Assigning to Guido for consideration of being added to 2.2.3, and since he through this patch was a good idea in the first place :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675422&group_id=5470 From noreply@sourceforge.net Fri Feb 21 12:03:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 21 Feb 2003 04:03:22 -0800 Subject: [Patches] [ python-Patches-491107 ] Cygwin setup.py import workaround patch Message-ID: Patches item #491107, was opened at 2001-12-10 02:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 Category: Distutils and setup.py >Group: Python 2.2.x >Status: Open Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: Cygwin setup.py import workaround patch Initial Comment: Sorry for submitting this in the 11th hour, but this patch re-enables clean building under Cygwin. See the following for details: http://cygwin.com/ml/cygwin/2001-12/msg00409.html Unfortunately, this patch is only a build workaround and does *not* solve the root cause which is Cygwin's problem with DLL address clashes during fork(). Hopefully, a yet to be instituted rebase tool will solve this problem for real. See the following for details: http://sources.redhat.com/ml/cygwin/2001-12/msg00446.html ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-02-21 03:03 Message: Logged In: YES user_id=86216 On Thu, Feb 20, 2003 at 01:50:40PM -0500, Guido van Rossum wrote: > Is this in current CVS on the 2.2.x branch? If not, it should be. Per Guido's request, I am back patching this to the 2.2.x branch. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-22 09:11 Message: Logged In: NO Looks OK to me. (--Guido, not logged in to SF.) ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-22 08:47 Message: Logged In: YES user_id=86216 Committed as setup.py 1.87. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-22 08:34 Message: Logged In: YES user_id=86216 This patch will not affect any platform except for Cygwin. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-22 08:26 Message: Logged In: YES user_id=6656 Uh, yeah. It's not going to affect any platform other than cygwin is it? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-22 08:23 Message: Logged In: YES user_id=86216 Can I check this in? Please see my comments from 2002-04-30 11:53 for my reasoning. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-22 07:56 Message: Logged In: YES user_id=6656 Jason, this is now your problem... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-02 06:31 Message: Logged In: YES user_id=6380 Giving Jason checkin permission is probably the best solution here. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-02 06:04 Message: Logged In: YES user_id=6656 I can't test cygwin any more. Is there anyone who can? I know Tim can, but I'm not sure this is worth his time. If you're just looking for someone to check stuff in, I can do that, or we can add Jason as a developer & then he can do it (gets my vote!). ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-04-30 11:53 Message: Logged In: YES user_id=86216 mwh wrote: > Jason, feel free to complain if you think this isn't > the right thing to do. I guess that I would like to complain and reopen this issue. :,) I cannot build a Python 2.2.1 with threads under Cygwin without this patch even though I'm using Michael's static _socket workaround. This is due to the Cygwin fork() problem with DLL base address conflicts that are triggered by importing many modules during the setup.py run. Similar problems can also be caused by regrtest.py. Even after my rebase patch is accepted into Cygwin's setup.exe, I feel that patch will still be necessary. This is because during the build process the shared extension (i.e., DLLs) will not be rebased yet. Hence, the potential for DLL base address conflicts will exist. One way to obviate this patch is to push the rebase functionality into Cygwin's ld. Unfortunately, I don't think this is likely to happen. Another possible way, is to use the yet to be defined and implemented unload module functionality: http://mail.python.org/pipermail/python-dev/2001-December/019028.html I have refreshed the patch against current CVS for convenience. Can this patch be accepted this time? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-12-12 06:25 Message: Logged In: YES user_id=86216 I'm not happy with my workaround, but I'm not happy that Python will not build OOTB under Cygwin until the fork() issue gets resolved. Choose your poison! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-12 05:40 Message: Logged In: YES user_id=6656 I'm rejecting this. Linking _socket statically is a better workaround until the issue actually gets sorted out at the cygwin end. Jason, feel free to complain if you think this isn't the right thing to do. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 06:34 Message: Logged In: YES user_id=6380 Sure. While the release candidate is officially scheduled for Wednesday this weel, I think it'll actually be Friday. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 06:21 Message: Logged In: YES user_id=6656 Well, it lets Python build, but the resulting Python doesn't work all that well. I've just noticed that linking _socket statically seems to cure the problem. Can we have a few more days to fiddle with this? I wouldn't recommend applying this patch at this stage. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 06:08 Message: Logged In: YES user_id=6380 Michael, can you review this ASAP? If not, please assign to Tim. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 From noreply@sourceforge.net Fri Feb 21 12:27:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 21 Feb 2003 04:27:58 -0800 Subject: [Patches] [ python-Patches-491107 ] Cygwin setup.py import workaround patch Message-ID: Patches item #491107, was opened at 2001-12-10 02:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 Category: Distutils and setup.py Group: Python 2.2.x >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: Cygwin setup.py import workaround patch Initial Comment: Sorry for submitting this in the 11th hour, but this patch re-enables clean building under Cygwin. See the following for details: http://cygwin.com/ml/cygwin/2001-12/msg00409.html Unfortunately, this patch is only a build workaround and does *not* solve the root cause which is Cygwin's problem with DLL address clashes during fork(). Hopefully, a yet to be instituted rebase tool will solve this problem for real. See the following for details: http://sources.redhat.com/ml/cygwin/2001-12/msg00446.html ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-02-21 03:27 Message: Logged In: YES user_id=86216 Committed as setup.py 1.73.4.15. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-02-21 03:03 Message: Logged In: YES user_id=86216 On Thu, Feb 20, 2003 at 01:50:40PM -0500, Guido van Rossum wrote: > Is this in current CVS on the 2.2.x branch? If not, it should be. Per Guido's request, I am back patching this to the 2.2.x branch. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-22 09:11 Message: Logged In: NO Looks OK to me. (--Guido, not logged in to SF.) ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-22 08:47 Message: Logged In: YES user_id=86216 Committed as setup.py 1.87. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-22 08:34 Message: Logged In: YES user_id=86216 This patch will not affect any platform except for Cygwin. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-22 08:26 Message: Logged In: YES user_id=6656 Uh, yeah. It's not going to affect any platform other than cygwin is it? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-22 08:23 Message: Logged In: YES user_id=86216 Can I check this in? Please see my comments from 2002-04-30 11:53 for my reasoning. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-22 07:56 Message: Logged In: YES user_id=6656 Jason, this is now your problem... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-02 06:31 Message: Logged In: YES user_id=6380 Giving Jason checkin permission is probably the best solution here. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-02 06:04 Message: Logged In: YES user_id=6656 I can't test cygwin any more. Is there anyone who can? I know Tim can, but I'm not sure this is worth his time. If you're just looking for someone to check stuff in, I can do that, or we can add Jason as a developer & then he can do it (gets my vote!). ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-04-30 11:53 Message: Logged In: YES user_id=86216 mwh wrote: > Jason, feel free to complain if you think this isn't > the right thing to do. I guess that I would like to complain and reopen this issue. :,) I cannot build a Python 2.2.1 with threads under Cygwin without this patch even though I'm using Michael's static _socket workaround. This is due to the Cygwin fork() problem with DLL base address conflicts that are triggered by importing many modules during the setup.py run. Similar problems can also be caused by regrtest.py. Even after my rebase patch is accepted into Cygwin's setup.exe, I feel that patch will still be necessary. This is because during the build process the shared extension (i.e., DLLs) will not be rebased yet. Hence, the potential for DLL base address conflicts will exist. One way to obviate this patch is to push the rebase functionality into Cygwin's ld. Unfortunately, I don't think this is likely to happen. Another possible way, is to use the yet to be defined and implemented unload module functionality: http://mail.python.org/pipermail/python-dev/2001-December/019028.html I have refreshed the patch against current CVS for convenience. Can this patch be accepted this time? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-12-12 06:25 Message: Logged In: YES user_id=86216 I'm not happy with my workaround, but I'm not happy that Python will not build OOTB under Cygwin until the fork() issue gets resolved. Choose your poison! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-12 05:40 Message: Logged In: YES user_id=6656 I'm rejecting this. Linking _socket statically is a better workaround until the issue actually gets sorted out at the cygwin end. Jason, feel free to complain if you think this isn't the right thing to do. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 06:34 Message: Logged In: YES user_id=6380 Sure. While the release candidate is officially scheduled for Wednesday this weel, I think it'll actually be Friday. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 06:21 Message: Logged In: YES user_id=6656 Well, it lets Python build, but the resulting Python doesn't work all that well. I've just noticed that linking _socket statically seems to cure the problem. Can we have a few more days to fiddle with this? I wouldn't recommend applying this patch at this stage. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 06:08 Message: Logged In: YES user_id=6380 Michael, can you review this ASAP? If not, please assign to Tim. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 From noreply@sourceforge.net Fri Feb 21 12:56:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 21 Feb 2003 04:56:37 -0800 Subject: [Patches] [ python-Patches-675422 ] Add tzset method to time module Message-ID: Patches item #675422, was opened at 2003-01-27 08:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675422&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Guido van Rossum (gvanrossum) Summary: Add tzset method to time module Initial Comment: Adds access to the tzset method, allowing you to change your local timezone as required. In addition to invoking the tzset system call, the code also updates the timezone attributes (time.timezone etc). This lets you do timezone conversions amongst other things. Also includes changes to configure.in to only build new code if the tzset method correctly switches timezones on your platform. This should be for all modern Unixes, and possibly other platforms. Also includes tests in test_time.py Docs would be along the lines of: tzset() -- Initialize, or reinitialize, the local timezone to the value stored in os.environ['TZ']. The TZ environment variable should be specified in standard Uniz timezone format as documented in the tzset man page (eg. 'US/Eastern', 'Europe/Amsterdam'). Unknown timezones will silently fall back to UTC. If the TZ environment variable is not set, the local timezone is set to the systems best guess of wallclock time. Changing the TZ environment variable without calling tzset *may* change the local timezone used by methods such as localtime, but this behaviour should not be relied on. eg:: >>> now = time.time() >>> os.environ['TZ'] = 'Europe/Amsterdam' >>> time.tzset() >>> time.ctime(now) 'Mon Jan 27 14:35:17 2003' >>> time.tzname ('CET', 'CEST') >>> os.environ['TZ'] = 'US/Eastern' >>> time.tzset() >>> time.ctime(now) 'Mon Jan 27 08:35:17 2003' >>> time.tzname ('EST', 'EDT') ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-21 07:56 Message: Logged In: YES user_id=6380 Uh? This is a new feature, so doesn't apply to 2.2.3. Maybe you meant 2.3? ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-02-20 23:29 Message: Logged In: YES user_id=46639 Assigning to Guido for consideration of being added to 2.2.3, and since he through this patch was a good idea in the first place :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675422&group_id=5470 From noreply@sourceforge.net Fri Feb 21 13:05:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 21 Feb 2003 05:05:40 -0800 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 21:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Walter Dörwald (doerwalter) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-02-21 14:05 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/string_tests.py 1.27 Lib/test/test_str.py 1.1 Lib/test/test_string.py 1.24 Lib/test/test_unicode.py 1.79 Lib/test/test_userstring.py 1.10 Lib/test/output/test_string delete I've removed the sets import and renamed the mixin tests to contain the relevant class/module names (e.g. MixinStrStringUserStringTest) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-21 04:39 Message: Logged In: YES user_id=80475 * test_string.py imports sets but does not use it. * the names of the mixin classes could possibly be made clearer so I won't have to search into the comments to find-out which mixins are appropriate for each class. Overall, it looks like a nice factoring job and ought to go a long ways toward keeping these guys in sync in the future. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-17 19:29 Message: Logged In: YES user_id=89016 Here is the next bunch of ports: the string tests have been ported to PyUnit and made as reusable as possible. Tests are now shared between str, unicode, UserString and the string module. As a result of reusing a part of the unicode tests for str, the coverage in stringobject.c goes from 83% to 86%. Furthermore it should help keep the API consistent between str and unicode (Example: "%c" % 0xffffffff raises OverflowError, u"%c" % 0xffffffff raises ValueError) Raymond can look look through the scripts and check that everything is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-16 10:33 Message: Logged In: YES user_id=89016 I'm currently working on a PyUnit port of the string tests (i.e. str, unicode, UserString and the string module). Uploading the result to this patch would be easier, as it already has a establsihed audience: But I can open a new patch for that if you want. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 21:11 Message: Logged In: YES user_id=33168 Walter, can this patch be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-14 12:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_charmapcodec delete Lib/test/test_charmapcodec.py 1.6 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 09:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 19:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-13 04:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 00:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 23:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 23:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 22:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 21:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 15:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 21:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 18:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 18:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 17:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 20:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 15:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 17:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 21:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Fri Feb 21 21:45:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 21 Feb 2003 13:45:09 -0800 Subject: [Patches] [ python-Patches-675422 ] Add tzset method to time module Message-ID: Patches item #675422, was opened at 2003-01-28 00:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675422&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Guido van Rossum (gvanrossum) Summary: Add tzset method to time module Initial Comment: Adds access to the tzset method, allowing you to change your local timezone as required. In addition to invoking the tzset system call, the code also updates the timezone attributes (time.timezone etc). This lets you do timezone conversions amongst other things. Also includes changes to configure.in to only build new code if the tzset method correctly switches timezones on your platform. This should be for all modern Unixes, and possibly other platforms. Also includes tests in test_time.py Docs would be along the lines of: tzset() -- Initialize, or reinitialize, the local timezone to the value stored in os.environ['TZ']. The TZ environment variable should be specified in standard Uniz timezone format as documented in the tzset man page (eg. 'US/Eastern', 'Europe/Amsterdam'). Unknown timezones will silently fall back to UTC. If the TZ environment variable is not set, the local timezone is set to the systems best guess of wallclock time. Changing the TZ environment variable without calling tzset *may* change the local timezone used by methods such as localtime, but this behaviour should not be relied on. eg:: >>> now = time.time() >>> os.environ['TZ'] = 'Europe/Amsterdam' >>> time.tzset() >>> time.ctime(now) 'Mon Jan 27 14:35:17 2003' >>> time.tzname ('CET', 'CEST') >>> os.environ['TZ'] = 'US/Eastern' >>> time.tzset() >>> time.ctime(now) 'Mon Jan 27 08:35:17 2003' >>> time.tzname ('EST', 'EDT') ---------------------------------------------------------------------- >Comment By: Stuart Bishop (zenzen) Date: 2003-02-22 08:45 Message: Logged In: YES user_id=46639 It is a patch to 2.3, but I'd though I'd try and sneak this new feature past people into 2.2.3 as I want to be able to use it in Zope 2 :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-21 23:56 Message: Logged In: YES user_id=6380 Uh? This is a new feature, so doesn't apply to 2.2.3. Maybe you meant 2.3? ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-02-21 15:29 Message: Logged In: YES user_id=46639 Assigning to Guido for consideration of being added to 2.2.3, and since he through this patch was a good idea in the first place :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675422&group_id=5470 From noreply@sourceforge.net Fri Feb 21 21:49:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 21 Feb 2003 13:49:44 -0800 Subject: [Patches] [ python-Patches-675422 ] Add tzset method to time module Message-ID: Patches item #675422, was opened at 2003-01-27 08:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675422&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Guido van Rossum (gvanrossum) Summary: Add tzset method to time module Initial Comment: Adds access to the tzset method, allowing you to change your local timezone as required. In addition to invoking the tzset system call, the code also updates the timezone attributes (time.timezone etc). This lets you do timezone conversions amongst other things. Also includes changes to configure.in to only build new code if the tzset method correctly switches timezones on your platform. This should be for all modern Unixes, and possibly other platforms. Also includes tests in test_time.py Docs would be along the lines of: tzset() -- Initialize, or reinitialize, the local timezone to the value stored in os.environ['TZ']. The TZ environment variable should be specified in standard Uniz timezone format as documented in the tzset man page (eg. 'US/Eastern', 'Europe/Amsterdam'). Unknown timezones will silently fall back to UTC. If the TZ environment variable is not set, the local timezone is set to the systems best guess of wallclock time. Changing the TZ environment variable without calling tzset *may* change the local timezone used by methods such as localtime, but this behaviour should not be relied on. eg:: >>> now = time.time() >>> os.environ['TZ'] = 'Europe/Amsterdam' >>> time.tzset() >>> time.ctime(now) 'Mon Jan 27 14:35:17 2003' >>> time.tzname ('CET', 'CEST') >>> os.environ['TZ'] = 'US/Eastern' >>> time.tzset() >>> time.ctime(now) 'Mon Jan 27 08:35:17 2003' >>> time.tzname ('EST', 'EDT') ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-21 16:49 Message: Logged In: YES user_id=6380 Sorry, not a chance. ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-02-21 16:45 Message: Logged In: YES user_id=46639 It is a patch to 2.3, but I'd though I'd try and sneak this new feature past people into 2.2.3 as I want to be able to use it in Zope 2 :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-21 07:56 Message: Logged In: YES user_id=6380 Uh? This is a new feature, so doesn't apply to 2.2.3. Maybe you meant 2.3? ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-02-20 23:29 Message: Logged In: YES user_id=46639 Assigning to Guido for consideration of being added to 2.2.3, and since he through this patch was a good idea in the first place :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675422&group_id=5470 From noreply@sourceforge.net Sat Feb 22 10:05:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 22 Feb 2003 02:05:32 -0800 Subject: [Patches] [ python-Patches-686379 ] logging.handlers.SMTPHandler and single 'to' address Message-ID: Patches item #686379, was opened at 2003-02-14 16:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686379&group_id=5470 >Category: Library (Lib) Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: logging.handlers.SMTPHandler and single 'to' address Initial Comment: logging.handlers.SMTPHandler should handle a single string to address - at the moment if you mess up and pass a string, (e.g. 'someuser@foo.com'), you get a message body To: line of s@localdomain,o@localdomain,m@localdomain,... smtplib has the same signature, but checks for a single string argument. This patch does the same for the logging module. Patch is to Lib/logging/handlers.py. Not sure if the version in the Python CVS is the "home" version of the code, or if it's just an import of a different CVS. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-02-22 21:05 Message: Logged In: YES user_id=29957 the recent set of patches for logging included this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686379&group_id=5470 From noreply@sourceforge.net Sat Feb 22 20:41:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 22 Feb 2003 12:41:37 -0800 Subject: [Patches] [ python-Patches-685051 ] fix for 680789: reprs in arraymodule Message-ID: Patches item #685051, was opened at 2003-02-11 19:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=685051&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Raymond Hettinger (rhettinger) Summary: fix for 680789: reprs in arraymodule Initial Comment: arraymodule's repr used "string += ',' + el" for each element in the array. Lists and dicts did a string.join to build the repr. Attached patch builds a tuple of array elements and then joins them. This fixes the time issue, but I don't know enough about how you guys manage memory in each case to tell what impact that'll have on really, really big arrays (although I imagine it takes more memory). ---------------------------------------------------------------------- >Comment By: logistix (logistix) Date: 2003-02-22 14:41 Message: Logged In: YES user_id=699438 As I learn more about the sizeof PyObjects, I don't really like my last patch. It creates too many intermediate PyObjects at at the same time. This patch uses two passes to build the repr, reducing the number of temporary PyObjects at any given time to 4 or five, instead of len(array) + 5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=685051&group_id=5470 From noreply@sourceforge.net Sun Feb 23 14:15:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 23 Feb 2003 06:15:25 -0800 Subject: [Patches] [ python-Patches-633359 ] Patch for sre bug 610299 Message-ID: Patches item #633359, was opened at 2002-11-04 11:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=633359&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: Accepted Priority: 7 Submitted By: Greg Chapman (glchapman) >Assigned to: Guido van Rossum (gvanrossum) Summary: Patch for sre bug 610299 Initial Comment: Bug report 610299 points out this discrepancy: >>> re.compile(r'\w{1}', re.U).sub('X', u'hello caf\xe9') u'XXXXX XXXX' >>> re.compile(r'\w', re.U).sub('X', u'hello caf\xe9') u'XXXXX XXX\xe9' The problem is in sre_compile.py: the call to _compile_charset near the end of _compile_info forgets to pass in the flags, so that the info charset is not compiled with re.U. (The info charset is used when searching to find the first character at which a match could start; it is not generated for patterns beginning with a repeat like '\w{1}'.) The attached patch changes this call to pass in the flags; it is against the 2.2.2 version of sre_compile.py. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 09:15 Message: Logged In: YES user_id=6380 Grabbing this since effbot seems unresponsive. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2002-11-04 13:28 Message: Logged In: YES user_id=86307 Sorry, I though I marked the checkbox (I know I went throught the browse button to find the file). Anyway, here's the file. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-04 12:43 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=633359&group_id=5470 From noreply@sourceforge.net Sun Feb 23 14:16:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 23 Feb 2003 06:16:42 -0800 Subject: [Patches] [ python-Patches-687598 ] array.append is sloooow Message-ID: Patches item #687598, was opened at 2003-02-16 14:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=687598&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: logistix (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: array.append is sloooow Initial Comment: array.append re'mallocs and copies each time an item is appended to it. That makes the code below grind to a halt. I stole the resizing algorithm from listobject.c and it speeds things up a bit. Python 2.3a1 (#38, Feb 16 2003, 14:23:39) [MSC v.1300 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import array >>> a = array.array('i') >>> for i in range(10000000): ... a.append(i) ... ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 09:16 Message: Logged In: YES user_id=6380 Good idea. Somebody please check the patch and then check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=687598&group_id=5470 From noreply@sourceforge.net Sun Feb 23 14:17:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 23 Feb 2003 06:17:45 -0800 Subject: [Patches] [ python-Patches-688584 ] 2.3 .spec file for building RPMs. Message-ID: Patches item #688584, was opened at 2003-02-18 05:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=688584&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Sean Reifschneider (jafo) >Assigned to: Guido van Rossum (gvanrossum) Summary: 2.3 .spec file for building RPMs. Initial Comment: Attached is a .spec file updated for Python 2.3, ready for the 2.3a2 release. Remove the python-2.2.spec and add this as python.spec for the 2.3a2 release. Thanks, Sean ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 09:17 Message: Logged In: YES user_id=6380 will do ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=688584&group_id=5470 From noreply@sourceforge.net Mon Feb 24 00:08:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 23 Feb 2003 16:08:00 -0800 Subject: [Patches] [ python-Patches-691928 ] Use datetime in _strptime Message-ID: Patches item #691928, was opened at 2003-02-23 16:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=691928&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Use datetime in _strptime Initial Comment: To prevent code duplication, I patched _strptime to use datetime's date object to do Julian day, Gregorian, and day of the week calculations (Tim's code has to be more reliable than mine =). Patch also includes new regression tests to test results and calculation gets triggered. Very minor comment changes and my contact email are also changed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=691928&group_id=5470 From noreply@sourceforge.net Mon Feb 24 00:56:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 23 Feb 2003 16:56:52 -0800 Subject: [Patches] [ python-Patches-691928 ] Use datetime in _strptime Message-ID: Patches item #691928, was opened at 2003-02-23 19:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=691928&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Use datetime in _strptime Initial Comment: To prevent code duplication, I patched _strptime to use datetime's date object to do Julian day, Gregorian, and day of the week calculations (Tim's code has to be more reliable than mine =). Patch also includes new regression tests to test results and calculation gets triggered. Very minor comment changes and my contact email are also changed. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-23 19:56 Message: Logged In: YES user_id=33168 Brett, is there any doc for the functions that were removed? firstjulian, gregorian, julianday, dayofweek Otherwise, the patch seemed fine (but I didn't look that closely). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=691928&group_id=5470 From noreply@sourceforge.net Mon Feb 24 01:21:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 23 Feb 2003 17:21:14 -0800 Subject: [Patches] [ python-Patches-688584 ] 2.3 .spec file for building RPMs. Message-ID: Patches item #688584, was opened at 2003-02-18 05:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=688584&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Sean Reifschneider (jafo) Assigned to: Guido van Rossum (gvanrossum) Summary: 2.3 .spec file for building RPMs. Initial Comment: Attached is a .spec file updated for Python 2.3, ready for the 2.3a2 release. Remove the python-2.2.spec and add this as python.spec for the 2.3a2 release. Thanks, Sean ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 20:21 Message: Logged In: YES user_id=6380 Darn. I didn't see this until after the release. (I only get to see things when they are assigned to me.) Anyway, it's checked in now. Please send updates as necessary for 2.3b1 and beyond. Are you uploading RPMs to python.org? Then please also update 2.3/index.ht (or send me the info). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 09:17 Message: Logged In: YES user_id=6380 will do ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=688584&group_id=5470 From noreply@sourceforge.net Mon Feb 24 01:28:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 23 Feb 2003 17:28:03 -0800 Subject: [Patches] [ python-Patches-633359 ] Patch for sre bug 610299 Message-ID: Patches item #633359, was opened at 2002-11-04 11:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=633359&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: Accepted Priority: 7 Submitted By: Greg Chapman (glchapman) Assigned to: Guido van Rossum (gvanrossum) Summary: Patch for sre bug 610299 Initial Comment: Bug report 610299 points out this discrepancy: >>> re.compile(r'\w{1}', re.U).sub('X', u'hello caf\xe9') u'XXXXX XXXX' >>> re.compile(r'\w', re.U).sub('X', u'hello caf\xe9') u'XXXXX XXX\xe9' The problem is in sre_compile.py: the call to _compile_charset near the end of _compile_info forgets to pass in the flags, so that the info charset is not compiled with re.U. (The info charset is used when searching to find the first character at which a match could start; it is not generated for patterns beginning with a repeat like '\w{1}'.) The attached patch changes this call to pass in the flags; it is against the 2.2.2 version of sre_compile.py. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 20:28 Message: Logged In: YES user_id=6380 Thanks! Fixed in 2.3. Keeping open for fixing in 2.2.3. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 09:15 Message: Logged In: YES user_id=6380 Grabbing this since effbot seems unresponsive. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2002-11-04 13:28 Message: Logged In: YES user_id=86307 Sorry, I though I marked the checkbox (I know I went throught the browse button to find the file). Anyway, here's the file. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-04 12:43 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=633359&group_id=5470 From noreply@sourceforge.net Mon Feb 24 01:32:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 23 Feb 2003 17:32:23 -0800 Subject: [Patches] [ python-Patches-633359 ] Patch for sre bug 610299 Message-ID: Patches item #633359, was opened at 2002-11-04 11:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=633359&group_id=5470 Category: Library (Lib) Group: Python 2.2.x >Status: Closed Resolution: Accepted Priority: 7 Submitted By: Greg Chapman (glchapman) Assigned to: Guido van Rossum (gvanrossum) Summary: Patch for sre bug 610299 Initial Comment: Bug report 610299 points out this discrepancy: >>> re.compile(r'\w{1}', re.U).sub('X', u'hello caf\xe9') u'XXXXX XXXX' >>> re.compile(r'\w', re.U).sub('X', u'hello caf\xe9') u'XXXXX XXX\xe9' The problem is in sre_compile.py: the call to _compile_charset near the end of _compile_info forgets to pass in the flags, so that the info charset is not compiled with re.U. (The info charset is used when searching to find the first character at which a match could start; it is not generated for patterns beginning with a repeat like '\w{1}'.) The attached patch changes this call to pass in the flags; it is against the 2.2.2 version of sre_compile.py. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 20:32 Message: Logged In: YES user_id=6380 Backport checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 20:28 Message: Logged In: YES user_id=6380 Thanks! Fixed in 2.3. Keeping open for fixing in 2.2.3. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 09:15 Message: Logged In: YES user_id=6380 Grabbing this since effbot seems unresponsive. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2002-11-04 13:28 Message: Logged In: YES user_id=86307 Sorry, I though I marked the checkbox (I know I went throught the browse button to find the file). Anyway, here's the file. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-04 12:43 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=633359&group_id=5470 From noreply@sourceforge.net Mon Feb 24 02:24:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 23 Feb 2003 18:24:04 -0800 Subject: [Patches] [ python-Patches-687598 ] array.append is sloooow Message-ID: Patches item #687598, was opened at 2003-02-16 14:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=687598&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: logistix (logistix) >Assigned to: Neal Norwitz (nnorwitz) Summary: array.append is sloooow Initial Comment: array.append re'mallocs and copies each time an item is appended to it. That makes the code below grind to a halt. I stole the resizing algorithm from listobject.c and it speeds things up a bit. Python 2.3a1 (#38, Feb 16 2003, 14:23:39) [MSC v.1300 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import array >>> a = array.array('i') >>> for i in range(10000000): ... a.append(i) ... ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-23 21:24 Message: Logged In: YES user_id=33168 Checked in as: Modules/arraymodule.c 2.84 This improves perf by about 5.6% for me on Linux, but it may help more on windows. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 09:16 Message: Logged In: YES user_id=6380 Good idea. Somebody please check the patch and then check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=687598&group_id=5470 From noreply@sourceforge.net Mon Feb 24 03:52:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 23 Feb 2003 19:52:17 -0800 Subject: [Patches] [ python-Patches-692001 ] properties and __getattribute__ Message-ID: Patches item #692001, was opened at 2003-02-23 22:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=692001&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Nobody/Anonymous (nobody) Summary: properties and __getattribute__ Initial Comment: Got tired of asking for clarification, so I just wrote this up. Hope it's useful (and correct). The old information about not being able to change __getattr__ and __setattr__ is outdated, so I removed it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=692001&group_id=5470 From noreply@sourceforge.net Mon Feb 24 03:56:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 23 Feb 2003 19:56:10 -0800 Subject: [Patches] [ python-Patches-692001 ] properties and __getattribute__ Message-ID: Patches item #692001, was opened at 2003-02-23 22:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=692001&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: properties and __getattribute__ Initial Comment: Got tired of asking for clarification, so I just wrote this up. Hope it's useful (and correct). The old information about not being able to change __getattr__ and __setattr__ is outdated, so I removed it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=692001&group_id=5470 From noreply@sourceforge.net Mon Feb 24 12:50:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 24 Feb 2003 04:50:19 -0800 Subject: [Patches] [ python-Patches-692001 ] properties and __getattribute__ Message-ID: Patches item #692001, was opened at 2003-02-23 22:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=692001&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: David Abrahams (david_abrahams) >Assigned to: Guido van Rossum (gvanrossum) Summary: properties and __getattribute__ Initial Comment: Got tired of asking for clarification, so I just wrote this up. Hope it's useful (and correct). The old information about not being able to change __getattr__ and __setattr__ is outdated, so I removed it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=692001&group_id=5470 From noreply@sourceforge.net Mon Feb 24 16:12:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 24 Feb 2003 08:12:40 -0800 Subject: [Patches] [ python-Patches-688584 ] 2.3 .spec file for building RPMs. Message-ID: Patches item #688584, was opened at 2003-02-18 10:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=688584&group_id=5470 Category: Build Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 7 Submitted By: Sean Reifschneider (jafo) Assigned to: Guido van Rossum (gvanrossum) Summary: 2.3 .spec file for building RPMs. Initial Comment: Attached is a .spec file updated for Python 2.3, ready for the 2.3a2 release. Remove the python-2.2.spec and add this as python.spec for the 2.3a2 release. Thanks, Sean ---------------------------------------------------------------------- >Comment By: Sean Reifschneider (jafo) Date: 2003-02-24 16:12 Message: Logged In: YES user_id=81797 What do you think about giving me CVS access and I'll just muck with it directly? Can you please do the following on creosote: chgrp g+w /usr/local/WWW/ftp.python.org/pub/python/2.3 I'll get the RPMs moved into place and a web page about them updated after that's taken care of. I can't dump them in place as the permissions are now. Thanks, Sean ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-24 01:21 Message: Logged In: YES user_id=6380 Darn. I didn't see this until after the release. (I only get to see things when they are assigned to me.) Anyway, it's checked in now. Please send updates as necessary for 2.3b1 and beyond. Are you uploading RPMs to python.org? Then please also update 2.3/index.ht (or send me the info). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 14:17 Message: Logged In: YES user_id=6380 will do ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=688584&group_id=5470 From noreply@sourceforge.net Mon Feb 24 16:28:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 24 Feb 2003 08:28:47 -0800 Subject: [Patches] [ python-Patches-688584 ] 2.3 .spec file for building RPMs. Message-ID: Patches item #688584, was opened at 2003-02-18 05:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=688584&group_id=5470 Category: Build Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 7 Submitted By: Sean Reifschneider (jafo) Assigned to: Guido van Rossum (gvanrossum) Summary: 2.3 .spec file for building RPMs. Initial Comment: Attached is a .spec file updated for Python 2.3, ready for the 2.3a2 release. Remove the python-2.2.spec and add this as python.spec for the 2.3a2 release. Thanks, Sean ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-24 11:28 Message: Logged In: YES user_id=6380 "chmod g+w /usr/local/WWW/ftp.python.org/pub/python/2.3" - done. Sorry about the permissions problem - this always happens when a directory is first added to creosote. CVS access: when I get tired of checkin in your changes. :-) ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-02-24 11:12 Message: Logged In: YES user_id=81797 What do you think about giving me CVS access and I'll just muck with it directly? Can you please do the following on creosote: chgrp g+w /usr/local/WWW/ftp.python.org/pub/python/2.3 I'll get the RPMs moved into place and a web page about them updated after that's taken care of. I can't dump them in place as the permissions are now. Thanks, Sean ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 20:21 Message: Logged In: YES user_id=6380 Darn. I didn't see this until after the release. (I only get to see things when they are assigned to me.) Anyway, it's checked in now. Please send updates as necessary for 2.3b1 and beyond. Are you uploading RPMs to python.org? Then please also update 2.3/index.ht (or send me the info). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 09:17 Message: Logged In: YES user_id=6380 will do ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=688584&group_id=5470 From noreply@sourceforge.net Mon Feb 24 17:03:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 24 Feb 2003 09:03:46 -0800 Subject: [Patches] [ python-Patches-692327 ] 2.3b1 .spec file. Message-ID: Patches item #692327, was opened at 2003-02-24 17:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=692327&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3b1 .spec file. Initial Comment: The included patch should be applied to the current CVS .spec file to prepare it for the 2.3b1 release. Oh, and the 2.3 RPMs page is up now. Sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=692327&group_id=5470 From noreply@sourceforge.net Mon Feb 24 17:05:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 24 Feb 2003 09:05:04 -0800 Subject: [Patches] [ python-Patches-692327 ] 2.3b1 .spec file. Message-ID: Patches item #692327, was opened at 2003-02-24 17:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=692327&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) >Assigned to: Guido van Rossum (gvanrossum) Summary: 2.3b1 .spec file. Initial Comment: The included patch should be applied to the current CVS .spec file to prepare it for the 2.3b1 release. Oh, and the 2.3 RPMs page is up now. Sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=692327&group_id=5470 From noreply@sourceforge.net Mon Feb 24 18:19:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 24 Feb 2003 10:19:18 -0800 Subject: [Patches] [ python-Patches-692327 ] 2.3b1 .spec file. Message-ID: Patches item #692327, was opened at 2003-02-24 12:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=692327&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Guido van Rossum (gvanrossum) Summary: 2.3b1 .spec file. Initial Comment: The included patch should be applied to the current CVS .spec file to prepare it for the 2.3b1 release. Oh, and the 2.3 RPMs page is up now. Sean ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-24 13:19 Message: Logged In: YES user_id=6380 Checked in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=692327&group_id=5470 From noreply@sourceforge.net Mon Feb 24 23:16:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 24 Feb 2003 15:16:49 -0800 Subject: [Patches] [ python-Patches-687598 ] array.append is sloooow Message-ID: Patches item #687598, was opened at 2003-02-16 13:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=687598&group_id=5470 Category: Modules Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 7 Submitted By: logistix (logistix) Assigned to: Neal Norwitz (nnorwitz) Summary: array.append is sloooow Initial Comment: array.append re'mallocs and copies each time an item is appended to it. That makes the code below grind to a halt. I stole the resizing algorithm from listobject.c and it speeds things up a bit. Python 2.3a1 (#38, Feb 16 2003, 14:23:39) [MSC v.1300 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import array >>> a = array.array('i') >>> for i in range(10000000): ... a.append(i) ... ---------------------------------------------------------------------- >Comment By: logistix (logistix) Date: 2003-02-24 17:16 Message: Logged In: YES user_id=699438 I saw Tim's benchmarks on the commit mailing list. It's consistent with what I get. BSD based machines also ran at exponential time before the patch. Now I'm curious about Mac OSX. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-23 20:24 Message: Logged In: YES user_id=33168 Checked in as: Modules/arraymodule.c 2.84 This improves perf by about 5.6% for me on Linux, but it may help more on windows. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 08:16 Message: Logged In: YES user_id=6380 Good idea. Somebody please check the patch and then check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=687598&group_id=5470 From noreply@sourceforge.net Tue Feb 25 04:26:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 24 Feb 2003 20:26:19 -0800 Subject: [Patches] [ python-Patches-692718 ] change file extension search? Message-ID: Patches item #692718, was opened at 2003-02-24 22:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=692718&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Neal Norwitz (nnorwitz) Summary: change file extension search? Initial Comment: Since most modules are written in Python, it seems a fair number of failed stat() calls could be avoided by considering .py files before .so and module.so files and program startup could thus be improved. The attached patch implements that change. I don't know if there are any semantic differences with the change in order, but if there are I suspect they will be few (though subtle to debug if encountered). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=692718&group_id=5470 From noreply@sourceforge.net Tue Feb 25 15:27:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 25 Feb 2003 07:27:11 -0800 Subject: [Patches] [ python-Patches-400998 ] experimental support for extended slicing on lists Message-ID: Patches item #400998, was opened at 2000-07-27 21:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=400998&group_id=5470 Category: Core (C code) Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: experimental support for extended slicing on lists Initial Comment: ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2003-02-25 15:27 Message: Logged In: YES user_id=4771 a very far-fetched bug... >>> slice(-3058, 0, -1).indices(20) (-1, 5, -1) >>> slice(-30589138798749473891743819L, 0, -1).indices(20) (0, 5, -1) this is due to _PyEval_SliceIndex() which "rounds" very large negative values up to 0. Of course I don't know who would care, because in both cases 'range(*slice(...).indices(20))' returns an empty list. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-06-11 11:00 Message: Logged In: YES user_id=6656 Re footnotes: wimp! Re long lines: there's still one longish line in listobject.c that I really couldn't see how to wrap nicely. All the others got trimmed. But this is now checked in (with mild modfications from the posted patch) as (deep breath): Doc/api/concrete.tex revision 1.16 Doc/lib/libstdtypes.tex revision 1.96 Doc/ref/ref3.tex revision 1.91 Doc/whatsnew/whatsnew23.tex revision 1.24 Include/sliceobject.h revision 2.6 Lib/test/test_bool.py revision 1.6 Lib/test/test_types.py revision 1.30 Misc/NEWS revision 1.423 Objects/listobject.c revision 2.109 Objects/sliceobject.c revision 2.13 Objects/stringobject.c revision 2.166 Objects/tupleobject.c revision 2.65 Objects/unicodeobject.c revision 2.152 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-10 16:58 Message: Logged In: YES user_id=6380 Wow. Good job on the docs! (Although personally I would have added the footnote at the end to keep the existing note numbering :-). In test_bool.py, #veris(operator.isMappingType([]), False) should either be deleted or a different sample used, e.g. veris(operator.isMappingType(1), False) Some lines added to listobject.c (e.g. in list_[ass_]subscript()) are longer than 79 characters. But please do check it in, correcting the nits as you go! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-06-08 16:28 Message: Logged In: YES user_id=6656 OK, I think the attached gets all the cases right. I've also implemented extended slicing for strings and unicode strings & documented the C API functions. I think this is ready to go, at last. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-06-07 15:11 Message: Logged In: YES user_id=6656 Doh, it's me that can't read, not you... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-07 15:10 Message: Logged In: YES user_id=6380 Yes, I said so ("from you"). :) That's why it was so ironic that you had a similar endcase bug. :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-06-07 15:05 Message: Logged In: YES user_id=6656 That message was from me :) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-07 15:01 Message: Logged In: YES user_id=6380 OK, sounds good. (BTW, a Google search for PySlice_GetIndices and Numeric turned up a message inpython-dev from you asking about a broken endcase in Numeric slices, with a question about who uses it in a PS. Of course there was no answer. The broken endcase made me try a few things with your patch. :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-06-07 14:56 Message: Logged In: YES user_id=6656 Hmm. In my working copy, PySlice_GetIndicesEx now has a different interface (it computes the length of the slice, as that's fiddly and almost always required). So I may remain cowardly here. As a bonus, I'll document both functions in Doc/api/. Yes, I was staring at my code and thinking "that can't get all the end cases, can it?". Almost a relief to hear it doesn't :) I'll get pen and paper out. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-07 14:40 Message: Logged In: YES user_id=6380 I checked the Numeric-21.0 source, and they don't use PySlice_GetIndices. They have their own function, slice_GetIndices, which appears to be a reformatted copy of PySlice_GetIndices. except that the fiddling at the end is different: it truncates out-of-bounds indices rather than calling them errors, and it doesn't call step==0 an error (why?). I also checked the numarray-0.3.3 source, and they don't do slices yet. So I think we're safe fixing PySlice_GetIndices. However, I think there's a bug in your code. Suppose a is range(10). Then a[1000:] returns []. But a[1000::] returns [9]! Similarly, a[-1000::-1] return [0] where I would expect []. I think the start/stop truncation needs to depend on the step, too. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-07 14:19 Message: Logged In: YES user_id=6380 > This patch changes the behaviour of PySlice_GetIndices, > which must count as a public API function (albeit a pretty > useless one as it is now). Is that OK? Or would it be > better to have a new function PySlice_GetIndicesEx or > something. Should check whether NumPy uses this function. The big change is that it now can set an exception. I think that's too big a change without changing the name. PySlice_GetIndicesEx is fine. You can call PyInt_AsLong on any object, and if it has a tp_int or __int__ it will do the right thing, so it's better not to call PyInt_Check or PyLong_Check. The check for *step==0 could come earlier. > Do you really want assignments to extended slices in lists? > They were never that inuitive to me. They're about as useful as getting an extended slice from a list, so I'd say yes. They're soooooo cute! :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-06-07 13:35 Message: Logged In: YES user_id=6656 Hmm, I'm now older and more cowardly than when I wrote this, and I have a couple of questions. This patch changes the behaviour of PySlice_GetIndices, which must count as a public API function (albeit a pretty useless one as it is now). Is that OK? Or would it be better to have a new function PySlice_GetIndicesEx or something. Should check whether NumPy uses this function. Do you really want assignments to extended slices in lists? They were never that inuitive to me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-06 16:48 Message: Logged In: YES user_id=6380 (I lied about array -- it is already a subclassable new-style type. So go ahead, but do that one last.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-06 16:29 Message: Logged In: YES user_id=6380 Go ahead and check it in. Strings and unicode also need to support slices. While "hello"[::2] is silly, it's useful to be able to write "hello"[slice(1,-1)]. I think array needs more work -- first 'array.array' should be made into a type object that can be invoked as a constructor and subclassed. That would be nice, yes, but is a lower priority for me ATM. Off-topic aside: the change you had to make to PyString_Format() and its Unicode cousin suggests that we need a better way to decide if something is really a mapping... E.g. this now gives a confusing error message: "%(foo)s %(bar)s" % [1,2,3] I wonder how many other places in the code make naive mapping tests (and of course operator.isMappingType becomes totally unreliable). Maybe the presence of a keys() method together with a __getitem__ method should be used as a standard test for mapping-ness? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-06-06 13:01 Message: Logged In: YES user_id=6656 Whoosh, this is a blast from the past. I've minimally updated the patch (it only failed to apply for the trivialest of reasons). All tests pass (I had to tweak test_bool -- operator.isMappingType([]) is True now). Suffice to say I don't really remember how this works :-/ What more needs to be done? strings, arrays (shouldn't be too hard). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-03 21:00 Message: Logged In: YES user_id=6380 Michael, the tide has changed. Would you be interested in reviving this patch and finishing it? It could possibly help to address bug 473985 and maybe also 459235. If you have no time, let me know and I'll see if I can find time myself. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-12-18 22:19 Message: Rejected for lack of interest. Sorry, Michael! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-11-13 19:45 Message: Is reviewing and applying this patch the best use of my time? I note that this is okay, but low priority -- I doubt that it will get used much. Plus, what about the array module, strings, UserList? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-09-01 02:10 Message: Too late for the release, sorry. And Tim hates negative strides. We'll get back to this for 2.1. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-08-16 19:30 Message: So, I missed my deadline by twenty five minutes. Sorry :-) This latest patch adds a fairly basic test suite, a stab at some docs, and jumps up and down on PySlice_GetIndices. Also (wrt. stringobject.c & unicodeobject.c) it's amazing what you can break, isn't it? Thank God for test suites... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-08-16 19:30 Message: So, I missed my deadline by twenty five minutes. Sorry :-) This latest patch adds a fairly basic test suite, a stab at some docs, and jumps up and down on PySlice_GetIndices. Also (wrt. stringobject.c & unicodeobject.c) it's amazing what you can break, isn't it? Thank God for test suites... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-08-15 19:04 Message: OK, I'll get to that soon (ie. <24hours, hopefully <4). But bear in mind I'm now going to the pub... I may need some advice for the docs... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-08-15 18:53 Message: Note that without doc and test patches too, and Real Soon, I'll have to Postpone this. Assigned to me to remind me of that. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-07-30 18:41 Message: meep! naughty Michael hadn't been running "make test" often enough. this update fixes that. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-07-30 18:10 Message: bugfixes (refounting in assignment, logic in deletion) & a few tweaks. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-07-29 10:36 Message: updated patch to support slice assignements, deletions (needs testing still) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-07-28 06:47 Message: negative indices! for i in listvar[::-1]: pass now iterates over the list backwards (rather than coredumping...) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-07-27 21:39 Message: c'mon michael! at least get *some* of the boundary cases... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-07-27 21:31 Message: this 10 minute hack adds support for "extended slicing" to lists, by which I mean things like: >>> range(100)[23:60:12] [23, 35, 47, 59] todo: find out if this is the approved approach add support for tuples write docs, testsuite (make test passes as is, but should be extended). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=400998&group_id=5470 From noreply@sourceforge.net Tue Feb 25 15:55:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 25 Feb 2003 07:55:02 -0800 Subject: [Patches] [ python-Patches-683592 ] unicode support for os.listdir() Message-ID: Patches item #683592, was opened at 2003-02-09 22:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: unicode support for os.listdir() Initial Comment: The attached patch makes os.listdir() return unicode strings, on plaforms that have Py_FileSystemDefaultEncoding defined as non-NULL. I'm by no means sure this is the right thing to do; it does seem right on OSX where Py_FileSystemDefaultEncoding is (or rather: will be real soon, I'm waiting for Jack's approval) utf-8. I'd be happy to add the code in an OSX-specific switch. A more subtle variant could perhaps only return unicode strings if the file name is not ASCII. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-02-25 16:55 Message: Logged In: YES user_id=92689 Having missed 2.3a2, I'd like to get this in way ahead of 2.3b1. Any objections? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 19:17 Message: Logged In: YES user_id=92689 I'm pretty sure os.path deals just fine with unicode strings (it's all pure string manipulations, isn't it?) Worries: well, apparently on Windows os.listdir() has been returning unicode for some time, so it's not like we're breaking completely new grounds here. If anything breaks it's probably good this happens, as it gives an opportunity to fix things... I just found several example of potential breakage: _bsddb.c parses a filename arg with the "z" format specifier. gdbmmodule.c uses "s". bsddbmodule.c and dbmmodule.c as well. I'm not sure the above modules work on Windows with non-ascii filenames at all, but it doesn't look like it. Besides Windows (for which my patch is not relevant), only OSX sets Py_FileSystemDefaultEncoding, so any new breakage won't reach a mass market right away . ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 18:46 Message: Logged In: YES user_id=38388 Ok, let's look at it from a different angle: things that you get from os.listdir() should be compatible to (at least) all the os.path tools and os itself. Converting to Unicode has the advantage that slicing and indexing into the path names will not break the paths (unlike UTF-8 encoded 8-bit strings which tend to break when you slice them). That said, I think you're right about the ASCII approach provided that the os, os.path tools can actually properly cope with Unicode. What I worry about is that if os.listdir() gives back Unicode for e.g. Latin-1 filenames and the application then passes the Unicode names to a C API using "s", prefectly working code will break... then again the C code should really use "es" for decoding to the Py_FileSystemDefaultEncoding as is done in e.g. fileobject.c. I really don't know what to do here... ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 17:24 Message: Logged In: YES user_id=92689 Here's an argument for ASCII and against the default encoding: if the default encoding is different from Py_FileSystemDefaultEncoding, things go wrong: an 8-bit string passed to file() will be interpreted as Py_FileSystemDefaultEncoding (more precisely: will not be interpreted at all), not the default encoding... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 12:24 Message: Logged In: YES user_id=38388 Right, except that injecting Unicode into Unicode-unaware code can be dangerous (e.g. some code might require a string object to work on). E.g. if someone sets the default encoding to Latin-1 he wouldn't expect os.listdir() to suddenly return Unicode for him. This may be a problem in general for the change to os.listdir(). We'll just have to see what happens during the alpha and beta phases. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 12:08 Message: Logged In: YES user_id=92689 On the other hand, if it's not ASCII, wouldn't a unicode string be more appropriate to begin with? If it's encodable with the default encoding, this will happen as soon as the string is used in a piece of unicode-unaware code, right? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 11:55 Message: Logged In: YES user_id=38388 Good question. The default encoding would better fit into the concept, I guess. Instead of PyUnicode_AsASCIIString(v) you'd have to use PyUnicode_AsEncodedString(v, NULL, "strict"). ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 11:49 Message: Logged In: YES user_id=92689 Ok, I went for your original suggestion: always convert to unicode and then try to convert to ascii. See new patch. Or should this use the default encoding? Hm. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 11:17 Message: Logged In: YES user_id=38388 The file system does not need to support embedded \0 chars even if it supports UTF-16. It only happens that your test assumes that you have one byte per characters encodings which may not always be true. With UTF-16 your test will see lots of \0 bytes but not necessarily ones which are ord(x)>=128. I'm not sure whether other variable length encodings can result in \0 bytes, e.g. the Asian ones. There's also the possibility of the encoding mapping the ASCII range to other non-ASCII characters, e.g. ShiftJIS does this for the Yen sign. If you absolutely want to use the simple test, I'd at least restrict the test to an ASCII isalnum(x) test and then try the encode/decode method I described if this test fails. Note that isalnum() can be locale dependent on some platforms, so you have to hard-code it. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 10:51 Message: Logged In: YES user_id=92689 I don't see hot UTF-16 could be a valid value for Py_FileSystemDefaultEncoding, as for most platforms the file name can't contain null bytes. My looking at the NAMELEN() spaghetti, it seems platforms without HAVE_DIRENT_H might still support embedded null bytes. Any wisdom on this? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 10:24 Message: Logged In: YES user_id=38388 Your test will probably catch most cases, but it could fail for e.g. UTF-16. The only true test would be to first convert to Unicode and then try to convert back to ASCII. If you get an error you can be sure that the text is not ASCII compatible. Given that .listdir() involves lots of IO I think the added performance hit wouldn't be noticable. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 10:12 Message: Logged In: YES user_id=92689 Applied both suggestions. However, I'm not sure if my ASCII test does the right thing, or at least I don't think it does if Py_FileSystemDefaultEncoding is not a superset of ASCII. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 04:07 Message: Logged In: YES user_id=33168 The code which uses unicode APIs should probably be wrapped with: #ifdef Py_USING_UNICODE /* code */ #endif ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-10 02:16 Message: Logged In: YES user_id=6380 At the very least, I'd like it to return Unicode only when the original string isn't just ASCII. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 From noreply@sourceforge.net Tue Feb 25 17:22:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 25 Feb 2003 09:22:44 -0800 Subject: [Patches] [ python-Patches-683592 ] unicode support for os.listdir() Message-ID: Patches item #683592, was opened at 2003-02-09 16:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: unicode support for os.listdir() Initial Comment: The attached patch makes os.listdir() return unicode strings, on plaforms that have Py_FileSystemDefaultEncoding defined as non-NULL. I'm by no means sure this is the right thing to do; it does seem right on OSX where Py_FileSystemDefaultEncoding is (or rather: will be real soon, I'm waiting for Jack's approval) utf-8. I'd be happy to add the code in an OSX-specific switch. A more subtle variant could perhaps only return unicode strings if the file name is not ASCII. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-25 12:22 Message: Logged In: YES user_id=6380 OK, check it in, just be prepared for contingencies. I really cannot judge whether this is right on all platforms. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-25 10:55 Message: Logged In: YES user_id=92689 Having missed 2.3a2, I'd like to get this in way ahead of 2.3b1. Any objections? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 13:17 Message: Logged In: YES user_id=92689 I'm pretty sure os.path deals just fine with unicode strings (it's all pure string manipulations, isn't it?) Worries: well, apparently on Windows os.listdir() has been returning unicode for some time, so it's not like we're breaking completely new grounds here. If anything breaks it's probably good this happens, as it gives an opportunity to fix things... I just found several example of potential breakage: _bsddb.c parses a filename arg with the "z" format specifier. gdbmmodule.c uses "s". bsddbmodule.c and dbmmodule.c as well. I'm not sure the above modules work on Windows with non-ascii filenames at all, but it doesn't look like it. Besides Windows (for which my patch is not relevant), only OSX sets Py_FileSystemDefaultEncoding, so any new breakage won't reach a mass market right away . ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 12:46 Message: Logged In: YES user_id=38388 Ok, let's look at it from a different angle: things that you get from os.listdir() should be compatible to (at least) all the os.path tools and os itself. Converting to Unicode has the advantage that slicing and indexing into the path names will not break the paths (unlike UTF-8 encoded 8-bit strings which tend to break when you slice them). That said, I think you're right about the ASCII approach provided that the os, os.path tools can actually properly cope with Unicode. What I worry about is that if os.listdir() gives back Unicode for e.g. Latin-1 filenames and the application then passes the Unicode names to a C API using "s", prefectly working code will break... then again the C code should really use "es" for decoding to the Py_FileSystemDefaultEncoding as is done in e.g. fileobject.c. I really don't know what to do here... ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 11:24 Message: Logged In: YES user_id=92689 Here's an argument for ASCII and against the default encoding: if the default encoding is different from Py_FileSystemDefaultEncoding, things go wrong: an 8-bit string passed to file() will be interpreted as Py_FileSystemDefaultEncoding (more precisely: will not be interpreted at all), not the default encoding... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 06:24 Message: Logged In: YES user_id=38388 Right, except that injecting Unicode into Unicode-unaware code can be dangerous (e.g. some code might require a string object to work on). E.g. if someone sets the default encoding to Latin-1 he wouldn't expect os.listdir() to suddenly return Unicode for him. This may be a problem in general for the change to os.listdir(). We'll just have to see what happens during the alpha and beta phases. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 06:08 Message: Logged In: YES user_id=92689 On the other hand, if it's not ASCII, wouldn't a unicode string be more appropriate to begin with? If it's encodable with the default encoding, this will happen as soon as the string is used in a piece of unicode-unaware code, right? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 05:55 Message: Logged In: YES user_id=38388 Good question. The default encoding would better fit into the concept, I guess. Instead of PyUnicode_AsASCIIString(v) you'd have to use PyUnicode_AsEncodedString(v, NULL, "strict"). ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 05:49 Message: Logged In: YES user_id=92689 Ok, I went for your original suggestion: always convert to unicode and then try to convert to ascii. See new patch. Or should this use the default encoding? Hm. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 05:17 Message: Logged In: YES user_id=38388 The file system does not need to support embedded \0 chars even if it supports UTF-16. It only happens that your test assumes that you have one byte per characters encodings which may not always be true. With UTF-16 your test will see lots of \0 bytes but not necessarily ones which are ord(x)>=128. I'm not sure whether other variable length encodings can result in \0 bytes, e.g. the Asian ones. There's also the possibility of the encoding mapping the ASCII range to other non-ASCII characters, e.g. ShiftJIS does this for the Yen sign. If you absolutely want to use the simple test, I'd at least restrict the test to an ASCII isalnum(x) test and then try the encode/decode method I described if this test fails. Note that isalnum() can be locale dependent on some platforms, so you have to hard-code it. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 04:51 Message: Logged In: YES user_id=92689 I don't see hot UTF-16 could be a valid value for Py_FileSystemDefaultEncoding, as for most platforms the file name can't contain null bytes. My looking at the NAMELEN() spaghetti, it seems platforms without HAVE_DIRENT_H might still support embedded null bytes. Any wisdom on this? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 04:24 Message: Logged In: YES user_id=38388 Your test will probably catch most cases, but it could fail for e.g. UTF-16. The only true test would be to first convert to Unicode and then try to convert back to ASCII. If you get an error you can be sure that the text is not ASCII compatible. Given that .listdir() involves lots of IO I think the added performance hit wouldn't be noticable. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 04:12 Message: Logged In: YES user_id=92689 Applied both suggestions. However, I'm not sure if my ASCII test does the right thing, or at least I don't think it does if Py_FileSystemDefaultEncoding is not a superset of ASCII. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-09 22:07 Message: Logged In: YES user_id=33168 The code which uses unicode APIs should probably be wrapped with: #ifdef Py_USING_UNICODE /* code */ #endif ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-09 20:16 Message: Logged In: YES user_id=6380 At the very least, I'd like it to return Unicode only when the original string isn't just ASCII. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 From noreply@sourceforge.net Tue Feb 25 17:53:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 25 Feb 2003 09:53:06 -0800 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 21:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: M.-A. Lemburg (lemburg) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-02-25 18:53 Message: Logged In: YES user_id=89016 OK, here are the next few ports: test_ucn and test_unicodedata. I'm not actually sure, whether changing test_unicodedata (which uses the comparison of generated output with expected output) is a good thing, as now updates to the database require manual changes. I've added a few error checks which increase coverage in unicodedata.c from 87% to 95%. Marc-André can you check if this is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-21 14:05 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/string_tests.py 1.27 Lib/test/test_str.py 1.1 Lib/test/test_string.py 1.24 Lib/test/test_unicode.py 1.79 Lib/test/test_userstring.py 1.10 Lib/test/output/test_string delete I've removed the sets import and renamed the mixin tests to contain the relevant class/module names (e.g. MixinStrStringUserStringTest) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-21 04:39 Message: Logged In: YES user_id=80475 * test_string.py imports sets but does not use it. * the names of the mixin classes could possibly be made clearer so I won't have to search into the comments to find-out which mixins are appropriate for each class. Overall, it looks like a nice factoring job and ought to go a long ways toward keeping these guys in sync in the future. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-17 19:29 Message: Logged In: YES user_id=89016 Here is the next bunch of ports: the string tests have been ported to PyUnit and made as reusable as possible. Tests are now shared between str, unicode, UserString and the string module. As a result of reusing a part of the unicode tests for str, the coverage in stringobject.c goes from 83% to 86%. Furthermore it should help keep the API consistent between str and unicode (Example: "%c" % 0xffffffff raises OverflowError, u"%c" % 0xffffffff raises ValueError) Raymond can look look through the scripts and check that everything is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-16 10:33 Message: Logged In: YES user_id=89016 I'm currently working on a PyUnit port of the string tests (i.e. str, unicode, UserString and the string module). Uploading the result to this patch would be easier, as it already has a establsihed audience: But I can open a new patch for that if you want. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 21:11 Message: Logged In: YES user_id=33168 Walter, can this patch be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-14 12:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_charmapcodec delete Lib/test/test_charmapcodec.py 1.6 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 09:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 19:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-13 04:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 00:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 23:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 23:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 22:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 21:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 15:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 21:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 18:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 18:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 17:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 20:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 15:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 17:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 21:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Tue Feb 25 21:26:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 25 Feb 2003 13:26:45 -0800 Subject: [Patches] [ python-Patches-693195 ] Add sys.exc_clear() to clear current exception Message-ID: Patches item #693195, was opened at 2003-02-25 16:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=693195&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kevin Jacobs (jacobs99) Assigned to: Nobody/Anonymous (nobody) Summary: Add sys.exc_clear() to clear current exception Initial Comment: There is no way to clear the "current" exception, which is available via the sys.exc_info() function. There are a few (obscure) easons why one would want to be able to do so, and mainly due to the implementation details of how exception information is stored. Specifically, sys.exc_info() will return information on the last exception even outside of an 'except:' block that caught the exception. So an exception and all of the frame objects on the stack, and all local variables stored in those frames are kept alive in the last exception traceback until either 1) another exception is thrown, or 2) the stack returns to a frame that is handling another exception (thrown before the "current" exception). Thus, it is sometimes useful to be able to clear the "current" exception. e.g.: 1) Some error handling and logging handlers will report on the current or last exception (as a hint about what may have gone wrong). Once that information is handled, additional error handling or logging calls should not report it again. 2) Sometimes resources are not released when an exception is raised until the next exception is raised. This causes problems for programs that rely on object finalization to release resources (like memory, locks, file descriptors, etc.). Such code is suboptimal, but it exists and there are few easy alternatives other than creating many 'finally:' clauses (which can violate encapsulation and abstraction layer boundries and is syntactically hairy at times). Anyhow, such programs may want to clear the current exception and trigger garbage collection at certain synchronization points, in order to flush pending object finalization. Clearly, this is a somewhat hit-or-miss strategy, though it works fairly well on practice, though no sane developer should ever rely on it. Anyhow, I've implemented a trivial patch to sysmodule.c to add a 'exc_clear()' function that clears the current or last exception. I've also added a test case and updated the documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=693195&group_id=5470 From noreply@sourceforge.net Tue Feb 25 21:39:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 25 Feb 2003 13:39:58 -0800 Subject: [Patches] [ python-Patches-693195 ] Add sys.exc_clear() to clear current exception Message-ID: Patches item #693195, was opened at 2003-02-25 16:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=693195&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kevin Jacobs (jacobs99) Assigned to: Nobody/Anonymous (nobody) Summary: Add sys.exc_clear() to clear current exception Initial Comment: There is no way to clear the "current" exception, which is available via the sys.exc_info() function. There are a few (obscure) easons why one would want to be able to do so, and mainly due to the implementation details of how exception information is stored. Specifically, sys.exc_info() will return information on the last exception even outside of an 'except:' block that caught the exception. So an exception and all of the frame objects on the stack, and all local variables stored in those frames are kept alive in the last exception traceback until either 1) another exception is thrown, or 2) the stack returns to a frame that is handling another exception (thrown before the "current" exception). Thus, it is sometimes useful to be able to clear the "current" exception. e.g.: 1) Some error handling and logging handlers will report on the current or last exception (as a hint about what may have gone wrong). Once that information is handled, additional error handling or logging calls should not report it again. 2) Sometimes resources are not released when an exception is raised until the next exception is raised. This causes problems for programs that rely on object finalization to release resources (like memory, locks, file descriptors, etc.). Such code is suboptimal, but it exists and there are few easy alternatives other than creating many 'finally:' clauses (which can violate encapsulation and abstraction layer boundries and is syntactically hairy at times). Anyhow, such programs may want to clear the current exception and trigger garbage collection at certain synchronization points, in order to flush pending object finalization. Clearly, this is a somewhat hit-or-miss strategy, though it works fairly well on practice, though no sane developer should ever rely on it. Anyhow, I've implemented a trivial patch to sysmodule.c to add a 'exc_clear()' function that clears the current or last exception. I've also added a test case and updated the documentation. ---------------------------------------------------------------------- >Comment By: Kevin Jacobs (jacobs99) Date: 2003-02-25 16:39 Message: Logged In: YES user_id=459565 Before someone else says it -- yes, technically there is a way to "clear" the current exception -- by raising another exception. However that leaves a bogus excepton in the thread state, which still stores at least one Python stack frame. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=693195&group_id=5470 From noreply@sourceforge.net Tue Feb 25 21:51:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 25 Feb 2003 13:51:28 -0800 Subject: [Patches] [ python-Patches-691928 ] Use datetime in _strptime Message-ID: Patches item #691928, was opened at 2003-02-23 16:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=691928&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Use datetime in _strptime Initial Comment: To prevent code duplication, I patched _strptime to use datetime's date object to do Julian day, Gregorian, and day of the week calculations (Tim's code has to be more reliable than mine =). Patch also includes new regression tests to test results and calculation gets triggered. Very minor comment changes and my contact email are also changed. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-02-25 13:51 Message: Logged In: YES user_id=357491 Only in the module (which was removed). None of the helper functions have ever been publicly advertised (although I think the locale date info might be helpful in locale; MvL wasn't interested, though). I uploaded a new diff that removes one more line that I forgot to remove when I eliminated the ability to pass in a regex object. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-23 16:56 Message: Logged In: YES user_id=33168 Brett, is there any doc for the functions that were removed? firstjulian, gregorian, julianday, dayofweek Otherwise, the patch seemed fine (but I didn't look that closely). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=691928&group_id=5470 From noreply@sourceforge.net Tue Feb 25 21:52:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 25 Feb 2003 13:52:19 -0800 Subject: [Patches] [ python-Patches-683592 ] unicode support for os.listdir() Message-ID: Patches item #683592, was opened at 2003-02-09 22:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: unicode support for os.listdir() Initial Comment: The attached patch makes os.listdir() return unicode strings, on plaforms that have Py_FileSystemDefaultEncoding defined as non-NULL. I'm by no means sure this is the right thing to do; it does seem right on OSX where Py_FileSystemDefaultEncoding is (or rather: will be real soon, I'm waiting for Jack's approval) utf-8. I'd be happy to add the code in an OSX-specific switch. A more subtle variant could perhaps only return unicode strings if the file name is not ASCII. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-02-25 22:52 Message: Logged In: YES user_id=92689 Checked in as rev. 2.287 of Modules/posixmodule.c. Leaving this item open for now, in case MvL has comments when he gets back. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-25 18:22 Message: Logged In: YES user_id=6380 OK, check it in, just be prepared for contingencies. I really cannot judge whether this is right on all platforms. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-25 16:55 Message: Logged In: YES user_id=92689 Having missed 2.3a2, I'd like to get this in way ahead of 2.3b1. Any objections? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 19:17 Message: Logged In: YES user_id=92689 I'm pretty sure os.path deals just fine with unicode strings (it's all pure string manipulations, isn't it?) Worries: well, apparently on Windows os.listdir() has been returning unicode for some time, so it's not like we're breaking completely new grounds here. If anything breaks it's probably good this happens, as it gives an opportunity to fix things... I just found several example of potential breakage: _bsddb.c parses a filename arg with the "z" format specifier. gdbmmodule.c uses "s". bsddbmodule.c and dbmmodule.c as well. I'm not sure the above modules work on Windows with non-ascii filenames at all, but it doesn't look like it. Besides Windows (for which my patch is not relevant), only OSX sets Py_FileSystemDefaultEncoding, so any new breakage won't reach a mass market right away . ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 18:46 Message: Logged In: YES user_id=38388 Ok, let's look at it from a different angle: things that you get from os.listdir() should be compatible to (at least) all the os.path tools and os itself. Converting to Unicode has the advantage that slicing and indexing into the path names will not break the paths (unlike UTF-8 encoded 8-bit strings which tend to break when you slice them). That said, I think you're right about the ASCII approach provided that the os, os.path tools can actually properly cope with Unicode. What I worry about is that if os.listdir() gives back Unicode for e.g. Latin-1 filenames and the application then passes the Unicode names to a C API using "s", prefectly working code will break... then again the C code should really use "es" for decoding to the Py_FileSystemDefaultEncoding as is done in e.g. fileobject.c. I really don't know what to do here... ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 17:24 Message: Logged In: YES user_id=92689 Here's an argument for ASCII and against the default encoding: if the default encoding is different from Py_FileSystemDefaultEncoding, things go wrong: an 8-bit string passed to file() will be interpreted as Py_FileSystemDefaultEncoding (more precisely: will not be interpreted at all), not the default encoding... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 12:24 Message: Logged In: YES user_id=38388 Right, except that injecting Unicode into Unicode-unaware code can be dangerous (e.g. some code might require a string object to work on). E.g. if someone sets the default encoding to Latin-1 he wouldn't expect os.listdir() to suddenly return Unicode for him. This may be a problem in general for the change to os.listdir(). We'll just have to see what happens during the alpha and beta phases. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 12:08 Message: Logged In: YES user_id=92689 On the other hand, if it's not ASCII, wouldn't a unicode string be more appropriate to begin with? If it's encodable with the default encoding, this will happen as soon as the string is used in a piece of unicode-unaware code, right? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 11:55 Message: Logged In: YES user_id=38388 Good question. The default encoding would better fit into the concept, I guess. Instead of PyUnicode_AsASCIIString(v) you'd have to use PyUnicode_AsEncodedString(v, NULL, "strict"). ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 11:49 Message: Logged In: YES user_id=92689 Ok, I went for your original suggestion: always convert to unicode and then try to convert to ascii. See new patch. Or should this use the default encoding? Hm. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 11:17 Message: Logged In: YES user_id=38388 The file system does not need to support embedded \0 chars even if it supports UTF-16. It only happens that your test assumes that you have one byte per characters encodings which may not always be true. With UTF-16 your test will see lots of \0 bytes but not necessarily ones which are ord(x)>=128. I'm not sure whether other variable length encodings can result in \0 bytes, e.g. the Asian ones. There's also the possibility of the encoding mapping the ASCII range to other non-ASCII characters, e.g. ShiftJIS does this for the Yen sign. If you absolutely want to use the simple test, I'd at least restrict the test to an ASCII isalnum(x) test and then try the encode/decode method I described if this test fails. Note that isalnum() can be locale dependent on some platforms, so you have to hard-code it. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 10:51 Message: Logged In: YES user_id=92689 I don't see hot UTF-16 could be a valid value for Py_FileSystemDefaultEncoding, as for most platforms the file name can't contain null bytes. My looking at the NAMELEN() spaghetti, it seems platforms without HAVE_DIRENT_H might still support embedded null bytes. Any wisdom on this? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-10 10:24 Message: Logged In: YES user_id=38388 Your test will probably catch most cases, but it could fail for e.g. UTF-16. The only true test would be to first convert to Unicode and then try to convert back to ASCII. If you get an error you can be sure that the text is not ASCII compatible. Given that .listdir() involves lots of IO I think the added performance hit wouldn't be noticable. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 10:12 Message: Logged In: YES user_id=92689 Applied both suggestions. However, I'm not sure if my ASCII test does the right thing, or at least I don't think it does if Py_FileSystemDefaultEncoding is not a superset of ASCII. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 04:07 Message: Logged In: YES user_id=33168 The code which uses unicode APIs should probably be wrapped with: #ifdef Py_USING_UNICODE /* code */ #endif ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-10 02:16 Message: Logged In: YES user_id=6380 At the very least, I'd like it to return Unicode only when the original string isn't just ASCII. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=683592&group_id=5470 From noreply@sourceforge.net Tue Feb 25 21:57:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 25 Feb 2003 13:57:29 -0800 Subject: [Patches] [ python-Patches-693221 ] fix bug 625698, speed up some comparisons Message-ID: Patches item #693221, was opened at 2003-02-25 21:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=693221&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Nobody/Anonymous (nobody) Summary: fix bug 625698, speed up some comparisons Initial Comment: This patch, patchrecursion GREATLY speeds up comparisons of recursive objects, fixing bug 625698. It works by throwing a new exception, a RecursionError, to break out of the current deeply nested comparison, and then redoing the comparison by the already established technique for recursive objects. I believe the only costs to normal non-recursive comparisons is two additional C comparisons. Backwards compatibility problems will occur only in code that attempts to handle ALL exceptions while doing comparisons. Of course, this is always a bad practice, so hopefully not much code does this. Also, most code probably doesn't attempt to handle exceptions within the actual comparison routines, instead catching them elsewhere, which will be fine. Another patch is also attached, patchequal, to handle some of the common cases where this comes up even faster. While it is true that python wants to have an == operator that does not define an equality relation, I believe that when == is not an equality relation python has few obligations to be nice to it. In particular, suppose we have an object NaN != NaN. I would say that (NaN,) == (NaN,) [NaN] == [NaN] {NaN:1} == {NaN:1} all intuitively still seem true. Isn't it obvious that if two lists contain the SAME objects, they are equal? That is, even though NaN does not equal itself, lists, tuples, and dicts have no obligation to respect the underlying == operator. I don't see any documentation saying they will respect it (though maybe I'm just missing it). patchequal assumes, ONLY for purposes of list tuple dict comparisons and dict lookups, that if id(a) == id(b), then a == b. Note there is some precedence for this patch, d = {NaN:1} NaN in d => True cmp(NaN, NaN) is 0 (though I suspect this is a mistake). This will cause backwards compatibility problems only for people using non-equality relation =='s, and probably not even for them, as they already probably use a trick to emulate this patch when they compare lists and such containing these weird objects. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=693221&group_id=5470 From noreply@sourceforge.net Wed Feb 26 03:15:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 25 Feb 2003 19:15:09 -0800 Subject: [Patches] [ python-Patches-692718 ] change file extension search? Message-ID: Patches item #692718, was opened at 2003-02-24 23:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=692718&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Skip Montanaro (montanaro) Summary: change file extension search? Initial Comment: Since most modules are written in Python, it seems a fair number of failed stat() calls could be avoided by considering .py files before .so and module.so files and program startup could thus be improved. The attached patch implements that change. I don't know if there are any semantic differences with the change in order, but if there are I suspect they will be few (though subtle to debug if encountered). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-25 22:15 Message: Logged In: YES user_id=33168 The patch looks correct. It seemed like Guido was against the patch since he explained the behaviour as a feature. If you want this patch approved, assign to Guido for pronouncement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=692718&group_id=5470 From noreply@sourceforge.net Wed Feb 26 03:32:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 25 Feb 2003 19:32:06 -0800 Subject: [Patches] [ python-Patches-693195 ] Add sys.exc_clear() to clear current exception Message-ID: Patches item #693195, was opened at 2003-02-25 16:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=693195&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kevin Jacobs (jacobs99) Assigned to: Nobody/Anonymous (nobody) Summary: Add sys.exc_clear() to clear current exception Initial Comment: There is no way to clear the "current" exception, which is available via the sys.exc_info() function. There are a few (obscure) easons why one would want to be able to do so, and mainly due to the implementation details of how exception information is stored. Specifically, sys.exc_info() will return information on the last exception even outside of an 'except:' block that caught the exception. So an exception and all of the frame objects on the stack, and all local variables stored in those frames are kept alive in the last exception traceback until either 1) another exception is thrown, or 2) the stack returns to a frame that is handling another exception (thrown before the "current" exception). Thus, it is sometimes useful to be able to clear the "current" exception. e.g.: 1) Some error handling and logging handlers will report on the current or last exception (as a hint about what may have gone wrong). Once that information is handled, additional error handling or logging calls should not report it again. 2) Sometimes resources are not released when an exception is raised until the next exception is raised. This causes problems for programs that rely on object finalization to release resources (like memory, locks, file descriptors, etc.). Such code is suboptimal, but it exists and there are few easy alternatives other than creating many 'finally:' clauses (which can violate encapsulation and abstraction layer boundries and is syntactically hairy at times). Anyhow, such programs may want to clear the current exception and trigger garbage collection at certain synchronization points, in order to flush pending object finalization. Clearly, this is a somewhat hit-or-miss strategy, though it works fairly well on practice, though no sane developer should ever rely on it. Anyhow, I've implemented a trivial patch to sysmodule.c to add a 'exc_clear()' function that clears the current or last exception. I've also added a test case and updated the documentation. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-25 22:32 Message: Logged In: YES user_id=33168 I have a couple of minor things. The prototype should be: sys_exc_clear(PyObject *self, PyObject *noargs). This will remove the (PyCFunction) cast. (I realize there are other places in the file you copied, but they are wrong too. :-) The doc for exc_clear should have a \versionadded{2.3} before the \end. Should the doc for exc_info() also be updated, since the docstring was updated? ---------------------------------------------------------------------- Comment By: Kevin Jacobs (jacobs99) Date: 2003-02-25 16:39 Message: Logged In: YES user_id=459565 Before someone else says it -- yes, technically there is a way to "clear" the current exception -- by raising another exception. However that leaves a bogus excepton in the thread state, which still stores at least one Python stack frame. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=693195&group_id=5470 From noreply@sourceforge.net Wed Feb 26 12:07:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 26 Feb 2003 04:07:06 -0800 Subject: [Patches] [ python-Patches-400998 ] experimental support for extended slicing on lists Message-ID: Patches item #400998, was opened at 2000-07-27 22:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=400998&group_id=5470 Category: Core (C code) Group: None >Status: Open Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: experimental support for extended slicing on lists Initial Comment: ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-02-26 12:07 Message: Logged In: YES user_id=6656 a comedy of errors! i'll fix this soon. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2003-02-25 15:27 Message: Logged In: YES user_id=4771 a very far-fetched bug... >>> slice(-3058, 0, -1).indices(20) (-1, 5, -1) >>> slice(-30589138798749473891743819L, 0, -1).indices(20) (0, 5, -1) this is due to _PyEval_SliceIndex() which "rounds" very large negative values up to 0. Of course I don't know who would care, because in both cases 'range(*slice(...).indices(20))' returns an empty list. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-06-11 12:00 Message: Logged In: YES user_id=6656 Re footnotes: wimp! Re long lines: there's still one longish line in listobject.c that I really couldn't see how to wrap nicely. All the others got trimmed. But this is now checked in (with mild modfications from the posted patch) as (deep breath): Doc/api/concrete.tex revision 1.16 Doc/lib/libstdtypes.tex revision 1.96 Doc/ref/ref3.tex revision 1.91 Doc/whatsnew/whatsnew23.tex revision 1.24 Include/sliceobject.h revision 2.6 Lib/test/test_bool.py revision 1.6 Lib/test/test_types.py revision 1.30 Misc/NEWS revision 1.423 Objects/listobject.c revision 2.109 Objects/sliceobject.c revision 2.13 Objects/stringobject.c revision 2.166 Objects/tupleobject.c revision 2.65 Objects/unicodeobject.c revision 2.152 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-10 17:58 Message: Logged In: YES user_id=6380 Wow. Good job on the docs! (Although personally I would have added the footnote at the end to keep the existing note numbering :-). In test_bool.py, #veris(operator.isMappingType([]), False) should either be deleted or a different sample used, e.g. veris(operator.isMappingType(1), False) Some lines added to listobject.c (e.g. in list_[ass_]subscript()) are longer than 79 characters. But please do check it in, correcting the nits as you go! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-06-08 17:28 Message: Logged In: YES user_id=6656 OK, I think the attached gets all the cases right. I've also implemented extended slicing for strings and unicode strings & documented the C API functions. I think this is ready to go, at last. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-06-07 16:11 Message: Logged In: YES user_id=6656 Doh, it's me that can't read, not you... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-07 16:10 Message: Logged In: YES user_id=6380 Yes, I said so ("from you"). :) That's why it was so ironic that you had a similar endcase bug. :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-06-07 16:05 Message: Logged In: YES user_id=6656 That message was from me :) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-07 16:01 Message: Logged In: YES user_id=6380 OK, sounds good. (BTW, a Google search for PySlice_GetIndices and Numeric turned up a message inpython-dev from you asking about a broken endcase in Numeric slices, with a question about who uses it in a PS. Of course there was no answer. The broken endcase made me try a few things with your patch. :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-06-07 15:56 Message: Logged In: YES user_id=6656 Hmm. In my working copy, PySlice_GetIndicesEx now has a different interface (it computes the length of the slice, as that's fiddly and almost always required). So I may remain cowardly here. As a bonus, I'll document both functions in Doc/api/. Yes, I was staring at my code and thinking "that can't get all the end cases, can it?". Almost a relief to hear it doesn't :) I'll get pen and paper out. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-07 15:40 Message: Logged In: YES user_id=6380 I checked the Numeric-21.0 source, and they don't use PySlice_GetIndices. They have their own function, slice_GetIndices, which appears to be a reformatted copy of PySlice_GetIndices. except that the fiddling at the end is different: it truncates out-of-bounds indices rather than calling them errors, and it doesn't call step==0 an error (why?). I also checked the numarray-0.3.3 source, and they don't do slices yet. So I think we're safe fixing PySlice_GetIndices. However, I think there's a bug in your code. Suppose a is range(10). Then a[1000:] returns []. But a[1000::] returns [9]! Similarly, a[-1000::-1] return [0] where I would expect []. I think the start/stop truncation needs to depend on the step, too. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-07 15:19 Message: Logged In: YES user_id=6380 > This patch changes the behaviour of PySlice_GetIndices, > which must count as a public API function (albeit a pretty > useless one as it is now). Is that OK? Or would it be > better to have a new function PySlice_GetIndicesEx or > something. Should check whether NumPy uses this function. The big change is that it now can set an exception. I think that's too big a change without changing the name. PySlice_GetIndicesEx is fine. You can call PyInt_AsLong on any object, and if it has a tp_int or __int__ it will do the right thing, so it's better not to call PyInt_Check or PyLong_Check. The check for *step==0 could come earlier. > Do you really want assignments to extended slices in lists? > They were never that inuitive to me. They're about as useful as getting an extended slice from a list, so I'd say yes. They're soooooo cute! :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-06-07 14:35 Message: Logged In: YES user_id=6656 Hmm, I'm now older and more cowardly than when I wrote this, and I have a couple of questions. This patch changes the behaviour of PySlice_GetIndices, which must count as a public API function (albeit a pretty useless one as it is now). Is that OK? Or would it be better to have a new function PySlice_GetIndicesEx or something. Should check whether NumPy uses this function. Do you really want assignments to extended slices in lists? They were never that inuitive to me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-06 17:48 Message: Logged In: YES user_id=6380 (I lied about array -- it is already a subclassable new-style type. So go ahead, but do that one last.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-06 17:29 Message: Logged In: YES user_id=6380 Go ahead and check it in. Strings and unicode also need to support slices. While "hello"[::2] is silly, it's useful to be able to write "hello"[slice(1,-1)]. I think array needs more work -- first 'array.array' should be made into a type object that can be invoked as a constructor and subclassed. That would be nice, yes, but is a lower priority for me ATM. Off-topic aside: the change you had to make to PyString_Format() and its Unicode cousin suggests that we need a better way to decide if something is really a mapping... E.g. this now gives a confusing error message: "%(foo)s %(bar)s" % [1,2,3] I wonder how many other places in the code make naive mapping tests (and of course operator.isMappingType becomes totally unreliable). Maybe the presence of a keys() method together with a __getitem__ method should be used as a standard test for mapping-ness? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-06-06 14:01 Message: Logged In: YES user_id=6656 Whoosh, this is a blast from the past. I've minimally updated the patch (it only failed to apply for the trivialest of reasons). All tests pass (I had to tweak test_bool -- operator.isMappingType([]) is True now). Suffice to say I don't really remember how this works :-/ What more needs to be done? strings, arrays (shouldn't be too hard). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-03 22:00 Message: Logged In: YES user_id=6380 Michael, the tide has changed. Would you be interested in reviving this patch and finishing it? It could possibly help to address bug 473985 and maybe also 459235. If you have no time, let me know and I'll see if I can find time myself. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-12-18 22:19 Message: Rejected for lack of interest. Sorry, Michael! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-11-13 19:45 Message: Is reviewing and applying this patch the best use of my time? I note that this is okay, but low priority -- I doubt that it will get used much. Plus, what about the array module, strings, UserList? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-09-01 03:10 Message: Too late for the release, sorry. And Tim hates negative strides. We'll get back to this for 2.1. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-08-16 20:30 Message: So, I missed my deadline by twenty five minutes. Sorry :-) This latest patch adds a fairly basic test suite, a stab at some docs, and jumps up and down on PySlice_GetIndices. Also (wrt. stringobject.c & unicodeobject.c) it's amazing what you can break, isn't it? Thank God for test suites... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-08-16 20:30 Message: So, I missed my deadline by twenty five minutes. Sorry :-) This latest patch adds a fairly basic test suite, a stab at some docs, and jumps up and down on PySlice_GetIndices. Also (wrt. stringobject.c & unicodeobject.c) it's amazing what you can break, isn't it? Thank God for test suites... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-08-15 20:04 Message: OK, I'll get to that soon (ie. <24hours, hopefully <4). But bear in mind I'm now going to the pub... I may need some advice for the docs... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-08-15 19:53 Message: Note that without doc and test patches too, and Real Soon, I'll have to Postpone this. Assigned to me to remind me of that. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-07-30 19:41 Message: meep! naughty Michael hadn't been running "make test" often enough. this update fixes that. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-07-30 19:10 Message: bugfixes (refounting in assignment, logic in deletion) & a few tweaks. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-07-29 11:36 Message: updated patch to support slice assignements, deletions (needs testing still) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-07-28 07:47 Message: negative indices! for i in listvar[::-1]: pass now iterates over the list backwards (rather than coredumping...) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-07-27 22:39 Message: c'mon michael! at least get *some* of the boundary cases... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-07-27 22:31 Message: this 10 minute hack adds support for "extended slicing" to lists, by which I mean things like: >>> range(100)[23:60:12] [23, 35, 47, 59] todo: find out if this is the approved approach add support for tuples write docs, testsuite (make test passes as is, but should be extended). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=400998&group_id=5470 From noreply@sourceforge.net Wed Feb 26 12:39:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 26 Feb 2003 04:39:31 -0800 Subject: [Patches] [ python-Patches-693195 ] Add sys.exc_clear() to clear current exception Message-ID: Patches item #693195, was opened at 2003-02-25 16:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=693195&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kevin Jacobs (jacobs99) Assigned to: Nobody/Anonymous (nobody) Summary: Add sys.exc_clear() to clear current exception Initial Comment: There is no way to clear the "current" exception, which is available via the sys.exc_info() function. There are a few (obscure) easons why one would want to be able to do so, and mainly due to the implementation details of how exception information is stored. Specifically, sys.exc_info() will return information on the last exception even outside of an 'except:' block that caught the exception. So an exception and all of the frame objects on the stack, and all local variables stored in those frames are kept alive in the last exception traceback until either 1) another exception is thrown, or 2) the stack returns to a frame that is handling another exception (thrown before the "current" exception). Thus, it is sometimes useful to be able to clear the "current" exception. e.g.: 1) Some error handling and logging handlers will report on the current or last exception (as a hint about what may have gone wrong). Once that information is handled, additional error handling or logging calls should not report it again. 2) Sometimes resources are not released when an exception is raised until the next exception is raised. This causes problems for programs that rely on object finalization to release resources (like memory, locks, file descriptors, etc.). Such code is suboptimal, but it exists and there are few easy alternatives other than creating many 'finally:' clauses (which can violate encapsulation and abstraction layer boundries and is syntactically hairy at times). Anyhow, such programs may want to clear the current exception and trigger garbage collection at certain synchronization points, in order to flush pending object finalization. Clearly, this is a somewhat hit-or-miss strategy, though it works fairly well on practice, though no sane developer should ever rely on it. Anyhow, I've implemented a trivial patch to sysmodule.c to add a 'exc_clear()' function that clears the current or last exception. I've also added a test case and updated the documentation. ---------------------------------------------------------------------- >Comment By: Kevin Jacobs (jacobs99) Date: 2003-02-26 07:39 Message: Logged In: YES user_id=459565 I've updated my patchj based on Neil's feedback: 1) sys_exc_clear and sys_exc_info now use the recommended prototype and the cast to PyCFunction was removed. 2) \versionadded was added to the exc_clear docs. 3) The exc_info docs were slightly modified to better match the updated doc string. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-25 22:32 Message: Logged In: YES user_id=33168 I have a couple of minor things. The prototype should be: sys_exc_clear(PyObject *self, PyObject *noargs). This will remove the (PyCFunction) cast. (I realize there are other places in the file you copied, but they are wrong too. :-) The doc for exc_clear should have a \versionadded{2.3} before the \end. Should the doc for exc_info() also be updated, since the docstring was updated? ---------------------------------------------------------------------- Comment By: Kevin Jacobs (jacobs99) Date: 2003-02-25 16:39 Message: Logged In: YES user_id=459565 Before someone else says it -- yes, technically there is a way to "clear" the current exception -- by raising another exception. However that leaves a bogus excepton in the thread state, which still stores at least one Python stack frame. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=693195&group_id=5470 From noreply@sourceforge.net Wed Feb 26 13:42:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 26 Feb 2003 05:42:28 -0800 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 21:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Walter Dörwald (doerwalter) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-26 14:42 Message: Logged In: YES user_id=38388 test_ucn and test_unicodedata look OK. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-25 18:53 Message: Logged In: YES user_id=89016 OK, here are the next few ports: test_ucn and test_unicodedata. I'm not actually sure, whether changing test_unicodedata (which uses the comparison of generated output with expected output) is a good thing, as now updates to the database require manual changes. I've added a few error checks which increase coverage in unicodedata.c from 87% to 95%. Marc-André can you check if this is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-21 14:05 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/string_tests.py 1.27 Lib/test/test_str.py 1.1 Lib/test/test_string.py 1.24 Lib/test/test_unicode.py 1.79 Lib/test/test_userstring.py 1.10 Lib/test/output/test_string delete I've removed the sets import and renamed the mixin tests to contain the relevant class/module names (e.g. MixinStrStringUserStringTest) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-21 04:39 Message: Logged In: YES user_id=80475 * test_string.py imports sets but does not use it. * the names of the mixin classes could possibly be made clearer so I won't have to search into the comments to find-out which mixins are appropriate for each class. Overall, it looks like a nice factoring job and ought to go a long ways toward keeping these guys in sync in the future. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-17 19:29 Message: Logged In: YES user_id=89016 Here is the next bunch of ports: the string tests have been ported to PyUnit and made as reusable as possible. Tests are now shared between str, unicode, UserString and the string module. As a result of reusing a part of the unicode tests for str, the coverage in stringobject.c goes from 83% to 86%. Furthermore it should help keep the API consistent between str and unicode (Example: "%c" % 0xffffffff raises OverflowError, u"%c" % 0xffffffff raises ValueError) Raymond can look look through the scripts and check that everything is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-16 10:33 Message: Logged In: YES user_id=89016 I'm currently working on a PyUnit port of the string tests (i.e. str, unicode, UserString and the string module). Uploading the result to this patch would be easier, as it already has a establsihed audience: But I can open a new patch for that if you want. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 21:11 Message: Logged In: YES user_id=33168 Walter, can this patch be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-14 12:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_charmapcodec delete Lib/test/test_charmapcodec.py 1.6 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 09:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 19:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-13 04:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 00:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 23:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 23:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 22:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 21:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 15:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 21:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 18:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 18:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 17:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 20:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 15:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 17:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 21:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Wed Feb 26 14:32:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 26 Feb 2003 06:32:18 -0800 Subject: [Patches] [ python-Patches-693638 ] rewrite ceval loop by jumping from static table Message-ID: Patches item #693638, was opened at 2003-02-26 09:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=693638&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: rewrite ceval loop by jumping from static table Initial Comment: Several times the topic of rewriting the ceval loop (eval_frame) has been brought up as a possibility of speeding up python. Here's the most recent. http://mail.python.org/pipermail/python-dev/2003-February/033680.html Quick results: after the rewrite, Python was about 15% slower. I think a bunch more optimizations could be made, but I think the best case would be to rival the existing speed--so I stopped. The way to squeeze more speed out of this patch would be change the calling conventions. One note, this patch probably uses less memory because there were a bunch of local variables removed from eval_frame. Of course, some are also included in the ceval_struct. I removed the entire switch from eval_frame. There are a bunch of snapshots along the way included in the tar file. All this work was against Python/ceval.c revision 2.350. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=693638&group_id=5470 From noreply@sourceforge.net Wed Feb 26 14:33:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 26 Feb 2003 06:33:56 -0800 Subject: [Patches] [ python-Patches-693638 ] rewrite ceval loop by jumping from static table Message-ID: Patches item #693638, was opened at 2003-02-26 09:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=693638&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: rewrite ceval loop by jumping from static table Initial Comment: Several times the topic of rewriting the ceval loop (eval_frame) has been brought up as a possibility of speeding up python. Here's the most recent. http://mail.python.org/pipermail/python-dev/2003-February/033680.html Quick results: after the rewrite, Python was about 15% slower. I think a bunch more optimizations could be made, but I think the best case would be to rival the existing speed--so I stopped. The way to squeeze more speed out of this patch would be change the calling conventions. One note, this patch probably uses less memory because there were a bunch of local variables removed from eval_frame. Of course, some are also included in the ceval_struct. I removed the entire switch from eval_frame. There are a bunch of snapshots along the way included in the tar file. All this work was against Python/ceval.c revision 2.350. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=693638&group_id=5470 From noreply@sourceforge.net Wed Feb 26 15:00:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 26 Feb 2003 07:00:14 -0800 Subject: [Patches] [ python-Patches-692718 ] change file extension search? Message-ID: Patches item #692718, was opened at 2003-02-24 22:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=692718&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Guido van Rossum (gvanrossum) Summary: change file extension search? Initial Comment: Since most modules are written in Python, it seems a fair number of failed stat() calls could be avoided by considering .py files before .so and module.so files and program startup could thus be improved. The attached patch implements that change. I don't know if there are any semantic differences with the change in order, but if there are I suspect they will be few (though subtle to debug if encountered). ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-02-26 09:00 Message: Logged In: YES user_id=44345 Assigning to Guido for his pronouncement (though I suspect I know what it will be). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-25 21:15 Message: Logged In: YES user_id=33168 The patch looks correct. It seemed like Guido was against the patch since he explained the behaviour as a feature. If you want this patch approved, assign to Guido for pronouncement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=692718&group_id=5470 From noreply@sourceforge.net Wed Feb 26 15:08:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 26 Feb 2003 07:08:57 -0800 Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest Message-ID: Patches item #662807, was opened at 2003-01-05 21:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Walter Dörwald (doerwalter) Summary: Port tests to unittest Initial Comment: This patch ports the three tests test_pow.py, test_charmapcodec.py and test_userdict.py to unittest. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-02-26 16:08 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_ucn.py 1.12 Lib/test/test_unicodedata.py 1.7 Lib/test/output/test_ucn delete Lib/test/output/test_unicodedata delete ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-26 14:42 Message: Logged In: YES user_id=38388 test_ucn and test_unicodedata look OK. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-25 18:53 Message: Logged In: YES user_id=89016 OK, here are the next few ports: test_ucn and test_unicodedata. I'm not actually sure, whether changing test_unicodedata (which uses the comparison of generated output with expected output) is a good thing, as now updates to the database require manual changes. I've added a few error checks which increase coverage in unicodedata.c from 87% to 95%. Marc-André can you check if this is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-21 14:05 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/string_tests.py 1.27 Lib/test/test_str.py 1.1 Lib/test/test_string.py 1.24 Lib/test/test_unicode.py 1.79 Lib/test/test_userstring.py 1.10 Lib/test/output/test_string delete I've removed the sets import and renamed the mixin tests to contain the relevant class/module names (e.g. MixinStrStringUserStringTest) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-21 04:39 Message: Logged In: YES user_id=80475 * test_string.py imports sets but does not use it. * the names of the mixin classes could possibly be made clearer so I won't have to search into the comments to find-out which mixins are appropriate for each class. Overall, it looks like a nice factoring job and ought to go a long ways toward keeping these guys in sync in the future. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-17 19:29 Message: Logged In: YES user_id=89016 Here is the next bunch of ports: the string tests have been ported to PyUnit and made as reusable as possible. Tests are now shared between str, unicode, UserString and the string module. As a result of reusing a part of the unicode tests for str, the coverage in stringobject.c goes from 83% to 86%. Furthermore it should help keep the API consistent between str and unicode (Example: "%c" % 0xffffffff raises OverflowError, u"%c" % 0xffffffff raises ValueError) Raymond can look look through the scripts and check that everything is OK? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-16 10:33 Message: Logged In: YES user_id=89016 I'm currently working on a PyUnit port of the string tests (i.e. str, unicode, UserString and the string module). Uploading the result to this patch would be easier, as it already has a establsihed audience: But I can open a new patch for that if you want. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-14 21:11 Message: Logged In: YES user_id=33168 Walter, can this patch be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-14 12:30 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_charmapcodec delete Lib/test/test_charmapcodec.py 1.6 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-14 09:52 Message: Logged In: YES user_id=38388 test_charmapcodec looks OK. Just remove the DOS-lineends before checking it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:16 Message: Logged In: YES user_id=89016 OK, checked in as test_userlist.py 1.7. Assigned back to MAL for the review of test_charmapcodec. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-13 19:08 Message: Logged In: YES user_id=6380 Walter, feel free to check in test_userlist.py! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-13 19:02 Message: Logged In: YES user_id=89016 Here's another one: test_userlist has been ported to PyUnit and a few tests have been added to increase coverage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-13 04:12 Message: Logged In: YES user_id=33168 MAL, could you look at the test_charmapcodec.py? I think that's the only file outstanding from this patch. It's a pretty straightforward test. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-04 00:13 Message: Logged In: YES user_id=89016 OK, test_sys.py is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 23:56 Message: Logged In: YES user_id=6380 I think you can check this in -- if it fails with Jython, Finn or Samuele will quickly patch it. :-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 23:44 Message: Logged In: YES user_id=89016 OK, here's a new test_sys.py > test_sys.py: > > - I agree that it's not worth testing the code > paths that will invoke a custom __displayhook__ or > __excepthook__, but I regret it nevertheless. :-) > maybe this deserves a comment? Testing a custom displayhook is now done (via compile(..., "single")/exec). Testing a custom excepthook seems to be trickier. This could probably be done by calling the interpreter recursively via os.system() or os.popen(). I've added a comment for now that this isn't tested. Unfortunately this leaves a large block in Python/pythonrun.c uncovered. > - sys.exit() should also be callable with a string OK, done. > - you could check that the value of the SystemExit exception > has the right exit code Done. - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). I haven't tested Jython yet, but I guess test_sys.py will have to many many exceptions for Jython. I'll try this tomorrow. - I presume you've tested this on Windows? Linux & Windows ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-03 22:10 Message: Logged In: YES user_id=6380 test_sys.py: - I agree that it's not worth testing the code paths that will invoke a custom __displayhook__ or __excepthook__, but I regret it nevertheless. :-) maybe this deserves a comment? - sys.exit() should also be callable with a string - you could check that the value of the SystemExit exception has the right exit code - Have you checked this with Jython? I don't know if it implements all of these; in particular I doubt it has getrefcount(). - I presume you've tested this on Windows? Sorry, I can't help you with charmapcodec ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-02-03 21:36 Message: Logged In: YES user_id=89016 Here's a new one: test_sys.py tests Python/sysmodule.c. Coverage goes from 68% to 77%. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 15:46 Message: Logged In: YES user_id=80475 All are approved except test_charmapcodec.py -- someone else should look at that one. Be sure to follow GvR's advice and replace assertEquals with assertEqual. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-16 21:47 Message: Logged In: YES user_id=89016 test_unicode is ported and enhanced (coverage goes from 80.81% to 85.05%) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 18:17 Message: Logged In: YES user_id=89016 > In general, don't do tests that hardwire implementation details So should we remove self.assertEquals(reduce(42, "1"), "1") self.assertEquals(reduce(42, "", "1"), "1") from test_filter? BTW, you should look at test_builtin first, as the others are still simply ports to PyUnit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 18:03 Message: Logged In: YES user_id=80475 Good to hear the news on increasing the coverage. In general, don't do tests that hardwire implementation details. Test it if it is a documented variable, exposed through __all__, is a key constact (like the magic numbers in random.py), or a variable that a module user is likely to be relying upon. Otherwise, no -- it should be possible to improve an implementation without crashing the suite. I'll try to review a few of these over the next few days. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-10 17:53 Message: Logged In: YES user_id=89016 test_builtin.py is now updated to test more error situations. This increases the coverage of bltinmodule.c from 75.13% to 92.20%, and it actually revealed one or two potential bugs: http://www.python.org/sf/665761 and http://www.python.org/sf/665835 I'm not 100% sure that test_intern() and test_execfile() do the right thing. I'm not sure, whether the test script should check for undocumented implementation artefacts, like: a = 1 self.assert_(min(a, 1L) is a) but in this way at least we get notified if something is changed unintentionally. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-08 20:05 Message: Logged In: YES user_id=89016 test_b1 and test_b2 are combined into test_builtin now ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-08 15:03 Message: Logged In: YES user_id=6380 Two random suggestions: - a blank line before each method, even trivial ones, even the first one - use assertEqual, not assertEquals BTW, I see you've picked up on the convention that unit test methods should not have doc strings. Good! (But they may have comments.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-07 17:37 Message: Logged In: YES user_id=89016 test_b1.py has been ported too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-05 21:56 Message: Logged In: YES user_id=89016 The patch is hard to read, so I'll upload all three test scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470 From noreply@sourceforge.net Wed Feb 26 15:55:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 26 Feb 2003 07:55:59 -0800 Subject: [Patches] [ python-Patches-692718 ] change file extension search? Message-ID: Patches item #692718, was opened at 2003-02-24 23:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=692718&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Guido van Rossum (gvanrossum) Summary: change file extension search? Initial Comment: Since most modules are written in Python, it seems a fair number of failed stat() calls could be avoided by considering .py files before .so and module.so files and program startup could thus be improved. The attached patch implements that change. I don't know if there are any semantic differences with the change in order, but if there are I suspect they will be few (though subtle to debug if encountered). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-26 10:55 Message: Logged In: YES user_id=6380 Yes, rejected, because it changes what I see as a feature. Also, it saves at most one stat() call per successfully imported module. Shortening your path would help you more. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-02-26 10:00 Message: Logged In: YES user_id=44345 Assigning to Guido for his pronouncement (though I suspect I know what it will be). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-25 22:15 Message: Logged In: YES user_id=33168 The patch looks correct. It seemed like Guido was against the patch since he explained the behaviour as a feature. If you want this patch approved, assign to Guido for pronouncement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=692718&group_id=5470 From noreply@sourceforge.net Wed Feb 26 16:24:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 26 Feb 2003 08:24:04 -0800 Subject: [Patches] [ python-Patches-692718 ] change file extension search? Message-ID: Patches item #692718, was opened at 2003-02-24 22:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=692718&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Closed Resolution: Rejected Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Guido van Rossum (gvanrossum) Summary: change file extension search? Initial Comment: Since most modules are written in Python, it seems a fair number of failed stat() calls could be avoided by considering .py files before .so and module.so files and program startup could thus be improved. The attached patch implements that change. I don't know if there are any semantic differences with the change in order, but if there are I suspect they will be few (though subtle to debug if encountered). ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-02-26 10:24 Message: Logged In: YES user_id=44345 >> Shortening your path would help you more. Understood. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-26 09:55 Message: Logged In: YES user_id=6380 Yes, rejected, because it changes what I see as a feature. Also, it saves at most one stat() call per successfully imported module. Shortening your path would help you more. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-02-26 09:00 Message: Logged In: YES user_id=44345 Assigning to Guido for his pronouncement (though I suspect I know what it will be). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-25 21:15 Message: Logged In: YES user_id=33168 The patch looks correct. It seemed like Guido was against the patch since he explained the behaviour as a feature. If you want this patch approved, assign to Guido for pronouncement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=692718&group_id=5470 From noreply@sourceforge.net Wed Feb 26 16:51:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 26 Feb 2003 08:51:07 -0800 Subject: [Patches] [ python-Patches-693753 ] fix for bug 639806: default for dict.pop Message-ID: Patches item #693753, was opened at 2003-02-26 16:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=693753&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Nobody/Anonymous (nobody) Summary: fix for bug 639806: default for dict.pop Initial Comment: This patch adds an optional default value to dict.pop, so that it parallels dict.get, see discussion in bug 639806. If no default is given, the old behavior still exists, so backwards compatibility is no problem. The new pop must use METH_VARARGS and PyArg_UnpackTuple, somewhat effecting efficiency. If this is considered desirable, I could also provide the same behavior for list.pop. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=693753&group_id=5470 From noreply@sourceforge.net Wed Feb 26 16:51:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 26 Feb 2003 08:51:50 -0800 Subject: [Patches] [ python-Patches-693755 ] Separate opcodes from dis.py Message-ID: Patches item #693755, was opened at 2003-02-26 10:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=693755&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Guido van Rossum (gvanrossum) Summary: Separate opcodes from dis.py Initial Comment: This patch implements a few changes I've had in my copy of dis.py for awhile. In particular, it separates opcode data definitions into a separate module, allows classes and strings containing bytecode to be disassembled. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=693755&group_id=5470 From noreply@sourceforge.net Thu Feb 27 15:00:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 27 Feb 2003 07:00:40 -0800 Subject: [Patches] [ python-Patches-400998 ] experimental support for extended slicing on lists Message-ID: Patches item #400998, was opened at 2000-07-27 22:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=400998&group_id=5470 Category: Core (C code) Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: experimental support for extended slicing on lists Initial Comment: ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-02-27 15:00 Message: Logged In: YES user_id=6656 Heh. I'd actually intended to change _PyEval_SliceIndex to round up to -INT_MAX but I'd botched it. Fixed in Python/ceval.c revision 2.352. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-02-26 12:07 Message: Logged In: YES user_id=6656 a comedy of errors! i'll fix this soon. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2003-02-25 15:27 Message: Logged In: YES user_id=4771 a very far-fetched bug... >>> slice(-3058, 0, -1).indices(20) (-1, 5, -1) >>> slice(-30589138798749473891743819L, 0, -1).indices(20) (0, 5, -1) this is due to _PyEval_SliceIndex() which "rounds" very large negative values up to 0. Of course I don't know who would care, because in both cases 'range(*slice(...).indices(20))' returns an empty list. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-06-11 12:00 Message: Logged In: YES user_id=6656 Re footnotes: wimp! Re long lines: there's still one longish line in listobject.c that I really couldn't see how to wrap nicely. All the others got trimmed. But this is now checked in (with mild modfications from the posted patch) as (deep breath): Doc/api/concrete.tex revision 1.16 Doc/lib/libstdtypes.tex revision 1.96 Doc/ref/ref3.tex revision 1.91 Doc/whatsnew/whatsnew23.tex revision 1.24 Include/sliceobject.h revision 2.6 Lib/test/test_bool.py revision 1.6 Lib/test/test_types.py revision 1.30 Misc/NEWS revision 1.423 Objects/listobject.c revision 2.109 Objects/sliceobject.c revision 2.13 Objects/stringobject.c revision 2.166 Objects/tupleobject.c revision 2.65 Objects/unicodeobject.c revision 2.152 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-10 17:58 Message: Logged In: YES user_id=6380 Wow. Good job on the docs! (Although personally I would have added the footnote at the end to keep the existing note numbering :-). In test_bool.py, #veris(operator.isMappingType([]), False) should either be deleted or a different sample used, e.g. veris(operator.isMappingType(1), False) Some lines added to listobject.c (e.g. in list_[ass_]subscript()) are longer than 79 characters. But please do check it in, correcting the nits as you go! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-06-08 17:28 Message: Logged In: YES user_id=6656 OK, I think the attached gets all the cases right. I've also implemented extended slicing for strings and unicode strings & documented the C API functions. I think this is ready to go, at last. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-06-07 16:11 Message: Logged In: YES user_id=6656 Doh, it's me that can't read, not you... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-07 16:10 Message: Logged In: YES user_id=6380 Yes, I said so ("from you"). :) That's why it was so ironic that you had a similar endcase bug. :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-06-07 16:05 Message: Logged In: YES user_id=6656 That message was from me :) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-07 16:01 Message: Logged In: YES user_id=6380 OK, sounds good. (BTW, a Google search for PySlice_GetIndices and Numeric turned up a message inpython-dev from you asking about a broken endcase in Numeric slices, with a question about who uses it in a PS. Of course there was no answer. The broken endcase made me try a few things with your patch. :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-06-07 15:56 Message: Logged In: YES user_id=6656 Hmm. In my working copy, PySlice_GetIndicesEx now has a different interface (it computes the length of the slice, as that's fiddly and almost always required). So I may remain cowardly here. As a bonus, I'll document both functions in Doc/api/. Yes, I was staring at my code and thinking "that can't get all the end cases, can it?". Almost a relief to hear it doesn't :) I'll get pen and paper out. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-07 15:40 Message: Logged In: YES user_id=6380 I checked the Numeric-21.0 source, and they don't use PySlice_GetIndices. They have their own function, slice_GetIndices, which appears to be a reformatted copy of PySlice_GetIndices. except that the fiddling at the end is different: it truncates out-of-bounds indices rather than calling them errors, and it doesn't call step==0 an error (why?). I also checked the numarray-0.3.3 source, and they don't do slices yet. So I think we're safe fixing PySlice_GetIndices. However, I think there's a bug in your code. Suppose a is range(10). Then a[1000:] returns []. But a[1000::] returns [9]! Similarly, a[-1000::-1] return [0] where I would expect []. I think the start/stop truncation needs to depend on the step, too. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-07 15:19 Message: Logged In: YES user_id=6380 > This patch changes the behaviour of PySlice_GetIndices, > which must count as a public API function (albeit a pretty > useless one as it is now). Is that OK? Or would it be > better to have a new function PySlice_GetIndicesEx or > something. Should check whether NumPy uses this function. The big change is that it now can set an exception. I think that's too big a change without changing the name. PySlice_GetIndicesEx is fine. You can call PyInt_AsLong on any object, and if it has a tp_int or __int__ it will do the right thing, so it's better not to call PyInt_Check or PyLong_Check. The check for *step==0 could come earlier. > Do you really want assignments to extended slices in lists? > They were never that inuitive to me. They're about as useful as getting an extended slice from a list, so I'd say yes. They're soooooo cute! :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-06-07 14:35 Message: Logged In: YES user_id=6656 Hmm, I'm now older and more cowardly than when I wrote this, and I have a couple of questions. This patch changes the behaviour of PySlice_GetIndices, which must count as a public API function (albeit a pretty useless one as it is now). Is that OK? Or would it be better to have a new function PySlice_GetIndicesEx or something. Should check whether NumPy uses this function. Do you really want assignments to extended slices in lists? They were never that inuitive to me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-06 17:48 Message: Logged In: YES user_id=6380 (I lied about array -- it is already a subclassable new-style type. So go ahead, but do that one last.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-06 17:29 Message: Logged In: YES user_id=6380 Go ahead and check it in. Strings and unicode also need to support slices. While "hello"[::2] is silly, it's useful to be able to write "hello"[slice(1,-1)]. I think array needs more work -- first 'array.array' should be made into a type object that can be invoked as a constructor and subclassed. That would be nice, yes, but is a lower priority for me ATM. Off-topic aside: the change you had to make to PyString_Format() and its Unicode cousin suggests that we need a better way to decide if something is really a mapping... E.g. this now gives a confusing error message: "%(foo)s %(bar)s" % [1,2,3] I wonder how many other places in the code make naive mapping tests (and of course operator.isMappingType becomes totally unreliable). Maybe the presence of a keys() method together with a __getitem__ method should be used as a standard test for mapping-ness? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-06-06 14:01 Message: Logged In: YES user_id=6656 Whoosh, this is a blast from the past. I've minimally updated the patch (it only failed to apply for the trivialest of reasons). All tests pass (I had to tweak test_bool -- operator.isMappingType([]) is True now). Suffice to say I don't really remember how this works :-/ What more needs to be done? strings, arrays (shouldn't be too hard). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-03 22:00 Message: Logged In: YES user_id=6380 Michael, the tide has changed. Would you be interested in reviving this patch and finishing it? It could possibly help to address bug 473985 and maybe also 459235. If you have no time, let me know and I'll see if I can find time myself. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-12-18 22:19 Message: Rejected for lack of interest. Sorry, Michael! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-11-13 19:45 Message: Is reviewing and applying this patch the best use of my time? I note that this is okay, but low priority -- I doubt that it will get used much. Plus, what about the array module, strings, UserList? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-09-01 03:10 Message: Too late for the release, sorry. And Tim hates negative strides. We'll get back to this for 2.1. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-08-16 20:30 Message: So, I missed my deadline by twenty five minutes. Sorry :-) This latest patch adds a fairly basic test suite, a stab at some docs, and jumps up and down on PySlice_GetIndices. Also (wrt. stringobject.c & unicodeobject.c) it's amazing what you can break, isn't it? Thank God for test suites... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-08-16 20:30 Message: So, I missed my deadline by twenty five minutes. Sorry :-) This latest patch adds a fairly basic test suite, a stab at some docs, and jumps up and down on PySlice_GetIndices. Also (wrt. stringobject.c & unicodeobject.c) it's amazing what you can break, isn't it? Thank God for test suites... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-08-15 20:04 Message: OK, I'll get to that soon (ie. <24hours, hopefully <4). But bear in mind I'm now going to the pub... I may need some advice for the docs... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-08-15 19:53 Message: Note that without doc and test patches too, and Real Soon, I'll have to Postpone this. Assigned to me to remind me of that. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-07-30 19:41 Message: meep! naughty Michael hadn't been running "make test" often enough. this update fixes that. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-07-30 19:10 Message: bugfixes (refounting in assignment, logic in deletion) & a few tweaks. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-07-29 11:36 Message: updated patch to support slice assignements, deletions (needs testing still) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-07-28 07:47 Message: negative indices! for i in listvar[::-1]: pass now iterates over the list backwards (rather than coredumping...) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-07-27 22:39 Message: c'mon michael! at least get *some* of the boundary cases... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2000-07-27 22:31 Message: this 10 minute hack adds support for "extended slicing" to lists, by which I mean things like: >>> range(100)[23:60:12] [23, 35, 47, 59] todo: find out if this is the approved approach add support for tuples write docs, testsuite (make test passes as is, but should be extended). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=400998&group_id=5470 From noreply@sourceforge.net Thu Feb 27 20:58:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 27 Feb 2003 12:58:43 -0800 Subject: [Patches] [ python-Patches-693755 ] Separate opcodes from dis.py Message-ID: Patches item #693755, was opened at 2003-02-26 11:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=693755&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Skip Montanaro (montanaro) Summary: Separate opcodes from dis.py Initial Comment: This patch implements a few changes I've had in my copy of dis.py for awhile. In particular, it separates opcode data definitions into a separate module, allows classes and strings containing bytecode to be disassembled. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-27 15:58 Message: Logged In: YES user_id=6380 Looks fine, except it seems you didn't actually delete the calls to def_op etc. from dis.py! Also: - maybe rename it to opcode.py in consistency with both keyword.py and opcode.h. And it would be nice of opcode.h knew how to update itself by reading opcode.h, but that's A Separate Project. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=693755&group_id=5470 From noreply@sourceforge.net Thu Feb 27 21:36:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 27 Feb 2003 13:36:17 -0800 Subject: [Patches] [ python-Patches-693755 ] Separate opcodes from dis.py Message-ID: Patches item #693755, was opened at 2003-02-26 10:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=693755&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: Separate opcodes from dis.py Initial Comment: This patch implements a few changes I've had in my copy of dis.py for awhile. In particular, it separates opcode data definitions into a separate module, allows classes and strings containing bytecode to be disassembled. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-02-27 15:36 Message: Logged In: YES user_id=44345 Whoops! I thought I had cleaned out the duplicate code from dis.py. Will check on that and rename opcodes to opcode. Agreed that automatically generating opcode.py from opcode.h is a separate thing. opcode.h will need some annotations to allow the various secondary calls (jrelop, hasconst.append, etc) to be generated as well. New patch should have the desired corrections as well as a minimal test_dis.py. Checking in... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-27 14:58 Message: Logged In: YES user_id=6380 Looks fine, except it seems you didn't actually delete the calls to def_op etc. from dis.py! Also: - maybe rename it to opcode.py in consistency with both keyword.py and opcode.h. And it would be nice of opcode.h knew how to update itself by reading opcode.h, but that's A Separate Project. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=693755&group_id=5470 From noreply@sourceforge.net Thu Feb 27 21:40:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 27 Feb 2003 13:40:28 -0800 Subject: [Patches] [ python-Patches-693755 ] Separate opcodes from dis.py Message-ID: Patches item #693755, was opened at 2003-02-26 10:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=693755&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: Separate opcodes from dis.py Initial Comment: This patch implements a few changes I've had in my copy of dis.py for awhile. In particular, it separates opcode data definitions into a separate module, allows classes and strings containing bytecode to be disassembled. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-02-27 15:40 Message: Logged In: YES user_id=44345 implemented as dis.py 1.45 opcode.py 1.1 test/test_dis.py 1.1 ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-02-27 15:36 Message: Logged In: YES user_id=44345 Whoops! I thought I had cleaned out the duplicate code from dis.py. Will check on that and rename opcodes to opcode. Agreed that automatically generating opcode.py from opcode.h is a separate thing. opcode.h will need some annotations to allow the various secondary calls (jrelop, hasconst.append, etc) to be generated as well. New patch should have the desired corrections as well as a minimal test_dis.py. Checking in... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-27 14:58 Message: Logged In: YES user_id=6380 Looks fine, except it seems you didn't actually delete the calls to def_op etc. from dis.py! Also: - maybe rename it to opcode.py in consistency with both keyword.py and opcode.h. And it would be nice of opcode.h knew how to update itself by reading opcode.h, but that's A Separate Project. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=693755&group_id=5470 From noreply@sourceforge.net Fri Feb 28 14:42:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 28 Feb 2003 06:42:31 -0800 Subject: [Patches] [ python-Patches-695090 ] Make build_py allow modules and packages at the same time Message-ID: Patches item #695090, was opened at 2003-02-28 15:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=695090&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bernhard Herzog (bernhard) Assigned to: Nobody/Anonymous (nobody) Summary: Make build_py allow modules and packages at the same time Initial Comment: The build command of the distutils currently doesn't support both python modules and python packages in the same setup.py call. See the distutils-sig for a discussion: http://mail.python.org/pipermail/distutils-sig/2003-February/003192.html This patch modifies the build_py command to allow this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=695090&group_id=5470 From noreply@sourceforge.net Fri Feb 28 16:34:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 28 Feb 2003 08:34:52 -0800 Subject: [Patches] [ python-Patches-692001 ] properties and __getattribute__ Message-ID: Patches item #692001, was opened at 2003-02-23 22:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=692001&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: David Abrahams (david_abrahams) Assigned to: Guido van Rossum (gvanrossum) Summary: properties and __getattribute__ Initial Comment: Got tired of asking for clarification, so I just wrote this up. Hope it's useful (and correct). The old information about not being able to change __getattr__ and __setattr__ is outdated, so I removed it. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-28 11:34 Message: Logged In: YES user_id=6380 done. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=692001&group_id=5470 From noreply@sourceforge.net Fri Feb 28 17:23:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 28 Feb 2003 09:23:45 -0800 Subject: [Patches] [ python-Patches-695090 ] Make build_py allow modules and packages at the same time Message-ID: Patches item #695090, was opened at 2003-02-28 09:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=695090&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bernhard Herzog (bernhard) >Assigned to: A.M. Kuchling (akuchling) Summary: Make build_py allow modules and packages at the same time Initial Comment: The build command of the distutils currently doesn't support both python modules and python packages in the same setup.py call. See the distutils-sig for a discussion: http://mail.python.org/pipermail/distutils-sig/2003-February/003192.html This patch modifies the build_py command to allow this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=695090&group_id=5470 From noreply@sourceforge.net Fri Feb 28 19:48:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 28 Feb 2003 11:48:33 -0800 Subject: [Patches] [ python-Patches-695250 ] fix for bug 672614 :) Message-ID: Patches item #695250, was opened at 2003-02-28 19:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=695250&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Nobody/Anonymous (nobody) Summary: fix for bug 672614 :) Initial Comment: python -S shouldn't show COPYRIGHT string as they are not available. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=695250&group_id=5470 From noreply@sourceforge.net Fri Feb 28 20:21:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 28 Feb 2003 12:21:27 -0800 Subject: [Patches] [ python-Patches-695275 ] environment parameter for popen2 Message-ID: Patches item #695275, was opened at 2003-02-28 21:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=695275&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bernhard Herzog (bernhard) Assigned to: Nobody/Anonymous (nobody) Summary: environment parameter for popen2 Initial Comment: The patch provides a way to specify the environment for the subprocess run by the popen2, popen3 and popen4 functions in the popen2 module on platforms that use the Popen3 class. It does that by adding this parameter to the __init__ method of Popen3 and the popenN functions calling execvpe in _run_child if the env parameter was not None. This patch obviously doesn't add this parameter on e.g. Windows. AFAICT from posixmodule.c where popen is implemented via CreateProcess on Windows it would be at least theorectically possible to implement it on Windows as well. I don't have the need nor the time for that unfortunately. Being able to specify the environment for the subprocess in popen is very useful for e.g. running a CGI from Zope. ZCGI for instance modifies os.environ so that the subprocess inherits it but that cause problems because other threads may occasionally see a modified environment. This is particularly bad for the oracle client libraries on Linux which require certain environment settings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=695275&group_id=5470