From noreply at sourceforge.net Fri Oct 1 04:51:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 1 04:51:14 2004 Subject: [Patches] [ python-Patches-1035498 ] -m option to run a module as a script Message-ID: Patches item #1035498, was opened at 2004-09-28 00:22 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Barry A. Warsaw (bwarsaw) Summary: -m option to run a module as a script Initial Comment: Implements the '-m' option recently discussed on python-dev. Runs a module 'as if' it had been invoked from the command line. E.g., for a build directory, the following two commands are equivalent: ./python -m pdb ./python Lib/pdb.py Note that neither of these does the same thing as "./python -c "import pdb". (In this latter case, any "if __name__ == "__main__" code would not be executed, whereas it will be invoked in the first two cases). Given the vagaries of sys.path, this is quite handy - if a module can be imported, it can be easily used as a script too. Not that all modules will necessarily do anything _interesting_ when used as a script. . . The current implementation makes changes to main.c (handle the new argument), pythonrun.[ch] (new flavour of PyRun_) and import.[ch] (expose a PyImport_FindModule C API) Current limitations / to-do if this is pursued: - print sensible errors for non-Python files (e.g. hotshot) - allow 'dotted' names - decide what to do with packages (e.g. run __init__.py) - check usage messages in main.c are all still under 512 characters (I assume that limit was set for a reason) - the 1K limit on absolute file paths seems rather arbitrary. - this is code written in the wee hours of the morning, so it probably has a few other lurking 'features'. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 12:51 Message: Logged In: YES user_id=1038590 New version (run_module_3.diff) Takes more account of the file description reported by PyImport. Explictly restricts itself to PY_SOURCE and PY_COMPILED scripts. Behaves correctly when a non-package is encountered while parsing a dotted name (closes the file descriptor and reports an error). I also realised that the '-m' option doesn't currently comprehend "__path__" variables in packages. So maybe we *should* be loading the packages as we find them, and then querying them for their __path__ variable. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 19:48 Message: Logged In: YES user_id=1038590 Barry, kicking this in your direction solely because you were one of the people to comment on it on py-dev. Feel free to say 'too busy' :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 19:39 Message: Logged In: YES user_id=1038590 New version of patch attached (run_module_2.diff). This version allows modules within packages to be executed. It does this *without* loading the packages first (just as if the script were specified directly on the command line). It's also a little more responsive when it comes to error message, and I've confirmed that the usage message components are now under 512 bytes each. The FindModule method is now marked as private (i.e. with leading underscore). The limit on file paths in pythonrun.c is now taken from osdefs.h (the same limit that import.c already uses) The only bug I know of is that it misbehaves if you supply a name like "a.b.module.d". You will get an ImportError saying that d was not found, and the file pointer for 'module' won't get closed properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 From noreply at sourceforge.net Fri Oct 1 06:14:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 1 06:14:03 2004 Subject: [Patches] [ python-Patches-1035498 ] -m option to run a module as a script Message-ID: Patches item #1035498, was opened at 2004-09-28 00:22 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Barry A. Warsaw (bwarsaw) Summary: -m option to run a module as a script Initial Comment: Implements the '-m' option recently discussed on python-dev. Runs a module 'as if' it had been invoked from the command line. E.g., for a build directory, the following two commands are equivalent: ./python -m pdb ./python Lib/pdb.py Note that neither of these does the same thing as "./python -c "import pdb". (In this latter case, any "if __name__ == "__main__" code would not be executed, whereas it will be invoked in the first two cases). Given the vagaries of sys.path, this is quite handy - if a module can be imported, it can be easily used as a script too. Not that all modules will necessarily do anything _interesting_ when used as a script. . . The current implementation makes changes to main.c (handle the new argument), pythonrun.[ch] (new flavour of PyRun_) and import.[ch] (expose a PyImport_FindModule C API) Current limitations / to-do if this is pursued: - print sensible errors for non-Python files (e.g. hotshot) - allow 'dotted' names - decide what to do with packages (e.g. run __init__.py) - check usage messages in main.c are all still under 512 characters (I assume that limit was set for a reason) - the 1K limit on absolute file paths seems rather arbitrary. - this is code written in the wee hours of the morning, so it probably has a few other lurking 'features'. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 14:13 Message: Logged In: YES user_id=1038590 New version (#4) Trivial fix - tell PyRun_SimpleFile to close the file when it's done with it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 12:51 Message: Logged In: YES user_id=1038590 New version (run_module_3.diff) Takes more account of the file description reported by PyImport. Explictly restricts itself to PY_SOURCE and PY_COMPILED scripts. Behaves correctly when a non-package is encountered while parsing a dotted name (closes the file descriptor and reports an error). I also realised that the '-m' option doesn't currently comprehend "__path__" variables in packages. So maybe we *should* be loading the packages as we find them, and then querying them for their __path__ variable. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 19:48 Message: Logged In: YES user_id=1038590 Barry, kicking this in your direction solely because you were one of the people to comment on it on py-dev. Feel free to say 'too busy' :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 19:39 Message: Logged In: YES user_id=1038590 New version of patch attached (run_module_2.diff). This version allows modules within packages to be executed. It does this *without* loading the packages first (just as if the script were specified directly on the command line). It's also a little more responsive when it comes to error message, and I've confirmed that the usage message components are now under 512 bytes each. The FindModule method is now marked as private (i.e. with leading underscore). The limit on file paths in pythonrun.c is now taken from osdefs.h (the same limit that import.c already uses) The only bug I know of is that it misbehaves if you supply a name like "a.b.module.d". You will get an ImportError saying that d was not found, and the file pointer for 'module' won't get closed properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 From noreply at sourceforge.net Fri Oct 1 07:41:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 1 07:41:31 2004 Subject: [Patches] [ python-Patches-1038256 ] Provide tuple of "special" exceptions Message-ID: Patches item #1038256, was opened at 2004-10-01 15:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038256&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Provide tuple of "special" exceptions Initial Comment: Add a "special_exceptions" tuple to builtins and exceptions module which lists the exceptions that users should be careful to avoid accidentally suppressing. The current list is SystemExit, MemoryError, KeyboardInterrupt and StopIteration A 'no builtin' version of the patch is supplied which only provides 'exceptions.special_exception', and leaves builtins alone. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038256&group_id=5470 From noreply at sourceforge.net Fri Oct 1 07:55:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 1 07:55:38 2004 Subject: [Patches] [ python-Patches-1038256 ] Provide tuple of "special" exceptions Message-ID: Patches item #1038256, was opened at 2004-10-01 00:41 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038256&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Provide tuple of "special" exceptions Initial Comment: Add a "special_exceptions" tuple to builtins and exceptions module which lists the exceptions that users should be careful to avoid accidentally suppressing. The current list is SystemExit, MemoryError, KeyboardInterrupt and StopIteration A 'no builtin' version of the patch is supplied which only provides 'exceptions.special_exception', and leaves builtins alone. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-01 00:55 Message: Logged In: YES user_id=80475 Aren't we looking for the inverse of that tuple, some way to write: try: myfunc() except non-special exceptions: altfunc() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038256&group_id=5470 From noreply at sourceforge.net Fri Oct 1 08:56:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 1 08:56:19 2004 Subject: [Patches] [ python-Patches-1038256 ] Provide tuple of "special" exceptions Message-ID: Patches item #1038256, was opened at 2004-10-01 15:41 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038256&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Provide tuple of "special" exceptions Initial Comment: Add a "special_exceptions" tuple to builtins and exceptions module which lists the exceptions that users should be careful to avoid accidentally suppressing. The current list is SystemExit, MemoryError, KeyboardInterrupt and StopIteration A 'no builtin' version of the patch is supplied which only provides 'exceptions.special_exception', and leaves builtins alone. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 16:56 Message: Logged In: YES user_id=1038590 Yes, we are. At the moment, the best way to spell that is: try: myfunc() except special_exceptions: raise except: dealwithit() I think it would be neat to spell that as: try: myfunc() except not special_exceptions: dealwithit() but that would be a helluva lot more work, and needs this tuple anyway :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-01 15:55 Message: Logged In: YES user_id=80475 Aren't we looking for the inverse of that tuple, some way to write: try: myfunc() except non-special exceptions: altfunc() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038256&group_id=5470 From noreply at sourceforge.net Fri Oct 1 12:02:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 1 12:02:16 2004 Subject: [Patches] [ python-Patches-1038388 ] __main__ for whichdb.py Message-ID: Patches item #1038388, was opened at 2004-10-01 14:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038388&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Nobody/Anonymous (nobody) Summary: __main__ for whichdb.py Initial Comment: This patch addsd shebang and __main__ script for whichdb.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038388&group_id=5470 From pelland at cmspan.net Fri Oct 1 23:44:39 2004 From: pelland at cmspan.net (pelland) Date: Fri Oct 1 23:45:38 2004 Subject: [Patches] RE:[1] 1mprove your-sperm morphology and quality... Message-ID: <000601c4a7ff$dd9e1380$514f28d1@PELLAND> Hi, My husband and i have been trying to conceive for a year and a half now. He has gone twice cor semen analysis. Which is expensive. And they have checked me. I was placed on progesterone. But i think the main problem is my husband. They say morphology is at 69%. but everything else is fine. So that is the only thing that is keeping us from getting pregnant. I want to go on clomid, but dont think that will work with him. Is there something we can do before it gets to expensive. I guess our next step is a urologist. But i dont know what he can do. Do you have any suggestions? thank you tammy pelland -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20041001/dfa4e431/attachment.html From noreply at sourceforge.net Sat Oct 2 07:07:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 2 07:07:06 2004 Subject: [Patches] [ python-Patches-1038854 ] Fix struct.pack on 64-bit archs (broken on 2.*) Message-ID: Patches item #1038854, was opened at 2004-10-02 07:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038854&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Grundmann (sgatwasetde) Assigned to: Nobody/Anonymous (nobody) Summary: Fix struct.pack on 64-bit archs (broken on 2.*) Initial Comment: Description: The code in the struct module assumes that sizeof(long) == sizeof(int) which is wrong on (most) 64-bit architectures (linux on amd64 with a 32-bit userland is an exception). How To Repeat: on a 32-bit platform struct.pack behaves as expected: $ uname -m -r -s FreeBSD 4.10-STABLE i386 $ python -c "import struct; print repr(struct.pack('I', 4294967296))" Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert on a 64-bit platform it treats integers as longs (it does not check for over/underflows and returns the lower 4 byte): $ uname -m -r -s FreeBSD 5.2-CURRENT sparc64 $ python -c "import struct; print repr(struct.pack('I', 4294967296))" '\x00\x00\x00\x00' Fix: in python/python/dist/src/Modules/structmodule.c: np_uint() and np_int() have to check for over/underflows using MAX_UINT, MAX_INT, MIN_INT as np_ushort() and np_short() already do for MAX_USHORT, ... the attached patch does this (diff was generated using diff -rNu and Revision 2.62 of python/python/dist/src/Modules/structmodule.c) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038854&group_id=5470 From noreply at sourceforge.net Sat Oct 2 09:16:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 2 09:16:43 2004 Subject: [Patches] [ python-Patches-1038256 ] Provide tuple of "special" exceptions Message-ID: Patches item #1038256, was opened at 2004-10-01 07:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038256&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Provide tuple of "special" exceptions Initial Comment: Add a "special_exceptions" tuple to builtins and exceptions module which lists the exceptions that users should be careful to avoid accidentally suppressing. The current list is SystemExit, MemoryError, KeyboardInterrupt and StopIteration A 'no builtin' version of the patch is supplied which only provides 'exceptions.special_exception', and leaves builtins alone. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-10-02 09:16 Message: Logged In: YES user_id=21627 I don't like the name of the tuple. "special_exceptions" does not indicate in what way they are special; the name should more directly indicate what this is or why one would use it. Also, I'm uncertain about the rationale for picking precisely these exceptions. I agree that one would normally not suppress SystemExit, and usually not KeyboardInterrupt. I'm uncertain about MemoryError, and I can't see why StopIteration would ever occur in a context where exceptions are suppressed. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 08:56 Message: Logged In: YES user_id=1038590 Yes, we are. At the moment, the best way to spell that is: try: myfunc() except special_exceptions: raise except: dealwithit() I think it would be neat to spell that as: try: myfunc() except not special_exceptions: dealwithit() but that would be a helluva lot more work, and needs this tuple anyway :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-01 07:55 Message: Logged In: YES user_id=80475 Aren't we looking for the inverse of that tuple, some way to write: try: myfunc() except non-special exceptions: altfunc() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038256&group_id=5470 From noreply at sourceforge.net Sat Oct 2 11:39:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 2 11:39:37 2004 Subject: [Patches] [ python-Patches-1038909 ] pydoc method documentation lookup enhancement Message-ID: Patches item #1038909, was opened at 2004-10-02 09:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038909&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Schmolck (aschmolck) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc method documentation lookup enhancement Initial Comment: If a method has no docstring, then pydoc.getdoc currently just looks for a comment or returns nothing. A more sensible behavior IMO would be if pydoc tried to get the docstring from the same method in a baseclass (in mro), if it exists. This ought to be "the right thing" (i.e. by the semantics of inheritance if the documentation of a overriden method is not overriden it should still present the same interface to the user) and the current behavior is a royal pain when working with backends or other types of subclasses that are derived from some abstract class that contains all the interface docs. Currently even fixing up docstrings by hand is not simple, because the straightforward ``Child.meth.__doc__ = Parent.meth.__doc__`` fails (one has to go directly via the .__dict__ which is problematic). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038909&group_id=5470 From noreply at sourceforge.net Sat Oct 2 11:40:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 2 11:40:45 2004 Subject: [Patches] [ python-Patches-1038911 ] OS X: Can't use #!/usr/bin/pythonw Message-ID: Patches item #1038911, was opened at 2004-10-02 02:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038911&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nathan Gray (n8gray) Assigned to: Nobody/Anonymous (nobody) Summary: OS X: Can't use #!/usr/bin/pythonw Initial Comment: At the moment, on OS X /usr/bin/pythonw2.x is a simple sh script that exec's a python interpreter within a valid OS X application bundle. The problem is that this prevents python scripts from using pythonw in the #! line. Darwin won't allow a script to act as an interpreter in a #! line. This patch replaces the shell script with a simple C program that does the same thing -- it just calls execv on the python interpreter within the OS X app bundle. Since it is a compiled executable it is allowed to act as an interpreter in #! lines. Your patch guidelines said you preferred multiple patches to be concatenated in a single file. My patch consists of a Makefile change and a new file, dist/src/Mac/OSX/pythonw.c. I've included both in the text file attached to this report. It would probably be prudent for somebody to review the Makefile change, since it's always tricky to find the right way to put a new file in someone else's build process. Thank you, -Nathan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038911&group_id=5470 From noreply at sourceforge.net Sat Oct 2 11:43:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 2 11:43:37 2004 Subject: [Patches] [ python-Patches-1038911 ] OS X: Can't use #!/usr/bin/pythonw Message-ID: Patches item #1038911, was opened at 2004-10-02 02:40 Message generated for change (Comment added) made by n8gray You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038911&group_id=5470 >Category: Macintosh >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nathan Gray (n8gray) Assigned to: Nobody/Anonymous (nobody) Summary: OS X: Can't use #!/usr/bin/pythonw Initial Comment: At the moment, on OS X /usr/bin/pythonw2.x is a simple sh script that exec's a python interpreter within a valid OS X application bundle. The problem is that this prevents python scripts from using pythonw in the #! line. Darwin won't allow a script to act as an interpreter in a #! line. This patch replaces the shell script with a simple C program that does the same thing -- it just calls execv on the python interpreter within the OS X app bundle. Since it is a compiled executable it is allowed to act as an interpreter in #! lines. Your patch guidelines said you preferred multiple patches to be concatenated in a single file. My patch consists of a Makefile change and a new file, dist/src/Mac/OSX/pythonw.c. I've included both in the text file attached to this report. It would probably be prudent for somebody to review the Makefile change, since it's always tricky to find the right way to put a new file in someone else's build process. Thank you, -Nathan ---------------------------------------------------------------------- >Comment By: Nathan Gray (n8gray) Date: 2004-10-02 02:43 Message: Logged In: YES user_id=121553 By the way, the patch is against CVS head. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038911&group_id=5470 From noreply at sourceforge.net Sat Oct 2 12:13:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 2 12:13:04 2004 Subject: [Patches] [ python-Patches-1038917 ] repair typos Message-ID: Patches item #1038917, was opened at 2004-10-02 19:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038917&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: repair typos Initial Comment: modified files include : - Misc/HISTORY - Doc/lib/libgetopt.tex - Doc/mac/libaetypes.tex - Doc/mac/using.tex - Doc/mac/libmacic.tex ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038917&group_id=5470 From noreply at sourceforge.net Sat Oct 2 13:02:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 2 13:02:46 2004 Subject: [Patches] [ python-Patches-1038917 ] repair typos Message-ID: Patches item #1038917, was opened at 2004-10-02 05:13 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038917&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: repair typos Initial Comment: modified files include : - Misc/HISTORY - Doc/lib/libgetopt.tex - Doc/mac/libaetypes.tex - Doc/mac/using.tex - Doc/mac/libmacic.tex ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-02 06:02 Message: Logged In: YES user_id=80475 Applied. Thank you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038917&group_id=5470 From noreply at sourceforge.net Sat Oct 2 13:47:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 2 13:47:09 2004 Subject: [Patches] [ python-Patches-1035576 ] Add New RPM-friendly record option to setup.py Message-ID: Patches item #1035576, was opened at 2004-09-28 00:33 Message generated for change (Comment added) made by bruthasj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035576&group_id=5470 Category: Distutils and setup.py Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Pitman (bruthasj) Assigned to: Nobody/Anonymous (nobody) Summary: Add New RPM-friendly record option to setup.py Initial Comment: One major weakness of the current usage of INSTALLED_FILES in bdist_rpm leaves directories unlisted thereby causing an uninstall of a package to leave these behind. This patch separates out into another option --record-rpm and function that generates a list friendly for RPM consumption. It currently handles data_dirs and install_lib (everything under site-packages). In addition, languages found under the common LC_MESSAGES sub-directory is also automatically tagged with %lang(de) attribute. Documentation does not need to be handled since RPM already sets this up if the packager uses %doc. I've run a couple of tests with this patch showing good results. Before taking the concept further, I submit it here for your review. ---------------------------------------------------------------------- >Comment By: Jeff Pitman (bruthasj) Date: 2004-10-02 19:47 Message: Logged In: YES user_id=46780 v0.2: Implement self.root optimization from how it was done before. v0.3: self.distribution.data_files can be None. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035576&group_id=5470 From noreply at sourceforge.net Sat Oct 2 17:22:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 2 17:22:45 2004 Subject: [Patches] [ python-Patches-932935 ] doctest: allow custom matchers for testing if got==want Message-ID: Patches item #932935, was opened at 2004-04-10 15:57 Message generated for change (Comment added) made by edloper You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=932935&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Edward Loper (edloper) Assigned to: Edward Loper (edloper) Summary: doctest: allow custom matchers for testing if got==want Initial Comment: To determine the success of a doctest example, doctest compares the actual output to the expected output. The test succeeds if the two match exactly. This patch gives the user the ability to supply a custom "matcher" function, which will be used instead of string equality to test whether the test succeeds. This function should take two string parameters, "got" and "want", which will contain the actual and expected output, respectively; and it should return True if they should be considered to match (i.e., test succeeds), and False if they should not (i.e., test fails). Two sample matcher functions are provided, as well: - match_ignoring_whitespace returns true if the actual output and expected output are equal, ignoring differences in amount of whitespace (eg 2 spaces vs 1). - match_ignoring_trailing_blanklines returns true if the actual output and expected output are equal, once any trailing blank lines are discarded. This can be useful with the END_WITH_DEDENT option, suggested in patch #932933 [1] The patch was made avainst revision 1.33 of doctest.py. [1] http://sourceforge.net/tracker/index.php? func=detail&aid=932933&group_id=5470&atid=3054 70 ---------------------------------------------------------------------- >Comment By: Edward Loper (edloper) Date: 2004-10-02 11:22 Message: Logged In: YES user_id=195958 The desired functionality was included in the new implementation of doctest. In particular, the user can customize the comparison between want & got using doctest option directives; and using a custom OutputChecker object. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-05-31 15:04 Message: Logged In: YES user_id=21627 Please resubmit the patch using unified diffs. You might just as well include test cases and documentation right away. ---------------------------------------------------------------------- Comment By: Edward Loper (edloper) Date: 2004-04-10 16:00 Message: Logged In: YES user_id=195958 If this patch looks good, I'd be happy to write a patch for the docs & test cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=932935&group_id=5470 From noreply at sourceforge.net Sat Oct 2 17:25:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 2 17:25:13 2004 Subject: [Patches] [ python-Patches-932932 ] doctest: Add Tester params to DocTestSuite Message-ID: Patches item #932932, was opened at 2004-04-10 15:56 Message generated for change (Comment added) made by edloper You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=932932&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Edward Loper (edloper) Assigned to: Edward Loper (edloper) Summary: doctest: Add Tester params to DocTestSuite Initial Comment: This diff adds the following parameters to DocTestSuite: globs, verbose, isprivate, optionflags. The new parameters are simply passed on to the Tester object that the DocTestSuite wraps. This match was made against revision 1.33 of doctest.py ---------------------------------------------------------------------- >Comment By: Edward Loper (edloper) Date: 2004-10-02 11:25 Message: Logged In: YES user_id=195958 The desired change was included in the new doctest implementation. (Except for the verbose flag; verbosity is controlled via the UnitTest framework) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-05-31 15:05 Message: Logged In: YES user_id=21627 The patch looks good in principle. Please submit test cases and documentation. ---------------------------------------------------------------------- Comment By: Edward Loper (edloper) Date: 2004-04-10 15:59 Message: Logged In: YES user_id=195958 If this patch looks good, I'd be happy to write a patch for the docs & test cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=932932&group_id=5470 From noreply at sourceforge.net Sat Oct 2 18:14:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 2 18:14:59 2004 Subject: [Patches] [ python-Patches-754022 ] Enhanced webbrowser.py Message-ID: Patches item #754022, was opened at 2003-06-13 19:24 Message generated for change (Settings changed) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 Category: Library (Lib) >Group: Python 2.4 Status: Open Resolution: None >Priority: 6 Submitted By: Oleg Broytmann (phd) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Enhanced webbrowser.py Initial Comment: The patch enhances webbrowser.py. First, all calls to os.system return result code, and the inverse of the code (it is ok/fail status) passed through all higher-level routines up to top-level call to open(url). This allows to check if a browser was really started. Second, the very open() modified so it is now trying to run all registered browsers in order until a browser returns 1. Third, the file can be used as a program: webbrowser.py url. Optional parameters -n allows to open the url in a new window. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 From noreply at sourceforge.net Sat Oct 2 18:15:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 2 18:15:34 2004 Subject: [Patches] [ python-Patches-821862 ] ftplib: Strict RFC 959 (telnet in command channel) Message-ID: Patches item #821862, was opened at 2003-10-11 22:04 Message generated for change (Settings changed) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=821862&group_id=5470 Category: Library (Lib) >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Nobody/Anonymous (nobody) Summary: ftplib: Strict RFC 959 (telnet in command channel) Initial Comment: RFC 959 *requires* to implemet a portion of the telnet protocol in the command channel. Without this ftlib has problems interacting with RFC959-compliant server (most Unix ftp daemons are compliant) if, e.g., a directory or a filename contains russian characters. The attched patch implements a minimal requirement (it doubles chr(255) in the .putline() method), but it allows a programer to choose if a session will be strict or not. Default value is "not strict" because most clients (even Unix clients) do not implemet this telnet option, and most Windoze servers do not implemet it. Tested with ProFTPd on GNU/Linux system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=821862&group_id=5470 From noreply at sourceforge.net Sat Oct 2 19:40:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 2 19:40:12 2004 Subject: [Patches] [ python-Patches-1039083 ] SimpleXMLRPCServer optional allow_none / encoding arguments Message-ID: Patches item #1039083, was opened at 2004-10-02 14:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1039083&group_id=5470 Category: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Guillermo M. Narvaja (guillon) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleXMLRPCServer optional allow_none / encoding arguments Initial Comment: xmlrpclip.ServerProxy supports an optional allow_none and encoding arguments while SimpleXMLRPCServer.py doesn't. The patch adds optional arguments to SimpleXMLRPCDispatcher, SimpleXMLRPCServer and CGIXMLRPCRequestHandler. "encoding" and "allow_none" arguments are passed to xmlrpclib.dumps calls in _marshalled_dispatch method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1039083&group_id=5470 From noreply at sourceforge.net Sat Oct 2 19:50:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 2 19:50:21 2004 Subject: [Patches] [ python-Patches-1039083 ] SimpleXMLRPCServer optional allow_none / encoding arguments Message-ID: Patches item #1039083, was opened at 2004-10-02 14:40 Message generated for change (Comment added) made by guillon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1039083&group_id=5470 Category: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Guillermo M. Narvaja (guillon) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleXMLRPCServer optional allow_none / encoding arguments Initial Comment: xmlrpclip.ServerProxy supports an optional allow_none and encoding arguments while SimpleXMLRPCServer.py doesn't. The patch adds optional arguments to SimpleXMLRPCDispatcher, SimpleXMLRPCServer and CGIXMLRPCRequestHandler. "encoding" and "allow_none" arguments are passed to xmlrpclib.dumps calls in _marshalled_dispatch method. ---------------------------------------------------------------------- >Comment By: Guillermo M. Narvaja (guillon) Date: 2004-10-02 14:50 Message: Logged In: YES user_id=1132014 Fixed some large lines to fit in 78 columns. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1039083&group_id=5470 From noreply at sourceforge.net Sat Oct 2 19:52:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 2 19:52:16 2004 Subject: [Patches] [ python-Patches-1039083 ] SimpleXMLRPCServer optional allow_none / encoding arguments Message-ID: Patches item #1039083, was opened at 2004-10-02 14:40 Message generated for change (Comment added) made by guillon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1039083&group_id=5470 Category: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Guillermo M. Narvaja (guillon) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleXMLRPCServer optional allow_none / encoding arguments Initial Comment: xmlrpclip.ServerProxy supports an optional allow_none and encoding arguments while SimpleXMLRPCServer.py doesn't. The patch adds optional arguments to SimpleXMLRPCDispatcher, SimpleXMLRPCServer and CGIXMLRPCRequestHandler. "encoding" and "allow_none" arguments are passed to xmlrpclib.dumps calls in _marshalled_dispatch method. ---------------------------------------------------------------------- >Comment By: Guillermo M. Narvaja (guillon) Date: 2004-10-02 14:52 Message: Logged In: YES user_id=1132014 Old file removed. ---------------------------------------------------------------------- Comment By: Guillermo M. Narvaja (guillon) Date: 2004-10-02 14:50 Message: Logged In: YES user_id=1132014 Fixed some large lines to fit in 78 columns. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1039083&group_id=5470 From noreply at sourceforge.net Sat Oct 2 23:15:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 2 23:15:07 2004 Subject: [Patches] [ python-Patches-1038256 ] Provide tuple of "special" exceptions Message-ID: Patches item #1038256, was opened at 2004-10-01 15:41 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038256&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Provide tuple of "special" exceptions Initial Comment: Add a "special_exceptions" tuple to builtins and exceptions module which lists the exceptions that users should be careful to avoid accidentally suppressing. The current list is SystemExit, MemoryError, KeyboardInterrupt and StopIteration A 'no builtin' version of the patch is supplied which only provides 'exceptions.special_exception', and leaves builtins alone. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-03 07:15 Message: Logged In: YES user_id=1038590 Hmm, how about "terminal_exceptions" and only include SystemExit and KeyboardInterrupt? MWH gave a decent example on py-dev (x = range(sys.maxint)) as to why MemoryError *shouldn't* be included - there are too many cases where a particular excessive request will fail, but subsequent, more sensible, memory requests will succeed. (x = list(somefile.readlines()) would be another example) Looking at StopIteration more closely, I'm inclined to agree with MvL. I can't see any way to trigger it except by calling an iterator's .next() method directly or indirectly. And that generally means one is either in a for loop, or iterating manually looking for StopIteration explicitly. (For what it's worth, the original list of 'special' exceptions was based on my reading of Tim Peter's message to Py-Dev regarding possible restructuring of the exception heirarchy) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-10-02 17:16 Message: Logged In: YES user_id=21627 I don't like the name of the tuple. "special_exceptions" does not indicate in what way they are special; the name should more directly indicate what this is or why one would use it. Also, I'm uncertain about the rationale for picking precisely these exceptions. I agree that one would normally not suppress SystemExit, and usually not KeyboardInterrupt. I'm uncertain about MemoryError, and I can't see why StopIteration would ever occur in a context where exceptions are suppressed. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 16:56 Message: Logged In: YES user_id=1038590 Yes, we are. At the moment, the best way to spell that is: try: myfunc() except special_exceptions: raise except: dealwithit() I think it would be neat to spell that as: try: myfunc() except not special_exceptions: dealwithit() but that would be a helluva lot more work, and needs this tuple anyway :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-01 15:55 Message: Logged In: YES user_id=80475 Aren't we looking for the inverse of that tuple, some way to write: try: myfunc() except non-special exceptions: altfunc() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038256&group_id=5470 From noreply at sourceforge.net Sun Oct 3 00:56:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 3 00:56:25 2004 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 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686545&group_id=5470 Category: Library (Lib) >Group: Python 2.5 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 at sourceforge.net Sun Oct 3 00:56:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 3 00:56:57 2004 Subject: [Patches] [ python-Patches-836088 ] Update htmllib to HTML 4.01 Message-ID: Patches item #836088, was opened at 2003-11-04 16:57 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=836088&group_id=5470 Category: Library (Lib) >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: A.M. Kuchling (akuchling) Summary: Update htmllib to HTML 4.01 Initial Comment: The attached patch adds methods for all of the HTML 4.01 elements and rearranges things a bit. This version is incomplete. Still to do: * Expand test suite to exercise all the methods. * Change documentation to match. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-07 17:53 Message: Logged In: YES user_id=469548 I used the list at http://www.w3.org/TR/html4/index/elements.html to check whether the right functions were used: col, frame, input and param should have do_tag() methods instead of start/end_tag(): they are empty tags in HTML 4.01. dd, dt and li should use start/end_tag() instead of do_tag(). They have an optional end tag in HTML 4.01. Oh, and I couldn't find a method for the 'div' element! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=836088&group_id=5470 From noreply at sourceforge.net Sun Oct 3 00:57:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 3 00:57:37 2004 Subject: [Patches] [ python-Patches-579435 ] Shadow Password Support Module Message-ID: Patches item #579435, was opened at 2002-07-09 23:13 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=579435&group_id=5470 Category: Modules >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Lance Ellinghaus (ellinghaus) Assigned to: A.M. Kuchling (akuchling) Summary: Shadow Password Support Module Initial Comment: Attached is the spwd module. This module provides support for Shadow Passwords on Solaris 2.8. This compliments the nis and pwd modules. This is the only way to gain access to the encrypted passwords when using shadow passwords on Solaris. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-22 12:38 Message: Logged In: YES user_id=21627 If we eventually want to support all the shadow passwort APIs, we should make this a separate module - with that approach, building spwd can might fail without causing a failure to compile pwd. Unfortunately, the patch is still incomplete: there is no change to setup.py, and no documentation change. Are there any volunteers interesting in completing it? If not, I'm going to close it again. Anybody hunting for such a module will still be able to find it. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-01-13 10:32 Message: Logged In: YES user_id=11375 As it happens, I was hunting for Python shadow password support and came across this patch. The module isn't Solaris-specific, and would be necessary on Linux, too. However, the interface for getting shadow passwords doesn't seem to be standardized; see http://www.unixpapa.com/incnote/passwd. html for a list. (The Single Unix spec doesn't seem to mention shadow passwords.) One question is whether we want a new module for this, or if the functions should be in the existing pwd module. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-11 21:22 Message: Logged In: YES user_id=33168 There doesn't seem to be much interest in this patch. I don't think it reaches a wide-enough audience, therefore, I'm rejecting it. If there is broader support (many people are interested in seeing shadow password support in the core), we can add it later. I think it would be best to provide this as a third-party module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=579435&group_id=5470 From noreply at sourceforge.net Sun Oct 3 03:00:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 3 03:01:04 2004 Subject: [Patches] [ python-Patches-1038911 ] OS X: Can't use #!/usr/bin/pythonw Message-ID: Patches item #1038911, was opened at 2004-10-02 02:40 Message generated for change (Comment added) made by n8gray You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038911&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nathan Gray (n8gray) >Assigned to: Jack Jansen (jackjansen) Summary: OS X: Can't use #!/usr/bin/pythonw Initial Comment: At the moment, on OS X /usr/bin/pythonw2.x is a simple sh script that exec's a python interpreter within a valid OS X application bundle. The problem is that this prevents python scripts from using pythonw in the #! line. Darwin won't allow a script to act as an interpreter in a #! line. This patch replaces the shell script with a simple C program that does the same thing -- it just calls execv on the python interpreter within the OS X app bundle. Since it is a compiled executable it is allowed to act as an interpreter in #! lines. Your patch guidelines said you preferred multiple patches to be concatenated in a single file. My patch consists of a Makefile change and a new file, dist/src/Mac/OSX/pythonw.c. I've included both in the text file attached to this report. It would probably be prudent for somebody to review the Makefile change, since it's always tricky to find the right way to put a new file in someone else's build process. Thank you, -Nathan ---------------------------------------------------------------------- >Comment By: Nathan Gray (n8gray) Date: 2004-10-02 18:00 Message: Logged In: YES user_id=121553 Assigning to Jack Jansen as suggested by Bob Ippolito on pythonmac-sig. ---------------------------------------------------------------------- Comment By: Nathan Gray (n8gray) Date: 2004-10-02 02:43 Message: Logged In: YES user_id=121553 By the way, the patch is against CVS head. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038911&group_id=5470 From noreply at sourceforge.net Sun Oct 3 15:45:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 3 15:45:12 2004 Subject: [Patches] [ python-Patches-1035576 ] Add New RPM-friendly record option to setup.py Message-ID: Patches item #1035576, was opened at 2004-09-28 00:33 Message generated for change (Comment added) made by bruthasj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035576&group_id=5470 Category: Distutils and setup.py Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Pitman (bruthasj) Assigned to: Nobody/Anonymous (nobody) Summary: Add New RPM-friendly record option to setup.py Initial Comment: One major weakness of the current usage of INSTALLED_FILES in bdist_rpm leaves directories unlisted thereby causing an uninstall of a package to leave these behind. This patch separates out into another option --record-rpm and function that generates a list friendly for RPM consumption. It currently handles data_dirs and install_lib (everything under site-packages). In addition, languages found under the common LC_MESSAGES sub-directory is also automatically tagged with %lang(de) attribute. Documentation does not need to be handled since RPM already sets this up if the packager uses %doc. I've run a couple of tests with this patch showing good results. Before taking the concept further, I submit it here for your review. ---------------------------------------------------------------------- >Comment By: Jeff Pitman (bruthasj) Date: 2004-10-03 21:45 Message: Logged In: YES user_id=46780 v0.4: fix dists using extra_path; hardcode site-packages instead ---------------------------------------------------------------------- Comment By: Jeff Pitman (bruthasj) Date: 2004-10-02 19:47 Message: Logged In: YES user_id=46780 v0.2: Implement self.root optimization from how it was done before. v0.3: self.distribution.data_files can be None. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035576&group_id=5470 From noreply at sourceforge.net Mon Oct 4 07:43:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 4 07:43:32 2004 Subject: [Patches] [ python-Patches-936813 ] fast modular exponentiation Message-ID: Patches item #936813, was opened at 2004-04-17 01:16 Message generated for change (Comment added) made by trevp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936813&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Trevor Perrin (trevp) Assigned to: Nobody/Anonymous (nobody) Summary: fast modular exponentiation Initial Comment: For crypto-sized numbers, Python mod-exp is several times slower than GMP or OpenSSL (6x or more). Those libraries do crazy special-case stuff, + assembly, platform-specific tuning, and so on. However, there's some low-hanging fruit: this patch has a few basic optimizations giving a 2-3x speedup for numbers in the 1000-8000 bit range (that's what I've mostly tested; but the patch should improve, or at least not hurt, everything else): - x_mul() is special-cased for squaring, which is almost twice as fast as general multiplication. - x_mul() uses pointers instead of indices for iteration, giving ~10% speedup (under VC6). - the right-to-left square-and-multiply exponentiation algorithm is replaced with a left-to-right square-and-multiply, which takes advantage of small bases. - when the exponent is above a certain size, "k-ary" exponentiation is used to reduce the number of multiplications via precalculation. - when the modulus is odd, Montgomery reduction is used. - the Karatsuba cutoff seems too low. For multiplicands in the range of 500-5000 bits, Karatsuba slows multiplication by around ~25% (VC6sp4, Intel P4M 1.7 Ghz). For larger numbers, the benefits of Karatsuba are less than they could be. Currently, the cutoff is 35 digits (525 bits). I've tried 70, 140, 280, and 560. 70, 140, and 280 are roughly the same: they don't slow down small values, and they have good speedup on large ones. 560 is not quite as good for large values, but at least it doesn't hurt small ones. I know this is platform-dependent, but I think we should err on the side of making the cutoff too high and losing some optimization, instead of putting it too low and slowing things down. I suggest 70. A couple misc. things: - Negative exponents with a modulus no longer give an error, when the base is coprime with the modulus. Instead, it calculates the multiplicative inverse of the base with respect to the modulus, using the extended euclidean algorithm, and exponentiates that. Libraries like GMP and LibTomMath work the same way. Being able to take inverses mod a number is useful for cryptography (e.g. RSA, DSA, and Elgamal). - The diff includes patch 923643, which supports converting longs to byte-strings. Ignore the last few diff entries, if you don't want this. - I haven't looked into harmonizing with int_pow(). Something may have to be done. ---------------------------------------------------------------------- >Comment By: Trevor Perrin (trevp) Date: 2004-10-03 22:43 Message: Logged In: YES user_id=973611 I did more code review, testing, and timing. The only change in this new patch (long_mont2.diff) is a couple "int"s were changed to "digits"s, and it's against CVS head. As far as testing, I used the random module and GMPY to check it on ~3 million random input values. That's about an hour of testing. I'll leave the tests running for a few days and see if anything crops up. As far as timing, I updated the benchmarks with a new machine (OpenBSD): http://trevp.net/long_pow/ On 3 different machines, Montgomery gives a speedup of 2x, 3x, and 4x. That dwarfs what we've done so far, so I'm crossing my fingers for 2.4. Let me know if I can explain or improve the code, or anything.. (The below crypto library comes with a "book" which has an explanation of Montgomery I found helpful): http://math.libtomcrypt.org/download.html ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-09-13 01:20 Message: Logged In: YES user_id=973611 Here's the 3rd part of the patch (long_mont.diff; Montgomery Reduction), diff'd against 2.4a3 and cleaned up a bit. Note that this doesn't include negative exponent handling. If this patch is accepted, I'll make a new tracker item for that, since it's not an optimization, just an "opportunistic feature" (it builds on one of the helper functions needed for Montgomery). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-29 19:47 Message: Logged In: YES user_id=31435 Same deal with the 2nd part of the patch (major format changes, minor code changes). Incidentally fixed an old leak bug in long_pow() during the review. Added code to raise a compile-time error (C) if SHIFT isn't divisible by 5, and removed long_pow's new hardcoded assumption that SHIFT is exactly 15. Include/longintrepr.h 2.16 Misc/NEWS 1.1120 Objects/longobject.c 1.163 This is cool stuff (& thank you!), but I'm sorry to say I can't foresee making time for the 3rd part of the patch for weeks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-29 15:21 Message: Logged In: YES user_id=31435 Checked in the first part of the patch, with major format changes (Python's C coding standard is hard 8-column tabs), and minor code changes: Include/longintrepr.h 2.15 Misc/ACKS 1.280 Misc/NEWS 1.1119 Objects/longobject.c 1.162 I don't know whether it's possible for me to get to part 2 of the patch before 2.4a3, but I would like to. It seems plainly impossible that I'll be able to get to part 3 before 2.4a3. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-22 01:39 Message: Logged In: YES user_id=973611 Pragmatics isn't my strong suit... but I get your drift :-). I split it into 3 diffs: 1) x_mul optimizations: (pointers instead of indices, special-case squaring, changing Karatsuba cutoff) 2) rewriting long_pow() for left-to-right 5-ary 3) Montgomery reduction. This also includes l_invmod(), since it's necessary for Montgomery. I've left out the code which exposes l_invmod() to the user (and associated docs, tests, and intobject changes). We could slap that on afterwards or not... Anyways, these are applied sequentially: longobject.c + longobject1.diff = longobject1.c longobject1.c + longobject2.diff = longobject2.c longobject2.c + longobject2.diff = longobject3.c Should I open new tracker items for them? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-21 12:29 Message: Logged In: YES user_id=31435 Pragmatics are a real problem here, Trevor. I don't foresee being able to make a solid block of sufficient hours to give to reviewing this before Python 2.4 is history (which is why I've left this patch unassigned, BTW -- I just can't promise to make enough time). So if nobody else can volunteer to review it, that alone is likely to leave the patch sitting here unapplied. But there are several independent changes in this patch, and it *could* be broken into several smaller patches. I tossed that bait out before, but you didn't bite. You should . ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-19 04:00 Message: Logged In: YES user_id=973611 Tim, thanks for the feedback. I'm uploading a new patch against CVS latest that fixes those issues, and adds docs and tests. Also, I cleaned up the code quite a bit, and got it properly handling (I hope) all the varied combinations of ints/longs, positives/negatives/zeros etc.. Unfortunately, Montgomery is the bulk of the speedup: http://trevp.net/long_pow/ But I could split out the negative exponent handling into a separate patch, if that would be easier. Anyways, I'd like to add more tests for the exponentiation stuff. Aside from that, I think the patch is complete. And more robust than previously, though I still wouldn't trust it until another person or two gives it a serious looking-over.... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-16 20:06 Message: Logged In: YES user_id=31435 Notes after a brief eyeball scan: Note that the expression a & 1 == 1 groups as a & (1 == 1) in C -- comparisons have higher precedence in C than bit- fiddling operators. Stuff like that is usually best resolved by explicitly parenthesizing any "impure" expression fiddling with bits. In this case, in a boolean expression plain a & 1 has the hoped-for effect. and is clearer anyway. Would be better to use "**" than "^" in comments when exponentiation is intended, since "^" means xor in both Python and C. Doc changes are needed, because you're changing visible semantics in some cases. Tests are needed, especially for new semantics. l_invmod can return NULL for more than one reason, but one of its callers ignores this, assuming that all NULL returns are due to lack of coprimality. It's unreasonable to, e.g., replace a MemoryError with a complaint about coprimality; this needs reworking. l_invmod should probably set an exception in the "not coprime" case. As is, it's a weird function, sometimes setting an exception when it returns NULL, but not setting one when coprimality doesn't obtain. That makes life difficult for callers (which isn't apparent in the patch, because its callers are currently ignoring this issue). The Montgomery reduction gimmicks grossly complicate this patch -- they're long-winded and hard to follow. That may come with the territory, but it's the only part of the patch that made me want to vomit . I'd be happier if it weren't there, for aesthetic, clarity, and maintainability reasons. How much of a speedup does it actually buy? You're right that int pow must deliver the same results as long pow, so code is needed for that too. "short int" versus "unbounded int" is increasingly meant to be an invisible internal implementation detail in Python. I'm also in favor of giving this meaning to modular negative exponents, btw, so no problem with that. An easy way would be to change int pow to delegate to long pow when this is needed. Pragmatics: there's a better chance of making 2.4 if the patch were done in bite-size stages. For example, no doc changes are needed to switch to 5-ary left-to-right exponentation, and that has no effect on the int implementation either, etc. A patch that did just that much probably would have gone in a long time ago. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-13 01:04 Message: Logged In: YES user_id=973611 Uploading 2nd version of longobject.diff - the only change is that patch 923643 is removed from this diff. That was a diff for converting longs to byte-strings, which I unnecessarily left in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936813&group_id=5470 From noreply at sourceforge.net Mon Oct 4 09:48:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 4 09:48:42 2004 Subject: [Patches] [ python-Patches-936813 ] fast modular exponentiation Message-ID: Patches item #936813, was opened at 2004-04-17 01:16 Message generated for change (Comment added) made by trevp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936813&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Trevor Perrin (trevp) Assigned to: Nobody/Anonymous (nobody) Summary: fast modular exponentiation Initial Comment: For crypto-sized numbers, Python mod-exp is several times slower than GMP or OpenSSL (6x or more). Those libraries do crazy special-case stuff, + assembly, platform-specific tuning, and so on. However, there's some low-hanging fruit: this patch has a few basic optimizations giving a 2-3x speedup for numbers in the 1000-8000 bit range (that's what I've mostly tested; but the patch should improve, or at least not hurt, everything else): - x_mul() is special-cased for squaring, which is almost twice as fast as general multiplication. - x_mul() uses pointers instead of indices for iteration, giving ~10% speedup (under VC6). - the right-to-left square-and-multiply exponentiation algorithm is replaced with a left-to-right square-and-multiply, which takes advantage of small bases. - when the exponent is above a certain size, "k-ary" exponentiation is used to reduce the number of multiplications via precalculation. - when the modulus is odd, Montgomery reduction is used. - the Karatsuba cutoff seems too low. For multiplicands in the range of 500-5000 bits, Karatsuba slows multiplication by around ~25% (VC6sp4, Intel P4M 1.7 Ghz). For larger numbers, the benefits of Karatsuba are less than they could be. Currently, the cutoff is 35 digits (525 bits). I've tried 70, 140, 280, and 560. 70, 140, and 280 are roughly the same: they don't slow down small values, and they have good speedup on large ones. 560 is not quite as good for large values, but at least it doesn't hurt small ones. I know this is platform-dependent, but I think we should err on the side of making the cutoff too high and losing some optimization, instead of putting it too low and slowing things down. I suggest 70. A couple misc. things: - Negative exponents with a modulus no longer give an error, when the base is coprime with the modulus. Instead, it calculates the multiplicative inverse of the base with respect to the modulus, using the extended euclidean algorithm, and exponentiates that. Libraries like GMP and LibTomMath work the same way. Being able to take inverses mod a number is useful for cryptography (e.g. RSA, DSA, and Elgamal). - The diff includes patch 923643, which supports converting longs to byte-strings. Ignore the last few diff entries, if you don't want this. - I haven't looked into harmonizing with int_pow(). Something may have to be done. ---------------------------------------------------------------------- >Comment By: Trevor Perrin (trevp) Date: 2004-10-04 00:48 Message: Logged In: YES user_id=973611 oops. Good thing for random testing, carry propagation was buggy. Submitting long_mont3.diff. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-10-03 22:43 Message: Logged In: YES user_id=973611 I did more code review, testing, and timing. The only change in this new patch (long_mont2.diff) is a couple "int"s were changed to "digits"s, and it's against CVS head. As far as testing, I used the random module and GMPY to check it on ~3 million random input values. That's about an hour of testing. I'll leave the tests running for a few days and see if anything crops up. As far as timing, I updated the benchmarks with a new machine (OpenBSD): http://trevp.net/long_pow/ On 3 different machines, Montgomery gives a speedup of 2x, 3x, and 4x. That dwarfs what we've done so far, so I'm crossing my fingers for 2.4. Let me know if I can explain or improve the code, or anything.. (The below crypto library comes with a "book" which has an explanation of Montgomery I found helpful): http://math.libtomcrypt.org/download.html ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-09-13 01:20 Message: Logged In: YES user_id=973611 Here's the 3rd part of the patch (long_mont.diff; Montgomery Reduction), diff'd against 2.4a3 and cleaned up a bit. Note that this doesn't include negative exponent handling. If this patch is accepted, I'll make a new tracker item for that, since it's not an optimization, just an "opportunistic feature" (it builds on one of the helper functions needed for Montgomery). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-29 19:47 Message: Logged In: YES user_id=31435 Same deal with the 2nd part of the patch (major format changes, minor code changes). Incidentally fixed an old leak bug in long_pow() during the review. Added code to raise a compile-time error (C) if SHIFT isn't divisible by 5, and removed long_pow's new hardcoded assumption that SHIFT is exactly 15. Include/longintrepr.h 2.16 Misc/NEWS 1.1120 Objects/longobject.c 1.163 This is cool stuff (& thank you!), but I'm sorry to say I can't foresee making time for the 3rd part of the patch for weeks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-29 15:21 Message: Logged In: YES user_id=31435 Checked in the first part of the patch, with major format changes (Python's C coding standard is hard 8-column tabs), and minor code changes: Include/longintrepr.h 2.15 Misc/ACKS 1.280 Misc/NEWS 1.1119 Objects/longobject.c 1.162 I don't know whether it's possible for me to get to part 2 of the patch before 2.4a3, but I would like to. It seems plainly impossible that I'll be able to get to part 3 before 2.4a3. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-22 01:39 Message: Logged In: YES user_id=973611 Pragmatics isn't my strong suit... but I get your drift :-). I split it into 3 diffs: 1) x_mul optimizations: (pointers instead of indices, special-case squaring, changing Karatsuba cutoff) 2) rewriting long_pow() for left-to-right 5-ary 3) Montgomery reduction. This also includes l_invmod(), since it's necessary for Montgomery. I've left out the code which exposes l_invmod() to the user (and associated docs, tests, and intobject changes). We could slap that on afterwards or not... Anyways, these are applied sequentially: longobject.c + longobject1.diff = longobject1.c longobject1.c + longobject2.diff = longobject2.c longobject2.c + longobject2.diff = longobject3.c Should I open new tracker items for them? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-21 12:29 Message: Logged In: YES user_id=31435 Pragmatics are a real problem here, Trevor. I don't foresee being able to make a solid block of sufficient hours to give to reviewing this before Python 2.4 is history (which is why I've left this patch unassigned, BTW -- I just can't promise to make enough time). So if nobody else can volunteer to review it, that alone is likely to leave the patch sitting here unapplied. But there are several independent changes in this patch, and it *could* be broken into several smaller patches. I tossed that bait out before, but you didn't bite. You should . ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-19 04:00 Message: Logged In: YES user_id=973611 Tim, thanks for the feedback. I'm uploading a new patch against CVS latest that fixes those issues, and adds docs and tests. Also, I cleaned up the code quite a bit, and got it properly handling (I hope) all the varied combinations of ints/longs, positives/negatives/zeros etc.. Unfortunately, Montgomery is the bulk of the speedup: http://trevp.net/long_pow/ But I could split out the negative exponent handling into a separate patch, if that would be easier. Anyways, I'd like to add more tests for the exponentiation stuff. Aside from that, I think the patch is complete. And more robust than previously, though I still wouldn't trust it until another person or two gives it a serious looking-over.... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-16 20:06 Message: Logged In: YES user_id=31435 Notes after a brief eyeball scan: Note that the expression a & 1 == 1 groups as a & (1 == 1) in C -- comparisons have higher precedence in C than bit- fiddling operators. Stuff like that is usually best resolved by explicitly parenthesizing any "impure" expression fiddling with bits. In this case, in a boolean expression plain a & 1 has the hoped-for effect. and is clearer anyway. Would be better to use "**" than "^" in comments when exponentiation is intended, since "^" means xor in both Python and C. Doc changes are needed, because you're changing visible semantics in some cases. Tests are needed, especially for new semantics. l_invmod can return NULL for more than one reason, but one of its callers ignores this, assuming that all NULL returns are due to lack of coprimality. It's unreasonable to, e.g., replace a MemoryError with a complaint about coprimality; this needs reworking. l_invmod should probably set an exception in the "not coprime" case. As is, it's a weird function, sometimes setting an exception when it returns NULL, but not setting one when coprimality doesn't obtain. That makes life difficult for callers (which isn't apparent in the patch, because its callers are currently ignoring this issue). The Montgomery reduction gimmicks grossly complicate this patch -- they're long-winded and hard to follow. That may come with the territory, but it's the only part of the patch that made me want to vomit . I'd be happier if it weren't there, for aesthetic, clarity, and maintainability reasons. How much of a speedup does it actually buy? You're right that int pow must deliver the same results as long pow, so code is needed for that too. "short int" versus "unbounded int" is increasingly meant to be an invisible internal implementation detail in Python. I'm also in favor of giving this meaning to modular negative exponents, btw, so no problem with that. An easy way would be to change int pow to delegate to long pow when this is needed. Pragmatics: there's a better chance of making 2.4 if the patch were done in bite-size stages. For example, no doc changes are needed to switch to 5-ary left-to-right exponentation, and that has no effect on the int implementation either, etc. A patch that did just that much probably would have gone in a long time ago. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-13 01:04 Message: Logged In: YES user_id=973611 Uploading 2nd version of longobject.diff - the only change is that patch 923643 is removed from this diff. That was a diff for converting longs to byte-strings, which I unnecessarily left in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936813&group_id=5470 From noreply at sourceforge.net Mon Oct 4 16:34:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 4 17:02:44 2004 Subject: [Patches] [ python-Patches-1038911 ] OS X: Can't use #!/usr/bin/pythonw Message-ID: Patches item #1038911, was opened at 2004-10-02 19:40 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038911&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nathan Gray (n8gray) Assigned to: Jack Jansen (jackjansen) Summary: OS X: Can't use #!/usr/bin/pythonw Initial Comment: At the moment, on OS X /usr/bin/pythonw2.x is a simple sh script that exec's a python interpreter within a valid OS X application bundle. The problem is that this prevents python scripts from using pythonw in the #! line. Darwin won't allow a script to act as an interpreter in a #! line. This patch replaces the shell script with a simple C program that does the same thing -- it just calls execv on the python interpreter within the OS X app bundle. Since it is a compiled executable it is allowed to act as an interpreter in #! lines. Your patch guidelines said you preferred multiple patches to be concatenated in a single file. My patch consists of a Makefile change and a new file, dist/src/Mac/OSX/pythonw.c. I've included both in the text file attached to this report. It would probably be prudent for somebody to review the Makefile change, since it's always tricky to find the right way to put a new file in someone else's build process. Thank you, -Nathan ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 00:34 Message: Logged In: YES user_id=1038590 As described in the python tutorial, the recommended solution to this is to use the following on the shebang line: #! /usr/bin/env pythonw this also has benefit of not caring where python is installed. ---------------------------------------------------------------------- Comment By: Nathan Gray (n8gray) Date: 2004-10-03 11:00 Message: Logged In: YES user_id=121553 Assigning to Jack Jansen as suggested by Bob Ippolito on pythonmac-sig. ---------------------------------------------------------------------- Comment By: Nathan Gray (n8gray) Date: 2004-10-02 19:43 Message: Logged In: YES user_id=121553 By the way, the patch is against CVS head. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038911&group_id=5470 From noreply at sourceforge.net Mon Oct 4 16:30:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 4 17:02:45 2004 Subject: [Patches] [ python-Patches-1035498 ] -m option to run a module as a script Message-ID: Patches item #1035498, was opened at 2004-09-28 00:22 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Barry A. Warsaw (bwarsaw) Summary: -m option to run a module as a script Initial Comment: Implements the '-m' option recently discussed on python-dev. Runs a module 'as if' it had been invoked from the command line. E.g., for a build directory, the following two commands are equivalent: ./python -m pdb ./python Lib/pdb.py Note that neither of these does the same thing as "./python -c "import pdb". (In this latter case, any "if __name__ == "__main__" code would not be executed, whereas it will be invoked in the first two cases). Given the vagaries of sys.path, this is quite handy - if a module can be imported, it can be easily used as a script too. Not that all modules will necessarily do anything _interesting_ when used as a script. . . The current implementation makes changes to main.c (handle the new argument), pythonrun.[ch] (new flavour of PyRun_) and import.[ch] (expose a PyImport_FindModule C API) Current limitations / to-do if this is pursued: - print sensible errors for non-Python files (e.g. hotshot) - allow 'dotted' names - decide what to do with packages (e.g. run __init__.py) - check usage messages in main.c are all still under 512 characters (I assume that limit was set for a reason) - the 1K limit on absolute file paths seems rather arbitrary. - this is code written in the wee hours of the morning, so it probably has a few other lurking 'features'. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 00:30 Message: Logged In: YES user_id=1038590 Relevant documentation locations that I can find: Tutorial section 2.1 (Invoking the Interpreter) Add a very brief description of the '-m' option Python/C API section 2 (The Very High Level Layer) Document PyRun_SimpleModule What's New sections 12 & 13 I'll do this as a separate patch from the previous two, as I can't recall if Andrew prefers to write these himself. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 14:13 Message: Logged In: YES user_id=1038590 New version (#4) Trivial fix - tell PyRun_SimpleFile to close the file when it's done with it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 12:51 Message: Logged In: YES user_id=1038590 New version (run_module_3.diff) Takes more account of the file description reported by PyImport. Explictly restricts itself to PY_SOURCE and PY_COMPILED scripts. Behaves correctly when a non-package is encountered while parsing a dotted name (closes the file descriptor and reports an error). I also realised that the '-m' option doesn't currently comprehend "__path__" variables in packages. So maybe we *should* be loading the packages as we find them, and then querying them for their __path__ variable. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 19:48 Message: Logged In: YES user_id=1038590 Barry, kicking this in your direction solely because you were one of the people to comment on it on py-dev. Feel free to say 'too busy' :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 19:39 Message: Logged In: YES user_id=1038590 New version of patch attached (run_module_2.diff). This version allows modules within packages to be executed. It does this *without* loading the packages first (just as if the script were specified directly on the command line). It's also a little more responsive when it comes to error message, and I've confirmed that the usage message components are now under 512 bytes each. The FindModule method is now marked as private (i.e. with leading underscore). The limit on file paths in pythonrun.c is now taken from osdefs.h (the same limit that import.c already uses) The only bug I know of is that it misbehaves if you supply a name like "a.b.module.d". You will get an ImportError saying that d was not found, and the file pointer for 'module' won't get closed properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 From noreply at sourceforge.net Mon Oct 4 19:48:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 4 19:49:03 2004 Subject: [Patches] [ python-Patches-1035498 ] -m option to run a module as a script Message-ID: Patches item #1035498, was opened at 2004-09-28 00:22 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Barry A. Warsaw (bwarsaw) Summary: -m option to run a module as a script Initial Comment: Implements the '-m' option recently discussed on python-dev. Runs a module 'as if' it had been invoked from the command line. E.g., for a build directory, the following two commands are equivalent: ./python -m pdb ./python Lib/pdb.py Note that neither of these does the same thing as "./python -c "import pdb". (In this latter case, any "if __name__ == "__main__" code would not be executed, whereas it will be invoked in the first two cases). Given the vagaries of sys.path, this is quite handy - if a module can be imported, it can be easily used as a script too. Not that all modules will necessarily do anything _interesting_ when used as a script. . . The current implementation makes changes to main.c (handle the new argument), pythonrun.[ch] (new flavour of PyRun_) and import.[ch] (expose a PyImport_FindModule C API) Current limitations / to-do if this is pursued: - print sensible errors for non-Python files (e.g. hotshot) - allow 'dotted' names - decide what to do with packages (e.g. run __init__.py) - check usage messages in main.c are all still under 512 characters (I assume that limit was set for a reason) - the 1K limit on absolute file paths seems rather arbitrary. - this is code written in the wee hours of the morning, so it probably has a few other lurking 'features'. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 03:48 Message: Logged In: YES user_id=1038590 5th version of patch attached - restricts option to top-level modules only. The correct semantics for a module inside a package just aren't clear enough at this stage. Support for dotted names can be added later if this patch gets accepted, and it still seems like a good idea. - adds a missing check from main.c (if we got the module option, don't try to open the file). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 00:30 Message: Logged In: YES user_id=1038590 Relevant documentation locations that I can find: Tutorial section 2.1 (Invoking the Interpreter) Add a very brief description of the '-m' option Python/C API section 2 (The Very High Level Layer) Document PyRun_SimpleModule What's New sections 12 & 13 I'll do this as a separate patch from the previous two, as I can't recall if Andrew prefers to write these himself. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 14:13 Message: Logged In: YES user_id=1038590 New version (#4) Trivial fix - tell PyRun_SimpleFile to close the file when it's done with it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 12:51 Message: Logged In: YES user_id=1038590 New version (run_module_3.diff) Takes more account of the file description reported by PyImport. Explictly restricts itself to PY_SOURCE and PY_COMPILED scripts. Behaves correctly when a non-package is encountered while parsing a dotted name (closes the file descriptor and reports an error). I also realised that the '-m' option doesn't currently comprehend "__path__" variables in packages. So maybe we *should* be loading the packages as we find them, and then querying them for their __path__ variable. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 19:48 Message: Logged In: YES user_id=1038590 Barry, kicking this in your direction solely because you were one of the people to comment on it on py-dev. Feel free to say 'too busy' :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 19:39 Message: Logged In: YES user_id=1038590 New version of patch attached (run_module_2.diff). This version allows modules within packages to be executed. It does this *without* loading the packages first (just as if the script were specified directly on the command line). It's also a little more responsive when it comes to error message, and I've confirmed that the usage message components are now under 512 bytes each. The FindModule method is now marked as private (i.e. with leading underscore). The limit on file paths in pythonrun.c is now taken from osdefs.h (the same limit that import.c already uses) The only bug I know of is that it misbehaves if you supply a name like "a.b.module.d". You will get an ImportError saying that d was not found, and the file pointer for 'module' won't get closed properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 From noreply at sourceforge.net Mon Oct 4 22:16:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 4 22:16:55 2004 Subject: [Patches] [ python-Patches-1038911 ] OS X: Can't use #!/usr/bin/pythonw Message-ID: Patches item #1038911, was opened at 2004-10-02 02:40 Message generated for change (Comment added) made by n8gray You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038911&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nathan Gray (n8gray) Assigned to: Jack Jansen (jackjansen) Summary: OS X: Can't use #!/usr/bin/pythonw Initial Comment: At the moment, on OS X /usr/bin/pythonw2.x is a simple sh script that exec's a python interpreter within a valid OS X application bundle. The problem is that this prevents python scripts from using pythonw in the #! line. Darwin won't allow a script to act as an interpreter in a #! line. This patch replaces the shell script with a simple C program that does the same thing -- it just calls execv on the python interpreter within the OS X app bundle. Since it is a compiled executable it is allowed to act as an interpreter in #! lines. Your patch guidelines said you preferred multiple patches to be concatenated in a single file. My patch consists of a Makefile change and a new file, dist/src/Mac/OSX/pythonw.c. I've included both in the text file attached to this report. It would probably be prudent for somebody to review the Makefile change, since it's always tricky to find the right way to put a new file in someone else's build process. Thank you, -Nathan ---------------------------------------------------------------------- >Comment By: Nathan Gray (n8gray) Date: 2004-10-04 13:16 Message: Logged In: YES user_id=121553 The issue is that sometimes you *do* care where python is installed, and you want to be sure to get the system python and not, for example, the Fink python. At the moment, the only solution is to use a gangly #! line like: #! /System/Library/Frameworks/Python.framework/Resources/ Python.app/Contents/MacOS/Python and you'll only figure that out if you're clever enough to understand why #!/usr/bin/python works but #!/usr/bin/pythonw doesn't. Mainly, it's just needlessly confusing to have a python interpreter that works from the command line but doesn't work in a #! line. It's unfortunate that the distinction between python and pythonw is necessary, but as long as it is then it would be nice if at least pythonw was able to act as a drop-in replacement for python. It's pretty simple to make it work as expected, so why not do it, for the sake of consistency? ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 07:34 Message: Logged In: YES user_id=1038590 As described in the python tutorial, the recommended solution to this is to use the following on the shebang line: #! /usr/bin/env pythonw this also has benefit of not caring where python is installed. ---------------------------------------------------------------------- Comment By: Nathan Gray (n8gray) Date: 2004-10-02 18:00 Message: Logged In: YES user_id=121553 Assigning to Jack Jansen as suggested by Bob Ippolito on pythonmac-sig. ---------------------------------------------------------------------- Comment By: Nathan Gray (n8gray) Date: 2004-10-02 02:43 Message: Logged In: YES user_id=121553 By the way, the patch is against CVS head. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038911&group_id=5470 From noreply at sourceforge.net Mon Oct 4 20:21:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 4 23:04:56 2004 Subject: [Patches] [ python-Patches-1035498 ] -m option to run a module as a script Message-ID: Patches item #1035498, was opened at 2004-09-28 00:22 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Barry A. Warsaw (bwarsaw) Summary: -m option to run a module as a script Initial Comment: Implements the '-m' option recently discussed on python-dev. Runs a module 'as if' it had been invoked from the command line. E.g., for a build directory, the following two commands are equivalent: ./python -m pdb ./python Lib/pdb.py Note that neither of these does the same thing as "./python -c "import pdb". (In this latter case, any "if __name__ == "__main__" code would not be executed, whereas it will be invoked in the first two cases). Given the vagaries of sys.path, this is quite handy - if a module can be imported, it can be easily used as a script too. Not that all modules will necessarily do anything _interesting_ when used as a script. . . The current implementation makes changes to main.c (handle the new argument), pythonrun.[ch] (new flavour of PyRun_) and import.[ch] (expose a PyImport_FindModule C API) Current limitations / to-do if this is pursued: - print sensible errors for non-Python files (e.g. hotshot) - allow 'dotted' names - decide what to do with packages (e.g. run __init__.py) - check usage messages in main.c are all still under 512 characters (I assume that limit was set for a reason) - the 1K limit on absolute file paths seems rather arbitrary. - this is code written in the wee hours of the morning, so it probably has a few other lurking 'features'. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 04:21 Message: Logged In: YES user_id=1038590 Doc patch attached. Take it with a grain of salt, since this is the first real doc patch I've made. This doesn't cover anything for 'What's New' - that can wait until the patch gets accepted (if it does). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 03:48 Message: Logged In: YES user_id=1038590 5th version of patch attached - restricts option to top-level modules only. The correct semantics for a module inside a package just aren't clear enough at this stage. Support for dotted names can be added later if this patch gets accepted, and it still seems like a good idea. - adds a missing check from main.c (if we got the module option, don't try to open the file). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 00:30 Message: Logged In: YES user_id=1038590 Relevant documentation locations that I can find: Tutorial section 2.1 (Invoking the Interpreter) Add a very brief description of the '-m' option Python/C API section 2 (The Very High Level Layer) Document PyRun_SimpleModule What's New sections 12 & 13 I'll do this as a separate patch from the previous two, as I can't recall if Andrew prefers to write these himself. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 14:13 Message: Logged In: YES user_id=1038590 New version (#4) Trivial fix - tell PyRun_SimpleFile to close the file when it's done with it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 12:51 Message: Logged In: YES user_id=1038590 New version (run_module_3.diff) Takes more account of the file description reported by PyImport. Explictly restricts itself to PY_SOURCE and PY_COMPILED scripts. Behaves correctly when a non-package is encountered while parsing a dotted name (closes the file descriptor and reports an error). I also realised that the '-m' option doesn't currently comprehend "__path__" variables in packages. So maybe we *should* be loading the packages as we find them, and then querying them for their __path__ variable. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 19:48 Message: Logged In: YES user_id=1038590 Barry, kicking this in your direction solely because you were one of the people to comment on it on py-dev. Feel free to say 'too busy' :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 19:39 Message: Logged In: YES user_id=1038590 New version of patch attached (run_module_2.diff). This version allows modules within packages to be executed. It does this *without* loading the packages first (just as if the script were specified directly on the command line). It's also a little more responsive when it comes to error message, and I've confirmed that the usage message components are now under 512 bytes each. The FindModule method is now marked as private (i.e. with leading underscore). The limit on file paths in pythonrun.c is now taken from osdefs.h (the same limit that import.c already uses) The only bug I know of is that it misbehaves if you supply a name like "a.b.module.d". You will get an ImportError saying that d was not found, and the file pointer for 'module' won't get closed properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 From noreply at sourceforge.net Mon Oct 4 22:04:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 4 23:06:50 2004 Subject: [Patches] [ python-Patches-1034053 ] unittest.py patch: add skipped test functionality Message-ID: Patches item #1034053, was opened at 2004-09-24 16:08 Message generated for change (Comment added) made by remyblank You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Remy Blank (remyblank) Assigned to: Steve Purcell (purcell) Summary: unittest.py patch: add skipped test functionality Initial Comment: I added the possibility for tests using the unittest.py framework to be skipped. Basically, I added two methods to TestCase: TestCase.skip(msg): skips test unconditionally TestCase.skipIf(expr, msg): skips test if expr is true These can be called either in setUp() or in the test methods. I also added reporting of skipped tests to TestResult, _TextTestResult and TextTestRunner. If no tests are skipped, everything should be the same as before. I am using Python 2.3.3, so the changes are against the file in that version. I can generate a patch for a more recent version if desired. I attached the patch against the original (unittest_skip.patch). I can provide a complete test suite for the new functionality and a usage example program. Quick usage example: class ReadShadowTest(unittest.TestCase): """Read access to /etc/shadow""" def testReadingAsRoot(self): """Reading /etc/shadow as root""" self.skipIf(os.geteuid() != 0, "Must be root") open("/etc/shadow").close() The example program produces the following output: $ ./SkippedTestDemo.py -v Access to autoexec.bat ... SKIPPED (Only available on Windows) Access to config.sys ... SKIPPED (Only available on Windows) Reading /etc/shadow as root ... SKIPPED (Must be root) Reading /etc/shadow as non-root ... ok ------------------------------------------------------- --------------- Ran 4 tests in 0.004s OK (skipped=3) ---------------------------------------------------------------------- >Comment By: Remy Blank (remyblank) Date: 2004-10-04 22:04 Message: Logged In: YES user_id=568100 I have just run the unit tests from Zope 2.7.2 (2358 tests) on Python 2.3.3, first with the original unittest.py, then with the patch. There was no difference in output, except for the total duration. That may give a hint about backward compatibility. ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2004-09-30 16:20 Message: Logged In: YES user_id=21477 Yes, that's right, and I would consider providing a number of such decorators at a later date. I've just spent a little time chatting to my colleage Joe Walnes (of nMock fame) about all this; he's more of an nUnit authority than I am. Categories are particularly interesting. In theory, it would be possible to get the same effect using TestSuites, but in practice tool support (including unittest.main()) discourages the use of TestSuites in favour of magic discovery of test cases; categories would be a better way of allowing tools to dynamically construct suites. @ignore could be considered equivalent to @category("ignored") in a certain sense. Skipping is not quite the same as ignoring, since it's determined at run-time, and so I think it is appropriate to add methods to explicitly support it. Interesting times indeed. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-30 15:46 Message: Logged In: YES user_id=568100 Speaking of decorators, the NUnit example is quite instructive, re. their use of attributes to mark classes as test cases, methods as test methods, grouping tests by category, and for that matter ignoring tests temporarily. I expect all of this can be done with decorators: @testMethod to mark individual tests, @category("LongRunning"), @ignore, @explicit, ... And if I'm not mistaken all of this can be added without breaking backward compatibility. Interesting times lay ahead! ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2004-09-30 13:31 Message: Logged In: YES user_id=21477 I've been really tied up; sorry for the delayed response, but I've been reading all the comments on this patch. Overall, I'm leaning in favour of accepting this patch, probably with some minor changes to the way skipped tests are reported. The concept of skipping is one that has been kept out of JUnit, but is found in NUnit and is well regarded there. In my XP coaching work ThoughtWorks I see an obscenely large number of JUnit tests, and a common mistake is to comment out test method bodies, leading to "false passes". Explicit support for skipping in unittest would mitigate this. I agree with Remy that the decorator example, though ingenious, has the wrong result; skipped tests will be reported as successes. In order for a test method to decide if it should be skipped, it will often need information from 'self' that was gathered during setUp() -- this makes decorators cumbersome for this. Also, a decorator solution would not allow test methods to skip if the setUp() method itself decides to skip(). Please give me a few more days on this, and I'll work on integrating and tweaking the patch. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-30 11:37 Message: Logged In: YES user_id=568100 I strongly disagree. Skipped tests should not just be transformed into passed tests, but must be recorded as skipped and reported to the user. Knowing that a test skipped is important information. The Python regression tests (although I'm not familiar with them) provide the same "skip" functionality, and I don't think people would be happy to replace it with just "pass". The decorator approach is an interesting idea, though, and could be combined with skipIf() so as to provide the other advantages you mention, namely single definition and appearance prior to definition. Something along the following: def rootOnly(f): """Decorator to skip tests that require root access""" def wrapper(self): self.skipIf(os.getuid() != 0, "Must be root") self.f() wrapper.__doc__ = f.__doc__ return wrapper class ReadShadowTest(unittest.TestCase): """Read access to /etc/shadow""" @rootOnly def testReadingAsRoot(self): """Reading /etc/shadow as root""" open("/etc/shadow").close() Note that I'm not yet familiar with decorators, so the wrapper() function might not be the correct way to do this. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-30 10:04 Message: Logged In: YES user_id=80475 After more thought, I think decorators offer a cleaner, more complete solution without further complicating the unittest module. def rootonly(f): "Decorator to skip tests that require root access" if os.geteuid() == 0: return f return lambda self: 0 @rootonly def testReadingAsRoot(self): . . . Note the rootonly() decorator need only be defined once instead of writing a full self.skipIf(condition) inside every test. Also, it appears prior to the definition rather than inside. The approach is more flexible than the original proposal though it does lack a reporting mechanism. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-29 08:36 Message: Logged In: YES user_id=1038590 I'd certainly find such a feature handy - when testing different variations of an embedded firmware image, it would make it much easier to enable/disable different tests based on the capabilities of the firmware. Ditto for the original example of cross-platform testing. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-26 12:13 Message: Logged In: YES user_id=80475 The skipIf() method is sufficient. From there, it is trivial to roll your own resource check. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2004-09-26 11:10 Message: Logged In: YES user_id=9205 This is a nice patch. I am wondering if it can be extended to support the resource idea used in the python regression tests. That is the user has a --resource option to give a list of available resources and a test only runs if its requested resources are available. Otherwise it will be skipped. Example: TestDemo.py --resource=network --resource=audio ... would supply the network and audio resource. Or does it make more sense to put this in a separate patch? ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 12:54 Message: Logged In: YES user_id=568100 Added sample code. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 12:53 Message: Logged In: YES user_id=568100 The test suite for the added functionality. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 12:51 Message: Logged In: YES user_id=568100 I don't think so. Basically, the patch changes the following: - Adds a class SkippedException to the unittest module - Adds a skipped attribute to TestResult, containing the list of skipped tests, and an addSkipped() method to add to the list. - Catches the SkippedException in TestCase.__call__() - Adds skip() and skipIf() to TestCase - Modifies _TextTestResult and TextTestRunner to report skipped tests *only if there are any* I see two potential problems: - Test runners based on (or using the output of) TextTestRunner. I've taken care that the output is unchanged if there are no skipped tests. - Code that uses repr() of a TestResult, as I extended it to always report skipped tests. I think this would be bad practice anyway. However, to use the test-skipping functionality, custom test runners will obviously need to be extended to report skipped tests. OTOH, I don't have a big test codebase to check. I read that e.g. Zope is using unittest. Maybe I can try to run their test suite with the patched unittest.py. I'll check. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-25 10:18 Message: Logged In: YES user_id=80475 Will this muck up some the existing test runners that people have written? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 From noreply at sourceforge.net Tue Oct 5 01:05:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 5 01:05:42 2004 Subject: [Patches] [ python-Patches-1035498 ] -m option to run a module as a script Message-ID: Patches item #1035498, was opened at 2004-09-28 00:22 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) >Assigned to: Raymond Hettinger (rhettinger) Summary: -m option to run a module as a script Initial Comment: Implements the '-m' option recently discussed on python-dev. Runs a module 'as if' it had been invoked from the command line. E.g., for a build directory, the following two commands are equivalent: ./python -m pdb ./python Lib/pdb.py Note that neither of these does the same thing as "./python -c "import pdb". (In this latter case, any "if __name__ == "__main__" code would not be executed, whereas it will be invoked in the first two cases). Given the vagaries of sys.path, this is quite handy - if a module can be imported, it can be easily used as a script too. Not that all modules will necessarily do anything _interesting_ when used as a script. . . The current implementation makes changes to main.c (handle the new argument), pythonrun.[ch] (new flavour of PyRun_) and import.[ch] (expose a PyImport_FindModule C API) Current limitations / to-do if this is pursued: - print sensible errors for non-Python files (e.g. hotshot) - allow 'dotted' names - decide what to do with packages (e.g. run __init__.py) - check usage messages in main.c are all still under 512 characters (I assume that limit was set for a reason) - the 1K limit on absolute file paths seems rather arbitrary. - this is code written in the wee hours of the morning, so it probably has a few other lurking 'features'. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 09:05 Message: Logged In: YES user_id=1038590 Raymond, Passing to you to see what you think of the code, rather than just the feature in the abstract. Guido settled for not vetoing it, but the discussion with him allowed me to articulate why I think this is a worthwhile feature. (Details at http://mail.python.org/pipermail/python-dev/2004-October/049236.html) Extension to allow packages and zip imports can wait until there is any demand for either feature. I don't really expect to see any, since I think the main uses will be "python -m pdb", "python -m profile" and "python -m timeit". ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 04:21 Message: Logged In: YES user_id=1038590 Doc patch attached. Take it with a grain of salt, since this is the first real doc patch I've made. This doesn't cover anything for 'What's New' - that can wait until the patch gets accepted (if it does). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 03:48 Message: Logged In: YES user_id=1038590 5th version of patch attached - restricts option to top-level modules only. The correct semantics for a module inside a package just aren't clear enough at this stage. Support for dotted names can be added later if this patch gets accepted, and it still seems like a good idea. - adds a missing check from main.c (if we got the module option, don't try to open the file). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 00:30 Message: Logged In: YES user_id=1038590 Relevant documentation locations that I can find: Tutorial section 2.1 (Invoking the Interpreter) Add a very brief description of the '-m' option Python/C API section 2 (The Very High Level Layer) Document PyRun_SimpleModule What's New sections 12 & 13 I'll do this as a separate patch from the previous two, as I can't recall if Andrew prefers to write these himself. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 14:13 Message: Logged In: YES user_id=1038590 New version (#4) Trivial fix - tell PyRun_SimpleFile to close the file when it's done with it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 12:51 Message: Logged In: YES user_id=1038590 New version (run_module_3.diff) Takes more account of the file description reported by PyImport. Explictly restricts itself to PY_SOURCE and PY_COMPILED scripts. Behaves correctly when a non-package is encountered while parsing a dotted name (closes the file descriptor and reports an error). I also realised that the '-m' option doesn't currently comprehend "__path__" variables in packages. So maybe we *should* be loading the packages as we find them, and then querying them for their __path__ variable. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 19:48 Message: Logged In: YES user_id=1038590 Barry, kicking this in your direction solely because you were one of the people to comment on it on py-dev. Feel free to say 'too busy' :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 19:39 Message: Logged In: YES user_id=1038590 New version of patch attached (run_module_2.diff). This version allows modules within packages to be executed. It does this *without* loading the packages first (just as if the script were specified directly on the command line). It's also a little more responsive when it comes to error message, and I've confirmed that the usage message components are now under 512 bytes each. The FindModule method is now marked as private (i.e. with leading underscore). The limit on file paths in pythonrun.c is now taken from osdefs.h (the same limit that import.c already uses) The only bug I know of is that it misbehaves if you supply a name like "a.b.module.d". You will get an ImportError saying that d was not found, and the file pointer for 'module' won't get closed properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 From noreply at sourceforge.net Tue Oct 5 06:32:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 5 06:32:16 2004 Subject: [Patches] [ python-Patches-1035498 ] -m option to run a module as a script Message-ID: Patches item #1035498, was opened at 2004-09-27 09:22 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) >Assigned to: Armin Rigo (arigo) Summary: -m option to run a module as a script Initial Comment: Implements the '-m' option recently discussed on python-dev. Runs a module 'as if' it had been invoked from the command line. E.g., for a build directory, the following two commands are equivalent: ./python -m pdb ./python Lib/pdb.py Note that neither of these does the same thing as "./python -c "import pdb". (In this latter case, any "if __name__ == "__main__" code would not be executed, whereas it will be invoked in the first two cases). Given the vagaries of sys.path, this is quite handy - if a module can be imported, it can be easily used as a script too. Not that all modules will necessarily do anything _interesting_ when used as a script. . . The current implementation makes changes to main.c (handle the new argument), pythonrun.[ch] (new flavour of PyRun_) and import.[ch] (expose a PyImport_FindModule C API) Current limitations / to-do if this is pursued: - print sensible errors for non-Python files (e.g. hotshot) - allow 'dotted' names - decide what to do with packages (e.g. run __init__.py) - check usage messages in main.c are all still under 512 characters (I assume that limit was set for a reason) - the 1K limit on absolute file paths seems rather arbitrary. - this is code written in the wee hours of the morning, so it probably has a few other lurking 'features'. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-04 23:32 Message: Logged In: YES user_id=80475 Armin, do you have time for this one. I'm buried for a few days. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 18:05 Message: Logged In: YES user_id=1038590 Raymond, Passing to you to see what you think of the code, rather than just the feature in the abstract. Guido settled for not vetoing it, but the discussion with him allowed me to articulate why I think this is a worthwhile feature. (Details at http://mail.python.org/pipermail/python-dev/2004-October/049236.html) Extension to allow packages and zip imports can wait until there is any demand for either feature. I don't really expect to see any, since I think the main uses will be "python -m pdb", "python -m profile" and "python -m timeit". ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 13:21 Message: Logged In: YES user_id=1038590 Doc patch attached. Take it with a grain of salt, since this is the first real doc patch I've made. This doesn't cover anything for 'What's New' - that can wait until the patch gets accepted (if it does). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 12:48 Message: Logged In: YES user_id=1038590 5th version of patch attached - restricts option to top-level modules only. The correct semantics for a module inside a package just aren't clear enough at this stage. Support for dotted names can be added later if this patch gets accepted, and it still seems like a good idea. - adds a missing check from main.c (if we got the module option, don't try to open the file). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 09:30 Message: Logged In: YES user_id=1038590 Relevant documentation locations that I can find: Tutorial section 2.1 (Invoking the Interpreter) Add a very brief description of the '-m' option Python/C API section 2 (The Very High Level Layer) Document PyRun_SimpleModule What's New sections 12 & 13 I'll do this as a separate patch from the previous two, as I can't recall if Andrew prefers to write these himself. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 23:13 Message: Logged In: YES user_id=1038590 New version (#4) Trivial fix - tell PyRun_SimpleFile to close the file when it's done with it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 21:51 Message: Logged In: YES user_id=1038590 New version (run_module_3.diff) Takes more account of the file description reported by PyImport. Explictly restricts itself to PY_SOURCE and PY_COMPILED scripts. Behaves correctly when a non-package is encountered while parsing a dotted name (closes the file descriptor and reports an error). I also realised that the '-m' option doesn't currently comprehend "__path__" variables in packages. So maybe we *should* be loading the packages as we find them, and then querying them for their __path__ variable. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 04:48 Message: Logged In: YES user_id=1038590 Barry, kicking this in your direction solely because you were one of the people to comment on it on py-dev. Feel free to say 'too busy' :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 04:39 Message: Logged In: YES user_id=1038590 New version of patch attached (run_module_2.diff). This version allows modules within packages to be executed. It does this *without* loading the packages first (just as if the script were specified directly on the command line). It's also a little more responsive when it comes to error message, and I've confirmed that the usage message components are now under 512 bytes each. The FindModule method is now marked as private (i.e. with leading underscore). The limit on file paths in pythonrun.c is now taken from osdefs.h (the same limit that import.c already uses) The only bug I know of is that it misbehaves if you supply a name like "a.b.module.d". You will get an ImportError saying that d was not found, and the file pointer for 'module' won't get closed properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 From noreply at sourceforge.net Tue Oct 5 09:25:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 5 09:25:11 2004 Subject: [Patches] [ python-Patches-936813 ] fast modular exponentiation Message-ID: Patches item #936813, was opened at 2004-04-17 01:16 Message generated for change (Comment added) made by trevp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936813&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Trevor Perrin (trevp) Assigned to: Nobody/Anonymous (nobody) Summary: fast modular exponentiation Initial Comment: For crypto-sized numbers, Python mod-exp is several times slower than GMP or OpenSSL (6x or more). Those libraries do crazy special-case stuff, + assembly, platform-specific tuning, and so on. However, there's some low-hanging fruit: this patch has a few basic optimizations giving a 2-3x speedup for numbers in the 1000-8000 bit range (that's what I've mostly tested; but the patch should improve, or at least not hurt, everything else): - x_mul() is special-cased for squaring, which is almost twice as fast as general multiplication. - x_mul() uses pointers instead of indices for iteration, giving ~10% speedup (under VC6). - the right-to-left square-and-multiply exponentiation algorithm is replaced with a left-to-right square-and-multiply, which takes advantage of small bases. - when the exponent is above a certain size, "k-ary" exponentiation is used to reduce the number of multiplications via precalculation. - when the modulus is odd, Montgomery reduction is used. - the Karatsuba cutoff seems too low. For multiplicands in the range of 500-5000 bits, Karatsuba slows multiplication by around ~25% (VC6sp4, Intel P4M 1.7 Ghz). For larger numbers, the benefits of Karatsuba are less than they could be. Currently, the cutoff is 35 digits (525 bits). I've tried 70, 140, 280, and 560. 70, 140, and 280 are roughly the same: they don't slow down small values, and they have good speedup on large ones. 560 is not quite as good for large values, but at least it doesn't hurt small ones. I know this is platform-dependent, but I think we should err on the side of making the cutoff too high and losing some optimization, instead of putting it too low and slowing things down. I suggest 70. A couple misc. things: - Negative exponents with a modulus no longer give an error, when the base is coprime with the modulus. Instead, it calculates the multiplicative inverse of the base with respect to the modulus, using the extended euclidean algorithm, and exponentiates that. Libraries like GMP and LibTomMath work the same way. Being able to take inverses mod a number is useful for cryptography (e.g. RSA, DSA, and Elgamal). - The diff includes patch 923643, which supports converting longs to byte-strings. Ignore the last few diff entries, if you don't want this. - I haven't looked into harmonizing with int_pow(). Something may have to be done. ---------------------------------------------------------------------- >Comment By: Trevor Perrin (trevp) Date: 2004-10-05 00:25 Message: Logged In: YES user_id=973611 Montgomery has a fixed cost, so it slows down small exponents. For example modular squaring is slowed ~5x. I added a MONTGOMERY_CUTOFF to take care of this. Submitting long_mont4.diff. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-10-04 00:48 Message: Logged In: YES user_id=973611 oops. Good thing for random testing, carry propagation was buggy. Submitting long_mont3.diff. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-10-03 22:43 Message: Logged In: YES user_id=973611 I did more code review, testing, and timing. The only change in this new patch (long_mont2.diff) is a couple "int"s were changed to "digits"s, and it's against CVS head. As far as testing, I used the random module and GMPY to check it on ~3 million random input values. That's about an hour of testing. I'll leave the tests running for a few days and see if anything crops up. As far as timing, I updated the benchmarks with a new machine (OpenBSD): http://trevp.net/long_pow/ On 3 different machines, Montgomery gives a speedup of 2x, 3x, and 4x. That dwarfs what we've done so far, so I'm crossing my fingers for 2.4. Let me know if I can explain or improve the code, or anything.. (The below crypto library comes with a "book" which has an explanation of Montgomery I found helpful): http://math.libtomcrypt.org/download.html ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-09-13 01:20 Message: Logged In: YES user_id=973611 Here's the 3rd part of the patch (long_mont.diff; Montgomery Reduction), diff'd against 2.4a3 and cleaned up a bit. Note that this doesn't include negative exponent handling. If this patch is accepted, I'll make a new tracker item for that, since it's not an optimization, just an "opportunistic feature" (it builds on one of the helper functions needed for Montgomery). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-29 19:47 Message: Logged In: YES user_id=31435 Same deal with the 2nd part of the patch (major format changes, minor code changes). Incidentally fixed an old leak bug in long_pow() during the review. Added code to raise a compile-time error (C) if SHIFT isn't divisible by 5, and removed long_pow's new hardcoded assumption that SHIFT is exactly 15. Include/longintrepr.h 2.16 Misc/NEWS 1.1120 Objects/longobject.c 1.163 This is cool stuff (& thank you!), but I'm sorry to say I can't foresee making time for the 3rd part of the patch for weeks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-29 15:21 Message: Logged In: YES user_id=31435 Checked in the first part of the patch, with major format changes (Python's C coding standard is hard 8-column tabs), and minor code changes: Include/longintrepr.h 2.15 Misc/ACKS 1.280 Misc/NEWS 1.1119 Objects/longobject.c 1.162 I don't know whether it's possible for me to get to part 2 of the patch before 2.4a3, but I would like to. It seems plainly impossible that I'll be able to get to part 3 before 2.4a3. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-22 01:39 Message: Logged In: YES user_id=973611 Pragmatics isn't my strong suit... but I get your drift :-). I split it into 3 diffs: 1) x_mul optimizations: (pointers instead of indices, special-case squaring, changing Karatsuba cutoff) 2) rewriting long_pow() for left-to-right 5-ary 3) Montgomery reduction. This also includes l_invmod(), since it's necessary for Montgomery. I've left out the code which exposes l_invmod() to the user (and associated docs, tests, and intobject changes). We could slap that on afterwards or not... Anyways, these are applied sequentially: longobject.c + longobject1.diff = longobject1.c longobject1.c + longobject2.diff = longobject2.c longobject2.c + longobject2.diff = longobject3.c Should I open new tracker items for them? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-21 12:29 Message: Logged In: YES user_id=31435 Pragmatics are a real problem here, Trevor. I don't foresee being able to make a solid block of sufficient hours to give to reviewing this before Python 2.4 is history (which is why I've left this patch unassigned, BTW -- I just can't promise to make enough time). So if nobody else can volunteer to review it, that alone is likely to leave the patch sitting here unapplied. But there are several independent changes in this patch, and it *could* be broken into several smaller patches. I tossed that bait out before, but you didn't bite. You should . ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-19 04:00 Message: Logged In: YES user_id=973611 Tim, thanks for the feedback. I'm uploading a new patch against CVS latest that fixes those issues, and adds docs and tests. Also, I cleaned up the code quite a bit, and got it properly handling (I hope) all the varied combinations of ints/longs, positives/negatives/zeros etc.. Unfortunately, Montgomery is the bulk of the speedup: http://trevp.net/long_pow/ But I could split out the negative exponent handling into a separate patch, if that would be easier. Anyways, I'd like to add more tests for the exponentiation stuff. Aside from that, I think the patch is complete. And more robust than previously, though I still wouldn't trust it until another person or two gives it a serious looking-over.... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-16 20:06 Message: Logged In: YES user_id=31435 Notes after a brief eyeball scan: Note that the expression a & 1 == 1 groups as a & (1 == 1) in C -- comparisons have higher precedence in C than bit- fiddling operators. Stuff like that is usually best resolved by explicitly parenthesizing any "impure" expression fiddling with bits. In this case, in a boolean expression plain a & 1 has the hoped-for effect. and is clearer anyway. Would be better to use "**" than "^" in comments when exponentiation is intended, since "^" means xor in both Python and C. Doc changes are needed, because you're changing visible semantics in some cases. Tests are needed, especially for new semantics. l_invmod can return NULL for more than one reason, but one of its callers ignores this, assuming that all NULL returns are due to lack of coprimality. It's unreasonable to, e.g., replace a MemoryError with a complaint about coprimality; this needs reworking. l_invmod should probably set an exception in the "not coprime" case. As is, it's a weird function, sometimes setting an exception when it returns NULL, but not setting one when coprimality doesn't obtain. That makes life difficult for callers (which isn't apparent in the patch, because its callers are currently ignoring this issue). The Montgomery reduction gimmicks grossly complicate this patch -- they're long-winded and hard to follow. That may come with the territory, but it's the only part of the patch that made me want to vomit . I'd be happier if it weren't there, for aesthetic, clarity, and maintainability reasons. How much of a speedup does it actually buy? You're right that int pow must deliver the same results as long pow, so code is needed for that too. "short int" versus "unbounded int" is increasingly meant to be an invisible internal implementation detail in Python. I'm also in favor of giving this meaning to modular negative exponents, btw, so no problem with that. An easy way would be to change int pow to delegate to long pow when this is needed. Pragmatics: there's a better chance of making 2.4 if the patch were done in bite-size stages. For example, no doc changes are needed to switch to 5-ary left-to-right exponentation, and that has no effect on the int implementation either, etc. A patch that did just that much probably would have gone in a long time ago. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-13 01:04 Message: Logged In: YES user_id=973611 Uploading 2nd version of longobject.diff - the only change is that patch 923643 is removed from this diff. That was a diff for converting longs to byte-strings, which I unnecessarily left in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936813&group_id=5470 From noreply at sourceforge.net Tue Oct 5 15:15:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 5 15:15:53 2004 Subject: [Patches] [ python-Patches-1035498 ] -m option to run a module as a script Message-ID: Patches item #1035498, was opened at 2004-09-27 14:22 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) >Assigned to: Nobody/Anonymous (nobody) Summary: -m option to run a module as a script Initial Comment: Implements the '-m' option recently discussed on python-dev. Runs a module 'as if' it had been invoked from the command line. E.g., for a build directory, the following two commands are equivalent: ./python -m pdb ./python Lib/pdb.py Note that neither of these does the same thing as "./python -c "import pdb". (In this latter case, any "if __name__ == "__main__" code would not be executed, whereas it will be invoked in the first two cases). Given the vagaries of sys.path, this is quite handy - if a module can be imported, it can be easily used as a script too. Not that all modules will necessarily do anything _interesting_ when used as a script. . . The current implementation makes changes to main.c (handle the new argument), pythonrun.[ch] (new flavour of PyRun_) and import.[ch] (expose a PyImport_FindModule C API) Current limitations / to-do if this is pursued: - print sensible errors for non-Python files (e.g. hotshot) - allow 'dotted' names - decide what to do with packages (e.g. run __init__.py) - check usage messages in main.c are all still under 512 characters (I assume that limit was set for a reason) - the 1K limit on absolute file paths seems rather arbitrary. - this is code written in the wee hours of the morning, so it probably has a few other lurking 'features'. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-10-05 13:15 Message: Logged In: YES user_id=4771 Sorry, I didn't follow any of this discussion, neither here nor in python-dev, so I cannot really comment. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-05 04:32 Message: Logged In: YES user_id=80475 Armin, do you have time for this one. I'm buried for a few days. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 23:05 Message: Logged In: YES user_id=1038590 Raymond, Passing to you to see what you think of the code, rather than just the feature in the abstract. Guido settled for not vetoing it, but the discussion with him allowed me to articulate why I think this is a worthwhile feature. (Details at http://mail.python.org/pipermail/python-dev/2004-October/049236.html) Extension to allow packages and zip imports can wait until there is any demand for either feature. I don't really expect to see any, since I think the main uses will be "python -m pdb", "python -m profile" and "python -m timeit". ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 18:21 Message: Logged In: YES user_id=1038590 Doc patch attached. Take it with a grain of salt, since this is the first real doc patch I've made. This doesn't cover anything for 'What's New' - that can wait until the patch gets accepted (if it does). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 17:48 Message: Logged In: YES user_id=1038590 5th version of patch attached - restricts option to top-level modules only. The correct semantics for a module inside a package just aren't clear enough at this stage. Support for dotted names can be added later if this patch gets accepted, and it still seems like a good idea. - adds a missing check from main.c (if we got the module option, don't try to open the file). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 14:30 Message: Logged In: YES user_id=1038590 Relevant documentation locations that I can find: Tutorial section 2.1 (Invoking the Interpreter) Add a very brief description of the '-m' option Python/C API section 2 (The Very High Level Layer) Document PyRun_SimpleModule What's New sections 12 & 13 I'll do this as a separate patch from the previous two, as I can't recall if Andrew prefers to write these himself. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 04:13 Message: Logged In: YES user_id=1038590 New version (#4) Trivial fix - tell PyRun_SimpleFile to close the file when it's done with it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 02:51 Message: Logged In: YES user_id=1038590 New version (run_module_3.diff) Takes more account of the file description reported by PyImport. Explictly restricts itself to PY_SOURCE and PY_COMPILED scripts. Behaves correctly when a non-package is encountered while parsing a dotted name (closes the file descriptor and reports an error). I also realised that the '-m' option doesn't currently comprehend "__path__" variables in packages. So maybe we *should* be loading the packages as we find them, and then querying them for their __path__ variable. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 09:48 Message: Logged In: YES user_id=1038590 Barry, kicking this in your direction solely because you were one of the people to comment on it on py-dev. Feel free to say 'too busy' :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 09:39 Message: Logged In: YES user_id=1038590 New version of patch attached (run_module_2.diff). This version allows modules within packages to be executed. It does this *without* loading the packages first (just as if the script were specified directly on the command line). It's also a little more responsive when it comes to error message, and I've confirmed that the usage message components are now under 512 bytes each. The FindModule method is now marked as private (i.e. with leading underscore). The limit on file paths in pythonrun.c is now taken from osdefs.h (the same limit that import.c already uses) The only bug I know of is that it misbehaves if you supply a name like "a.b.module.d". You will get an ImportError saying that d was not found, and the file pointer for 'module' won't get closed properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 From noreply at sourceforge.net Tue Oct 5 15:20:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 5 15:20:17 2004 Subject: [Patches] [ python-Patches-658407 ] email: minimal header encoding Message-ID: Patches item #658407, was opened at 2002-12-25 16:47 Message generated for change (Settings changed) made by hatukanezumi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658407&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open >Resolution: Out of Date Priority: 5 Submitted By: Hatuka*nezumi (hatukanezumi) Assigned to: Nobody/Anonymous (nobody) Summary: email: minimal header encoding Initial Comment: Most implementations using 'B' header encoding (e.g. for ISO-2022-JP) encode 'minimal' portions of header value and do not encode US-ASCII portions as much as possible. This patch does this. Current version (2.4.3) of email.Header module encodes whole of header value. Though this feature is MIME-compliant, especially with 'B' encoding, causes some difficulty. For example: Subject prefix of mailing list postings are usually written in ASCII characters -- GL part of its charset. Encoded form of subject prefix is not only human-readable but also some search, header-rewrite etc. capabilities are forced to implement preprocessing for decoding. ---------------------------------------------------------------------- Comment By: Hatuka*nezumi (hatukanezumi) Date: 2002-12-25 16:50 Message: Logged In: YES user_id=529503 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=658407&group_id=5470 From noreply at sourceforge.net Tue Oct 5 15:31:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 5 15:32:02 2004 Subject: [Patches] [ python-Patches-1038854 ] Fix struct.pack on 64-bit archs (broken on 2.*) Message-ID: Patches item #1038854, was opened at 2004-10-02 05:07 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038854&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Grundmann (sgatwasetde) Assigned to: Nobody/Anonymous (nobody) Summary: Fix struct.pack on 64-bit archs (broken on 2.*) Initial Comment: Description: The code in the struct module assumes that sizeof(long) == sizeof(int) which is wrong on (most) 64-bit architectures (linux on amd64 with a 32-bit userland is an exception). How To Repeat: on a 32-bit platform struct.pack behaves as expected: $ uname -m -r -s FreeBSD 4.10-STABLE i386 $ python -c "import struct; print repr(struct.pack('I', 4294967296))" Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert on a 64-bit platform it treats integers as longs (it does not check for over/underflows and returns the lower 4 byte): $ uname -m -r -s FreeBSD 5.2-CURRENT sparc64 $ python -c "import struct; print repr(struct.pack('I', 4294967296))" '\x00\x00\x00\x00' Fix: in python/python/dist/src/Modules/structmodule.c: np_uint() and np_int() have to check for over/underflows using MAX_UINT, MAX_INT, MIN_INT as np_ushort() and np_short() already do for MAX_USHORT, ... the attached patch does this (diff was generated using diff -rNu and Revision 2.62 of python/python/dist/src/Modules/structmodule.c) ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-10-05 13:31 Message: Logged In: YES user_id=4771 At a first glance, it appears that there is the same problem in bp_int/bp_uint and lp_int/lp_unit. Can you check that pack('I',...) fail to detect the overflow in the same way? If so, can you also provide the patch for these 4 other routines? Finally, it would be nice to add a test case in Lib/test/test_struct.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038854&group_id=5470 From noreply at sourceforge.net Wed Oct 6 08:31:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 6 08:31:48 2004 Subject: [Patches] [ python-Patches-1038854 ] Fix struct.pack on 64-bit archs (broken on 2.*) Message-ID: Patches item #1038854, was opened at 2004-10-02 07:07 Message generated for change (Comment added) made by sgatwasetde You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038854&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Grundmann (sgatwasetde) Assigned to: Nobody/Anonymous (nobody) Summary: Fix struct.pack on 64-bit archs (broken on 2.*) Initial Comment: Description: The code in the struct module assumes that sizeof(long) == sizeof(int) which is wrong on (most) 64-bit architectures (linux on amd64 with a 32-bit userland is an exception). How To Repeat: on a 32-bit platform struct.pack behaves as expected: $ uname -m -r -s FreeBSD 4.10-STABLE i386 $ python -c "import struct; print repr(struct.pack('I', 4294967296))" Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert on a 64-bit platform it treats integers as longs (it does not check for over/underflows and returns the lower 4 byte): $ uname -m -r -s FreeBSD 5.2-CURRENT sparc64 $ python -c "import struct; print repr(struct.pack('I', 4294967296))" '\x00\x00\x00\x00' Fix: in python/python/dist/src/Modules/structmodule.c: np_uint() and np_int() have to check for over/underflows using MAX_UINT, MAX_INT, MIN_INT as np_ushort() and np_short() already do for MAX_USHORT, ... the attached patch does this (diff was generated using diff -rNu and Revision 2.62 of python/python/dist/src/Modules/structmodule.c) ---------------------------------------------------------------------- >Comment By: Stefan Grundmann (sgatwasetde) Date: 2004-10-06 08:31 Message: Logged In: YES user_id=1131807 I removed the attached patch since it only handles overflows for np_int/np_uint. bp_int/bp_uint and lp_int/lp_unit have different issues (no overflow checking at all, unneccessary loops - that will not be optimized by the compiler). I'm working on a new patch that fixes these problems (and the rest of BUGGY_RANGE_CHECK ;) ). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-10-05 15:31 Message: Logged In: YES user_id=4771 At a first glance, it appears that there is the same problem in bp_int/bp_uint and lp_int/lp_unit. Can you check that pack('I',...) fail to detect the overflow in the same way? If so, can you also provide the patch for these 4 other routines? Finally, it would be nice to add a test case in Lib/test/test_struct.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038854&group_id=5470 From noreply at sourceforge.net Wed Oct 6 12:49:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 6 12:49:47 2004 Subject: [Patches] [ python-Patches-1037516 ] ftplib PASV error bug Message-ID: Patches item #1037516, was opened at 2004-09-30 15:35 Message generated for change (Comment added) made by spiv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1037516&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Nelson (wayland) Assigned to: Nobody/Anonymous (nobody) Summary: ftplib PASV error bug Initial Comment: Hi. If ftplib gets an error while doing the PASV section of the ntransfercmd it dies. I've altered it so that ntransfercmd does an autodetect, if an autodetect hasn't been done yet. If there are any problems (as I'm not a python programmer :) ), please either fix them or let me know. ---------------------------------------------------------------------- Comment By: Andrew Bennetts (spiv) Date: 2004-10-06 20:49 Message: Logged In: YES user_id=50945 Did you mean to submit a patch with this bug report? It sounds like you did, but there's no files attached to this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1037516&group_id=5470 From noreply at sourceforge.net Wed Oct 6 12:58:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 6 12:58:27 2004 Subject: [Patches] [ python-Patches-1035498 ] -m option to run a module as a script Message-ID: Patches item #1035498, was opened at 2004-09-27 09:22 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: -m option to run a module as a script Initial Comment: Implements the '-m' option recently discussed on python-dev. Runs a module 'as if' it had been invoked from the command line. E.g., for a build directory, the following two commands are equivalent: ./python -m pdb ./python Lib/pdb.py Note that neither of these does the same thing as "./python -c "import pdb". (In this latter case, any "if __name__ == "__main__" code would not be executed, whereas it will be invoked in the first two cases). Given the vagaries of sys.path, this is quite handy - if a module can be imported, it can be easily used as a script too. Not that all modules will necessarily do anything _interesting_ when used as a script. . . The current implementation makes changes to main.c (handle the new argument), pythonrun.[ch] (new flavour of PyRun_) and import.[ch] (expose a PyImport_FindModule C API) Current limitations / to-do if this is pursued: - print sensible errors for non-Python files (e.g. hotshot) - allow 'dotted' names - decide what to do with packages (e.g. run __init__.py) - check usage messages in main.c are all still under 512 characters (I assume that limit was set for a reason) - the 1K limit on absolute file paths seems rather arbitrary. - this is code written in the wee hours of the morning, so it probably has a few other lurking 'features'. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-06 05:58 Message: Logged In: YES user_id=80475 The patch does not compile on windows. AFAICT, importdl.h is the culprit because it loads windows.h for a second time resulting a double redinition of BYTE deep in the bowls of include files. Wish I had time to help you on this one, but I don't. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-10-05 08:15 Message: Logged In: YES user_id=4771 Sorry, I didn't follow any of this discussion, neither here nor in python-dev, so I cannot really comment. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-04 23:32 Message: Logged In: YES user_id=80475 Armin, do you have time for this one. I'm buried for a few days. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 18:05 Message: Logged In: YES user_id=1038590 Raymond, Passing to you to see what you think of the code, rather than just the feature in the abstract. Guido settled for not vetoing it, but the discussion with him allowed me to articulate why I think this is a worthwhile feature. (Details at http://mail.python.org/pipermail/python-dev/2004-October/049236.html) Extension to allow packages and zip imports can wait until there is any demand for either feature. I don't really expect to see any, since I think the main uses will be "python -m pdb", "python -m profile" and "python -m timeit". ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 13:21 Message: Logged In: YES user_id=1038590 Doc patch attached. Take it with a grain of salt, since this is the first real doc patch I've made. This doesn't cover anything for 'What's New' - that can wait until the patch gets accepted (if it does). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 12:48 Message: Logged In: YES user_id=1038590 5th version of patch attached - restricts option to top-level modules only. The correct semantics for a module inside a package just aren't clear enough at this stage. Support for dotted names can be added later if this patch gets accepted, and it still seems like a good idea. - adds a missing check from main.c (if we got the module option, don't try to open the file). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 09:30 Message: Logged In: YES user_id=1038590 Relevant documentation locations that I can find: Tutorial section 2.1 (Invoking the Interpreter) Add a very brief description of the '-m' option Python/C API section 2 (The Very High Level Layer) Document PyRun_SimpleModule What's New sections 12 & 13 I'll do this as a separate patch from the previous two, as I can't recall if Andrew prefers to write these himself. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 23:13 Message: Logged In: YES user_id=1038590 New version (#4) Trivial fix - tell PyRun_SimpleFile to close the file when it's done with it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 21:51 Message: Logged In: YES user_id=1038590 New version (run_module_3.diff) Takes more account of the file description reported by PyImport. Explictly restricts itself to PY_SOURCE and PY_COMPILED scripts. Behaves correctly when a non-package is encountered while parsing a dotted name (closes the file descriptor and reports an error). I also realised that the '-m' option doesn't currently comprehend "__path__" variables in packages. So maybe we *should* be loading the packages as we find them, and then querying them for their __path__ variable. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 04:48 Message: Logged In: YES user_id=1038590 Barry, kicking this in your direction solely because you were one of the people to comment on it on py-dev. Feel free to say 'too busy' :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 04:39 Message: Logged In: YES user_id=1038590 New version of patch attached (run_module_2.diff). This version allows modules within packages to be executed. It does this *without* loading the packages first (just as if the script were specified directly on the command line). It's also a little more responsive when it comes to error message, and I've confirmed that the usage message components are now under 512 bytes each. The FindModule method is now marked as private (i.e. with leading underscore). The limit on file paths in pythonrun.c is now taken from osdefs.h (the same limit that import.c already uses) The only bug I know of is that it misbehaves if you supply a name like "a.b.module.d". You will get an ImportError saying that d was not found, and the file pointer for 'module' won't get closed properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 From noreply at sourceforge.net Wed Oct 6 13:22:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 6 13:22:26 2004 Subject: [Patches] [ python-Patches-1041364 ] True/False instead of 1/0 in libstdtypes.tex Message-ID: Patches item #1041364, was opened at 2004-10-06 13:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1041364&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: True/False instead of 1/0 in libstdtypes.tex Initial Comment: The attached patch changes 1/0 into True/False in section 2.3.6 Sequence Types. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1041364&group_id=5470 From noreply at sourceforge.net Wed Oct 6 17:07:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 6 17:07:40 2004 Subject: [Patches] [ python-Patches-1035498 ] -m option to run a module as a script Message-ID: Patches item #1035498, was opened at 2004-09-28 00:22 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: -m option to run a module as a script Initial Comment: Implements the '-m' option recently discussed on python-dev. Runs a module 'as if' it had been invoked from the command line. E.g., for a build directory, the following two commands are equivalent: ./python -m pdb ./python Lib/pdb.py Note that neither of these does the same thing as "./python -c "import pdb". (In this latter case, any "if __name__ == "__main__" code would not be executed, whereas it will be invoked in the first two cases). Given the vagaries of sys.path, this is quite handy - if a module can be imported, it can be easily used as a script too. Not that all modules will necessarily do anything _interesting_ when used as a script. . . The current implementation makes changes to main.c (handle the new argument), pythonrun.[ch] (new flavour of PyRun_) and import.[ch] (expose a PyImport_FindModule C API) Current limitations / to-do if this is pursued: - print sensible errors for non-Python files (e.g. hotshot) - allow 'dotted' names - decide what to do with packages (e.g. run __init__.py) - check usage messages in main.c are all still under 512 characters (I assume that limit was set for a reason) - the 1K limit on absolute file paths seems rather arbitrary. - this is code written in the wee hours of the morning, so it probably has a few other lurking 'features'. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-07 01:07 Message: Logged In: YES user_id=1038590 New version attached which should fix the Windows compile bug (pythonrun.c does the right thing by undefining BYTE before including windows.h - the inclusion of 'importdl.h' has been moved to be after that 'fixed' include). Unfortunately, I won't get access to a Windows build machine until after the beta 1 deadline, or I'd check it myself :( ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-06 20:58 Message: Logged In: YES user_id=80475 The patch does not compile on windows. AFAICT, importdl.h is the culprit because it loads windows.h for a second time resulting a double redinition of BYTE deep in the bowls of include files. Wish I had time to help you on this one, but I don't. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-10-05 23:15 Message: Logged In: YES user_id=4771 Sorry, I didn't follow any of this discussion, neither here nor in python-dev, so I cannot really comment. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-05 14:32 Message: Logged In: YES user_id=80475 Armin, do you have time for this one. I'm buried for a few days. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 09:05 Message: Logged In: YES user_id=1038590 Raymond, Passing to you to see what you think of the code, rather than just the feature in the abstract. Guido settled for not vetoing it, but the discussion with him allowed me to articulate why I think this is a worthwhile feature. (Details at http://mail.python.org/pipermail/python-dev/2004-October/049236.html) Extension to allow packages and zip imports can wait until there is any demand for either feature. I don't really expect to see any, since I think the main uses will be "python -m pdb", "python -m profile" and "python -m timeit". ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 04:21 Message: Logged In: YES user_id=1038590 Doc patch attached. Take it with a grain of salt, since this is the first real doc patch I've made. This doesn't cover anything for 'What's New' - that can wait until the patch gets accepted (if it does). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 03:48 Message: Logged In: YES user_id=1038590 5th version of patch attached - restricts option to top-level modules only. The correct semantics for a module inside a package just aren't clear enough at this stage. Support for dotted names can be added later if this patch gets accepted, and it still seems like a good idea. - adds a missing check from main.c (if we got the module option, don't try to open the file). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 00:30 Message: Logged In: YES user_id=1038590 Relevant documentation locations that I can find: Tutorial section 2.1 (Invoking the Interpreter) Add a very brief description of the '-m' option Python/C API section 2 (The Very High Level Layer) Document PyRun_SimpleModule What's New sections 12 & 13 I'll do this as a separate patch from the previous two, as I can't recall if Andrew prefers to write these himself. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 14:13 Message: Logged In: YES user_id=1038590 New version (#4) Trivial fix - tell PyRun_SimpleFile to close the file when it's done with it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 12:51 Message: Logged In: YES user_id=1038590 New version (run_module_3.diff) Takes more account of the file description reported by PyImport. Explictly restricts itself to PY_SOURCE and PY_COMPILED scripts. Behaves correctly when a non-package is encountered while parsing a dotted name (closes the file descriptor and reports an error). I also realised that the '-m' option doesn't currently comprehend "__path__" variables in packages. So maybe we *should* be loading the packages as we find them, and then querying them for their __path__ variable. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 19:48 Message: Logged In: YES user_id=1038590 Barry, kicking this in your direction solely because you were one of the people to comment on it on py-dev. Feel free to say 'too busy' :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 19:39 Message: Logged In: YES user_id=1038590 New version of patch attached (run_module_2.diff). This version allows modules within packages to be executed. It does this *without* loading the packages first (just as if the script were specified directly on the command line). It's also a little more responsive when it comes to error message, and I've confirmed that the usage message components are now under 512 bytes each. The FindModule method is now marked as private (i.e. with leading underscore). The limit on file paths in pythonrun.c is now taken from osdefs.h (the same limit that import.c already uses) The only bug I know of is that it misbehaves if you supply a name like "a.b.module.d". You will get an ImportError saying that d was not found, and the file pointer for 'module' won't get closed properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 From noreply at sourceforge.net Wed Oct 6 20:09:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 6 20:09:33 2004 Subject: [Patches] [ python-Patches-1035498 ] -m option to run a module as a script Message-ID: Patches item #1035498, was opened at 2004-09-27 09:22 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: -m option to run a module as a script Initial Comment: Implements the '-m' option recently discussed on python-dev. Runs a module 'as if' it had been invoked from the command line. E.g., for a build directory, the following two commands are equivalent: ./python -m pdb ./python Lib/pdb.py Note that neither of these does the same thing as "./python -c "import pdb". (In this latter case, any "if __name__ == "__main__" code would not be executed, whereas it will be invoked in the first two cases). Given the vagaries of sys.path, this is quite handy - if a module can be imported, it can be easily used as a script too. Not that all modules will necessarily do anything _interesting_ when used as a script. . . The current implementation makes changes to main.c (handle the new argument), pythonrun.[ch] (new flavour of PyRun_) and import.[ch] (expose a PyImport_FindModule C API) Current limitations / to-do if this is pursued: - print sensible errors for non-Python files (e.g. hotshot) - allow 'dotted' names - decide what to do with packages (e.g. run __init__.py) - check usage messages in main.c are all still under 512 characters (I assume that limit was set for a reason) - the 1K limit on absolute file paths seems rather arbitrary. - this is code written in the wee hours of the morning, so it probably has a few other lurking 'features'. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-06 13:09 Message: Logged In: YES user_id=80475 Put the test directory in PYTHONPATH and run the following to see if you get the same results: python -tt -m regrtest -u network python -tt lib\test\regrtest.py -u network ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-06 10:07 Message: Logged In: YES user_id=1038590 New version attached which should fix the Windows compile bug (pythonrun.c does the right thing by undefining BYTE before including windows.h - the inclusion of 'importdl.h' has been moved to be after that 'fixed' include). Unfortunately, I won't get access to a Windows build machine until after the beta 1 deadline, or I'd check it myself :( ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-06 05:58 Message: Logged In: YES user_id=80475 The patch does not compile on windows. AFAICT, importdl.h is the culprit because it loads windows.h for a second time resulting a double redinition of BYTE deep in the bowls of include files. Wish I had time to help you on this one, but I don't. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-10-05 08:15 Message: Logged In: YES user_id=4771 Sorry, I didn't follow any of this discussion, neither here nor in python-dev, so I cannot really comment. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-04 23:32 Message: Logged In: YES user_id=80475 Armin, do you have time for this one. I'm buried for a few days. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 18:05 Message: Logged In: YES user_id=1038590 Raymond, Passing to you to see what you think of the code, rather than just the feature in the abstract. Guido settled for not vetoing it, but the discussion with him allowed me to articulate why I think this is a worthwhile feature. (Details at http://mail.python.org/pipermail/python-dev/2004-October/049236.html) Extension to allow packages and zip imports can wait until there is any demand for either feature. I don't really expect to see any, since I think the main uses will be "python -m pdb", "python -m profile" and "python -m timeit". ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 13:21 Message: Logged In: YES user_id=1038590 Doc patch attached. Take it with a grain of salt, since this is the first real doc patch I've made. This doesn't cover anything for 'What's New' - that can wait until the patch gets accepted (if it does). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 12:48 Message: Logged In: YES user_id=1038590 5th version of patch attached - restricts option to top-level modules only. The correct semantics for a module inside a package just aren't clear enough at this stage. Support for dotted names can be added later if this patch gets accepted, and it still seems like a good idea. - adds a missing check from main.c (if we got the module option, don't try to open the file). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 09:30 Message: Logged In: YES user_id=1038590 Relevant documentation locations that I can find: Tutorial section 2.1 (Invoking the Interpreter) Add a very brief description of the '-m' option Python/C API section 2 (The Very High Level Layer) Document PyRun_SimpleModule What's New sections 12 & 13 I'll do this as a separate patch from the previous two, as I can't recall if Andrew prefers to write these himself. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 23:13 Message: Logged In: YES user_id=1038590 New version (#4) Trivial fix - tell PyRun_SimpleFile to close the file when it's done with it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 21:51 Message: Logged In: YES user_id=1038590 New version (run_module_3.diff) Takes more account of the file description reported by PyImport. Explictly restricts itself to PY_SOURCE and PY_COMPILED scripts. Behaves correctly when a non-package is encountered while parsing a dotted name (closes the file descriptor and reports an error). I also realised that the '-m' option doesn't currently comprehend "__path__" variables in packages. So maybe we *should* be loading the packages as we find them, and then querying them for their __path__ variable. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 04:48 Message: Logged In: YES user_id=1038590 Barry, kicking this in your direction solely because you were one of the people to comment on it on py-dev. Feel free to say 'too busy' :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 04:39 Message: Logged In: YES user_id=1038590 New version of patch attached (run_module_2.diff). This version allows modules within packages to be executed. It does this *without* loading the packages first (just as if the script were specified directly on the command line). It's also a little more responsive when it comes to error message, and I've confirmed that the usage message components are now under 512 bytes each. The FindModule method is now marked as private (i.e. with leading underscore). The limit on file paths in pythonrun.c is now taken from osdefs.h (the same limit that import.c already uses) The only bug I know of is that it misbehaves if you supply a name like "a.b.module.d". You will get an ImportError saying that d was not found, and the file pointer for 'module' won't get closed properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 From noreply at sourceforge.net Wed Oct 6 20:56:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 6 20:56:56 2004 Subject: [Patches] [ python-Patches-1035498 ] -m option to run a module as a script Message-ID: Patches item #1035498, was opened at 2004-09-28 00:22 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: -m option to run a module as a script Initial Comment: Implements the '-m' option recently discussed on python-dev. Runs a module 'as if' it had been invoked from the command line. E.g., for a build directory, the following two commands are equivalent: ./python -m pdb ./python Lib/pdb.py Note that neither of these does the same thing as "./python -c "import pdb". (In this latter case, any "if __name__ == "__main__" code would not be executed, whereas it will be invoked in the first two cases). Given the vagaries of sys.path, this is quite handy - if a module can be imported, it can be easily used as a script too. Not that all modules will necessarily do anything _interesting_ when used as a script. . . The current implementation makes changes to main.c (handle the new argument), pythonrun.[ch] (new flavour of PyRun_) and import.[ch] (expose a PyImport_FindModule C API) Current limitations / to-do if this is pursued: - print sensible errors for non-Python files (e.g. hotshot) - allow 'dotted' names - decide what to do with packages (e.g. run __init__.py) - check usage messages in main.c are all still under 512 characters (I assume that limit was set for a reason) - the 1K limit on absolute file paths seems rather arbitrary. - this is code written in the wee hours of the morning, so it probably has a few other lurking 'features'. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-07 04:56 Message: Logged In: YES user_id=1038590 Nice catch. . . I figured out what the problem is - regrtest.py uses sys.argv[0] to delete it's own directory from sys.path. And -m currently sets sys.argv[0] to just 'regrtest', instead of the full path to the module. Obviously, that is going to have to change. Either PyRun_SImpleModule will have to do it, or I'll get rid of that function all together, and put the 'module-finding' logic directly in main.c. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-07 04:09 Message: Logged In: YES user_id=80475 Put the test directory in PYTHONPATH and run the following to see if you get the same results: python -tt -m regrtest -u network python -tt lib\test\regrtest.py -u network ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-07 01:07 Message: Logged In: YES user_id=1038590 New version attached which should fix the Windows compile bug (pythonrun.c does the right thing by undefining BYTE before including windows.h - the inclusion of 'importdl.h' has been moved to be after that 'fixed' include). Unfortunately, I won't get access to a Windows build machine until after the beta 1 deadline, or I'd check it myself :( ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-06 20:58 Message: Logged In: YES user_id=80475 The patch does not compile on windows. AFAICT, importdl.h is the culprit because it loads windows.h for a second time resulting a double redinition of BYTE deep in the bowls of include files. Wish I had time to help you on this one, but I don't. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-10-05 23:15 Message: Logged In: YES user_id=4771 Sorry, I didn't follow any of this discussion, neither here nor in python-dev, so I cannot really comment. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-05 14:32 Message: Logged In: YES user_id=80475 Armin, do you have time for this one. I'm buried for a few days. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 09:05 Message: Logged In: YES user_id=1038590 Raymond, Passing to you to see what you think of the code, rather than just the feature in the abstract. Guido settled for not vetoing it, but the discussion with him allowed me to articulate why I think this is a worthwhile feature. (Details at http://mail.python.org/pipermail/python-dev/2004-October/049236.html) Extension to allow packages and zip imports can wait until there is any demand for either feature. I don't really expect to see any, since I think the main uses will be "python -m pdb", "python -m profile" and "python -m timeit". ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 04:21 Message: Logged In: YES user_id=1038590 Doc patch attached. Take it with a grain of salt, since this is the first real doc patch I've made. This doesn't cover anything for 'What's New' - that can wait until the patch gets accepted (if it does). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 03:48 Message: Logged In: YES user_id=1038590 5th version of patch attached - restricts option to top-level modules only. The correct semantics for a module inside a package just aren't clear enough at this stage. Support for dotted names can be added later if this patch gets accepted, and it still seems like a good idea. - adds a missing check from main.c (if we got the module option, don't try to open the file). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 00:30 Message: Logged In: YES user_id=1038590 Relevant documentation locations that I can find: Tutorial section 2.1 (Invoking the Interpreter) Add a very brief description of the '-m' option Python/C API section 2 (The Very High Level Layer) Document PyRun_SimpleModule What's New sections 12 & 13 I'll do this as a separate patch from the previous two, as I can't recall if Andrew prefers to write these himself. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 14:13 Message: Logged In: YES user_id=1038590 New version (#4) Trivial fix - tell PyRun_SimpleFile to close the file when it's done with it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 12:51 Message: Logged In: YES user_id=1038590 New version (run_module_3.diff) Takes more account of the file description reported by PyImport. Explictly restricts itself to PY_SOURCE and PY_COMPILED scripts. Behaves correctly when a non-package is encountered while parsing a dotted name (closes the file descriptor and reports an error). I also realised that the '-m' option doesn't currently comprehend "__path__" variables in packages. So maybe we *should* be loading the packages as we find them, and then querying them for their __path__ variable. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 19:48 Message: Logged In: YES user_id=1038590 Barry, kicking this in your direction solely because you were one of the people to comment on it on py-dev. Feel free to say 'too busy' :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 19:39 Message: Logged In: YES user_id=1038590 New version of patch attached (run_module_2.diff). This version allows modules within packages to be executed. It does this *without* loading the packages first (just as if the script were specified directly on the command line). It's also a little more responsive when it comes to error message, and I've confirmed that the usage message components are now under 512 bytes each. The FindModule method is now marked as private (i.e. with leading underscore). The limit on file paths in pythonrun.c is now taken from osdefs.h (the same limit that import.c already uses) The only bug I know of is that it misbehaves if you supply a name like "a.b.module.d". You will get an ImportError saying that d was not found, and the file pointer for 'module' won't get closed properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 From noreply at sourceforge.net Wed Oct 6 23:32:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 6 23:32:10 2004 Subject: [Patches] [ python-Patches-1035498 ] -m option to run a module as a script Message-ID: Patches item #1035498, was opened at 2004-09-28 00:22 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: -m option to run a module as a script Initial Comment: Implements the '-m' option recently discussed on python-dev. Runs a module 'as if' it had been invoked from the command line. E.g., for a build directory, the following two commands are equivalent: ./python -m pdb ./python Lib/pdb.py Note that neither of these does the same thing as "./python -c "import pdb". (In this latter case, any "if __name__ == "__main__" code would not be executed, whereas it will be invoked in the first two cases). Given the vagaries of sys.path, this is quite handy - if a module can be imported, it can be easily used as a script too. Not that all modules will necessarily do anything _interesting_ when used as a script. . . The current implementation makes changes to main.c (handle the new argument), pythonrun.[ch] (new flavour of PyRun_) and import.[ch] (expose a PyImport_FindModule C API) Current limitations / to-do if this is pursued: - print sensible errors for non-Python files (e.g. hotshot) - allow 'dotted' names - decide what to do with packages (e.g. run __init__.py) - check usage messages in main.c are all still under 512 characters (I assume that limit was set for a reason) - the 1K limit on absolute file paths seems rather arbitrary. - this is code written in the wee hours of the morning, so it probably has a few other lurking 'features'. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-07 07:32 Message: Logged In: YES user_id=1038590 New version (7) attached which does the right thing for "python -tt -m regrtest -u network". (I really like that test case btw - very concise) This one sets argv[0] correctly, but was initially a little ungraceful in some failure modes (such as "python -m parser"). I had to add a new private API function to import.h (_PyImport_IsScript) to clean that up. Examples of the error handling in this version: [...@localhost src]$ ./python -m foo ./python: module foo not found [...@localhost src]$ ./python -m sys ./python: module sys has no associated file [...@localhost src]$ ./python -m parser ./python: module parser not usable as script (/home/.../dev/python/dist/src/build/lib.linux-i686-2.4/parser.so) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-07 04:56 Message: Logged In: YES user_id=1038590 Nice catch. . . I figured out what the problem is - regrtest.py uses sys.argv[0] to delete it's own directory from sys.path. And -m currently sets sys.argv[0] to just 'regrtest', instead of the full path to the module. Obviously, that is going to have to change. Either PyRun_SImpleModule will have to do it, or I'll get rid of that function all together, and put the 'module-finding' logic directly in main.c. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-07 04:09 Message: Logged In: YES user_id=80475 Put the test directory in PYTHONPATH and run the following to see if you get the same results: python -tt -m regrtest -u network python -tt lib\test\regrtest.py -u network ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-07 01:07 Message: Logged In: YES user_id=1038590 New version attached which should fix the Windows compile bug (pythonrun.c does the right thing by undefining BYTE before including windows.h - the inclusion of 'importdl.h' has been moved to be after that 'fixed' include). Unfortunately, I won't get access to a Windows build machine until after the beta 1 deadline, or I'd check it myself :( ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-06 20:58 Message: Logged In: YES user_id=80475 The patch does not compile on windows. AFAICT, importdl.h is the culprit because it loads windows.h for a second time resulting a double redinition of BYTE deep in the bowls of include files. Wish I had time to help you on this one, but I don't. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-10-05 23:15 Message: Logged In: YES user_id=4771 Sorry, I didn't follow any of this discussion, neither here nor in python-dev, so I cannot really comment. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-05 14:32 Message: Logged In: YES user_id=80475 Armin, do you have time for this one. I'm buried for a few days. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 09:05 Message: Logged In: YES user_id=1038590 Raymond, Passing to you to see what you think of the code, rather than just the feature in the abstract. Guido settled for not vetoing it, but the discussion with him allowed me to articulate why I think this is a worthwhile feature. (Details at http://mail.python.org/pipermail/python-dev/2004-October/049236.html) Extension to allow packages and zip imports can wait until there is any demand for either feature. I don't really expect to see any, since I think the main uses will be "python -m pdb", "python -m profile" and "python -m timeit". ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 04:21 Message: Logged In: YES user_id=1038590 Doc patch attached. Take it with a grain of salt, since this is the first real doc patch I've made. This doesn't cover anything for 'What's New' - that can wait until the patch gets accepted (if it does). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 03:48 Message: Logged In: YES user_id=1038590 5th version of patch attached - restricts option to top-level modules only. The correct semantics for a module inside a package just aren't clear enough at this stage. Support for dotted names can be added later if this patch gets accepted, and it still seems like a good idea. - adds a missing check from main.c (if we got the module option, don't try to open the file). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 00:30 Message: Logged In: YES user_id=1038590 Relevant documentation locations that I can find: Tutorial section 2.1 (Invoking the Interpreter) Add a very brief description of the '-m' option Python/C API section 2 (The Very High Level Layer) Document PyRun_SimpleModule What's New sections 12 & 13 I'll do this as a separate patch from the previous two, as I can't recall if Andrew prefers to write these himself. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 14:13 Message: Logged In: YES user_id=1038590 New version (#4) Trivial fix - tell PyRun_SimpleFile to close the file when it's done with it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 12:51 Message: Logged In: YES user_id=1038590 New version (run_module_3.diff) Takes more account of the file description reported by PyImport. Explictly restricts itself to PY_SOURCE and PY_COMPILED scripts. Behaves correctly when a non-package is encountered while parsing a dotted name (closes the file descriptor and reports an error). I also realised that the '-m' option doesn't currently comprehend "__path__" variables in packages. So maybe we *should* be loading the packages as we find them, and then querying them for their __path__ variable. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 19:48 Message: Logged In: YES user_id=1038590 Barry, kicking this in your direction solely because you were one of the people to comment on it on py-dev. Feel free to say 'too busy' :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 19:39 Message: Logged In: YES user_id=1038590 New version of patch attached (run_module_2.diff). This version allows modules within packages to be executed. It does this *without* loading the packages first (just as if the script were specified directly on the command line). It's also a little more responsive when it comes to error message, and I've confirmed that the usage message components are now under 512 bytes each. The FindModule method is now marked as private (i.e. with leading underscore). The limit on file paths in pythonrun.c is now taken from osdefs.h (the same limit that import.c already uses) The only bug I know of is that it misbehaves if you supply a name like "a.b.module.d". You will get an ImportError saying that d was not found, and the file pointer for 'module' won't get closed properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 From noreply at sourceforge.net Wed Oct 6 23:38:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 6 23:38:24 2004 Subject: [Patches] [ python-Patches-896011 ] pdb enhancements and bug fixes Message-ID: Patches item #896011, was opened at 2004-02-12 21:07 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=896011&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ilya Sandler (isandler) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: pdb enhancements and bug fixes Initial Comment: Bug fixes B1) Execute script in its own namespace (script was executed in pdb.py name space. E.g one could do print line_prefix in your script and one would get pdb's line_prefix variable (and I guess if was possible to accidentally stomp on pdb internals from the script)) B2) Remove pdb.py's path from sys.path. (pdb.py path was not removed from sys.path.. While normally this is not a problem, it CAN cause hard to diagnose problems. e.g. if your script needs to override some of std modules and you put them in some location and set PYTHONPATH accordingly, then everything works without pdb, but when you run under pdb (which is normally located with the rest of python std libs) your overriding suddenly breaks) This addresses CVS Bug report #751124, part 2 B3) Fix handling of breakpoints "file_name:line_no" (pdb was failing to set the breakpoint specified as "b file_name:100" when file_name did not end with ".py", and was not an absolute path.This is quite bad as many scripts commonly do not have ".py" suffix... In at least some cases, (e.g when running under emacs gud) user can't workaround this problem, as the "break" command is issued by another program..) Enhancements: E1) Now pdb gets directly to the 1st line of script (the CVS version of pdb required doing "step" twice before you get to the first line of your code: both ugly and annoying) E2) Restart the program (and preserve debugger state, such as breakpoints) if program being debugged exits (CVS version was exitting on program's exitNow debugger does not die on script's exit, taking all the settings with it) E3) Enter post-mortem debugging if the program throws an uncaught exception (CVS version was simply dying in this case This addresses CVS bug report #751124, part 1) All changes apply to the command line interface of pdb.py Ie. only when pdb.py invoked as "pdb.py script" The only exception is B3 which fixes a bug in do_break() ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-06 23:38 Message: Logged In: YES user_id=469548 I just looked at the bug-fixing parts for now. B1 and B2 are clear-cut and I'll check in the fix once I've fully processed the patch. B3: Could you give an example of a script where this bug appears (copy/paste console session would be nice)? I'm not sure I get the bug. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-09-23 05:45 Message: Logged In: YES user_id=971153 Another iteration of the patch 1. Allow to set bkpts while in post-mortem debuggin (which now happens in the same instance of pdb) 2. Against latest pdb.py (1.69) ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-03-05 20:28 Message: Logged In: YES user_id=971153 I am attaching a new version of the patch. Changes include: 1) the new patch is against the latest pdb.py v 1.67 2) it allows to debug code protected by if __name__== '__main__' conditional (the first version of the patch did not set __name__, so this code was not reachable).... Also, is there anything I can do to help with consideration of this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=896011&group_id=5470 From noreply at sourceforge.net Thu Oct 7 00:24:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 7 00:24:28 2004 Subject: [Patches] [ python-Patches-1035498 ] -m option to run a module as a script Message-ID: Patches item #1035498, was opened at 2004-09-28 00:22 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: -m option to run a module as a script Initial Comment: Implements the '-m' option recently discussed on python-dev. Runs a module 'as if' it had been invoked from the command line. E.g., for a build directory, the following two commands are equivalent: ./python -m pdb ./python Lib/pdb.py Note that neither of these does the same thing as "./python -c "import pdb". (In this latter case, any "if __name__ == "__main__" code would not be executed, whereas it will be invoked in the first two cases). Given the vagaries of sys.path, this is quite handy - if a module can be imported, it can be easily used as a script too. Not that all modules will necessarily do anything _interesting_ when used as a script. . . The current implementation makes changes to main.c (handle the new argument), pythonrun.[ch] (new flavour of PyRun_) and import.[ch] (expose a PyImport_FindModule C API) Current limitations / to-do if this is pursued: - print sensible errors for non-Python files (e.g. hotshot) - allow 'dotted' names - decide what to do with packages (e.g. run __init__.py) - check usage messages in main.c are all still under 512 characters (I assume that limit was set for a reason) - the 1K limit on absolute file paths seems rather arbitrary. - this is code written in the wee hours of the morning, so it probably has a few other lurking 'features'. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-07 08:24 Message: Logged In: YES user_id=1038590 New version of doc patch which changes the tutorial only (since PyRun_SimpleModule is no longer part of the patch). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-07 07:32 Message: Logged In: YES user_id=1038590 New version (7) attached which does the right thing for "python -tt -m regrtest -u network". (I really like that test case btw - very concise) This one sets argv[0] correctly, but was initially a little ungraceful in some failure modes (such as "python -m parser"). I had to add a new private API function to import.h (_PyImport_IsScript) to clean that up. Examples of the error handling in this version: [...@localhost src]$ ./python -m foo ./python: module foo not found [...@localhost src]$ ./python -m sys ./python: module sys has no associated file [...@localhost src]$ ./python -m parser ./python: module parser not usable as script (/home/.../dev/python/dist/src/build/lib.linux-i686-2.4/parser.so) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-07 04:56 Message: Logged In: YES user_id=1038590 Nice catch. . . I figured out what the problem is - regrtest.py uses sys.argv[0] to delete it's own directory from sys.path. And -m currently sets sys.argv[0] to just 'regrtest', instead of the full path to the module. Obviously, that is going to have to change. Either PyRun_SImpleModule will have to do it, or I'll get rid of that function all together, and put the 'module-finding' logic directly in main.c. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-07 04:09 Message: Logged In: YES user_id=80475 Put the test directory in PYTHONPATH and run the following to see if you get the same results: python -tt -m regrtest -u network python -tt lib\test\regrtest.py -u network ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-07 01:07 Message: Logged In: YES user_id=1038590 New version attached which should fix the Windows compile bug (pythonrun.c does the right thing by undefining BYTE before including windows.h - the inclusion of 'importdl.h' has been moved to be after that 'fixed' include). Unfortunately, I won't get access to a Windows build machine until after the beta 1 deadline, or I'd check it myself :( ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-06 20:58 Message: Logged In: YES user_id=80475 The patch does not compile on windows. AFAICT, importdl.h is the culprit because it loads windows.h for a second time resulting a double redinition of BYTE deep in the bowls of include files. Wish I had time to help you on this one, but I don't. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-10-05 23:15 Message: Logged In: YES user_id=4771 Sorry, I didn't follow any of this discussion, neither here nor in python-dev, so I cannot really comment. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-05 14:32 Message: Logged In: YES user_id=80475 Armin, do you have time for this one. I'm buried for a few days. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 09:05 Message: Logged In: YES user_id=1038590 Raymond, Passing to you to see what you think of the code, rather than just the feature in the abstract. Guido settled for not vetoing it, but the discussion with him allowed me to articulate why I think this is a worthwhile feature. (Details at http://mail.python.org/pipermail/python-dev/2004-October/049236.html) Extension to allow packages and zip imports can wait until there is any demand for either feature. I don't really expect to see any, since I think the main uses will be "python -m pdb", "python -m profile" and "python -m timeit". ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 04:21 Message: Logged In: YES user_id=1038590 Doc patch attached. Take it with a grain of salt, since this is the first real doc patch I've made. This doesn't cover anything for 'What's New' - that can wait until the patch gets accepted (if it does). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 03:48 Message: Logged In: YES user_id=1038590 5th version of patch attached - restricts option to top-level modules only. The correct semantics for a module inside a package just aren't clear enough at this stage. Support for dotted names can be added later if this patch gets accepted, and it still seems like a good idea. - adds a missing check from main.c (if we got the module option, don't try to open the file). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 00:30 Message: Logged In: YES user_id=1038590 Relevant documentation locations that I can find: Tutorial section 2.1 (Invoking the Interpreter) Add a very brief description of the '-m' option Python/C API section 2 (The Very High Level Layer) Document PyRun_SimpleModule What's New sections 12 & 13 I'll do this as a separate patch from the previous two, as I can't recall if Andrew prefers to write these himself. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 14:13 Message: Logged In: YES user_id=1038590 New version (#4) Trivial fix - tell PyRun_SimpleFile to close the file when it's done with it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 12:51 Message: Logged In: YES user_id=1038590 New version (run_module_3.diff) Takes more account of the file description reported by PyImport. Explictly restricts itself to PY_SOURCE and PY_COMPILED scripts. Behaves correctly when a non-package is encountered while parsing a dotted name (closes the file descriptor and reports an error). I also realised that the '-m' option doesn't currently comprehend "__path__" variables in packages. So maybe we *should* be loading the packages as we find them, and then querying them for their __path__ variable. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 19:48 Message: Logged In: YES user_id=1038590 Barry, kicking this in your direction solely because you were one of the people to comment on it on py-dev. Feel free to say 'too busy' :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 19:39 Message: Logged In: YES user_id=1038590 New version of patch attached (run_module_2.diff). This version allows modules within packages to be executed. It does this *without* loading the packages first (just as if the script were specified directly on the command line). It's also a little more responsive when it comes to error message, and I've confirmed that the usage message components are now under 512 bytes each. The FindModule method is now marked as private (i.e. with leading underscore). The limit on file paths in pythonrun.c is now taken from osdefs.h (the same limit that import.c already uses) The only bug I know of is that it misbehaves if you supply a name like "a.b.module.d". You will get an ImportError saying that d was not found, and the file pointer for 'module' won't get closed properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 From noreply at sourceforge.net Thu Oct 7 01:56:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 7 01:57:01 2004 Subject: [Patches] [ python-Patches-1035498 ] -m option to run a module as a script Message-ID: Patches item #1035498, was opened at 2004-09-27 09:22 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: -m option to run a module as a script Initial Comment: Implements the '-m' option recently discussed on python-dev. Runs a module 'as if' it had been invoked from the command line. E.g., for a build directory, the following two commands are equivalent: ./python -m pdb ./python Lib/pdb.py Note that neither of these does the same thing as "./python -c "import pdb". (In this latter case, any "if __name__ == "__main__" code would not be executed, whereas it will be invoked in the first two cases). Given the vagaries of sys.path, this is quite handy - if a module can be imported, it can be easily used as a script too. Not that all modules will necessarily do anything _interesting_ when used as a script. . . The current implementation makes changes to main.c (handle the new argument), pythonrun.[ch] (new flavour of PyRun_) and import.[ch] (expose a PyImport_FindModule C API) Current limitations / to-do if this is pursued: - print sensible errors for non-Python files (e.g. hotshot) - allow 'dotted' names - decide what to do with packages (e.g. run __init__.py) - check usage messages in main.c are all still under 512 characters (I assume that limit was set for a reason) - the 1K limit on absolute file paths seems rather arbitrary. - this is code written in the wee hours of the morning, so it probably has a few other lurking 'features'. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-06 18:56 Message: Logged In: YES user_id=80475 Please put in a single, combined documentation patch. Be sure to spell-check and run: python -m texcheck tut.tex ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-06 17:24 Message: Logged In: YES user_id=1038590 New version of doc patch which changes the tutorial only (since PyRun_SimpleModule is no longer part of the patch). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-06 16:32 Message: Logged In: YES user_id=1038590 New version (7) attached which does the right thing for "python -tt -m regrtest -u network". (I really like that test case btw - very concise) This one sets argv[0] correctly, but was initially a little ungraceful in some failure modes (such as "python -m parser"). I had to add a new private API function to import.h (_PyImport_IsScript) to clean that up. Examples of the error handling in this version: [...@localhost src]$ ./python -m foo ./python: module foo not found [...@localhost src]$ ./python -m sys ./python: module sys has no associated file [...@localhost src]$ ./python -m parser ./python: module parser not usable as script (/home/.../dev/python/dist/src/build/lib.linux-i686-2.4/parser.so) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-06 13:56 Message: Logged In: YES user_id=1038590 Nice catch. . . I figured out what the problem is - regrtest.py uses sys.argv[0] to delete it's own directory from sys.path. And -m currently sets sys.argv[0] to just 'regrtest', instead of the full path to the module. Obviously, that is going to have to change. Either PyRun_SImpleModule will have to do it, or I'll get rid of that function all together, and put the 'module-finding' logic directly in main.c. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-06 13:09 Message: Logged In: YES user_id=80475 Put the test directory in PYTHONPATH and run the following to see if you get the same results: python -tt -m regrtest -u network python -tt lib\test\regrtest.py -u network ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-06 10:07 Message: Logged In: YES user_id=1038590 New version attached which should fix the Windows compile bug (pythonrun.c does the right thing by undefining BYTE before including windows.h - the inclusion of 'importdl.h' has been moved to be after that 'fixed' include). Unfortunately, I won't get access to a Windows build machine until after the beta 1 deadline, or I'd check it myself :( ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-06 05:58 Message: Logged In: YES user_id=80475 The patch does not compile on windows. AFAICT, importdl.h is the culprit because it loads windows.h for a second time resulting a double redinition of BYTE deep in the bowls of include files. Wish I had time to help you on this one, but I don't. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-10-05 08:15 Message: Logged In: YES user_id=4771 Sorry, I didn't follow any of this discussion, neither here nor in python-dev, so I cannot really comment. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-04 23:32 Message: Logged In: YES user_id=80475 Armin, do you have time for this one. I'm buried for a few days. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 18:05 Message: Logged In: YES user_id=1038590 Raymond, Passing to you to see what you think of the code, rather than just the feature in the abstract. Guido settled for not vetoing it, but the discussion with him allowed me to articulate why I think this is a worthwhile feature. (Details at http://mail.python.org/pipermail/python-dev/2004-October/049236.html) Extension to allow packages and zip imports can wait until there is any demand for either feature. I don't really expect to see any, since I think the main uses will be "python -m pdb", "python -m profile" and "python -m timeit". ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 13:21 Message: Logged In: YES user_id=1038590 Doc patch attached. Take it with a grain of salt, since this is the first real doc patch I've made. This doesn't cover anything for 'What's New' - that can wait until the patch gets accepted (if it does). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 12:48 Message: Logged In: YES user_id=1038590 5th version of patch attached - restricts option to top-level modules only. The correct semantics for a module inside a package just aren't clear enough at this stage. Support for dotted names can be added later if this patch gets accepted, and it still seems like a good idea. - adds a missing check from main.c (if we got the module option, don't try to open the file). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 09:30 Message: Logged In: YES user_id=1038590 Relevant documentation locations that I can find: Tutorial section 2.1 (Invoking the Interpreter) Add a very brief description of the '-m' option Python/C API section 2 (The Very High Level Layer) Document PyRun_SimpleModule What's New sections 12 & 13 I'll do this as a separate patch from the previous two, as I can't recall if Andrew prefers to write these himself. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 23:13 Message: Logged In: YES user_id=1038590 New version (#4) Trivial fix - tell PyRun_SimpleFile to close the file when it's done with it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 21:51 Message: Logged In: YES user_id=1038590 New version (run_module_3.diff) Takes more account of the file description reported by PyImport. Explictly restricts itself to PY_SOURCE and PY_COMPILED scripts. Behaves correctly when a non-package is encountered while parsing a dotted name (closes the file descriptor and reports an error). I also realised that the '-m' option doesn't currently comprehend "__path__" variables in packages. So maybe we *should* be loading the packages as we find them, and then querying them for their __path__ variable. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 04:48 Message: Logged In: YES user_id=1038590 Barry, kicking this in your direction solely because you were one of the people to comment on it on py-dev. Feel free to say 'too busy' :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 04:39 Message: Logged In: YES user_id=1038590 New version of patch attached (run_module_2.diff). This version allows modules within packages to be executed. It does this *without* loading the packages first (just as if the script were specified directly on the command line). It's also a little more responsive when it comes to error message, and I've confirmed that the usage message components are now under 512 bytes each. The FindModule method is now marked as private (i.e. with leading underscore). The limit on file paths in pythonrun.c is now taken from osdefs.h (the same limit that import.c already uses) The only bug I know of is that it misbehaves if you supply a name like "a.b.module.d". You will get an ImportError saying that d was not found, and the file pointer for 'module' won't get closed properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 From noreply at sourceforge.net Thu Oct 7 03:49:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 7 03:49:16 2004 Subject: [Patches] [ python-Patches-896011 ] pdb enhancements and bug fixes Message-ID: Patches item #896011, was opened at 2004-02-12 12:07 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=896011&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: Johannes Gijsbers (jlgijsbers) Summary: pdb enhancements and bug fixes Initial Comment: Bug fixes B1) Execute script in its own namespace (script was executed in pdb.py name space. E.g one could do print line_prefix in your script and one would get pdb's line_prefix variable (and I guess if was possible to accidentally stomp on pdb internals from the script)) B2) Remove pdb.py's path from sys.path. (pdb.py path was not removed from sys.path.. While normally this is not a problem, it CAN cause hard to diagnose problems. e.g. if your script needs to override some of std modules and you put them in some location and set PYTHONPATH accordingly, then everything works without pdb, but when you run under pdb (which is normally located with the rest of python std libs) your overriding suddenly breaks) This addresses CVS Bug report #751124, part 2 B3) Fix handling of breakpoints "file_name:line_no" (pdb was failing to set the breakpoint specified as "b file_name:100" when file_name did not end with ".py", and was not an absolute path.This is quite bad as many scripts commonly do not have ".py" suffix... In at least some cases, (e.g when running under emacs gud) user can't workaround this problem, as the "break" command is issued by another program..) Enhancements: E1) Now pdb gets directly to the 1st line of script (the CVS version of pdb required doing "step" twice before you get to the first line of your code: both ugly and annoying) E2) Restart the program (and preserve debugger state, such as breakpoints) if program being debugged exits (CVS version was exitting on program's exitNow debugger does not die on script's exit, taking all the settings with it) E3) Enter post-mortem debugging if the program throws an uncaught exception (CVS version was simply dying in this case This addresses CVS bug report #751124, part 1) All changes apply to the command line interface of pdb.py Ie. only when pdb.py invoked as "pdb.py script" The only exception is B3 which fixes a bug in do_break() ---------------------------------------------------------------------- >Comment By: Ilya Sandler (isandler) Date: 2004-10-06 18:49 Message: Logged In: YES user_id=971153 Yes, here is an example of B3 type of bug The program: bagira:~/python/dist/src/Lib> cat pdb_t x=1 y=2 x=3 and the bug: bagira:~/python/dist/src/Lib> ../python pdb.py pdb_t > (1)?() (Pdb) b pdb_t:2 <-- fails *** 'pdb_t' not found from sys.path (Pdb) s --Call-- > /home/ilya/python/dist/src/Lib/pdb_t(1)?() -> x=1 (Pdb) b pdb_t:2 <---again fails *** 'pdb_t' not found from sys.path (Pdb) b 2 <--but succeeds w/o file name Breakpoint 1 at /home/ilya/python/dist/src/Lib/pdb_t:2 ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-06 14:38 Message: Logged In: YES user_id=469548 I just looked at the bug-fixing parts for now. B1 and B2 are clear-cut and I'll check in the fix once I've fully processed the patch. B3: Could you give an example of a script where this bug appears (copy/paste console session would be nice)? I'm not sure I get the bug. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-09-22 20:45 Message: Logged In: YES user_id=971153 Another iteration of the patch 1. Allow to set bkpts while in post-mortem debuggin (which now happens in the same instance of pdb) 2. Against latest pdb.py (1.69) ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-03-05 11:28 Message: Logged In: YES user_id=971153 I am attaching a new version of the patch. Changes include: 1) the new patch is against the latest pdb.py v 1.67 2) it allows to debug code protected by if __name__== '__main__' conditional (the first version of the patch did not set __name__, so this code was not reachable).... Also, is there anything I can do to help with consideration of this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=896011&group_id=5470 From noreply at sourceforge.net Thu Oct 7 05:36:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 7 05:36:31 2004 Subject: [Patches] [ python-Patches-1035498 ] -m option to run a module as a script Message-ID: Patches item #1035498, was opened at 2004-09-28 00:22 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: -m option to run a module as a script Initial Comment: Implements the '-m' option recently discussed on python-dev. Runs a module 'as if' it had been invoked from the command line. E.g., for a build directory, the following two commands are equivalent: ./python -m pdb ./python Lib/pdb.py Note that neither of these does the same thing as "./python -c "import pdb". (In this latter case, any "if __name__ == "__main__" code would not be executed, whereas it will be invoked in the first two cases). Given the vagaries of sys.path, this is quite handy - if a module can be imported, it can be easily used as a script too. Not that all modules will necessarily do anything _interesting_ when used as a script. . . The current implementation makes changes to main.c (handle the new argument), pythonrun.[ch] (new flavour of PyRun_) and import.[ch] (expose a PyImport_FindModule C API) Current limitations / to-do if this is pursued: - print sensible errors for non-Python files (e.g. hotshot) - allow 'dotted' names - decide what to do with packages (e.g. run __init__.py) - check usage messages in main.c are all still under 512 characters (I assume that limit was set for a reason) - the 1K limit on absolute file paths seems rather arbitrary. - this is code written in the wee hours of the morning, so it probably has a few other lurking 'features'. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-07 13:36 Message: Logged In: YES user_id=1038590 texcheck complains about the Unicode in the tutorial even on a clean checkout. The line numbers (> 900) are well past the point where I'm editing. (It turns out editing the the tex files works a lot better with xemacs than with the KDE editors - no spurious edits this time) I'm not sure what, if anything, I need to do for "what's new", but I've uploaded a combined code & documentation patch that implements version 7 of the -m behaviour, and makes relevant changes to section 2 of the tutorial. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-07 09:56 Message: Logged In: YES user_id=80475 Please put in a single, combined documentation patch. Be sure to spell-check and run: python -m texcheck tut.tex ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-07 08:24 Message: Logged In: YES user_id=1038590 New version of doc patch which changes the tutorial only (since PyRun_SimpleModule is no longer part of the patch). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-07 07:32 Message: Logged In: YES user_id=1038590 New version (7) attached which does the right thing for "python -tt -m regrtest -u network". (I really like that test case btw - very concise) This one sets argv[0] correctly, but was initially a little ungraceful in some failure modes (such as "python -m parser"). I had to add a new private API function to import.h (_PyImport_IsScript) to clean that up. Examples of the error handling in this version: [...@localhost src]$ ./python -m foo ./python: module foo not found [...@localhost src]$ ./python -m sys ./python: module sys has no associated file [...@localhost src]$ ./python -m parser ./python: module parser not usable as script (/home/.../dev/python/dist/src/build/lib.linux-i686-2.4/parser.so) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-07 04:56 Message: Logged In: YES user_id=1038590 Nice catch. . . I figured out what the problem is - regrtest.py uses sys.argv[0] to delete it's own directory from sys.path. And -m currently sets sys.argv[0] to just 'regrtest', instead of the full path to the module. Obviously, that is going to have to change. Either PyRun_SImpleModule will have to do it, or I'll get rid of that function all together, and put the 'module-finding' logic directly in main.c. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-07 04:09 Message: Logged In: YES user_id=80475 Put the test directory in PYTHONPATH and run the following to see if you get the same results: python -tt -m regrtest -u network python -tt lib\test\regrtest.py -u network ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-07 01:07 Message: Logged In: YES user_id=1038590 New version attached which should fix the Windows compile bug (pythonrun.c does the right thing by undefining BYTE before including windows.h - the inclusion of 'importdl.h' has been moved to be after that 'fixed' include). Unfortunately, I won't get access to a Windows build machine until after the beta 1 deadline, or I'd check it myself :( ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-06 20:58 Message: Logged In: YES user_id=80475 The patch does not compile on windows. AFAICT, importdl.h is the culprit because it loads windows.h for a second time resulting a double redinition of BYTE deep in the bowls of include files. Wish I had time to help you on this one, but I don't. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-10-05 23:15 Message: Logged In: YES user_id=4771 Sorry, I didn't follow any of this discussion, neither here nor in python-dev, so I cannot really comment. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-05 14:32 Message: Logged In: YES user_id=80475 Armin, do you have time for this one. I'm buried for a few days. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 09:05 Message: Logged In: YES user_id=1038590 Raymond, Passing to you to see what you think of the code, rather than just the feature in the abstract. Guido settled for not vetoing it, but the discussion with him allowed me to articulate why I think this is a worthwhile feature. (Details at http://mail.python.org/pipermail/python-dev/2004-October/049236.html) Extension to allow packages and zip imports can wait until there is any demand for either feature. I don't really expect to see any, since I think the main uses will be "python -m pdb", "python -m profile" and "python -m timeit". ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 04:21 Message: Logged In: YES user_id=1038590 Doc patch attached. Take it with a grain of salt, since this is the first real doc patch I've made. This doesn't cover anything for 'What's New' - that can wait until the patch gets accepted (if it does). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 03:48 Message: Logged In: YES user_id=1038590 5th version of patch attached - restricts option to top-level modules only. The correct semantics for a module inside a package just aren't clear enough at this stage. Support for dotted names can be added later if this patch gets accepted, and it still seems like a good idea. - adds a missing check from main.c (if we got the module option, don't try to open the file). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 00:30 Message: Logged In: YES user_id=1038590 Relevant documentation locations that I can find: Tutorial section 2.1 (Invoking the Interpreter) Add a very brief description of the '-m' option Python/C API section 2 (The Very High Level Layer) Document PyRun_SimpleModule What's New sections 12 & 13 I'll do this as a separate patch from the previous two, as I can't recall if Andrew prefers to write these himself. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 14:13 Message: Logged In: YES user_id=1038590 New version (#4) Trivial fix - tell PyRun_SimpleFile to close the file when it's done with it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 12:51 Message: Logged In: YES user_id=1038590 New version (run_module_3.diff) Takes more account of the file description reported by PyImport. Explictly restricts itself to PY_SOURCE and PY_COMPILED scripts. Behaves correctly when a non-package is encountered while parsing a dotted name (closes the file descriptor and reports an error). I also realised that the '-m' option doesn't currently comprehend "__path__" variables in packages. So maybe we *should* be loading the packages as we find them, and then querying them for their __path__ variable. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 19:48 Message: Logged In: YES user_id=1038590 Barry, kicking this in your direction solely because you were one of the people to comment on it on py-dev. Feel free to say 'too busy' :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 19:39 Message: Logged In: YES user_id=1038590 New version of patch attached (run_module_2.diff). This version allows modules within packages to be executed. It does this *without* loading the packages first (just as if the script were specified directly on the command line). It's also a little more responsive when it comes to error message, and I've confirmed that the usage message components are now under 512 bytes each. The FindModule method is now marked as private (i.e. with leading underscore). The limit on file paths in pythonrun.c is now taken from osdefs.h (the same limit that import.c already uses) The only bug I know of is that it misbehaves if you supply a name like "a.b.module.d". You will get an ImportError saying that d was not found, and the file pointer for 'module' won't get closed properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 From noreply at sourceforge.net Thu Oct 7 08:46:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 7 08:50:11 2004 Subject: [Patches] [ python-Patches-1035498 ] -m option to run a module as a script Message-ID: Patches item #1035498, was opened at 2004-09-27 09:22 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: -m option to run a module as a script Initial Comment: Implements the '-m' option recently discussed on python-dev. Runs a module 'as if' it had been invoked from the command line. E.g., for a build directory, the following two commands are equivalent: ./python -m pdb ./python Lib/pdb.py Note that neither of these does the same thing as "./python -c "import pdb". (In this latter case, any "if __name__ == "__main__" code would not be executed, whereas it will be invoked in the first two cases). Given the vagaries of sys.path, this is quite handy - if a module can be imported, it can be easily used as a script too. Not that all modules will necessarily do anything _interesting_ when used as a script. . . The current implementation makes changes to main.c (handle the new argument), pythonrun.[ch] (new flavour of PyRun_) and import.[ch] (expose a PyImport_FindModule C API) Current limitations / to-do if this is pursued: - print sensible errors for non-Python files (e.g. hotshot) - allow 'dotted' names - decide what to do with packages (e.g. run __init__.py) - check usage messages in main.c are all still under 512 characters (I assume that limit was set for a reason) - the 1K limit on absolute file paths seems rather arbitrary. - this is code written in the wee hours of the morning, so it probably has a few other lurking 'features'. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-07 01:46 Message: Logged In: YES user_id=80475 Accepted and applied. Checking in Doc/tut/tut.tex; /cvsroot/python/python/dist/src/Doc/tut/tut.tex,v <-- tut.tex new revision: 1.254; previous revision: 1.253 done Checking in Include/import.h; /cvsroot/python/python/dist/src/Include/import.h,v <-- import.h new revision: 2.30; previous revision: 2.29 done Checking in Misc/NEWS; /cvsroot/python/python/dist/src/Misc/NEWS,v <-- NEWS new revision: 1.1154; previous revision: 1.1153 done Checking in Modules/main.c; /cvsroot/python/python/dist/src/Modules/main.c,v <-- main.c new revision: 1.84; previous revision: 1.83 done Checking in Python/import.c; /cvsroot/python/python/dist/src/Python/import.c,v <-- import.c new revision: 2.240; previous revision: 2.239 cvs diff: [06:46:25] waiting for rhettinger's lock in /cvsroot/python/python/dis t/src/Doc/tut done ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-06 22:36 Message: Logged In: YES user_id=1038590 texcheck complains about the Unicode in the tutorial even on a clean checkout. The line numbers (> 900) are well past the point where I'm editing. (It turns out editing the the tex files works a lot better with xemacs than with the KDE editors - no spurious edits this time) I'm not sure what, if anything, I need to do for "what's new", but I've uploaded a combined code & documentation patch that implements version 7 of the -m behaviour, and makes relevant changes to section 2 of the tutorial. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-06 18:56 Message: Logged In: YES user_id=80475 Please put in a single, combined documentation patch. Be sure to spell-check and run: python -m texcheck tut.tex ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-06 17:24 Message: Logged In: YES user_id=1038590 New version of doc patch which changes the tutorial only (since PyRun_SimpleModule is no longer part of the patch). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-06 16:32 Message: Logged In: YES user_id=1038590 New version (7) attached which does the right thing for "python -tt -m regrtest -u network". (I really like that test case btw - very concise) This one sets argv[0] correctly, but was initially a little ungraceful in some failure modes (such as "python -m parser"). I had to add a new private API function to import.h (_PyImport_IsScript) to clean that up. Examples of the error handling in this version: [...@localhost src]$ ./python -m foo ./python: module foo not found [...@localhost src]$ ./python -m sys ./python: module sys has no associated file [...@localhost src]$ ./python -m parser ./python: module parser not usable as script (/home/.../dev/python/dist/src/build/lib.linux-i686-2.4/parser.so) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-06 13:56 Message: Logged In: YES user_id=1038590 Nice catch. . . I figured out what the problem is - regrtest.py uses sys.argv[0] to delete it's own directory from sys.path. And -m currently sets sys.argv[0] to just 'regrtest', instead of the full path to the module. Obviously, that is going to have to change. Either PyRun_SImpleModule will have to do it, or I'll get rid of that function all together, and put the 'module-finding' logic directly in main.c. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-06 13:09 Message: Logged In: YES user_id=80475 Put the test directory in PYTHONPATH and run the following to see if you get the same results: python -tt -m regrtest -u network python -tt lib\test\regrtest.py -u network ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-06 10:07 Message: Logged In: YES user_id=1038590 New version attached which should fix the Windows compile bug (pythonrun.c does the right thing by undefining BYTE before including windows.h - the inclusion of 'importdl.h' has been moved to be after that 'fixed' include). Unfortunately, I won't get access to a Windows build machine until after the beta 1 deadline, or I'd check it myself :( ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-06 05:58 Message: Logged In: YES user_id=80475 The patch does not compile on windows. AFAICT, importdl.h is the culprit because it loads windows.h for a second time resulting a double redinition of BYTE deep in the bowls of include files. Wish I had time to help you on this one, but I don't. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-10-05 08:15 Message: Logged In: YES user_id=4771 Sorry, I didn't follow any of this discussion, neither here nor in python-dev, so I cannot really comment. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-04 23:32 Message: Logged In: YES user_id=80475 Armin, do you have time for this one. I'm buried for a few days. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 18:05 Message: Logged In: YES user_id=1038590 Raymond, Passing to you to see what you think of the code, rather than just the feature in the abstract. Guido settled for not vetoing it, but the discussion with him allowed me to articulate why I think this is a worthwhile feature. (Details at http://mail.python.org/pipermail/python-dev/2004-October/049236.html) Extension to allow packages and zip imports can wait until there is any demand for either feature. I don't really expect to see any, since I think the main uses will be "python -m pdb", "python -m profile" and "python -m timeit". ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 13:21 Message: Logged In: YES user_id=1038590 Doc patch attached. Take it with a grain of salt, since this is the first real doc patch I've made. This doesn't cover anything for 'What's New' - that can wait until the patch gets accepted (if it does). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 12:48 Message: Logged In: YES user_id=1038590 5th version of patch attached - restricts option to top-level modules only. The correct semantics for a module inside a package just aren't clear enough at this stage. Support for dotted names can be added later if this patch gets accepted, and it still seems like a good idea. - adds a missing check from main.c (if we got the module option, don't try to open the file). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 09:30 Message: Logged In: YES user_id=1038590 Relevant documentation locations that I can find: Tutorial section 2.1 (Invoking the Interpreter) Add a very brief description of the '-m' option Python/C API section 2 (The Very High Level Layer) Document PyRun_SimpleModule What's New sections 12 & 13 I'll do this as a separate patch from the previous two, as I can't recall if Andrew prefers to write these himself. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 23:13 Message: Logged In: YES user_id=1038590 New version (#4) Trivial fix - tell PyRun_SimpleFile to close the file when it's done with it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 21:51 Message: Logged In: YES user_id=1038590 New version (run_module_3.diff) Takes more account of the file description reported by PyImport. Explictly restricts itself to PY_SOURCE and PY_COMPILED scripts. Behaves correctly when a non-package is encountered while parsing a dotted name (closes the file descriptor and reports an error). I also realised that the '-m' option doesn't currently comprehend "__path__" variables in packages. So maybe we *should* be loading the packages as we find them, and then querying them for their __path__ variable. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 04:48 Message: Logged In: YES user_id=1038590 Barry, kicking this in your direction solely because you were one of the people to comment on it on py-dev. Feel free to say 'too busy' :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 04:39 Message: Logged In: YES user_id=1038590 New version of patch attached (run_module_2.diff). This version allows modules within packages to be executed. It does this *without* loading the packages first (just as if the script were specified directly on the command line). It's also a little more responsive when it comes to error message, and I've confirmed that the usage message components are now under 512 bytes each. The FindModule method is now marked as private (i.e. with leading underscore). The limit on file paths in pythonrun.c is now taken from osdefs.h (the same limit that import.c already uses) The only bug I know of is that it misbehaves if you supply a name like "a.b.module.d". You will get an ImportError saying that d was not found, and the file pointer for 'module' won't get closed properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 From noreply at sourceforge.net Thu Oct 7 09:49:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 7 09:49:15 2004 Subject: [Patches] [ python-Patches-1038388 ] __main__ for whichdb.py Message-ID: Patches item #1038388, was opened at 2004-10-01 14:02 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038388&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Nobody/Anonymous (nobody) Summary: __main__ for whichdb.py Initial Comment: This patch addsd shebang and __main__ script for whichdb.py. ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2004-10-07 11:49 Message: Logged In: YES user_id=4799 And don't forget to make it executable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038388&group_id=5470 From noreply at sourceforge.net Thu Oct 7 09:48:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 7 09:49:34 2004 Subject: [Patches] [ python-Patches-754022 ] Enhanced webbrowser.py Message-ID: Patches item #754022, was opened at 2003-06-13 19:24 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Oleg Broytmann (phd) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Enhanced webbrowser.py Initial Comment: The patch enhances webbrowser.py. First, all calls to os.system return result code, and the inverse of the code (it is ok/fail status) passed through all higher-level routines up to top-level call to open(url). This allows to check if a browser was really started. Second, the very open() modified so it is now trying to run all registered browsers in order until a browser returns 1. Third, the file can be used as a program: webbrowser.py url. Optional parameters -n allows to open the url in a new window. ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2004-10-07 11:48 Message: Logged In: YES user_id=4799 And don't forget to make it executable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 From noreply at sourceforge.net Thu Oct 7 09:49:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 7 09:49:56 2004 Subject: [Patches] [ python-Patches-784089 ] A program to scan python files and list those require coding Message-ID: Patches item #784089, was opened at 2003-08-06 14:47 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784089&group_id=5470 Category: Demos and tools Group: Python 2.3 Status: Open Resolution: None Priority: 3 Submitted By: Oleg Broytmann (phd) Assigned to: Nobody/Anonymous (nobody) Summary: A program to scan python files and list those require coding Initial Comment: A program to scan python files (recursively) and list those that require coding directive (pseudocomment) because there non-ASCII characters in the file (including comments). The program treats files as python files if the extension is .py or there is "python" in the first line of the file. ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2004-10-07 11:49 Message: Logged In: YES user_id=4799 And don't forget to make it executable. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-08 01:50 Message: Logged In: YES user_id=11375 So, does something need to be done with this script, like adding it to the distribution? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-06 16:36 Message: Logged In: YES user_id=38388 Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784089&group_id=5470 From noreply at sourceforge.net Thu Oct 7 21:04:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 7 21:05:00 2004 Subject: [Patches] [ python-Patches-896011 ] pdb enhancements and bug fixes Message-ID: Patches item #896011, was opened at 2004-02-12 21:07 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=896011&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: Johannes Gijsbers (jlgijsbers) Summary: pdb enhancements and bug fixes Initial Comment: Bug fixes B1) Execute script in its own namespace (script was executed in pdb.py name space. E.g one could do print line_prefix in your script and one would get pdb's line_prefix variable (and I guess if was possible to accidentally stomp on pdb internals from the script)) B2) Remove pdb.py's path from sys.path. (pdb.py path was not removed from sys.path.. While normally this is not a problem, it CAN cause hard to diagnose problems. e.g. if your script needs to override some of std modules and you put them in some location and set PYTHONPATH accordingly, then everything works without pdb, but when you run under pdb (which is normally located with the rest of python std libs) your overriding suddenly breaks) This addresses CVS Bug report #751124, part 2 B3) Fix handling of breakpoints "file_name:line_no" (pdb was failing to set the breakpoint specified as "b file_name:100" when file_name did not end with ".py", and was not an absolute path.This is quite bad as many scripts commonly do not have ".py" suffix... In at least some cases, (e.g when running under emacs gud) user can't workaround this problem, as the "break" command is issued by another program..) Enhancements: E1) Now pdb gets directly to the 1st line of script (the CVS version of pdb required doing "step" twice before you get to the first line of your code: both ugly and annoying) E2) Restart the program (and preserve debugger state, such as breakpoints) if program being debugged exits (CVS version was exitting on program's exitNow debugger does not die on script's exit, taking all the settings with it) E3) Enter post-mortem debugging if the program throws an uncaught exception (CVS version was simply dying in this case This addresses CVS bug report #751124, part 1) All changes apply to the command line interface of pdb.py Ie. only when pdb.py invoked as "pdb.py script" The only exception is B3 which fixes a bug in do_break() ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-07 21:04 Message: Logged In: YES user_id=469548 Ah, I've got it now. However, your fix (which should be in lookupmodule, like you suggested) is a bit too broad. 'b pbd_t:2' works, but 'b :2' also works, while it shouldn't. Maybe we should use _initial_file here as well? ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-10-07 03:49 Message: Logged In: YES user_id=971153 Yes, here is an example of B3 type of bug The program: bagira:~/python/dist/src/Lib> cat pdb_t x=1 y=2 x=3 and the bug: bagira:~/python/dist/src/Lib> ../python pdb.py pdb_t > (1)?() (Pdb) b pdb_t:2 <-- fails *** 'pdb_t' not found from sys.path (Pdb) s --Call-- > /home/ilya/python/dist/src/Lib/pdb_t(1)?() -> x=1 (Pdb) b pdb_t:2 <---again fails *** 'pdb_t' not found from sys.path (Pdb) b 2 <--but succeeds w/o file name Breakpoint 1 at /home/ilya/python/dist/src/Lib/pdb_t:2 ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-06 23:38 Message: Logged In: YES user_id=469548 I just looked at the bug-fixing parts for now. B1 and B2 are clear-cut and I'll check in the fix once I've fully processed the patch. B3: Could you give an example of a script where this bug appears (copy/paste console session would be nice)? I'm not sure I get the bug. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-09-23 05:45 Message: Logged In: YES user_id=971153 Another iteration of the patch 1. Allow to set bkpts while in post-mortem debuggin (which now happens in the same instance of pdb) 2. Against latest pdb.py (1.69) ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-03-05 20:28 Message: Logged In: YES user_id=971153 I am attaching a new version of the patch. Changes include: 1) the new patch is against the latest pdb.py v 1.67 2) it allows to debug code protected by if __name__== '__main__' conditional (the first version of the patch did not set __name__, so this code was not reachable).... Also, is there anything I can do to help with consideration of this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=896011&group_id=5470 From noreply at sourceforge.net Thu Oct 7 22:21:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 7 22:21:31 2004 Subject: [Patches] [ python-Patches-946373 ] do not add directory of sys.argv[0] into sys.path Message-ID: Patches item #946373, was opened at 2004-05-02 14:51 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=946373&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: wrobell (wrobell) Assigned to: Nobody/Anonymous (nobody) Summary: do not add directory of sys.argv[0] into sys.path Initial Comment: Python adds magically directory of sys.argv[0] into sys.path, i.e. >>> import sys >>> sys.path ['', '/usr/lib/python23.zip', '/usr/share/python2.3', '/usr/share/python2.3/plat-linux2', '/usr/share/python2.3/lib-tk', '/usr/lib/python2.3/lib-dynload', '/usr/lib/python2.3/site-packages', '/usr/lib/python2.3/site-packages/gtk-2.0', '/usr/share/python2.3/site-packages'] where '' (or /usr/bin when executed script is in /usr/bin directory, etc.) is added automatically. It is useful in many circumstances but fails when name conflict occurs. For example, create getpass.py or pdb.py scripts which import getpass and pdb modules. Script names conflict with modules names and modules are not going to be imported because path to the scripts is appended into sys.path, so a script is imported instead of a module. The solutions: 1. User of script with conflicting name (i.e. getpass.py or timeit.py) can set PYTHONPATH to system library path, i.e. /usr/lib/python2.3. 2. User can modify the script to delete site.path[0]. 3. User can rename the script. 4. Python can be modified to not add magically directory of sys.argv[0]. The 1. is a tricky and not intuitive and quite funny: set PYTHONPATH to system library path to import system module (and only in specific circumstances). ;-P The 2. is a dirty hack: hey, we gonna import system module, ain't it? The 3. is, IMHO, not acceptable because there is more than 200 python system modules, more in the future and user cannot be forced to maintain script names blacklist. The 4. is only acceptable, IMHO. It makes python more inconvenient but gives no trouble when names conflict occurs. Moreover, fourth solution makes python more standard with other languages behaviour, i.e. one has to set CLASSPATH to load Java classes. Maybe there is another solution, but... Patch attached. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-07 22:21 Message: Logged In: YES user_id=469548 wrobell, would you be willing to produce a version of the patch which implements PEP 328? I'll close this patch if not. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-21 01:55 Message: Logged In: YES user_id=341410 This "problem" will be fixed in Python 2.4 with the introduction of absolute and relative import semantics as given in PEP 328: http://www.python.org/peps/pep-0328.html As stated in the PEP, to use the obviously backwards incompatible semantics, the future import will be used for 2.4 and 2.5, where in 2.6 it will become the default. from __future__ import absolute_import ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-12 17:34 Message: Logged In: YES user_id=29957 I've been bitten by this before. See e.g. the shtoom.py script clashing with the shtoom package. I used the hacky approach of moving '' to the end of sys.path. While it would be nice if this wasn't needed, I can't see this being anything other than a backwards compatibility nightmare. It will absolutely break a lot of things to change it. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-05-08 01:45 Message: Logged In: YES user_id=971153 Would not this cause serious backward compatibility problems?? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=946373&group_id=5470 From noreply at sourceforge.net Thu Oct 7 22:48:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 7 22:48:22 2004 Subject: [Patches] [ python-Patches-896011 ] pdb enhancements and bug fixes Message-ID: Patches item #896011, was opened at 2004-02-12 21:07 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=896011&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: Johannes Gijsbers (jlgijsbers) Summary: pdb enhancements and bug fixes Initial Comment: Bug fixes B1) Execute script in its own namespace (script was executed in pdb.py name space. E.g one could do print line_prefix in your script and one would get pdb's line_prefix variable (and I guess if was possible to accidentally stomp on pdb internals from the script)) B2) Remove pdb.py's path from sys.path. (pdb.py path was not removed from sys.path.. While normally this is not a problem, it CAN cause hard to diagnose problems. e.g. if your script needs to override some of std modules and you put them in some location and set PYTHONPATH accordingly, then everything works without pdb, but when you run under pdb (which is normally located with the rest of python std libs) your overriding suddenly breaks) This addresses CVS Bug report #751124, part 2 B3) Fix handling of breakpoints "file_name:line_no" (pdb was failing to set the breakpoint specified as "b file_name:100" when file_name did not end with ".py", and was not an absolute path.This is quite bad as many scripts commonly do not have ".py" suffix... In at least some cases, (e.g when running under emacs gud) user can't workaround this problem, as the "break" command is issued by another program..) Enhancements: E1) Now pdb gets directly to the 1st line of script (the CVS version of pdb required doing "step" twice before you get to the first line of your code: both ugly and annoying) E2) Restart the program (and preserve debugger state, such as breakpoints) if program being debugged exits (CVS version was exitting on program's exitNow debugger does not die on script's exit, taking all the settings with it) E3) Enter post-mortem debugging if the program throws an uncaught exception (CVS version was simply dying in this case This addresses CVS bug report #751124, part 1) All changes apply to the command line interface of pdb.py Ie. only when pdb.py invoked as "pdb.py script" The only exception is B3 which fixes a bug in do_break() ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-07 22:48 Message: Logged In: YES user_id=469548 On the enhancements: E1. Should be fine (this is the frame.f_lineno <= 0 part of the patch, right?). E2. Nice addition. It could do with better docs. Come to think of it, all of this needs to be documented. A new doc section on running the module as a script would be nice. I can write it, but it would be great if you could E3. Yes! In general: * I'm not completely sure about this, but I'm thinking do_debug_script() would fit better as a method on the Pdb class. It seems to have a bit of feature envy towards the pdb class. What do you think? * I'd like to rename the method to runscript() for consistency with the rest of pdb. * You might want to read http://python.org/peps/pep-0008.html, especially the sections on Whitespace and Comments. While you're at it, http://python.org/peps/pep-0257.html is important too. That's it... for now. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-07 21:04 Message: Logged In: YES user_id=469548 Ah, I've got it now. However, your fix (which should be in lookupmodule, like you suggested) is a bit too broad. 'b pbd_t:2' works, but 'b :2' also works, while it shouldn't. Maybe we should use _initial_file here as well? ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-10-07 03:49 Message: Logged In: YES user_id=971153 Yes, here is an example of B3 type of bug The program: bagira:~/python/dist/src/Lib> cat pdb_t x=1 y=2 x=3 and the bug: bagira:~/python/dist/src/Lib> ../python pdb.py pdb_t > (1)?() (Pdb) b pdb_t:2 <-- fails *** 'pdb_t' not found from sys.path (Pdb) s --Call-- > /home/ilya/python/dist/src/Lib/pdb_t(1)?() -> x=1 (Pdb) b pdb_t:2 <---again fails *** 'pdb_t' not found from sys.path (Pdb) b 2 <--but succeeds w/o file name Breakpoint 1 at /home/ilya/python/dist/src/Lib/pdb_t:2 ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-06 23:38 Message: Logged In: YES user_id=469548 I just looked at the bug-fixing parts for now. B1 and B2 are clear-cut and I'll check in the fix once I've fully processed the patch. B3: Could you give an example of a script where this bug appears (copy/paste console session would be nice)? I'm not sure I get the bug. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-09-23 05:45 Message: Logged In: YES user_id=971153 Another iteration of the patch 1. Allow to set bkpts while in post-mortem debuggin (which now happens in the same instance of pdb) 2. Against latest pdb.py (1.69) ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-03-05 20:28 Message: Logged In: YES user_id=971153 I am attaching a new version of the patch. Changes include: 1) the new patch is against the latest pdb.py v 1.67 2) it allows to debug code protected by if __name__== '__main__' conditional (the first version of the patch did not set __name__, so this code was not reachable).... Also, is there anything I can do to help with consideration of this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=896011&group_id=5470 From noreply at sourceforge.net Fri Oct 8 03:13:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 8 03:13:38 2004 Subject: [Patches] [ python-Patches-1041364 ] True/False instead of 1/0 in libstdtypes.tex Message-ID: Patches item #1041364, was opened at 2004-10-06 06:22 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1041364&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: True/False instead of 1/0 in libstdtypes.tex Initial Comment: The attached patch changes 1/0 into True/False in section 2.3.6 Sequence Types. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-10-07 20:13 Message: Logged In: YES user_id=2772 This patch looks simple and to the point. I applied the patch to my CVS tree, built and verified the html version of the documentation. Looks fine. Please apply. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1041364&group_id=5470 From noreply at sourceforge.net Fri Oct 8 03:43:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 8 03:43:06 2004 Subject: [Patches] [ python-Patches-1042705 ] bbetter document popenX 'cmd' argument Message-ID: Patches item #1042705, was opened at 2004-10-07 20:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1042705&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Nobody/Anonymous (nobody) Summary: bbetter document popenX 'cmd' argument Initial Comment: Documentation and docstrings for the 'cmd'-as-sequence usage of popenX functions in os and popen2 on unix. All texts are a variation on the following: On \UNIX, \var{cmd} may be a sequence, in which case arguments will be passed directly to the program without shell intervention (as with \function{os.spawnv()}. If \var{cmd} is a string it will be passed to the shell (as with \function{os.system()}). See also 888380 for an older patch addressing the same issue. If this patch is applied, that tracker item should be closed too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1042705&group_id=5470 From noreply at sourceforge.net Fri Oct 8 03:44:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 8 03:44:10 2004 Subject: [Patches] [ python-Patches-888380 ] popen2.popen2() 'cmd' list syntax docstring Message-ID: Patches item #888380, was opened at 2004-01-31 18:44 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=888380&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Connelly aka shellreef (jeffconnelly) Assigned to: Nobody/Anonymous (nobody) Summary: popen2.popen2() 'cmd' list syntax docstring Initial Comment: This simple patch documents using popen2() with a list as the first argument. Currently this feature is not documented. It is good practice to use the list-popen2 as it avoids shell interpretation. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-10-07 20:44 Message: Logged In: YES user_id=2772 see http://python.org/sf/1042705 for a new, more complete patch of popenX documentation ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-07 16:39 Message: Logged In: YES user_id=11375 Just a reminder -- could you please update this patch so that it can be applied? ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-07-10 08:14 Message: Logged In: YES user_id=2772 Please resubmit the patch in context or unified diff format. ed-format diffs generally won't apply when any other changes have been made in that file in the meantime. The same or similar documentation change should also be applied to Popen3.__init__, Popen4.__init__ (which does't exist yet), popen3(), and popoen4() The line number in your version of the patch seems to indicate that the change was made within the 'if sys.platform[:3] == "win" ...:' block, which is where the advice doesn't apply. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=888380&group_id=5470 From noreply at sourceforge.net Fri Oct 8 03:53:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 8 03:53:40 2004 Subject: [Patches] [ python-Patches-1041364 ] True/False instead of 1/0 in libstdtypes.tex Message-ID: Patches item #1041364, was opened at 2004-10-06 06:22 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1041364&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: True/False instead of 1/0 in libstdtypes.tex Initial Comment: The attached patch changes 1/0 into True/False in section 2.3.6 Sequence Types. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-07 20:53 Message: Logged In: YES user_id=80475 Thanks for the patch and review. Applied: C:\py24\Doc\lib>cvs ci libstdtypes.tex Checking in libstdtypes.tex; /cvsroot/python/python/dist/src/Doc/lib/libstdtypes.tex,v <-- libstdtypes.tex new revision: 1.167; previous revision: 1.166 ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-10-07 20:13 Message: Logged In: YES user_id=2772 This patch looks simple and to the point. I applied the patch to my CVS tree, built and verified the html version of the documentation. Looks fine. Please apply. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1041364&group_id=5470 From noreply at sourceforge.net Fri Oct 8 07:25:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 8 07:25:31 2004 Subject: [Patches] [ python-Patches-896011 ] pdb enhancements and bug fixes Message-ID: Patches item #896011, was opened at 2004-02-12 12:07 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=896011&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: Johannes Gijsbers (jlgijsbers) Summary: pdb enhancements and bug fixes Initial Comment: Bug fixes B1) Execute script in its own namespace (script was executed in pdb.py name space. E.g one could do print line_prefix in your script and one would get pdb's line_prefix variable (and I guess if was possible to accidentally stomp on pdb internals from the script)) B2) Remove pdb.py's path from sys.path. (pdb.py path was not removed from sys.path.. While normally this is not a problem, it CAN cause hard to diagnose problems. e.g. if your script needs to override some of std modules and you put them in some location and set PYTHONPATH accordingly, then everything works without pdb, but when you run under pdb (which is normally located with the rest of python std libs) your overriding suddenly breaks) This addresses CVS Bug report #751124, part 2 B3) Fix handling of breakpoints "file_name:line_no" (pdb was failing to set the breakpoint specified as "b file_name:100" when file_name did not end with ".py", and was not an absolute path.This is quite bad as many scripts commonly do not have ".py" suffix... In at least some cases, (e.g when running under emacs gud) user can't workaround this problem, as the "break" command is issued by another program..) Enhancements: E1) Now pdb gets directly to the 1st line of script (the CVS version of pdb required doing "step" twice before you get to the first line of your code: both ugly and annoying) E2) Restart the program (and preserve debugger state, such as breakpoints) if program being debugged exits (CVS version was exitting on program's exitNow debugger does not die on script's exit, taking all the settings with it) E3) Enter post-mortem debugging if the program throws an uncaught exception (CVS version was simply dying in this case This addresses CVS bug report #751124, part 1) All changes apply to the command line interface of pdb.py Ie. only when pdb.py invoked as "pdb.py script" The only exception is B3 which fixes a bug in do_break() ---------------------------------------------------------------------- >Comment By: Ilya Sandler (isandler) Date: 2004-10-07 22:25 Message: Logged In: YES user_id=971153 > (this is the frame.f_lineno <= 0 part of the patch, right?). Yes >However, your fix (which should be in lookupmodule), is a bit > too broad. 'b pbd_t:2' works, but >'b :2' also works, while >it shouldn't. I am not sure I agree here: e.g even in CVS version of pdb you can set a breakpoint in a random file (as long as this file is specified via absolute path or can be found in sys.path)... E.g. 'b pydoc.py:124' succeeds even if your script never loads pydoc And I think this is in general a useful behaviour as debugger has no way (in general) to know that a particular source file may be loaded in the future.. As far as placement of it in lookupmodule(). Well, I guess I was afraid to change existing function (as it could theoretically break some other code). Another issue is that, strictly speaking, lookupmodule() already does more then just looks up modules, so I did not want to add even more to it...I don't feel strongly either way, so if you think lookupmodule() is the place to fix B3, let me know... >do_debug_script() would fit better as a method on the Pdb >class. It seems to have a bit of feature envy towards the >pdb class. What do you think? Well, yes and no: e.g basic setup for the script debugging g={"__name__" : "__main__"} l=g pdb._initial_file=pdb.canonic(filename) statement='execfile( "'+ filename+'")' pdb.run(statement, globals=g, locals=l) could indeed become a method of Pdb, but I am not sure about the wrapping loop/postmortem, which would result in a method which never return... > I'd like to rename the method to runscript() for >consistency with the rest of pdb. I could add runscript() with the above code in it and still have the main() function which is responsible for the loop and postmortem.. Would it be better? >E2. Nice addition. It could do with better docs. > Come to think of it, all of this needs to be documented. A new >doc section on running the module as a script would be nice. Could you elaborate a bit on what would like to see in such a doc? (E.g normaly such docs would include command line options, but we don't have any and the cli itself is already documented) . ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-07 13:48 Message: Logged In: YES user_id=469548 On the enhancements: E1. Should be fine (this is the frame.f_lineno <= 0 part of the patch, right?). E2. Nice addition. It could do with better docs. Come to think of it, all of this needs to be documented. A new doc section on running the module as a script would be nice. I can write it, but it would be great if you could E3. Yes! In general: * I'm not completely sure about this, but I'm thinking do_debug_script() would fit better as a method on the Pdb class. It seems to have a bit of feature envy towards the pdb class. What do you think? * I'd like to rename the method to runscript() for consistency with the rest of pdb. * You might want to read http://python.org/peps/pep-0008.html, especially the sections on Whitespace and Comments. While you're at it, http://python.org/peps/pep-0257.html is important too. That's it... for now. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-07 12:04 Message: Logged In: YES user_id=469548 Ah, I've got it now. However, your fix (which should be in lookupmodule, like you suggested) is a bit too broad. 'b pbd_t:2' works, but 'b :2' also works, while it shouldn't. Maybe we should use _initial_file here as well? ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-10-06 18:49 Message: Logged In: YES user_id=971153 Yes, here is an example of B3 type of bug The program: bagira:~/python/dist/src/Lib> cat pdb_t x=1 y=2 x=3 and the bug: bagira:~/python/dist/src/Lib> ../python pdb.py pdb_t > (1)?() (Pdb) b pdb_t:2 <-- fails *** 'pdb_t' not found from sys.path (Pdb) s --Call-- > /home/ilya/python/dist/src/Lib/pdb_t(1)?() -> x=1 (Pdb) b pdb_t:2 <---again fails *** 'pdb_t' not found from sys.path (Pdb) b 2 <--but succeeds w/o file name Breakpoint 1 at /home/ilya/python/dist/src/Lib/pdb_t:2 ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-06 14:38 Message: Logged In: YES user_id=469548 I just looked at the bug-fixing parts for now. B1 and B2 are clear-cut and I'll check in the fix once I've fully processed the patch. B3: Could you give an example of a script where this bug appears (copy/paste console session would be nice)? I'm not sure I get the bug. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-09-22 20:45 Message: Logged In: YES user_id=971153 Another iteration of the patch 1. Allow to set bkpts while in post-mortem debuggin (which now happens in the same instance of pdb) 2. Against latest pdb.py (1.69) ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-03-05 11:28 Message: Logged In: YES user_id=971153 I am attaching a new version of the patch. Changes include: 1) the new patch is against the latest pdb.py v 1.67 2) it allows to debug code protected by if __name__== '__main__' conditional (the first version of the patch did not set __name__, so this code was not reachable).... Also, is there anything I can do to help with consideration of this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=896011&group_id=5470 From noreply at sourceforge.net Fri Oct 8 08:07:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 8 08:08:00 2004 Subject: [Patches] [ python-Patches-1038854 ] Fix struct.pack on 64-bit archs (broken on 2.*) Message-ID: Patches item #1038854, was opened at 2004-10-02 07:07 Message generated for change (Comment added) made by sgatwasetde You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038854&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Grundmann (sgatwasetde) Assigned to: Nobody/Anonymous (nobody) Summary: Fix struct.pack on 64-bit archs (broken on 2.*) Initial Comment: Description: The code in the struct module assumes that sizeof(long) == sizeof(int) which is wrong on (most) 64-bit architectures (linux on amd64 with a 32-bit userland is an exception). How To Repeat: on a 32-bit platform struct.pack behaves as expected: $ uname -m -r -s FreeBSD 4.10-STABLE i386 $ python -c "import struct; print repr(struct.pack('I', 4294967296))" Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert on a 64-bit platform it treats integers as longs (it does not check for over/underflows and returns the lower 4 byte): $ uname -m -r -s FreeBSD 5.2-CURRENT sparc64 $ python -c "import struct; print repr(struct.pack('I', 4294967296))" '\x00\x00\x00\x00' Fix: in python/python/dist/src/Modules/structmodule.c: np_uint() and np_int() have to check for over/underflows using MAX_UINT, MAX_INT, MIN_INT as np_ushort() and np_short() already do for MAX_USHORT, ... the attached patch does this (diff was generated using diff -rNu and Revision 2.62 of python/python/dist/src/Modules/structmodule.c) ---------------------------------------------------------------------- >Comment By: Stefan Grundmann (sgatwasetde) Date: 2004-10-08 08:07 Message: Logged In: YES user_id=1131807 The attached patch will fix the range-checking-code of the integer pack functions for 64 and 32 bit architectures (tested on i386 and Sparc64, 64-bit little-endian was not tested 'cause of lack of hardware). All test cases worked as expected, there is no more need for BUGGY_RANGE_CHECK. I'm a bit unsure about the used method to get an unsigned long from a Python_Long object with overflow checking... PyLong_AsUnsignedLong(PyLong_FromLong(PyInt_AS_LONG(v))) looks a rather excessive. ---------------------------------------------------------------------- Comment By: Stefan Grundmann (sgatwasetde) Date: 2004-10-06 08:31 Message: Logged In: YES user_id=1131807 I removed the attached patch since it only handles overflows for np_int/np_uint. bp_int/bp_uint and lp_int/lp_unit have different issues (no overflow checking at all, unneccessary loops - that will not be optimized by the compiler). I'm working on a new patch that fixes these problems (and the rest of BUGGY_RANGE_CHECK ;) ). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-10-05 15:31 Message: Logged In: YES user_id=4771 At a first glance, it appears that there is the same problem in bp_int/bp_uint and lp_int/lp_unit. Can you check that pack('I',...) fail to detect the overflow in the same way? If so, can you also provide the patch for these 4 other routines? Finally, it would be nice to add a test case in Lib/test/test_struct.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038854&group_id=5470 From noreply at sourceforge.net Fri Oct 8 13:43:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 8 19:02:59 2004 Subject: [Patches] [ python-Patches-1042969 ] broken TeX markup Message-ID: Patches item #1042969, was opened at 2004-10-08 20:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1042969&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: broken TeX markup Initial Comment: TeX markup of Doc/ref/ref5.tex is broken and renderd into a malformed HTML. The closing brace for \token {generator_expression} is missing. You can see it at BNF of generator expression's grammer: http://www.python.org/dev/doc/devel/ref/atoms.html HTML Help compiler reports warning messages about them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1042969&group_id=5470 From noreply at sourceforge.net Fri Oct 8 19:49:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 8 19:49:48 2004 Subject: [Patches] [ python-Patches-1043218 ] Decimal.py enhancements Message-ID: Patches item #1043218, was opened at 2004-10-08 14:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1043218&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Facundo Batista (facundobatista) Assigned to: Raymond Hettinger (rhettinger) Summary: Decimal.py enhancements Initial Comment: Raymond: Changed the _fix and _fixexponents semantics according to how they were used by the module, which simplifies several things (less checks to see if "something" is None, skipped the check for _is_special at the start of _fixexponents, etc...). Also skipped copying ``self`` in _fix() before calling _fixexponents() (which already makes a copy of it). And made some style fixups. The tests passed ok, showing a 4% speedup. I'm posting this like a patch and not doing a direct commit to you to check if another change to the code (with this speedup) is valuable. . Facundo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1043218&group_id=5470 From noreply at sourceforge.net Fri Oct 8 19:50:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 8 19:51:06 2004 Subject: [Patches] [ python-Patches-1043218 ] Decimal.py enhancements Message-ID: Patches item #1043218, was opened at 2004-10-08 14:49 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1043218&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Facundo Batista (facundobatista) Assigned to: Raymond Hettinger (rhettinger) Summary: Decimal.py enhancements Initial Comment: Raymond: Changed the _fix and _fixexponents semantics according to how they were used by the module, which simplifies several things (less checks to see if "something" is None, skipped the check for _is_special at the start of _fixexponents, etc...). Also skipped copying ``self`` in _fix() before calling _fixexponents() (which already makes a copy of it). And made some style fixups. The tests passed ok, showing a 4% speedup. I'm posting this like a patch and not doing a direct commit to you to check if another change to the code (with this speedup) is valuable. . Facundo ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2004-10-08 14:50 Message: Logged In: YES user_id=752496 Posting the diff file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1043218&group_id=5470 From noreply at sourceforge.net Fri Oct 8 20:23:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 8 20:23:09 2004 Subject: [Patches] [ python-Patches-1035498 ] -m option to run a module as a script Message-ID: Patches item #1035498, was opened at 2004-09-27 16:22 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: -m option to run a module as a script Initial Comment: Implements the '-m' option recently discussed on python-dev. Runs a module 'as if' it had been invoked from the command line. E.g., for a build directory, the following two commands are equivalent: ./python -m pdb ./python Lib/pdb.py Note that neither of these does the same thing as "./python -c "import pdb". (In this latter case, any "if __name__ == "__main__" code would not be executed, whereas it will be invoked in the first two cases). Given the vagaries of sys.path, this is quite handy - if a module can be imported, it can be easily used as a script too. Not that all modules will necessarily do anything _interesting_ when used as a script. . . The current implementation makes changes to main.c (handle the new argument), pythonrun.[ch] (new flavour of PyRun_) and import.[ch] (expose a PyImport_FindModule C API) Current limitations / to-do if this is pursued: - print sensible errors for non-Python files (e.g. hotshot) - allow 'dotted' names - decide what to do with packages (e.g. run __init__.py) - check usage messages in main.c are all still under 512 characters (I assume that limit was set for a reason) - the 1K limit on absolute file paths seems rather arbitrary. - this is code written in the wee hours of the morning, so it probably has a few other lurking 'features'. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-10-08 20:23 Message: Logged In: YES user_id=11105 Regarding support for packages, here's a use case: python -m pychecker.checker mymodule.py (plus my own tools which live inside packages) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-07 08:46 Message: Logged In: YES user_id=80475 Accepted and applied. Checking in Doc/tut/tut.tex; /cvsroot/python/python/dist/src/Doc/tut/tut.tex,v <-- tut.tex new revision: 1.254; previous revision: 1.253 done Checking in Include/import.h; /cvsroot/python/python/dist/src/Include/import.h,v <-- import.h new revision: 2.30; previous revision: 2.29 done Checking in Misc/NEWS; /cvsroot/python/python/dist/src/Misc/NEWS,v <-- NEWS new revision: 1.1154; previous revision: 1.1153 done Checking in Modules/main.c; /cvsroot/python/python/dist/src/Modules/main.c,v <-- main.c new revision: 1.84; previous revision: 1.83 done Checking in Python/import.c; /cvsroot/python/python/dist/src/Python/import.c,v <-- import.c new revision: 2.240; previous revision: 2.239 cvs diff: [06:46:25] waiting for rhettinger's lock in /cvsroot/python/python/dis t/src/Doc/tut done ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-07 05:36 Message: Logged In: YES user_id=1038590 texcheck complains about the Unicode in the tutorial even on a clean checkout. The line numbers (> 900) are well past the point where I'm editing. (It turns out editing the the tex files works a lot better with xemacs than with the KDE editors - no spurious edits this time) I'm not sure what, if anything, I need to do for "what's new", but I've uploaded a combined code & documentation patch that implements version 7 of the -m behaviour, and makes relevant changes to section 2 of the tutorial. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-07 01:56 Message: Logged In: YES user_id=80475 Please put in a single, combined documentation patch. Be sure to spell-check and run: python -m texcheck tut.tex ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-07 00:24 Message: Logged In: YES user_id=1038590 New version of doc patch which changes the tutorial only (since PyRun_SimpleModule is no longer part of the patch). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-06 23:32 Message: Logged In: YES user_id=1038590 New version (7) attached which does the right thing for "python -tt -m regrtest -u network". (I really like that test case btw - very concise) This one sets argv[0] correctly, but was initially a little ungraceful in some failure modes (such as "python -m parser"). I had to add a new private API function to import.h (_PyImport_IsScript) to clean that up. Examples of the error handling in this version: [...@localhost src]$ ./python -m foo ./python: module foo not found [...@localhost src]$ ./python -m sys ./python: module sys has no associated file [...@localhost src]$ ./python -m parser ./python: module parser not usable as script (/home/.../dev/python/dist/src/build/lib.linux-i686-2.4/parser.so) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-06 20:56 Message: Logged In: YES user_id=1038590 Nice catch. . . I figured out what the problem is - regrtest.py uses sys.argv[0] to delete it's own directory from sys.path. And -m currently sets sys.argv[0] to just 'regrtest', instead of the full path to the module. Obviously, that is going to have to change. Either PyRun_SImpleModule will have to do it, or I'll get rid of that function all together, and put the 'module-finding' logic directly in main.c. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-06 20:09 Message: Logged In: YES user_id=80475 Put the test directory in PYTHONPATH and run the following to see if you get the same results: python -tt -m regrtest -u network python -tt lib\test\regrtest.py -u network ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-06 17:07 Message: Logged In: YES user_id=1038590 New version attached which should fix the Windows compile bug (pythonrun.c does the right thing by undefining BYTE before including windows.h - the inclusion of 'importdl.h' has been moved to be after that 'fixed' include). Unfortunately, I won't get access to a Windows build machine until after the beta 1 deadline, or I'd check it myself :( ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-06 12:58 Message: Logged In: YES user_id=80475 The patch does not compile on windows. AFAICT, importdl.h is the culprit because it loads windows.h for a second time resulting a double redinition of BYTE deep in the bowls of include files. Wish I had time to help you on this one, but I don't. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-10-05 15:15 Message: Logged In: YES user_id=4771 Sorry, I didn't follow any of this discussion, neither here nor in python-dev, so I cannot really comment. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-05 06:32 Message: Logged In: YES user_id=80475 Armin, do you have time for this one. I'm buried for a few days. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-05 01:05 Message: Logged In: YES user_id=1038590 Raymond, Passing to you to see what you think of the code, rather than just the feature in the abstract. Guido settled for not vetoing it, but the discussion with him allowed me to articulate why I think this is a worthwhile feature. (Details at http://mail.python.org/pipermail/python-dev/2004-October/049236.html) Extension to allow packages and zip imports can wait until there is any demand for either feature. I don't really expect to see any, since I think the main uses will be "python -m pdb", "python -m profile" and "python -m timeit". ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 20:21 Message: Logged In: YES user_id=1038590 Doc patch attached. Take it with a grain of salt, since this is the first real doc patch I've made. This doesn't cover anything for 'What's New' - that can wait until the patch gets accepted (if it does). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 19:48 Message: Logged In: YES user_id=1038590 5th version of patch attached - restricts option to top-level modules only. The correct semantics for a module inside a package just aren't clear enough at this stage. Support for dotted names can be added later if this patch gets accepted, and it still seems like a good idea. - adds a missing check from main.c (if we got the module option, don't try to open the file). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 16:30 Message: Logged In: YES user_id=1038590 Relevant documentation locations that I can find: Tutorial section 2.1 (Invoking the Interpreter) Add a very brief description of the '-m' option Python/C API section 2 (The Very High Level Layer) Document PyRun_SimpleModule What's New sections 12 & 13 I'll do this as a separate patch from the previous two, as I can't recall if Andrew prefers to write these himself. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 06:13 Message: Logged In: YES user_id=1038590 New version (#4) Trivial fix - tell PyRun_SimpleFile to close the file when it's done with it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-01 04:51 Message: Logged In: YES user_id=1038590 New version (run_module_3.diff) Takes more account of the file description reported by PyImport. Explictly restricts itself to PY_SOURCE and PY_COMPILED scripts. Behaves correctly when a non-package is encountered while parsing a dotted name (closes the file descriptor and reports an error). I also realised that the '-m' option doesn't currently comprehend "__path__" variables in packages. So maybe we *should* be loading the packages as we find them, and then querying them for their __path__ variable. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 11:48 Message: Logged In: YES user_id=1038590 Barry, kicking this in your direction solely because you were one of the people to comment on it on py-dev. Feel free to say 'too busy' :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 11:39 Message: Logged In: YES user_id=1038590 New version of patch attached (run_module_2.diff). This version allows modules within packages to be executed. It does this *without* loading the packages first (just as if the script were specified directly on the command line). It's also a little more responsive when it comes to error message, and I've confirmed that the usage message components are now under 512 bytes each. The FindModule method is now marked as private (i.e. with leading underscore). The limit on file paths in pythonrun.c is now taken from osdefs.h (the same limit that import.c already uses) The only bug I know of is that it misbehaves if you supply a name like "a.b.module.d". You will get an ImportError saying that d was not found, and the file pointer for 'module' won't get closed properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 From noreply at sourceforge.net Fri Oct 8 22:48:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 8 22:49:03 2004 Subject: [Patches] [ python-Patches-1005857 ] replacing rfc822.formatdate Message-ID: Patches item #1005857, was opened at 2004-08-09 05:31 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005857&group_id=5470 Category: Library (Lib) >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) >Assigned to: Anthony Baxter (anthonybaxter) Summary: replacing rfc822.formatdate Initial Comment: If we're going to deprecate rfc822, we should stop using it. The following patch makes urllib and urllib2 stop using it for date strings. Unfortunately HTTP insists on the "GMT" notation for the timezone, not "-0000"[1], so email.Utils.formatdate grew a new flag "asciigmt". Assigning to Barry, as email is his baby. [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1 ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-10-08 16:48 Message: Logged In: YES user_id=12800 Please include a test case, and add a note to the documentation that asciigmt is only consulted if the localtime flag is true. Also 'asciigmt' looks kind of funny -- how about 'usegmt'? Other than that +1 ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 02:07 Message: Logged In: YES user_id=1038590 I downloaded and applied this without any apparent problems. (I got a failure of test_socketserver when running with -unetwork, but I reverted the patch and confirmed that that was not due to Anthony's patch) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005857&group_id=5470 From noreply at sourceforge.net Fri Oct 8 23:44:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 8 23:44:05 2004 Subject: [Patches] [ python-Patches-1043356 ] Enhancing '-m' to support packages Message-ID: Patches item #1043356, was opened at 2004-10-09 07:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1043356&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Enhancing '-m' to support packages Initial Comment: Thomas Heller posted "python -m pychecker.checker