From noreply at sourceforge.net Tue Feb 1 20:19:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 1 20:19:38 2005 Subject: [Patches] [ python-Patches-1079734 ] Make cgi.py use email instead of rfc822 or mimetools Message-ID: Patches item #1079734, was opened at 2004-12-06 05:22 Message generated for change (Comment added) made by irmen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1079734&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Josh Hoyt (joshhoyt) Assigned to: Johannes Gijsbers (jlgijsbers) Summary: Make cgi.py use email instead of rfc822 or mimetools Initial Comment: Remove dependencies on (deprecated) rfc822 and mimetools modules, replacing with email. ---------------------------------------------------------------------- >Comment By: Irmen de Jong (irmen) Date: 2005-02-01 20:19 Message: Logged In: YES user_id=129426 Umm, I think this patch broke cgi.FieldStorage w/ multipart post requests... see bug #1112856 ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-08 14:56 Message: Logged In: YES user_id=469548 Checked in as rev 1.83 of cgi.py. Thanks for the patch! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1079734&group_id=5470 From noreply at sourceforge.net Wed Feb 2 00:04:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 2 00:04:19 2005 Subject: [Patches] [ python-Patches-1114345 ] Add SSL certificate validation Message-ID: Patches item #1114345, was opened at 2005-02-01 15:04 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=1114345&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: James Eagan (noonian) Assigned to: Nobody/Anonymous (nobody) Summary: Add SSL certificate validation Initial Comment: One line summary: adds certificate validation to the SSL module and programmer-level hooks to control how and whether certificate validation is performed. Details: The current SSL implementation in python goes through the motions of negotiating an SSL connection, but never validates the certificates exchanged. This is like going through the motions of checking someone's photo id, but never making sure the picture matches the person you're talking to. This patch fixes that. This patch adds 3 module-level variables to the socket module, which get exposed iff ssl is built in. These variables (ssl_ca_file, ssl_ca_path, and ssl_verify_level) provide programmer-level access to the certificate authorities database and to control what level of certificate verification is performed (by default, none, as is the current behavior). If certificate verification is enabled, then one of the two certificate authority parameters must be set to a valid certificate authority database or all certificate verification operations will fail. I have an example certificate authority database (extracted from the Java keystore) that I can provide, but I'm not sure how to contribute that through the patch mechanism. Cheers! James Eagan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1114345&group_id=5470 From noreply at sourceforge.net Wed Feb 2 01:50:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 2 01:50:28 2005 Subject: [Patches] [ python-Patches-1100942 ] datetime.strptime constructor added Message-ID: Patches item #1100942, was opened at 2005-01-12 14:53 Message generated for change (Comment added) made by josh-sf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100942&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Josh (josh-sf) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.strptime constructor added Initial Comment: Alllow creating new datetime objects by parsing date strings. datetime already has strftime, so adding strptime is logical. The new constructor is equivalent to datetime(*(time.strptime(date_string, format)[0:6])). Patch includes documentation and unit test. ---------------------------------------------------------------------- >Comment By: Josh (josh-sf) Date: 2005-02-02 00:50 Message: Logged In: YES user_id=1194964 Regarding support by datetime.time and datetime.date, if a date component or a time component is specified, respectively, do you think that we should raise an exception? or should we just ignore it? ---------------------------------------------------------------------- Comment By: Alan Green (alanvgreen) Date: 2005-01-25 12:05 Message: Logged In: YES user_id=1174944 This patch will be welcomed by all of that have had to write "datetime(*(time.strptime(date_string, format)[0:6]))". I don't understand the C API well enough to check if reference counts are handled properly, but otherwise the implementation looks straight forward. Documentation looks good and the test passes on my machine. Two suggestions: 1. In the time module, the strptime() function's format parameter is optional. For consistency's sake, I'd expect datetime.strptime()'s format parameter also to be optional. (On the other hand, the default value for the format is not very useful.) 2. Since strftime is supported by datetime.time, datetime.date and datetime.datetime, I'd also expect strptime to be supported by all three classes. Could you add that now, or would it be better to do it as a separate patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100942&group_id=5470 From noreply at sourceforge.net Wed Feb 2 23:17:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 2 23:17:35 2005 Subject: [Patches] [ python-Patches-1115086 ] support PY_LONGLONG in structmember Message-ID: Patches item #1115086, was opened at 2005-02-02 14:17 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=1115086&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Sam Rushing (rushing) Assigned to: Nobody/Anonymous (nobody) Summary: support PY_LONGLONG in structmember Initial Comment: Adds signed/unsigned PY_LONG_LONG support to structmember. Need this at IronPort for Pyrex extensions that need 64-bit slots. I'm submitting a matching small patch for Pyrex. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1115086&group_id=5470 From noreply at sourceforge.net Wed Feb 2 23:17:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 2 23:17:37 2005 Subject: [Patches] [ python-Patches-936169 ] CodeContext - an extension to show you where you are Message-ID: Patches item #936169, was opened at 2004-04-16 03:40 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936169&group_id=5470 Category: IDLE Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Kurt B. Kaiser (kbk) Summary: CodeContext - an extension to show you where you are Initial Comment: Have you ever edited a code, and did not know exactly which block you were closing? Or didn't know exactly even in which block you were? This extension solves this problem, by adding a few lines (3 by default) above the IDLE edit box, which show you exactly where you are in your code. For example, you may be editing a code with three indentation levels (has three tabs on its left), but to find the reason for this - to find what is the meaning of your block - you have to scroll upwards a long distance. CodeContext will add three lines of text above your edit box, so your editing window will look like this: ---------------------------------- Class MyClass: def myMethod(self, arg1, arg2): <- auto-updated if something_happens: ---------------------------------- i += 1 print "hello" <- You edit here ... ---------------------------------- So you can know that i is incremented by 1, in the method myMethod of class MyClass, and only if something_happens. To make this extension work, you have to put the attached file, CodeContext.py, in your IDLE directory, and add these lines to config-extensions.def: ---------------------------------- [CodeContext] enable=1 numlines=3 bgcolor=LightGray fgcolor=Black ---------------------------------- A note to KBK: I think this extension can go into the Python distribution. If you don't like it, or if you want a testing period, you can put "enable=0" instead of "enable=1". In this way, most users will not even know CodeContext exists, but "power users" will be able to put "enable=1" and have CodeContext if they like it (- I like it). Best wishes, Noam Raphael ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-02 17:17 Message: Logged In: YES user_id=149084 1. Please improve the doc string for interesting_lines(), it's no longer a generator. 2. You removed a comment from update_label() which was helpful when studying the code. What does it do now? 3. The variable 'l' should not be used because it's hard to discriminate from '1'. See PEP 8, Naming Conventions. I suggest 'ln' if it must be short, otherwise 'line' ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2004-09-07 17:42 Message: Logged In: YES user_id=679426 I improved the algorithm for finding the context lines, so it now scans the minimum number of lines it needs in order to update the panel - it uses the information it already has in a better way. This makes the scrolling of long modules more "streaming", on my not-that-new computer. I tried it, and it seems to work just as good as the old algorithm - it produces the same results. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-06-05 20:33 Message: Logged In: YES user_id=149084 Checked in Noam Raphael's improvements. CodeContext.py 1.4 et. al. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2004-04-27 16:24 Message: Logged In: YES user_id=679426 Hello, I think that showing / not showing the Code Context panel should be a persistent setting - if the user wants it, it will appear, and if he doesn't, it won't. The concept of "it has an initial state, and you can change it afterwards if you like" is confusing. Using a persistent setting makes a keyboard shortcut unnecessary - I think that usually the user will be happy with what he likes, and won't hide/show the panel many times. So I made the <> event save the new setting in the user's configuration file. The new setting will be applied also to new windows opened in the same session. This required me to add a SetOption method to configHandler.IdleConf. Also, the initialization of the CodeContext instance required the menu item to be already installed, but EditorWindow.load_extension installs the menu items after it initializes the extension's instance. It turns out that the menu items can be installed before the instance initialization, so I changed it. Another problem was that the Code Context menu item was installed on shell windows, but wasn't functioning, which was quite confusing. So I added new optional configurations for extensions: enable_shell and enable_editor, which allow you to write extensions only for the editor/shell window, without using the "isinstance(editwin, PyShell)" trick. About using a Text widget instead of a Label - it may work, I don't know, but making the Label behave as I wanted was hard enough, and it looks fine to me as it is, so I leave it for now. Bye Bye, Noam ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-04-26 17:28 Message: Logged In: YES user_id=149084 Yeah, I noticed that problem and wasn't sure if I had caused it. Thanks, fixed. CodeContext.py 1.3. Sorry I took so long getting back, for some reason I'm not getting mail from SF when a Tracker item changes (though I don't have a problem sending mail to myself via users.sourceforge.net). I added an entry for Code Context on the Options menu, it toggles the context pane. Any suggestion for a keybinding? A remaining problem is the text in the Label doesn't quite line up with the text in the main pane. Adding a pad of one space makes it almost perfect. But maybe using a Text widget instead of a Label would fix it 100%? ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2004-04-22 15:11 Message: Logged In: YES user_id=679426 I'm glad you like it! Thanks for the changes - your English is certainly better than mine. A buglet you made - in line 91 you added "elif" as a block opener which should show the previous block opener of the same indentation, which is a good idea, but you wrote: if opener == "else" or "elif": which is an expression which always yields True. It caused all block openers to be displayed, not only the relevant ones. Change it to if opener in ("else", "elif"): and it will work fine. Happy Israel Independence Day! (I know you probably don't celebrate it, but it is on 27 April this year) Noam ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-04-21 15:09 Message: Logged In: YES user_id=149084 Cool Extension! Thanks! CodeContext.py 1.1 config-extensions.def 1.13 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936169&group_id=5470 From noreply at sourceforge.net Thu Feb 3 02:37:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 3 02:37:57 2005 Subject: [Patches] [ python-Patches-914546 ] Make history recall a-cyclic Message-ID: Patches item #914546, was opened at 2004-03-11 18:00 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914546&group_id=5470 Category: IDLE Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Kurt B. Kaiser (kbk) Summary: Make history recall a-cyclic Initial Comment: This patch adds an option for idleHistory to be a-cyclic -- holding the Alt-P keys will bring all the commands typed, one by one, and stop at the first one. This, I think, is more intuitive - when history is cyclic, and you press Alt-P continuously, you have no sense of your position, since it's always jumping from end to beginning. That's why I added this option, and that's why I made it a-cyclic by default. The diffs are against idlefork 0.9b1, but work against current idle cvs. Noam ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-02 20:37 Message: Logged In: YES user_id=149084 IdleHistory.py rev 1.5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914546&group_id=5470 From noreply at sourceforge.net Thu Feb 3 19:42:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 3 19:43:00 2005 Subject: [Patches] [ python-Patches-1115631 ] Add SSL certificate validation Message-ID: Patches item #1115631, was opened at 2005-02-03 10:42 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=1115631&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: James Eagan (noonian) Assigned to: Nobody/Anonymous (nobody) Summary: Add SSL certificate validation Initial Comment: One line summary: adds certificate validation to the SSL module and programmer-level hooks to control how and whether certificate validation is performed. Details: The current SSL implementation in python goes through the motions of negotiating an SSL connection, but never validates the certificates exchanged. This is like going through the motions of checking someone's photo id, but never making sure the picture matches the person you're talking to. This patch fixes that. This patch adds 3 module-level variables to the socket module, which get exposed iff ssl is built in. These variables (ssl_ca_file, ssl_ca_path, and ssl_verify_level) provide programmer-level access to the certificate authorities database and to control what level of certificate verification is performed (by default, none, as is the current behavior). If certificate verification is enabled, then one of the two certificate authority parameters must be set to a valid certificate authority database or all certificate verification operations will fail. I have an example certificate authority database (extracted from the Java keystore) that I can provide, but I'm not sure how to contribute that through the patch mechanism. Cheers! James Eagan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1115631&group_id=5470 From noreply at sourceforge.net Thu Feb 3 19:48:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 3 19:48:49 2005 Subject: [Patches] [ python-Patches-1115631 ] Add SSL certificate validation Message-ID: Patches item #1115631, was opened at 2005-02-03 13:42 Message generated for change (Comment added) made by holdenweb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1115631&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: James Eagan (noonian) Assigned to: Nobody/Anonymous (nobody) Summary: Add SSL certificate validation Initial Comment: One line summary: adds certificate validation to the SSL module and programmer-level hooks to control how and whether certificate validation is performed. Details: The current SSL implementation in python goes through the motions of negotiating an SSL connection, but never validates the certificates exchanged. This is like going through the motions of checking someone's photo id, but never making sure the picture matches the person you're talking to. This patch fixes that. This patch adds 3 module-level variables to the socket module, which get exposed iff ssl is built in. These variables (ssl_ca_file, ssl_ca_path, and ssl_verify_level) provide programmer-level access to the certificate authorities database and to control what level of certificate verification is performed (by default, none, as is the current behavior). If certificate verification is enabled, then one of the two certificate authority parameters must be set to a valid certificate authority database or all certificate verification operations will fail. I have an example certificate authority database (extracted from the Java keystore) that I can provide, but I'm not sure how to contribute that through the patch mechanism. Cheers! James Eagan ---------------------------------------------------------------------- >Comment By: Steve Holden (holdenweb) Date: 2005-02-03 13:48 Message: Logged In: YES user_id=88157 How does this differ from 1114345? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1115631&group_id=5470 From noreply at sourceforge.net Thu Feb 3 20:00:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 3 20:00:41 2005 Subject: [Patches] [ python-Patches-1115631 ] Add SSL certificate validation Message-ID: Patches item #1115631, was opened at 2005-02-03 10:42 Message generated for change (Comment added) made by noonian You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1115631&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: James Eagan (noonian) Assigned to: Nobody/Anonymous (nobody) Summary: Add SSL certificate validation Initial Comment: One line summary: adds certificate validation to the SSL module and programmer-level hooks to control how and whether certificate validation is performed. Details: The current SSL implementation in python goes through the motions of negotiating an SSL connection, but never validates the certificates exchanged. This is like going through the motions of checking someone's photo id, but never making sure the picture matches the person you're talking to. This patch fixes that. This patch adds 3 module-level variables to the socket module, which get exposed iff ssl is built in. These variables (ssl_ca_file, ssl_ca_path, and ssl_verify_level) provide programmer-level access to the certificate authorities database and to control what level of certificate verification is performed (by default, none, as is the current behavior). If certificate verification is enabled, then one of the two certificate authority parameters must be set to a valid certificate authority database or all certificate verification operations will fail. I have an example certificate authority database (extracted from the Java keystore) that I can provide, but I'm not sure how to contribute that through the patch mechanism. Cheers! James Eagan ---------------------------------------------------------------------- >Comment By: James Eagan (noonian) Date: 2005-02-03 11:00 Message: Logged In: YES user_id=31389 Uh, it doesn't. It was a user error/refresh bug with me and my web browser. Sorry 'bout that. ---------------------------------------------------------------------- Comment By: Steve Holden (holdenweb) Date: 2005-02-03 10:48 Message: Logged In: YES user_id=88157 How does this differ from 1114345? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1115631&group_id=5470 From noreply at sourceforge.net Fri Feb 4 01:17:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 4 01:17:39 2005 Subject: [Patches] [ python-Patches-936169 ] CodeContext - an extension to show you where you are Message-ID: Patches item #936169, was opened at 2004-04-16 11:40 Message generated for change (Comment added) made by noamr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936169&group_id=5470 Category: IDLE Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Kurt B. Kaiser (kbk) Summary: CodeContext - an extension to show you where you are Initial Comment: Have you ever edited a code, and did not know exactly which block you were closing? Or didn't know exactly even in which block you were? This extension solves this problem, by adding a few lines (3 by default) above the IDLE edit box, which show you exactly where you are in your code. For example, you may be editing a code with three indentation levels (has three tabs on its left), but to find the reason for this - to find what is the meaning of your block - you have to scroll upwards a long distance. CodeContext will add three lines of text above your edit box, so your editing window will look like this: ---------------------------------- Class MyClass: def myMethod(self, arg1, arg2): <- auto-updated if something_happens: ---------------------------------- i += 1 print "hello" <- You edit here ... ---------------------------------- So you can know that i is incremented by 1, in the method myMethod of class MyClass, and only if something_happens. To make this extension work, you have to put the attached file, CodeContext.py, in your IDLE directory, and add these lines to config-extensions.def: ---------------------------------- [CodeContext] enable=1 numlines=3 bgcolor=LightGray fgcolor=Black ---------------------------------- A note to KBK: I think this extension can go into the Python distribution. If you don't like it, or if you want a testing period, you can put "enable=0" instead of "enable=1". In this way, most users will not even know CodeContext exists, but "power users" will be able to put "enable=1" and have CodeContext if they like it (- I like it). Best wishes, Noam Raphael ---------------------------------------------------------------------- >Comment By: Noam Raphael (noamr) Date: 2005-02-04 02:17 Message: Logged In: YES user_id=679426 Thanks for your comments. What do you think of the new patch? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-03 00:17 Message: Logged In: YES user_id=149084 1. Please improve the doc string for interesting_lines(), it's no longer a generator. 2. You removed a comment from update_label() which was helpful when studying the code. What does it do now? 3. The variable 'l' should not be used because it's hard to discriminate from '1'. See PEP 8, Naming Conventions. I suggest 'ln' if it must be short, otherwise 'line' ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2004-09-08 01:42 Message: Logged In: YES user_id=679426 I improved the algorithm for finding the context lines, so it now scans the minimum number of lines it needs in order to update the panel - it uses the information it already has in a better way. This makes the scrolling of long modules more "streaming", on my not-that-new computer. I tried it, and it seems to work just as good as the old algorithm - it produces the same results. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-06-06 04:33 Message: Logged In: YES user_id=149084 Checked in Noam Raphael's improvements. CodeContext.py 1.4 et. al. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2004-04-28 00:24 Message: Logged In: YES user_id=679426 Hello, I think that showing / not showing the Code Context panel should be a persistent setting - if the user wants it, it will appear, and if he doesn't, it won't. The concept of "it has an initial state, and you can change it afterwards if you like" is confusing. Using a persistent setting makes a keyboard shortcut unnecessary - I think that usually the user will be happy with what he likes, and won't hide/show the panel many times. So I made the <> event save the new setting in the user's configuration file. The new setting will be applied also to new windows opened in the same session. This required me to add a SetOption method to configHandler.IdleConf. Also, the initialization of the CodeContext instance required the menu item to be already installed, but EditorWindow.load_extension installs the menu items after it initializes the extension's instance. It turns out that the menu items can be installed before the instance initialization, so I changed it. Another problem was that the Code Context menu item was installed on shell windows, but wasn't functioning, which was quite confusing. So I added new optional configurations for extensions: enable_shell and enable_editor, which allow you to write extensions only for the editor/shell window, without using the "isinstance(editwin, PyShell)" trick. About using a Text widget instead of a Label - it may work, I don't know, but making the Label behave as I wanted was hard enough, and it looks fine to me as it is, so I leave it for now. Bye Bye, Noam ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-04-27 01:28 Message: Logged In: YES user_id=149084 Yeah, I noticed that problem and wasn't sure if I had caused it. Thanks, fixed. CodeContext.py 1.3. Sorry I took so long getting back, for some reason I'm not getting mail from SF when a Tracker item changes (though I don't have a problem sending mail to myself via users.sourceforge.net). I added an entry for Code Context on the Options menu, it toggles the context pane. Any suggestion for a keybinding? A remaining problem is the text in the Label doesn't quite line up with the text in the main pane. Adding a pad of one space makes it almost perfect. But maybe using a Text widget instead of a Label would fix it 100%? ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2004-04-22 23:11 Message: Logged In: YES user_id=679426 I'm glad you like it! Thanks for the changes - your English is certainly better than mine. A buglet you made - in line 91 you added "elif" as a block opener which should show the previous block opener of the same indentation, which is a good idea, but you wrote: if opener == "else" or "elif": which is an expression which always yields True. It caused all block openers to be displayed, not only the relevant ones. Change it to if opener in ("else", "elif"): and it will work fine. Happy Israel Independence Day! (I know you probably don't celebrate it, but it is on 27 April this year) Noam ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-04-21 23:09 Message: Logged In: YES user_id=149084 Cool Extension! Thanks! CodeContext.py 1.1 config-extensions.def 1.13 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936169&group_id=5470 From noreply at sourceforge.net Fri Feb 4 02:02:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 4 02:03:00 2005 Subject: [Patches] [ python-Patches-989712 ] Support using Tk without a mainloop Message-ID: Patches item #989712, was opened at 2004-07-12 15:16 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=989712&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Kurt B. Kaiser (kbk) Summary: Support using Tk without a mainloop Initial Comment: In the regular python shell, you can open Tk windows, and they will operate even though you didn't call Tkinter.mainloop(). This is useful, for example, when you manipulate matplotlib graphs from within the python shell. This is done by a hook, installed when a tkapp object is being initialized, which handles Tk events while the shell is waiting for user input. I imitated this behaviour in IDLE: When the subprocess is idle, it checks whether Tkinter._default_root is set (this happens when the Tkinter.Tk class, which makes a tkapp object, is initialized, unless Tkinter._use_default_root is False), and if so, handles Tk events. For me it works very well. Have a good day, Noam Raphael ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-03 20:02 Message: Logged In: YES user_id=149084 Hm, this seems closely related to Bug 798058 I'd lost track of it because it got switched to tkinter. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2005-01-30 06:58 Message: Logged In: YES user_id=679426 in _tkinter.c, look for EventHook - you'll find the EventHook function, which is called when the interpreter is idle, and the Enable/Disable EventHook functions. In readline.c, line 765, you'll find the call to PyOS_InputHook, when waiting for input. Perhaps a more general approach would be to let Python code call PyOS_InputHook, for example, by defining readline.call_input_hook() and readline.has_input_hook(). Then IDLE would be able to call them when idle, with no Tkinter-specific code. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-07-14 15:44 Message: Logged In: YES user_id=149084 Can you give me some more information on the hook in the Python interpreter? Where is it in the code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=989712&group_id=5470 From noreply at sourceforge.net Fri Feb 4 14:08:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 4 14:08:42 2005 Subject: [Patches] [ python-Patches-989712 ] Support using Tk without a mainloop Message-ID: Patches item #989712, was opened at 2004-07-13 05:16 Message generated for change (Comment added) made by mdehoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=989712&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Kurt B. Kaiser (kbk) Summary: Support using Tk without a mainloop Initial Comment: In the regular python shell, you can open Tk windows, and they will operate even though you didn't call Tkinter.mainloop(). This is useful, for example, when you manipulate matplotlib graphs from within the python shell. This is done by a hook, installed when a tkapp object is being initialized, which handles Tk events while the shell is waiting for user input. I imitated this behaviour in IDLE: When the subprocess is idle, it checks whether Tkinter._default_root is set (this happens when the Tkinter.Tk class, which makes a tkapp object, is initialized, unless Tkinter._use_default_root is False), and if so, handles Tk events. For me it works very well. Have a good day, Noam Raphael ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-04 22:08 Message: Logged In: YES user_id=488897 I agree, this is basically the same bug as #798058. The call to readline.call_input_hook sounds like a good solution. But the hook function should be different than the current EventHook in _tkinter.c. That hook function sits in a loop until a keyboard event is noticed. A problem occurs if there is more than one hook function. Currently, that is not possible in Python, since there is only one PyOS_InputHook. I am working on a patch in which PyOS_InputHook is replaced by PyOS_AddInputHook and PyOS_RemoveInputHook, so that there can be more than one hook functions. Now suppose that there is one hook function to handle Tk events, and another one e.g. handling messages to windows in Microsoft Windows. (This is a real issue for one of my extension modules). If python sits in a loop in _tkinter.c's EventHook until a key is pressed, the MS windows won't get their messages. The following structure might work better: while(there is no keyboard input or other interesting event) { Call PyOS_InputHook #1 Call PyOS_InputHook #2 etc. } where each of the PyOS_InputHook functions should return if there is no more work for them. The tricky part is to find out which events to wait for; some of the events may be handled by one of the PyOS_InputHook functions. Obviously I need to do some more thinking about this. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-04 10:02 Message: Logged In: YES user_id=149084 Hm, this seems closely related to Bug 798058 I'd lost track of it because it got switched to tkinter. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2005-01-30 20:58 Message: Logged In: YES user_id=679426 in _tkinter.c, look for EventHook - you'll find the EventHook function, which is called when the interpreter is idle, and the Enable/Disable EventHook functions. In readline.c, line 765, you'll find the call to PyOS_InputHook, when waiting for input. Perhaps a more general approach would be to let Python code call PyOS_InputHook, for example, by defining readline.call_input_hook() and readline.has_input_hook(). Then IDLE would be able to call them when idle, with no Tkinter-specific code. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-07-15 05:44 Message: Logged In: YES user_id=149084 Can you give me some more information on the hook in the Python interpreter? Where is it in the code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=989712&group_id=5470 From noreply at sourceforge.net Fri Feb 4 19:16:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 4 19:16:39 2005 Subject: [Patches] [ python-Patches-1116362 ] date.strptime and time.strptime as well Message-ID: Patches item #1116362, was opened at 2005-02-04 18:16 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=1116362&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josh (josh-sf) Assigned to: Nobody/Anonymous (nobody) Summary: date.strptime and time.strptime as well Initial Comment: Add strptime constructor to date and time as well as datetime. This patch is really a followup to http://sourceforge.net/tracker/index.php?func=detail&aid=1100942&group_id=5470&atid=305470 , but re-posted here in order to attract attention :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116362&group_id=5470 From noreply at sourceforge.net Fri Feb 4 20:52:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 4 20:52:49 2005 Subject: [Patches] [ python-Patches-1115631 ] Add SSL certificate validation Message-ID: Patches item #1115631, was opened at 2005-02-03 13:42 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1115631&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: James Eagan (noonian) Assigned to: Nobody/Anonymous (nobody) Summary: Add SSL certificate validation Initial Comment: One line summary: adds certificate validation to the SSL module and programmer-level hooks to control how and whether certificate validation is performed. Details: The current SSL implementation in python goes through the motions of negotiating an SSL connection, but never validates the certificates exchanged. This is like going through the motions of checking someone's photo id, but never making sure the picture matches the person you're talking to. This patch fixes that. This patch adds 3 module-level variables to the socket module, which get exposed iff ssl is built in. These variables (ssl_ca_file, ssl_ca_path, and ssl_verify_level) provide programmer-level access to the certificate authorities database and to control what level of certificate verification is performed (by default, none, as is the current behavior). If certificate verification is enabled, then one of the two certificate authority parameters must be set to a valid certificate authority database or all certificate verification operations will fail. I have an example certificate authority database (extracted from the Java keystore) that I can provide, but I'm not sure how to contribute that through the patch mechanism. Cheers! James Eagan ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-04 14:52 Message: Logged In: YES user_id=593130 So please close this one as 'duplicate' or the closest thing thereto, such as 'invalid'. ---------------------------------------------------------------------- Comment By: James Eagan (noonian) Date: 2005-02-03 14:00 Message: Logged In: YES user_id=31389 Uh, it doesn't. It was a user error/refresh bug with me and my web browser. Sorry 'bout that. ---------------------------------------------------------------------- Comment By: Steve Holden (holdenweb) Date: 2005-02-03 13:48 Message: Logged In: YES user_id=88157 How does this differ from 1114345? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1115631&group_id=5470 From noreply at sourceforge.net Fri Feb 4 21:26:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 4 21:26:15 2005 Subject: [Patches] [ python-Patches-1115631 ] Add SSL certificate validation Message-ID: Patches item #1115631, was opened at 2005-02-03 10:42 Message generated for change (Settings changed) made by noonian You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1115631&group_id=5470 Category: Modules Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: James Eagan (noonian) Assigned to: Nobody/Anonymous (nobody) Summary: Add SSL certificate validation Initial Comment: One line summary: adds certificate validation to the SSL module and programmer-level hooks to control how and whether certificate validation is performed. Details: The current SSL implementation in python goes through the motions of negotiating an SSL connection, but never validates the certificates exchanged. This is like going through the motions of checking someone's photo id, but never making sure the picture matches the person you're talking to. This patch fixes that. This patch adds 3 module-level variables to the socket module, which get exposed iff ssl is built in. These variables (ssl_ca_file, ssl_ca_path, and ssl_verify_level) provide programmer-level access to the certificate authorities database and to control what level of certificate verification is performed (by default, none, as is the current behavior). If certificate verification is enabled, then one of the two certificate authority parameters must be set to a valid certificate authority database or all certificate verification operations will fail. I have an example certificate authority database (extracted from the Java keystore) that I can provide, but I'm not sure how to contribute that through the patch mechanism. Cheers! James Eagan ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-04 11:52 Message: Logged In: YES user_id=593130 So please close this one as 'duplicate' or the closest thing thereto, such as 'invalid'. ---------------------------------------------------------------------- Comment By: James Eagan (noonian) Date: 2005-02-03 11:00 Message: Logged In: YES user_id=31389 Uh, it doesn't. It was a user error/refresh bug with me and my web browser. Sorry 'bout that. ---------------------------------------------------------------------- Comment By: Steve Holden (holdenweb) Date: 2005-02-03 10:48 Message: Logged In: YES user_id=88157 How does this differ from 1114345? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1115631&group_id=5470 From noreply at sourceforge.net Fri Feb 4 21:30:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 4 21:30:26 2005 Subject: [Patches] [ python-Patches-1115631 ] Add SSL certificate validation Message-ID: Patches item #1115631, was opened at 2005-02-03 10:42 Message generated for change (Settings changed) made by noonian You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1115631&group_id=5470 Category: Modules Group: None Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: James Eagan (noonian) Assigned to: Nobody/Anonymous (nobody) Summary: Add SSL certificate validation Initial Comment: One line summary: adds certificate validation to the SSL module and programmer-level hooks to control how and whether certificate validation is performed. Details: The current SSL implementation in python goes through the motions of negotiating an SSL connection, but never validates the certificates exchanged. This is like going through the motions of checking someone's photo id, but never making sure the picture matches the person you're talking to. This patch fixes that. This patch adds 3 module-level variables to the socket module, which get exposed iff ssl is built in. These variables (ssl_ca_file, ssl_ca_path, and ssl_verify_level) provide programmer-level access to the certificate authorities database and to control what level of certificate verification is performed (by default, none, as is the current behavior). If certificate verification is enabled, then one of the two certificate authority parameters must be set to a valid certificate authority database or all certificate verification operations will fail. I have an example certificate authority database (extracted from the Java keystore) that I can provide, but I'm not sure how to contribute that through the patch mechanism. Cheers! James Eagan ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-04 11:52 Message: Logged In: YES user_id=593130 So please close this one as 'duplicate' or the closest thing thereto, such as 'invalid'. ---------------------------------------------------------------------- Comment By: James Eagan (noonian) Date: 2005-02-03 11:00 Message: Logged In: YES user_id=31389 Uh, it doesn't. It was a user error/refresh bug with me and my web browser. Sorry 'bout that. ---------------------------------------------------------------------- Comment By: Steve Holden (holdenweb) Date: 2005-02-03 10:48 Message: Logged In: YES user_id=88157 How does this differ from 1114345? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1115631&group_id=5470 From noreply at sourceforge.net Sat Feb 5 00:10:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 5 00:10:46 2005 Subject: [Patches] [ python-Patches-1053150 ] urllib2: better import ftplib and gopherlib etc late Message-ID: Patches item #1053150, was opened at 2004-10-24 12:50 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1053150&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Kiendl (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2: better import ftplib and gopherlib etc late Initial Comment: importing those libs like (ftplib, gopherlib, ..) unconditionally on top of urllib2 slows down and hinders distributing small app packages (py2exe'd, mcm.installer, ...). simple patch in attachment ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-04 23:10 Message: Logged In: YES user_id=261020 Looks good to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1053150&group_id=5470 From noreply at sourceforge.net Sat Feb 5 01:40:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 5 01:40:41 2005 Subject: [Patches] [ python-Patches-1116583 ] NameError in cookielib domain check Message-ID: Patches item #1116583, was opened at 2005-02-04 19: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=1116583&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Chad Miller (chadmiller) Assigned to: Nobody/Anonymous (nobody) Summary: NameError in cookielib domain check Initial Comment: Some cookies trigger this cookielib bug. The bug is analogous to... if a == ...: new_a = a + other_value if new_a ... : foo() But, "new_a" doesn't exist if the first condition fails. I included a lot of lines of context to show that it's correct without having to see surrounding code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116583&group_id=5470 From noreply at sourceforge.net Sat Feb 5 02:01:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 5 02:01:14 2005 Subject: [Patches] [ python-Patches-1116583 ] NameError in cookielib domain check Message-ID: Patches item #1116583, was opened at 2005-02-04 19:40 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116583&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Chad Miller (chadmiller) >Assigned to: Raymond Hettinger (rhettinger) Summary: NameError in cookielib domain check Initial Comment: Some cookies trigger this cookielib bug. The bug is analogous to... if a == ...: new_a = a + other_value if new_a ... : foo() But, "new_a" doesn't exist if the first condition fails. I included a lot of lines of context to show that it's correct without having to see surrounding code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116583&group_id=5470 From noreply at sourceforge.net Sat Feb 5 02:33:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 5 02:33:47 2005 Subject: [Patches] [ python-Patches-1116583 ] NameError in cookielib domain check Message-ID: Patches item #1116583, was opened at 2005-02-04 19:40 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116583&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Chad Miller (chadmiller) Assigned to: Raymond Hettinger (rhettinger) Summary: NameError in cookielib domain check Initial Comment: Some cookies trigger this cookielib bug. The bug is analogous to... if a == ...: new_a = a + other_value if new_a ... : foo() But, "new_a" doesn't exist if the first condition fails. I included a lot of lines of context to show that it's correct without having to see surrounding code. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-04 20:33 Message: Logged In: YES user_id=80475 Applied to Lib/cookielib.py 1.5 and 1.4.2.1 Thanks for the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116583&group_id=5470 From noreply at sourceforge.net Sat Feb 5 02:43:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 5 02:43:53 2005 Subject: [Patches] [ python-Patches-1028908 ] Changes to cookielib.py & friends for 2.4b1 Message-ID: Patches item #1028908, was opened at 2004-09-15 19:19 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1028908&group_id=5470 Category: Library (Lib) >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Jeremy Hylton (jhylton) Summary: Changes to cookielib.py & friends for 2.4b1 Initial Comment: The patch contains uncontroversial changes to cookielib and associated modules, documentation and tests. Would be unfortunate not to have these in 2.4.0. 1. Changes to keep cookielib in sync with ClientCookie 1.0 release. This will make life simpler for people migrating from ClientCookie (the package from whence cookielib, and some recent urllib2 changes, came). a. Moved country-code pseudo-top-level domain (eg. .co.uk) code into a separate method of DefaultCookiePolicy to make life easier for subclassers (.set_ok_countrycode_domain()). b. Added Cookie.nonstandard_attr_keys() method. 2. Added a new test. 3. Documentation corrections and clarifications (including adding a prominent warning about current lack of thread-safety, and a new example). 4. Small-scale refactoring in cookielib.py (including moving magic_re to its rightful place in _LWPCookieJar.py). 5. Tiny code clarification in urllib2.py. 6. Removed coding declaration from test_cookielib.py, in favour of escape sequences, since I discovered that I don't understand coding declarations :-/ ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-04 20:43 Message: Logged In: YES user_id=80475 A new method is not okay for 2.4.1. The doc changes should be reviewed carefully. At first glance, some appear to be unnecessary rewordings that do not add new new information. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2004-12-23 07:35 Message: Logged In: YES user_id=261020 Yes, it's safe for 2.4.1. There's one new method, but I guess that's OK? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2004-12-22 09:41 Message: Logged In: YES user_id=31392 Is it safe to add these as bug fixes for 2.4.1? It looks okay to me, but I wanted to be sure that wasn't some API change that was signficant. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2004-12-19 02:35 Message: Logged In: YES user_id=23486 Applied patch & ran 'make test' under Linux with latest from CVS. Everything works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1028908&group_id=5470 From noreply at sourceforge.net Sat Feb 5 02:48:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 5 02:48:28 2005 Subject: [Patches] [ python-Patches-1049855 ] PyOS_InputHook inconsistency on Windows Message-ID: Patches item #1049855, was opened at 2004-10-19 04:03 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1049855&group_id=5470 >Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) >Assigned to: Kurt B. Kaiser (kbk) Summary: PyOS_InputHook inconsistency on Windows Initial Comment: PyOS_InputHook is a pointer to a function to be called periodically when Python is idle. It is used, for example, to get messages delivered to graphics windows. If I compile Python from source (which uses Modules/readline.c), PyOS_InputHook is called ten times per second. However, with the Windows-version of Python, PyOS_InputHook is called only once for each command typed by the user. It seems that the problem resides in Parser/myreadline.c (which I presume is used for the Windows-version of Python): if (PyOS_InputHook != NULL) (void)(PyOS_InputHook)(); ... p = fgets(buf, len, fp); Python idles at "fgets", but PyOS_InputHook is not being called while Python is idle. The attached patch solves this problem by using the "select" function, basically in the same way as what is in Module/readline.c. I don't know how to compile Python for Windows, so I wasn't able to test this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1049855&group_id=5470 From noreply at sourceforge.net Sat Feb 5 13:54:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 5 13:54:28 2005 Subject: [Patches] [ python-Patches-1028908 ] Changes to cookielib.py & friends for 2.4b1 Message-ID: Patches item #1028908, was opened at 2004-09-16 01:19 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1028908&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Jeremy Hylton (jhylton) Summary: Changes to cookielib.py & friends for 2.4b1 Initial Comment: The patch contains uncontroversial changes to cookielib and associated modules, documentation and tests. Would be unfortunate not to have these in 2.4.0. 1. Changes to keep cookielib in sync with ClientCookie 1.0 release. This will make life simpler for people migrating from ClientCookie (the package from whence cookielib, and some recent urllib2 changes, came). a. Moved country-code pseudo-top-level domain (eg. .co.uk) code into a separate method of DefaultCookiePolicy to make life easier for subclassers (.set_ok_countrycode_domain()). b. Added Cookie.nonstandard_attr_keys() method. 2. Added a new test. 3. Documentation corrections and clarifications (including adding a prominent warning about current lack of thread-safety, and a new example). 4. Small-scale refactoring in cookielib.py (including moving magic_re to its rightful place in _LWPCookieJar.py). 5. Tiny code clarification in urllib2.py. 6. Removed coding declaration from test_cookielib.py, in favour of escape sequences, since I discovered that I don't understand coding declarations :-/ ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2005-02-05 12:54 Message: Logged In: YES user_id=261020 New method (actually, there are two, I see on re-checking -- (a) and (b) in my list above): understood. Will submit revised patch without them, and a separate patch for 2.5 with only the new methods. Docs: I have verified that none of these are unnecessary rewordings. Some are fixes for typos or bad English. Most of the rest are of minor clarifications or corrections, but are solid improvements. Please point out specific changes whose value you doubt, and I will explain (or remove if persuaded, of course)! ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-05 01:43 Message: Logged In: YES user_id=80475 A new method is not okay for 2.4.1. The doc changes should be reviewed carefully. At first glance, some appear to be unnecessary rewordings that do not add new new information. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2004-12-23 12:35 Message: Logged In: YES user_id=261020 Yes, it's safe for 2.4.1. There's one new method, but I guess that's OK? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2004-12-22 14:41 Message: Logged In: YES user_id=31392 Is it safe to add these as bug fixes for 2.4.1? It looks okay to me, but I wanted to be sure that wasn't some API change that was signficant. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2004-12-19 07:35 Message: Logged In: YES user_id=23486 Applied patch & ran 'make test' under Linux with latest from CVS. Everything works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1028908&group_id=5470 From noreply at sourceforge.net Sat Feb 5 15:42:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 5 15:42:25 2005 Subject: [Patches] [ python-Patches-1028908 ] Changes to cookielib.py & friends for 2.4b1 Message-ID: Patches item #1028908, was opened at 2004-09-15 19:19 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1028908&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Jeremy Hylton (jhylton) Summary: Changes to cookielib.py & friends for 2.4b1 Initial Comment: The patch contains uncontroversial changes to cookielib and associated modules, documentation and tests. Would be unfortunate not to have these in 2.4.0. 1. Changes to keep cookielib in sync with ClientCookie 1.0 release. This will make life simpler for people migrating from ClientCookie (the package from whence cookielib, and some recent urllib2 changes, came). a. Moved country-code pseudo-top-level domain (eg. .co.uk) code into a separate method of DefaultCookiePolicy to make life easier for subclassers (.set_ok_countrycode_domain()). b. Added Cookie.nonstandard_attr_keys() method. 2. Added a new test. 3. Documentation corrections and clarifications (including adding a prominent warning about current lack of thread-safety, and a new example). 4. Small-scale refactoring in cookielib.py (including moving magic_re to its rightful place in _LWPCookieJar.py). 5. Tiny code clarification in urllib2.py. 6. Removed coding declaration from test_cookielib.py, in favour of escape sequences, since I discovered that I don't understand coding declarations :-/ ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-05 09:42 Message: Logged In: YES user_id=80475 Applied the urllib2 portion as Lib/urllib2.py 1.80. Leaving the rest for Jeremy to see if he finds sufficient improvement to warrant API changes. FWIW, I think the thread-safety comment should be omitted or reworded positively (i.e. resource locks are needed when cookielib is used in a multi-threaded environment). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-05 07:54 Message: Logged In: YES user_id=261020 New method (actually, there are two, I see on re-checking -- (a) and (b) in my list above): understood. Will submit revised patch without them, and a separate patch for 2.5 with only the new methods. Docs: I have verified that none of these are unnecessary rewordings. Some are fixes for typos or bad English. Most of the rest are of minor clarifications or corrections, but are solid improvements. Please point out specific changes whose value you doubt, and I will explain (or remove if persuaded, of course)! ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-04 20:43 Message: Logged In: YES user_id=80475 A new method is not okay for 2.4.1. The doc changes should be reviewed carefully. At first glance, some appear to be unnecessary rewordings that do not add new new information. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2004-12-23 07:35 Message: Logged In: YES user_id=261020 Yes, it's safe for 2.4.1. There's one new method, but I guess that's OK? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2004-12-22 09:41 Message: Logged In: YES user_id=31392 Is it safe to add these as bug fixes for 2.4.1? It looks okay to me, but I wanted to be sure that wasn't some API change that was signficant. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2004-12-19 02:35 Message: Logged In: YES user_id=23486 Applied patch & ran 'make test' under Linux with latest from CVS. Everything works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1028908&group_id=5470 From b-pop at radar.axi.fr Thu Feb 3 20:01:30 2005 From: b-pop at radar.axi.fr (PopList) Date: Sat Feb 5 18:50:18 2005 Subject: [Patches] PopList vous fait gagner 2000 euros ! Message-ID: Votre client mail ne lit pas les messages HTML. Copier coller cet url dans votre navigateur web: http://www.axipub.com/mirroir/EMM-WjMGKi.php -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20050203/69a5b906/attachment.htm From noreply at sourceforge.net Sun Feb 6 03:19:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 6 03:19:50 2005 Subject: [Patches] [ python-Patches-1028908 ] Changes to cookielib.py & friends for 2.4b1 Message-ID: Patches item #1028908, was opened at 2004-09-16 01:19 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1028908&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) >Assigned to: Nobody/Anonymous (nobody) Summary: Changes to cookielib.py & friends for 2.4b1 Initial Comment: The patch contains uncontroversial changes to cookielib and associated modules, documentation and tests. Would be unfortunate not to have these in 2.4.0. 1. Changes to keep cookielib in sync with ClientCookie 1.0 release. This will make life simpler for people migrating from ClientCookie (the package from whence cookielib, and some recent urllib2 changes, came). a. Moved country-code pseudo-top-level domain (eg. .co.uk) code into a separate method of DefaultCookiePolicy to make life easier for subclassers (.set_ok_countrycode_domain()). b. Added Cookie.nonstandard_attr_keys() method. 2. Added a new test. 3. Documentation corrections and clarifications (including adding a prominent warning about current lack of thread-safety, and a new example). 4. Small-scale refactoring in cookielib.py (including moving magic_re to its rightful place in _LWPCookieJar.py). 5. Tiny code clarification in urllib2.py. 6. Removed coding declaration from test_cookielib.py, in favour of escape sequences, since I discovered that I don't understand coding declarations :-/ ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2005-02-06 02:19 Message: Logged In: YES user_id=261020 The problem with the thread issue is that -- as I drew attention to when the module was considered for addition to stdlib -- there is thread synchronization in there, but it is untested, and I now strongly suspect is broken. I'm not thread-competent enough to be confident in my testing of any fix I might attempt. I now regret not simply stripping all the thread synchronization out from the start. Perhaps that should be done now, and a comment like that you suggest added? Advice here is most welcome! Re the rest: As per my last comment, will resubmit API changes (ie. method additions) as separate patch for 2.5. I'll split the rest up into separate patches, too. Therefore, I'm unassigning Jeremy and will close this patch when I've opened the new ones. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-05 14:42 Message: Logged In: YES user_id=80475 Applied the urllib2 portion as Lib/urllib2.py 1.80. Leaving the rest for Jeremy to see if he finds sufficient improvement to warrant API changes. FWIW, I think the thread-safety comment should be omitted or reworded positively (i.e. resource locks are needed when cookielib is used in a multi-threaded environment). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-05 12:54 Message: Logged In: YES user_id=261020 New method (actually, there are two, I see on re-checking -- (a) and (b) in my list above): understood. Will submit revised patch without them, and a separate patch for 2.5 with only the new methods. Docs: I have verified that none of these are unnecessary rewordings. Some are fixes for typos or bad English. Most of the rest are of minor clarifications or corrections, but are solid improvements. Please point out specific changes whose value you doubt, and I will explain (or remove if persuaded, of course)! ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-05 01:43 Message: Logged In: YES user_id=80475 A new method is not okay for 2.4.1. The doc changes should be reviewed carefully. At first glance, some appear to be unnecessary rewordings that do not add new new information. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2004-12-23 12:35 Message: Logged In: YES user_id=261020 Yes, it's safe for 2.4.1. There's one new method, but I guess that's OK? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2004-12-22 14:41 Message: Logged In: YES user_id=31392 Is it safe to add these as bug fixes for 2.4.1? It looks okay to me, but I wanted to be sure that wasn't some API change that was signficant. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2004-12-19 07:35 Message: Logged In: YES user_id=23486 Applied patch & ran 'make test' under Linux with latest from CVS. Everything works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1028908&group_id=5470 From noreply at sourceforge.net Sun Feb 6 03:28:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 6 03:28:57 2005 Subject: [Patches] [ python-Patches-1117114 ] Minor improvement on 1116583 Message-ID: Patches item #1117114, was opened at 2005-02-06 02:28 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=1117114&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: Minor improvement on 1116583 Initial Comment: Minor improvement on 1116583. Patch applies to CVS HEAD. See comments in original bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117114&group_id=5470 From noreply at sourceforge.net Sun Feb 6 03:44:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 6 03:44:14 2005 Subject: [Patches] [ python-Patches-1116583 ] NameError in cookielib domain check Message-ID: Patches item #1116583, was opened at 2005-02-05 00:40 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116583&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Chad Miller (chadmiller) Assigned to: Raymond Hettinger (rhettinger) Summary: NameError in cookielib domain check Initial Comment: Some cookies trigger this cookielib bug. The bug is analogous to... if a == ...: new_a = a + other_value if new_a ... : foo() But, "new_a" doesn't exist if the first condition fails. I included a lot of lines of context to show that it's correct without having to see surrounding code. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-06 02:44 Message: Logged In: YES user_id=261020 Well spotted, Chad. However, I am unable to see how this bug ever causes an exception in practice: witness test_cookielib.CookieTests.test_domain_return_ok(). The reason is that neither the request-host nor the effective request-host ever start with a dot (and it wouldn't matter if they did, for the purposes of this method), so the code should be simplified as per patch 1117114. Clearly, "Some cookies trigger this cookielib bug." implies my reasoning above is incorrect. Chad, did you really find a cookie that triggers this, or do you just have a sharp eye? If the former, I'd be very pleased to see a test case that triggers the bug (even if you can't provide running code). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-05 01:33 Message: Logged In: YES user_id=80475 Applied to Lib/cookielib.py 1.5 and 1.4.2.1 Thanks for the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116583&group_id=5470 From noreply at sourceforge.net Sun Feb 6 04:17:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 6 04:17:23 2005 Subject: [Patches] [ python-Patches-1116583 ] NameError in cookielib domain check Message-ID: Patches item #1116583, was opened at 2005-02-04 19:40 Message generated for change (Comment added) made by chadmiller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116583&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Chad Miller (chadmiller) Assigned to: Raymond Hettinger (rhettinger) Summary: NameError in cookielib domain check Initial Comment: Some cookies trigger this cookielib bug. The bug is analogous to... if a == ...: new_a = a + other_value if new_a ... : foo() But, "new_a" doesn't exist if the first condition fails. I included a lot of lines of context to show that it's correct without having to see surrounding code. ---------------------------------------------------------------------- >Comment By: Chad Miller (chadmiller) Date: 2005-02-05 22:17 Message: Logged In: YES user_id=1212466 Yes, jjlee, I found this bug through experiment, not reading code. Specifically, a program I'm writing to interface to Netflix' terrible queue interface discovered it. I can provide you, jjlee, source code that excercises it, in a week or so, after the code stabilizes again. Should I send it to you then? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-05 21:44 Message: Logged In: YES user_id=261020 Well spotted, Chad. However, I am unable to see how this bug ever causes an exception in practice: witness test_cookielib.CookieTests.test_domain_return_ok(). The reason is that neither the request-host nor the effective request-host ever start with a dot (and it wouldn't matter if they did, for the purposes of this method), so the code should be simplified as per patch 1117114. Clearly, "Some cookies trigger this cookielib bug." implies my reasoning above is incorrect. Chad, did you really find a cookie that triggers this, or do you just have a sharp eye? If the former, I'd be very pleased to see a test case that triggers the bug (even if you can't provide running code). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-04 20:33 Message: Logged In: YES user_id=80475 Applied to Lib/cookielib.py 1.5 and 1.4.2.1 Thanks for the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116583&group_id=5470 From noreply at sourceforge.net Sun Feb 6 14:03:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 6 14:03:22 2005 Subject: [Patches] [ python-Patches-790710 ] breakpoint command lists in pdb Message-ID: Patches item #790710, was opened at 2003-08-18 17:52 Message generated for change (Comment added) made by dooms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790710&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gr?goire Dooms (dooms) Assigned to: Guido van Rossum (gvanrossum) Summary: breakpoint command lists in pdb Initial Comment: This patch enables the user to define a list of commands associated to a breakpoint. Those commands are executed whenever the given breakpoint makes the program stop execution. The "commands [bpnumber]" command works like in gdb. This patch is against the CVS HEAD, it has been tested with python 2.3. The documentation is updated too. ---------------------------------------------------------------------- >Comment By: Gr?goire Dooms (dooms) Date: 2005-02-06 13:03 Message: Logged In: YES user_id=846867 I redid this patch according to your comments. The command list definition interaction is made by calling cmdloop again. onecmd is overriden to check if the line is entered in "normal mode" or in "command list definition mode". This way is much cleaner than before. I also renamed all additional data attributes so they contain "commands" as a substring. I add the new patch against revision 1.66 (python 2.3) and revision 1.73 (python 2.4). This patch does not contain the documentation changes as I did not rewrite the doc (refer to the old diff file for the doc patch). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-18 17:40 Message: Logged In: YES user_id=21627 Oops. Changing the prompt itself is fine - I just disliked the control flow that follows. IDLE things can be discussed on either list, I guess, or directly sent to kbk. If you mean changes, you best submit them as a patch here to SF. ---------------------------------------------------------------------- Comment By: Gr?goire Dooms (dooms) Date: 2004-08-18 12:48 Message: Logged In: YES user_id=846867 Ok, I see. This implementation is one year old. I'll recode this according to your comments. Why should'nt 'commands' change the prompt ? Should I assign to somebody else ? Are IDLE topics preferably discussed in idle-dev or python-dev mailing list ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-18 12:19 Message: Logged In: YES user_id=21627 I like the feature, but the implementation is not acceptable in its current form: it changes the prompt, and the rebinds all existing commands so that they add to self.commands. Instead of all this trickery, do_commands should invoke cmdloop directly, and add precmd and do_end implementations; overriding onecmd also might be an option. In addition, the patch should avoid setting member variables of pdb in cases where a local variable is sufficient (e.g. lastcmd_back). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-03-20 23:02 Message: Logged In: YES user_id=6380 I'm all for this, but don't have the bandwidth to review it. Who does? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790710&group_id=5470 From noreply at sourceforge.net Sun Feb 6 14:06:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 6 14:06:11 2005 Subject: [Patches] [ python-Patches-790710 ] breakpoint command lists in pdb Message-ID: Patches item #790710, was opened at 2003-08-18 17:52 Message generated for change (Comment added) made by dooms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790710&group_id=5470 Category: Library (Lib) >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gr?goire Dooms (dooms) Assigned to: Guido van Rossum (gvanrossum) Summary: breakpoint command lists in pdb Initial Comment: This patch enables the user to define a list of commands associated to a breakpoint. Those commands are executed whenever the given breakpoint makes the program stop execution. The "commands [bpnumber]" command works like in gdb. This patch is against the CVS HEAD, it has been tested with python 2.3. The documentation is updated too. ---------------------------------------------------------------------- >Comment By: Gr?goire Dooms (dooms) Date: 2005-02-06 13:06 Message: Logged In: YES user_id=846867 Patch against python 2.4 : pdb.py revision 1.73 ---------------------------------------------------------------------- Comment By: Gr?goire Dooms (dooms) Date: 2005-02-06 13:03 Message: Logged In: YES user_id=846867 I redid this patch according to your comments. The command list definition interaction is made by calling cmdloop again. onecmd is overriden to check if the line is entered in "normal mode" or in "command list definition mode". This way is much cleaner than before. I also renamed all additional data attributes so they contain "commands" as a substring. I add the new patch against revision 1.66 (python 2.3) and revision 1.73 (python 2.4). This patch does not contain the documentation changes as I did not rewrite the doc (refer to the old diff file for the doc patch). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-18 17:40 Message: Logged In: YES user_id=21627 Oops. Changing the prompt itself is fine - I just disliked the control flow that follows. IDLE things can be discussed on either list, I guess, or directly sent to kbk. If you mean changes, you best submit them as a patch here to SF. ---------------------------------------------------------------------- Comment By: Gr?goire Dooms (dooms) Date: 2004-08-18 12:48 Message: Logged In: YES user_id=846867 Ok, I see. This implementation is one year old. I'll recode this according to your comments. Why should'nt 'commands' change the prompt ? Should I assign to somebody else ? Are IDLE topics preferably discussed in idle-dev or python-dev mailing list ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-18 12:19 Message: Logged In: YES user_id=21627 I like the feature, but the implementation is not acceptable in its current form: it changes the prompt, and the rebinds all existing commands so that they add to self.commands. Instead of all this trickery, do_commands should invoke cmdloop directly, and add precmd and do_end implementations; overriding onecmd also might be an option. In addition, the patch should avoid setting member variables of pdb in cases where a local variable is sufficient (e.g. lastcmd_back). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-03-20 23:02 Message: Logged In: YES user_id=6380 I'm all for this, but don't have the bandwidth to review it. Who does? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790710&group_id=5470 From noreply at sourceforge.net Sun Feb 6 14:48:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 6 14:48:38 2005 Subject: [Patches] [ python-Patches-1116583 ] NameError in cookielib domain check Message-ID: Patches item #1116583, was opened at 2005-02-05 00:40 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116583&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Chad Miller (chadmiller) Assigned to: Raymond Hettinger (rhettinger) Summary: NameError in cookielib domain check Initial Comment: Some cookies trigger this cookielib bug. The bug is analogous to... if a == ...: new_a = a + other_value if new_a ... : foo() But, "new_a" doesn't exist if the first condition fails. I included a lot of lines of context to show that it's correct without having to see surrounding code. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-06 13:48 Message: Logged In: YES user_id=261020 Please do. Thanks. Looking again, I guess the problem must be that you have a relative URL but no Host header (so the erhn is just ".local"), which I guess reveals another problem in somebody's code. ---------------------------------------------------------------------- Comment By: Chad Miller (chadmiller) Date: 2005-02-06 03:17 Message: Logged In: YES user_id=1212466 Yes, jjlee, I found this bug through experiment, not reading code. Specifically, a program I'm writing to interface to Netflix' terrible queue interface discovered it. I can provide you, jjlee, source code that excercises it, in a week or so, after the code stabilizes again. Should I send it to you then? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-06 02:44 Message: Logged In: YES user_id=261020 Well spotted, Chad. However, I am unable to see how this bug ever causes an exception in practice: witness test_cookielib.CookieTests.test_domain_return_ok(). The reason is that neither the request-host nor the effective request-host ever start with a dot (and it wouldn't matter if they did, for the purposes of this method), so the code should be simplified as per patch 1117114. Clearly, "Some cookies trigger this cookielib bug." implies my reasoning above is incorrect. Chad, did you really find a cookie that triggers this, or do you just have a sharp eye? If the former, I'd be very pleased to see a test case that triggers the bug (even if you can't provide running code). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-05 01:33 Message: Logged In: YES user_id=80475 Applied to Lib/cookielib.py 1.5 and 1.4.2.1 Thanks for the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116583&group_id=5470 From noreply at sourceforge.net Sun Feb 6 16:30:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 6 16:30:34 2005 Subject: [Patches] [ python-Patches-1117339 ] cookielib and cookies with special names Message-ID: Patches item #1117339, was opened at 2005-02-06 15:30 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=1117339&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: cookielib and cookies with special names Initial Comment: cookielib's Netscape cookies parser, parse_ns_headers(), treats Netscape cookies whose names happen to match one of the special cookie-attribute names as if they were a cookie-attribute rather than a cookie name=value pair. Eg. Set-Cookie: expires="foo" Here, expires is the cookie name, not a special expires cookie-attribute. The patch includes two new tests, a patch to cookielib.py and a fix to an existing test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117339&group_id=5470 From noreply at sourceforge.net Sun Feb 6 16:32:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 6 16:32:34 2005 Subject: [Patches] [ python-Patches-1117114 ] Minor improvement on 1116583 Message-ID: Patches item #1117114, was opened at 2005-02-06 02:28 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117114&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: Minor improvement on 1116583 Initial Comment: Minor improvement on 1116583. Patch applies to CVS HEAD. See comments in original bug. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2005-02-06 15:32 Message: Logged In: YES user_id=261020 (Don't commit this yet: waiting for input from Chad, see original patch 1116583) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117114&group_id=5470 From noreply at sourceforge.net Sun Feb 6 18:39:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 6 18:39:59 2005 Subject: [Patches] [ python-Patches-1117398 ] cookielib LWPCookieJar and MozillaCookieJar exceptions Message-ID: Patches item #1117398, was opened at 2005-02-06 17: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=1117398&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: cookielib LWPCookieJar and MozillaCookieJar exceptions Initial Comment: cookielib.LWPCookieJar and .MozillaCookieJar are documented to raise cookielib.LoadError on attempt to load an invalid cookies file, but do not. I think this should be backported to the 2.4 maintenance branch. Reason: I suspect more people will be bitten by the bug than will be bitten by the patch, since cookies files will rarely be invalid, so people are likely to have written except statements based on the docs in this case, rather than based on the actual exception that currently occurs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 From noreply at sourceforge.net Sun Feb 6 19:14:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 6 19:14:06 2005 Subject: [Patches] [ python-Patches-790710 ] breakpoint command lists in pdb Message-ID: Patches item #790710, was opened at 2003-08-18 13:52 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790710&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gr?goire Dooms (dooms) >Assigned to: Nobody/Anonymous (nobody) Summary: breakpoint command lists in pdb Initial Comment: This patch enables the user to define a list of commands associated to a breakpoint. Those commands are executed whenever the given breakpoint makes the program stop execution. The "commands [bpnumber]" command works like in gdb. This patch is against the CVS HEAD, it has been tested with python 2.3. The documentation is updated too. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-02-06 13:14 Message: Logged In: YES user_id=6380 Still no time, so unassigning. ---------------------------------------------------------------------- Comment By: Gr?goire Dooms (dooms) Date: 2005-02-06 08:06 Message: Logged In: YES user_id=846867 Patch against python 2.4 : pdb.py revision 1.73 ---------------------------------------------------------------------- Comment By: Gr?goire Dooms (dooms) Date: 2005-02-06 08:03 Message: Logged In: YES user_id=846867 I redid this patch according to your comments. The command list definition interaction is made by calling cmdloop again. onecmd is overriden to check if the line is entered in "normal mode" or in "command list definition mode". This way is much cleaner than before. I also renamed all additional data attributes so they contain "commands" as a substring. I add the new patch against revision 1.66 (python 2.3) and revision 1.73 (python 2.4). This patch does not contain the documentation changes as I did not rewrite the doc (refer to the old diff file for the doc patch). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-18 13:40 Message: Logged In: YES user_id=21627 Oops. Changing the prompt itself is fine - I just disliked the control flow that follows. IDLE things can be discussed on either list, I guess, or directly sent to kbk. If you mean changes, you best submit them as a patch here to SF. ---------------------------------------------------------------------- Comment By: Gr?goire Dooms (dooms) Date: 2004-08-18 08:48 Message: Logged In: YES user_id=846867 Ok, I see. This implementation is one year old. I'll recode this according to your comments. Why should'nt 'commands' change the prompt ? Should I assign to somebody else ? Are IDLE topics preferably discussed in idle-dev or python-dev mailing list ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-18 08:19 Message: Logged In: YES user_id=21627 I like the feature, but the implementation is not acceptable in its current form: it changes the prompt, and the rebinds all existing commands so that they add to self.commands. Instead of all this trickery, do_commands should invoke cmdloop directly, and add precmd and do_end implementations; overriding onecmd also might be an option. In addition, the patch should avoid setting member variables of pdb in cases where a local variable is sufficient (e.g. lastcmd_back). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-03-20 18:02 Message: Logged In: YES user_id=6380 I'm all for this, but don't have the bandwidth to review it. Who does? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790710&group_id=5470 From noreply at sourceforge.net Sun Feb 6 20:37:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 6 20:37:17 2005 Subject: [Patches] [ python-Patches-1117454 ] cookielib.LWPCookieJar incorrectly loads value-less cookies Message-ID: Patches item #1117454, was opened at 2005-02-06 19:37 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=1117454&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: cookielib.LWPCookieJar incorrectly loads value-less cookies Initial Comment: cookielib.LWPCookieJar contains a couple of lines of code left over from an earlier incarnation of the module in which cookies like Set-Cookie: foo were treated as name-less instead of value-less. This causes corruption on loading such cookies from LWP format files. The patch fixes this bug and a similar relic that did not cause an actual bug. It also adds a comment, and a new test. Should be backported to 2.4 maintenance branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117454&group_id=5470 From noreply at sourceforge.net Mon Feb 7 01:18:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 7 01:18:40 2005 Subject: [Patches] [ python-Patches-1117588 ] urllib2 .getheaders attribute error Message-ID: Patches item #1117588, was opened at 2005-02-07 01:18 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=1117588&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 .getheaders attribute error Initial Comment: The headers arguments to all methods are dictionaries, however the http_error_302 method calls headers.getheaders() which results in an attribute error. The attached patch against current CVS fixes this by using headers.get() instead of .getheaders(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117588&group_id=5470 From noreply at sourceforge.net Mon Feb 7 09:29:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 7 09:29:21 2005 Subject: [Patches] [ python-Patches-1088078 ] Patch for bug 1088077 Message-ID: Patches item #1088078, was opened at 2004-12-19 14:27 Message generated for change (Comment added) made by donut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1088078&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for bug 1088077 Initial Comment: This patches adds a setsane function to the tty module. ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2005-02-07 01:29 Message: Logged In: YES user_id=65253 Hi, I'm not a Python developer, but I've looked at your patch. The following two problems jump out at me: 1) The mode is being saved in a single global variable, which would be overwritten if the functions are called on different fds. 2) If setraw and/or setcbreak are called multiple times, the initial value of _mode is lost. The obvious fix would just be to use a dict and not set the value if it is already set. Also, I think think setsane is a somewhat misleading name, perhaps something along the lines of setinitial or restoremode would be more accurate. Aside from all that, I don't know if keeping hidden state in the module is really the best solution to the problem. Requiring the users to save and restore the value from tcgetattr is not significantly harder and makes it more obvious what is going on. If some fix is required, adding a note to the tty docs about how to save and restore the mode using termios may be enough, or perhaps adding some (really) thin savemode/restoremode wrappers to the tty module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1088078&group_id=5470 From noreply at sourceforge.net Mon Feb 7 17:10:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 7 17:10:47 2005 Subject: [Patches] [ python-Patches-1117961 ] replace md5 impl. with one having a more free license Message-ID: Patches item #1117961, was opened at 2005-02-07 17:10 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=1117961&group_id=5470 Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 6 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: replace md5 impl. with one having a more free license Initial Comment: details at http://mail.python.org/pipermail/python-dev/2005-February/051450.html the code is taken from Debian's dpkg source package, which should at least build on Linux, the Hurd and the kfreebsd-gnu and knetbsd-gnu BSD variants. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117961&group_id=5470 From noreply at sourceforge.net Tue Feb 8 03:39:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 8 03:39:33 2005 Subject: [Patches] [ python-Patches-1118341 ] unknown locale: lt_LT (patch) Message-ID: Patches item #1118341, was opened at 2005-02-08 04: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=1118341&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nerijus Baliunas (nerijus) Assigned to: Nobody/Anonymous (nobody) Summary: unknown locale: lt_LT (patch) Initial Comment: When running wxPython app I get: ... from wx._core import * File "/usr/lib/python2.3/site-packages/wx-2.5.4-gtk2-ansi/wx/_core.py", line 11035, in ? default = locale.getdefaultlocale()[1] File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: lt_LT Attached patch helps. I also changed Latvian, as ISO8859-13 is an official standard in both Latvia and Lithuania, and Estonian, as they use ISO8859-15 now. Also added Windows language identifiers for all 3 languages. It can be applied to both 2.3 and 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1118341&group_id=5470 From noreply at sourceforge.net Tue Feb 8 09:53:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 8 09:53:27 2005 Subject: [Patches] [ python-Patches-989712 ] Support using Tk without a mainloop Message-ID: Patches item #989712, was opened at 2004-07-13 05:16 Message generated for change (Comment added) made by mdehoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=989712&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Kurt B. Kaiser (kbk) Summary: Support using Tk without a mainloop Initial Comment: In the regular python shell, you can open Tk windows, and they will operate even though you didn't call Tkinter.mainloop(). This is useful, for example, when you manipulate matplotlib graphs from within the python shell. This is done by a hook, installed when a tkapp object is being initialized, which handles Tk events while the shell is waiting for user input. I imitated this behaviour in IDLE: When the subprocess is idle, it checks whether Tkinter._default_root is set (this happens when the Tkinter.Tk class, which makes a tkapp object, is initialized, unless Tkinter._use_default_root is False), and if so, handles Tk events. For me it works very well. Have a good day, Noam Raphael ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-08 17:53 Message: Logged In: YES user_id=488897 I have written a patch that solves this problem more generally via PyOS_InputHook, as suggested by Noam. This patch also solves the related bugs #1053687, #798058, and supersedes patch #1049855. The patch is available at http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff Currently, the EventHook function sits in a loop handling Tcl events until keyboard input is detected. The presence of Tcl events is checked every Tkinter_busywaitinterval milliseconds. If a Tcl event arrives during this interval, it won't be handled until the end of the interval. However, with the default value of Tkinter_busywaitinterval = 20 milliseconds, that delay is not noticable. Now consider the situation in which there can be more than one input hook, for example set by different extension modules. We cannot have EventHook sit in a loop until keyboard input is detected, because that would prevent other PyOS_InputHooks from being serviced. So in the EventHook in the patch, the function returns immediately after handling all Tcl events. If we use Python from the command line and open a Tkinter label: >>> from Tkinter import * >>> l = Label() then readline will call PyOS_InputHook ten times per second while Python is idle. Because PyOS_InputHook points to EventHook, we will return to the EventHook function almost immediately. Effectively, we are then in the same situation as before the patch. On Cygwin, however, previously mainloop needed to be run in order for the label to appear; this is no longer necessary with this patch. On Windows, currently PyOS_InputHook is partially broken, as it is called only once per command instead of ten times per second. This patch fixed that also (same as patch #1049855). If we have two or more input hooks, they are called successively by readline. Since each input hook returns after it has no more work to do, all of the input hooks are guaranteed to be serviced. To be able to have more than one input hook, we need to replace PyOS_InputHook by three functions: PyOS_AddInputHook, PyOS_RemoveInputHook, and PyOS_CallInputHooks. For the third function, the corresponding Python function call_input_hooks was created in the readline module. By adding a call to readline.call_input_hooks in run.py, as suggested by Noam, all input hook functions are serviced when IDLE is idle. So we can use Tkinter without calling mainloop, and we can use other extension packages that use input hooks. We can even do both: >>> import Tkinter >>> import gist # my extension module also needs input hooks >>> Tkinter.Label() # label appears >>> gist.window() # Graphics window appears. works both with command-line python and IDLE. I'm interested to hear your comments and suggestions. If this patch seems like the way to go, I'd be happy to write the documentation for it. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-04 22:08 Message: Logged In: YES user_id=488897 I agree, this is basically the same bug as #798058. The call to readline.call_input_hook sounds like a good solution. But the hook function should be different than the current EventHook in _tkinter.c. That hook function sits in a loop until a keyboard event is noticed. A problem occurs if there is more than one hook function. Currently, that is not possible in Python, since there is only one PyOS_InputHook. I am working on a patch in which PyOS_InputHook is replaced by PyOS_AddInputHook and PyOS_RemoveInputHook, so that there can be more than one hook functions. Now suppose that there is one hook function to handle Tk events, and another one e.g. handling messages to windows in Microsoft Windows. (This is a real issue for one of my extension modules). If python sits in a loop in _tkinter.c's EventHook until a key is pressed, the MS windows won't get their messages. The following structure might work better: while(there is no keyboard input or other interesting event) { Call PyOS_InputHook #1 Call PyOS_InputHook #2 etc. } where each of the PyOS_InputHook functions should return if there is no more work for them. The tricky part is to find out which events to wait for; some of the events may be handled by one of the PyOS_InputHook functions. Obviously I need to do some more thinking about this. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-04 10:02 Message: Logged In: YES user_id=149084 Hm, this seems closely related to Bug 798058 I'd lost track of it because it got switched to tkinter. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2005-01-30 20:58 Message: Logged In: YES user_id=679426 in _tkinter.c, look for EventHook - you'll find the EventHook function, which is called when the interpreter is idle, and the Enable/Disable EventHook functions. In readline.c, line 765, you'll find the call to PyOS_InputHook, when waiting for input. Perhaps a more general approach would be to let Python code call PyOS_InputHook, for example, by defining readline.call_input_hook() and readline.has_input_hook(). Then IDLE would be able to call them when idle, with no Tkinter-specific code. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-07-15 05:44 Message: Logged In: YES user_id=149084 Can you give me some more information on the hook in the Python interpreter? Where is it in the code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=989712&group_id=5470 From noreply at sourceforge.net Tue Feb 8 14:09:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 8 14:09:50 2005 Subject: [Patches] [ python-Patches-852995 ] tests and processors patch for urllib2 Message-ID: Patches item #852995, was opened at 2003-12-02 18:53 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852995&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Closed Resolution: Accepted Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Jeremy Hylton (jhylton) Summary: tests and processors patch for urllib2 Initial Comment: Here are some unit tests for urllib2 and a revised version of my urllib2 "processors" patch (originally posted as RFE 759792 -- I'm posting it here since it is a patch, not just a wish). The tests depend on the patch, but test more than just the changes introduced by the patch. A fuller discussion is in the original RFE tracker item, but briefly: the patch makes it possible to implement functionality like HTTP cookie handling, Refresh handling, etc. etc. using handler objects. At the moment urllib2's handler objects aren't quite up to the job, which results in a lot of cut-n-paste and subclassing. I believe the changes are backwards-compatible, with the exception of people who've reimplemented build_opener()'s functionality -- those people would need to call opener.add_handler(HTTPErrorProcessor). The main change is allowing handlers to implement methods like: http_request(request) http_response(request, response) In addition to the usual http_open(request) http_error{_*}(...) I call handlers that implement these methods "processors". These methods get called for *every* processor (in contrast to the ordinary handler methods, where the OpenerDirector stops calling the methods as soon as the first handler handles the request by returning a response) to pre-process requests and post-process responses. If this is accepted, I can submit patches for handlers (processors) that do HTTP Refresh redirection, cookie handling etc. Changes in the patch: -OpenerDirector changes to call new <protocol>_request and <protocol>_response methods. I haven't put all the documentation for this interface in this set of patches because there's no obvious place for it: handlers aren't really documented either. The urllib2 docs need a cleanup, but I'll do that in a separate patch. -Added .unredirected_hdrs dict to Request, together with .add_unredirected_headers() and .has_header() methods. These headers don't get copied to redirected requests. I didn't add this as a feature for people calling urlopen on a Request. Rather, the motivation comes from the fact that processors need to explicitly add headers to Requests (Cookie, Referer, Content-Length, etc.), rather than directly sending them over the wire. The problem is, if they add them to the regular .headers attribute of requests, processors will end up clobbering headers added by the user who called urlopen (which would break backwards-compatibility). Having processors use a separate set of headers that never get redirected makes this problem go away: users can add headers (with either .add_header() or .add_unredirected_header(), since processors don't clobber either) and know that they won't get clobbered by any handler. -HTTPErrorProcessor is necessary to allow response processors to see responses before redirections &c happen, by moving the call to parent.error() out of AbstractHTTPHandler.do_open(). It has the side-effect of stopping people grumbling that 200 is not the only success code in HTTP <0.5 wink>, since it makes it feasible to override urllib2's behaviour of raising an exception unless the HTTP code == 200. -Split part of AbstractHTTPHandler.do_open (which implements http_open / https_open in the HTTP/HTTPSHandler subclasses) into a new .do_request (which implements http_request in the subclasses). Just because I could, really (with the new *_request methods). It seems clearer to me. -Single string-formatting-character change to OpenerDirector.error() to allow "refresh" as an error code. -Added .code and .msg attributes to HTTP response objects, so that processors can know what the response code and message are. I haven't documented these, because they're HTTP-specific. -Renamed HTTPRedirectHandler.error_302_dict --> .redirect_dict -Finally, there's one bugfix to HTTPRedirectHandler included in the patch, because the tests test for it: multiple visits to a single URL with different redirect codes is no longer erroneously detected as a loop. http://a.com/a --> 302 --> http://a.com/b --> Refresh --> http://a.com/a Yes, I have seen a site where this really happens! There are a few other bugs that turned up while writing the tests, and those tests are commented out ATM. I'll file bug reports for those separately after this one is sorted out. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-02-08 07:09 Message: Logged In: YES user_id=2772 The fedora folks claim that this patch has caused "yum", an apt-like tool for RPMs, to break in python 2.4.0. I haven't been able to verify this, and nobody has come up with a simple, standalone script to produce the problem. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138535 ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2004-01-04 17:51 Message: Logged In: YES user_id=261020 Fixed tests in patch 870606. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-31 22:00 Message: Logged In: YES user_id=80475 FWIW, the test for urllib2 is currently failing and needs to be fixed. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-14 10:11 Message: Logged In: YES user_id=261020 Reopening to add a note to Misc/NEWS about the backwards-incompatibility for people who don't use build_opener(). I presume that's the right place for this note? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-14 09:17 Message: Logged In: YES user_id=261020 Just a note that my justification of Request.add_unredirected_hdrs above makes no sense. :-/ I mis-remembered my own reasons for adding this. My original comment from 759792 is correct: Some headers (Content-Length, Referer, ...) mustn't be copied to requests for a redirected URL. This requires the addition of a new dict to Request. I've added an add_unredirected_headers method, too. The old implementation just sends these headers directly, but that's not possible if you want to use procesors to implement these things. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-12-13 23:28 Message: Logged In: YES user_id=31392 Committed as rev 1.57 of urllib2.py ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-07 18:04 Message: Logged In: YES user_id=261020 Oops, I left a couple of lines in urllib2.py that add an HTTP debugging method and constructor arg. Please ignore that part of the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852995&group_id=5470 From noreply at sourceforge.net Tue Feb 8 14:25:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 8 14:25:27 2005 Subject: [Patches] [ python-Patches-1118602 ] Fix crash in xmlprase_GetInputContext in pyexpat.c Message-ID: Patches item #1118602, was opened at 2005-02-08 06:25 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=1118602&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mathieu Fenniak (laotzu0) Assigned to: Nobody/Anonymous (nobody) Summary: Fix crash in xmlprase_GetInputContext in pyexpat.c Initial Comment: I've run across a couple of cases where pyexpat will crash in xmlparse_GetInputContext. The problem stems from the 'offset' variable that can be returned from XML_GetInputContext - if it is non-zero, then the size being passed into PyString_FromStringAndSize is incorrectly too large. The offset should be subtracted from that size. I cannot provide a test case to reproduce this - my attempts to create a minimal test case do not crash. The application I'm developing is using simpleTAL and when a large XML comment (multiline Javascript) is entered in the software templates it will often crash. This seems to only occur on a Python installation where the module xml.sax.saxlib is not present (i.e. PyXML is not installed) - I'm not sure why this is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1118602&group_id=5470 From noreply at sourceforge.net Tue Feb 8 17:56:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 8 17:56:15 2005 Subject: [Patches] [ python-Patches-1118748 ] enable time + timedelta Message-ID: Patches item #1118748, was opened at 2005-02-08 16:56 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=1118748&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josh (josh-sf) Assigned to: Nobody/Anonymous (nobody) Summary: enable time + timedelta Initial Comment: This patch enables timedelta arithmetic for times (in addition to dates and datetimes). Tests and doc included Here's a response to the probable reason why this hasn't been enabled already... Times greater than 24 hours should not raise an exception, but always wrap around. Any other behavior is too surprising. (People expect to be able to call you up at 11pm, and say "meet me in two hours" (if you're a night person)). Clock time is cyclical. Though it's convenient to assign hours numbers, an unqualified hour 23.5 is not naturally "greater than" hour 0.5. (Though I'm not suggesting that we break this.) The special meaning for hour 0 is only relevant for datetimes. When dates are not involved, it shouldn't get any special treatment. When dates are involved, it's easy to "assert datetime1.date() == datetime2.date()" If this change is made however, maybe datetime.timedelta(hours=-1) should no longer normalize to datetime.timedelta(-1, 82800) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1118748&group_id=5470 From noreply at sourceforge.net Tue Feb 8 17:58:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 8 17:58:14 2005 Subject: [Patches] [ python-Patches-1117398 ] cookielib LWPCookieJar and MozillaCookieJar exceptions Message-ID: Patches item #1117398, was opened at 2005-02-06 12:39 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: cookielib LWPCookieJar and MozillaCookieJar exceptions Initial Comment: cookielib.LWPCookieJar and .MozillaCookieJar are documented to raise cookielib.LoadError on attempt to load an invalid cookies file, but do not. I think this should be backported to the 2.4 maintenance branch. Reason: I suspect more people will be bitten by the bug than will be bitten by the patch, since cookies files will rarely be invalid, so people are likely to have written except statements based on the docs in this case, rather than based on the actual exception that currently occurs. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-08 11:58 Message: Logged In: YES user_id=764593 I often look at the code in a second idle window rather than starting a web browser. Would it work to make LoadError a subclass of IOError, at least for the backport? People who followed the docs will get a bugfix, but people who followed the code would get no breakage. Should LoadError be a subclass of IOError even in the main trunk? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 From noreply at sourceforge.net Wed Feb 9 01:55:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 9 01:55:06 2005 Subject: [Patches] [ python-Patches-1119016 ] fix for a bug in Header.__unicode__() Message-ID: Patches item #1119016, was opened at 2005-02-09 01:55 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=1119016&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: fix for a bug in Header.__unicode__() Initial Comment: In three places in the __unicode__ method there is a line that looks like this: if lastcs not in (None, 'us-ascii'): They will generate a TypeError because lastcs is a Charset object. This patch fixes this bug by using (None, Charset('us-ascii')) instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1119016&group_id=5470 From noreply at sourceforge.net Wed Feb 9 10:33:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 9 10:33:50 2005 Subject: [Patches] [ python-Patches-1119016 ] fix for a bug in Header.__unicode__() Message-ID: Patches item #1119016, was opened at 2005-02-09 01:55 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1119016&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bj?rn Lindqvist (sonderblade) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: fix for a bug in Header.__unicode__() Initial Comment: In three places in the __unicode__ method there is a line that looks like this: if lastcs not in (None, 'us-ascii'): They will generate a TypeError because lastcs is a Charset object. This patch fixes this bug by using (None, Charset('us-ascii')) instead. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-02-09 10:33 Message: Logged In: YES user_id=38388 Hi Barry, I think Bj?rn is talking about a problem in the email package. Note to Bj?rn: the patch does not seem to have made it. Please try again. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1119016&group_id=5470 From noreply at sourceforge.net Wed Feb 9 11:44:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 9 11:44:40 2005 Subject: [Patches] [ python-Patches-1098732 ] Enhance tracebacks and stack traces with vars Message-ID: Patches item #1098732, was opened at 2005-01-09 02:59 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1098732&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Enhance tracebacks and stack traces with vars Initial Comment: I think it would be useful to sometimes have local variable values printed with tracebacks and stack frames. The attached patch is a first cut at that. I don't know if people would want that as the default, so I've defaulted argument printing to disabled. With arg printing enabled, executing this script: #!/usr/bin/env python import sys import traceback def exch(ty, val, tb): traceback.print_exception(ty, val, tb, args=True) sys.excepthook = exch def f(n,d): return n/d def g(a): return a/(a-1) for i in range(5,-1,-1): print g(i) displays this output: 1 1 1 2 Traceback (most recent call last): File "/Users/skip/tmp/tb.py", line 17, in ? print g(i) exch: f: g: i: 1 File "/Users/skip/tmp/tb.py", line 14, in g return a/(a-1) a: 1 ZeroDivisionError: integer division or modulo by zero ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2005-02-09 11:44 Message: Logged In: YES user_id=51702 I like this idea alot! I usually debug by inserting print "somevar =",somevar around where I think the problem code is and this patch basically does it automagically for me. I can definitely image this patch saving me many hours of debug time. But: 1. It outputs to much information. An unhandled exception that bubbles up can be 3-4 stackframes long and seeing all the variables in those frames is excessive. 2. I think it would be better if the enhanced traceback was either default or activated with a commandline option to Python. Item 1 maybe can be solved by only outputting those names that are contained in the lines in which the exception is raised? So that the output in your example becomes: Traceback (most recent call last): File "exception.py", line 20, in ? print g(i) g: i: 1 File "exception.py", line 14, in g return a/(a-1) a: 1 ZeroDivisionError: integer division or modulo by zero It feels a little weird to have to hook sys.excepthook. I think this idea is to good to be "buried" like that. Hopefully, with some polishing it can be activated with a commandline option or become the default bahaviour. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1098732&group_id=5470 From beta_nunessdkdj8374 at hotmail.com Wed Feb 9 13:13:01 2005 From: beta_nunessdkdj8374 at hotmail.com (Roberta Nunes) Date: Wed Feb 9 13:13:12 2005 Subject: [Patches] =?iso-8859-1?q?MALA_DIRETA_DE_E-MAILS_SEGMENTADOS_GEN?= =?iso-8859-1?q?=C9RICOS_MIRADOS_FOCADOS_http=3A//www=2Egueb=2Ede/s?= =?iso-8859-1?q?egmails?= Message-ID: <20050209121311.481F51E4003@bag.python.org> .. MALA DIRETA DE E-MAILS SEGMENTADOS GEN?RICOS MIRADOS FOCADOS http://www.gueb.de/segmails @ Listas de E-Mails Mala Direta E-mails Segmentados ou E-mails Gen?ricos Marketing Direto Divulga??o Visite agora: http://www.gueb.de/segmails . CADASTRAMENTO DE HOME PAGES EM MILHARES DE SITES DE BUSCAS NO BRASIL E NO MUNDO . MALA DIRETA DE EMAILS SEGMENTADA . MALA DIRETA DE EMAILS GEN?RICA . VALIDA??O DE LISTAS E-MAILS . SMS (MENSANGENS A CELULAR ) . ICQ 9(MENSANGENS A ICQ ) Visite agora: http://www.gueb.de/segmails bulk mail,mailing list,e-maling,listas,cadastros,email,emaiu,emeiu,emaiu,emaius e-mails para mala direta,e-mails,emails,email,emaio,listas de e-mails,mailing list,listagem,cadastros,listas de e-mail,marketing direto,mmv,publicidade,divulga??o,mp3,e-mails segmentados,home page,bulk mail,playboy,propaganda,maladireta,maling list,sexo E-mails para Mala Direta/Marketing Direto gen?ricos ou segmentados por ramo de atividade,sexo,idade,cidade,estado Visite agora: http://www.gueb.de/segmails Cadastramento de Home Page em sites de buscas,otimiza??o,dicas e downloads gr?tis From noreply at sourceforge.net Wed Feb 9 15:18:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 9 15:18:11 2005 Subject: [Patches] [ python-Patches-1104669 ] new-style exceptions Message-ID: Patches item #1104669, was opened at 2005-01-18 18:09 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: new-style exceptions Initial Comment: This patch allows new-style exceptions and makes Exception a new-style class. The test suite runs, apart from failures in test_tempfile (will dig, but doubt this is my fault) and test__locale (known OS X problem). ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-02-09 14:18 Message: Logged In: YES user_id=6656 New patch attached. Did this a while ago, don't actually remember the details of what's new :-/ The problem with the previous patch was that one of my exception- checking macros had the side-effect of clearing any pending exception... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-01-19 13:25 Message: Logged In: YES user_id=6656 You're right! Odd. No time to fix it today, I'm afraid. ---------------------------------------------------------------------- Comment By: Simon Percivall (percivall) Date: 2005-01-18 19:47 Message: Logged In: YES user_id=329382 One thing: Raising an old-style class/instance doesn't give a traceback or populate sys.last_*. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 From noreply at sourceforge.net Wed Feb 9 18:00:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 9 18:00:42 2005 Subject: [Patches] [ python-Patches-1119423 ] python -c readlink()s and stat()s '-c' Message-ID: Patches item #1119423, was opened at 2005-02-09 17:00 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=1119423&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Brian Foley (bpfoley) Assigned to: Nobody/Anonymous (nobody) Summary: python -c readlink()s and stat()s '-c' Initial Comment: Due to the way input arguments are processed by Py_Main when Python is invoked with the -c switch, PySys_SetArgv treats '-c' as the name of the python executable and tries to get an absolute path for it before adding it to sys.argv. This is mostly harmless, but is doing work that shouldn't be done: on UNIX it involves calling readlink() and realpath(). The patch avoids the lookup if argv0 is '-c'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1119423&group_id=5470 From noreply at sourceforge.net Wed Feb 9 22:18:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 9 22:18:32 2005 Subject: [Patches] [ python-Patches-1119626 ] patches to compile for AIX 4.1.x Message-ID: Patches item #1119626, was opened at 2005-02-09 16:18 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=1119626&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) Assigned to: Nobody/Anonymous (nobody) Summary: patches to compile for AIX 4.1.x Initial Comment: Support for AIX 4.1 got lost, or was dropped with python 2.3. The only thing AIX 4.1 needs over generic AIX support is a call to loadbind when loading dynamic modules. This patch also provides stubs for openpty in posixmodule and wgetnstr in cursesmodule. The openpty stub is non-functional. The wgetnstr stub is functional, but uses a fixed size temporary buffer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1119626&group_id=5470 From noreply at sourceforge.net Wed Feb 9 23:29:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 9 23:29:34 2005 Subject: [Patches] [ python-Patches-992750 ] zipfile and big zipped file Message-ID: Patches item #992750, was opened at 2004-07-17 02:45 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=992750&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Keyphrene (keyphrene) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile and big zipped file Initial Comment: read method decompress the zipped files, but this method returns bytes, more the file is big, more the bytes array is big. readFile method allows to send the bytes in a file. ---------------------------------------------------------------------- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-02-09 17:29 Message: Logged In: YES user_id=1115903 The current behavior of ZipFile.read is an occasional annoyance for me. I will make the changes described in loewis' comments and submit the updated patch, unless somebody is already working on it. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-18 08:13 Message: Logged In: YES user_id=21627 The patch is unacceptable in its current form. It duplicates too much code; read and readfile should really share the common code (e.g. by read falling back to readfile). Also, as this really copies the data to fileobj, it probably is better called copyfile, instead of readfile. Finally, I would much prefer if zipfile would have an .open method, returning a file-like object. Then you would have such implementations def read(self, name): return self.open(name, "r").read() def readfile(self, name, dest): import shutil shutil.copyfileobj(self.open(name,"r"), dest) I would then probably leave the last method out, and encourage users to invoke shutil.copyfileobj directly if desired. Are you willing to make changes in this direction? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=992750&group_id=5470 From noreply at sourceforge.net Thu Feb 10 00:21:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 00:21:12 2005 Subject: [Patches] [ python-Patches-1098732 ] Enhance tracebacks and stack traces with vars Message-ID: Patches item #1098732, was opened at 2005-01-09 02:59 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1098732&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Enhance tracebacks and stack traces with vars Initial Comment: I think it would be useful to sometimes have local variable values printed with tracebacks and stack frames. The attached patch is a first cut at that. I don't know if people would want that as the default, so I've defaulted argument printing to disabled. With arg printing enabled, executing this script: #!/usr/bin/env python import sys import traceback def exch(ty, val, tb): traceback.print_exception(ty, val, tb, args=True) sys.excepthook = exch def f(n,d): return n/d def g(a): return a/(a-1) for i in range(5,-1,-1): print g(i) displays this output: 1 1 1 2 Traceback (most recent call last): File "/Users/skip/tmp/tb.py", line 17, in ? print g(i) exch: f: g: i: 1 File "/Users/skip/tmp/tb.py", line 14, in g return a/(a-1) a: 1 ZeroDivisionError: integer division or modulo by zero ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-10 00:21 Message: Logged In: YES user_id=21627 Philipp Eby commented that he would not like to see this as a default, as the default already prints too much information. He also (indirectly) suggested that he would not like to see it as a command line option, but that he would prefer to see a different command line option instead which enters pdb on uncaught exceptions. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2005-02-09 11:44 Message: Logged In: YES user_id=51702 I like this idea alot! I usually debug by inserting print "somevar =",somevar around where I think the problem code is and this patch basically does it automagically for me. I can definitely image this patch saving me many hours of debug time. But: 1. It outputs to much information. An unhandled exception that bubbles up can be 3-4 stackframes long and seeing all the variables in those frames is excessive. 2. I think it would be better if the enhanced traceback was either default or activated with a commandline option to Python. Item 1 maybe can be solved by only outputting those names that are contained in the lines in which the exception is raised? So that the output in your example becomes: Traceback (most recent call last): File "exception.py", line 20, in ? print g(i) g: i: 1 File "exception.py", line 14, in g return a/(a-1) a: 1 ZeroDivisionError: integer division or modulo by zero It feels a little weird to have to hook sys.excepthook. I think this idea is to good to be "buried" like that. Hopefully, with some polishing it can be activated with a commandline option or become the default bahaviour. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1098732&group_id=5470 From noreply at sourceforge.net Thu Feb 10 00:46:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 00:46:07 2005 Subject: [Patches] [ python-Patches-1119626 ] patches to compile for AIX 4.1.x Message-ID: Patches item #1119626, was opened at 2005-02-09 22:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1119626&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) >Assigned to: Guido van Rossum (gvanrossum) Summary: patches to compile for AIX 4.1.x Initial Comment: Support for AIX 4.1 got lost, or was dropped with python 2.3. The only thing AIX 4.1 needs over generic AIX support is a call to loadbind when loading dynamic modules. This patch also provides stubs for openpty in posixmodule and wgetnstr in cursesmodule. The openpty stub is non-functional. The wgetnstr stub is functional, but uses a fixed size temporary buffer. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-10 00:46 Message: Logged In: YES user_id=21627 I don't understand the patch. Why do you provide an implementation of openpty that says it creates a pseudo tty master slave pair, and is implementented by setting errno to ENOENT? The changes to remove loadbind were made in dynload_aix.c 2.12, where Guido applied #568629, which in turn was from Oren Tirosh. It was meant to replace the new module, so I presume the change to dynload_aix was unintentional (but then, it is probably no problem, as nobody noticed during the entire life of Python 2.3). Assigning this to gvanrossum for further comments, and also asking orenti to comment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1119626&group_id=5470 From noreply at sourceforge.net Thu Feb 10 00:49:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 00:49:40 2005 Subject: [Patches] [ python-Patches-1118602 ] Fix crash in xmlprase_GetInputContext in pyexpat.c Message-ID: Patches item #1118602, was opened at 2005-02-08 14:25 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1118602&group_id=5470 Category: Modules Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Mathieu Fenniak (laotzu0) >Assigned to: Martin v. L?wis (loewis) Summary: Fix crash in xmlprase_GetInputContext in pyexpat.c Initial Comment: I've run across a couple of cases where pyexpat will crash in xmlparse_GetInputContext. The problem stems from the 'offset' variable that can be returned from XML_GetInputContext - if it is non-zero, then the size being passed into PyString_FromStringAndSize is incorrectly too large. The offset should be subtracted from that size. I cannot provide a test case to reproduce this - my attempts to create a minimal test case do not crash. The application I'm developing is using simpleTAL and when a large XML comment (multiline Javascript) is entered in the software templates it will often crash. This seems to only occur on a Python installation where the module xml.sax.saxlib is not present (i.e. PyXML is not installed) - I'm not sure why this is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1118602&group_id=5470 From noreply at sourceforge.net Thu Feb 10 00:55:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 00:55:13 2005 Subject: [Patches] [ python-Patches-1119626 ] patches to compile for AIX 4.1.x Message-ID: Patches item #1119626, was opened at 2005-02-09 16:18 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1119626&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) >Assigned to: Nobody/Anonymous (nobody) Summary: patches to compile for AIX 4.1.x Initial Comment: Support for AIX 4.1 got lost, or was dropped with python 2.3. The only thing AIX 4.1 needs over generic AIX support is a call to loadbind when loading dynamic modules. This patch also provides stubs for openpty in posixmodule and wgetnstr in cursesmodule. The openpty stub is non-functional. The wgetnstr stub is functional, but uses a fixed size temporary buffer. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-02-09 18:55 Message: Logged In: YES user_id=6380 Sorry, I don't have a clue any more. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-09 18:46 Message: Logged In: YES user_id=21627 I don't understand the patch. Why do you provide an implementation of openpty that says it creates a pseudo tty master slave pair, and is implementented by setting errno to ENOENT? The changes to remove loadbind were made in dynload_aix.c 2.12, where Guido applied #568629, which in turn was from Oren Tirosh. It was meant to replace the new module, so I presume the change to dynload_aix was unintentional (but then, it is probably no problem, as nobody noticed during the entire life of Python 2.3). Assigning this to gvanrossum for further comments, and also asking orenti to comment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1119626&group_id=5470 From noreply at sourceforge.net Thu Feb 10 01:34:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 01:34:16 2005 Subject: [Patches] [ python-Patches-1116722 ] Solaris 10 fails to compile complexobject.c [FIX incl.] Message-ID: Patches item #1116722, was opened at 2005-02-05 08:02 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 >Category: Build >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Case Van Horsen (casevh) >Assigned to: Martin v. L?wis (loewis) Summary: Solaris 10 fails to compile complexobject.c [FIX incl.] Initial Comment: This is a duplicate of 970334. The fix I used was to make the following change in pyport.h: Change #define Py_HUGE_VAL HUGE_VAL to #define PY_HUGE_VAL DBL_MAX. DBL_MAX is found in float.h Versions used: Python 2.4 gcc 3.4.3 Solaris 10 x86 GA release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 From noreply at sourceforge.net Thu Feb 10 02:26:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 02:26:24 2005 Subject: [Patches] [ python-Patches-1119626 ] patches to compile for AIX 4.1.x Message-ID: Patches item #1119626, was opened at 2005-02-09 16:18 Message generated for change (Comment added) made by customdesigned You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1119626&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) Assigned to: Nobody/Anonymous (nobody) Summary: patches to compile for AIX 4.1.x Initial Comment: Support for AIX 4.1 got lost, or was dropped with python 2.3. The only thing AIX 4.1 needs over generic AIX support is a call to loadbind when loading dynamic modules. This patch also provides stubs for openpty in posixmodule and wgetnstr in cursesmodule. The openpty stub is non-functional. The wgetnstr stub is functional, but uses a fixed size temporary buffer. ---------------------------------------------------------------------- >Comment By: Stuart D. Gathman (customdesigned) Date: 2005-02-09 20:26 Message: Logged In: YES user_id=142072 openpty patch: The openpty stub is nonfunctional. I spent a day trying to emulate enough pty stuff on AIX 4.1 to get it to work - but failed. At least with the stub it compiles. Almost everything else works on AIX 4.1 (need to get db4.2 installed for bsddb to work, curses has a few bugs). AIX 4.1 has BSD style ptys (with matching pty and tty pairs), and also sysv style where opening a magic device assigns you an arbitrary minor device number. I'm pretty sure it is possible to make ptys work reasonably with python on aix 4.1, but I haven't had time to get it to work. By returning ENOENT, python code that depends on pty support thinks that none are available - which is effectively the case at present. dynload_aix patch: The change to dynload_aix.c was correct for aix 4.2 and later. It is only aix 4.1 that requires the call to loadbind. That is why the restored code is ifdefed for _AIX41 specifically. I did notice during the lifecycle of python 2.3, in that I never got python2.3 to run on aix4.1 - but I didn't have time to track down the problem. I am just getting around to it now, but thought I'd go for 2.4 instead. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-02-09 18:55 Message: Logged In: YES user_id=6380 Sorry, I don't have a clue any more. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-09 18:46 Message: Logged In: YES user_id=21627 I don't understand the patch. Why do you provide an implementation of openpty that says it creates a pseudo tty master slave pair, and is implementented by setting errno to ENOENT? The changes to remove loadbind were made in dynload_aix.c 2.12, where Guido applied #568629, which in turn was from Oren Tirosh. It was meant to replace the new module, so I presume the change to dynload_aix was unintentional (but then, it is probably no problem, as nobody noticed during the entire life of Python 2.3). Assigning this to gvanrossum for further comments, and also asking orenti to comment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1119626&group_id=5470 From noreply at sourceforge.net Thu Feb 10 02:43:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 02:43:41 2005 Subject: [Patches] [ python-Patches-1116722 ] Solaris 10 fails to compile complexobject.c [FIX incl.] Message-ID: Patches item #1116722, was opened at 2005-02-05 02:02 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Case Van Horsen (casevh) Assigned to: Martin v. L?wis (loewis) Summary: Solaris 10 fails to compile complexobject.c [FIX incl.] Initial Comment: This is a duplicate of 970334. The fix I used was to make the following change in pyport.h: Change #define Py_HUGE_VAL HUGE_VAL to #define PY_HUGE_VAL DBL_MAX. DBL_MAX is found in float.h Versions used: Python 2.4 gcc 3.4.3 Solaris 10 x86 GA release. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-02-09 20:43 Message: Logged In: YES user_id=31435 The C standard requires that "The macro HUGE_VAL expands to a positive double constant expression, not necessarily representable as a float". Python requires that too. #define'ing to worm around a broken compilation environment isn't acceptable to me; finding a switch to make this environment conform to the standard would be OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 From noreply at sourceforge.net Thu Feb 10 04:23:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 04:23:05 2005 Subject: [Patches] [ python-Patches-1116722 ] Solaris 10 fails to compile complexobject.c [FIX incl.] Message-ID: Patches item #1116722, was opened at 2005-02-05 08:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Case Van Horsen (casevh) Assigned to: Martin v. L?wis (loewis) Summary: Solaris 10 fails to compile complexobject.c [FIX incl.] Initial Comment: This is a duplicate of 970334. The fix I used was to make the following change in pyport.h: Change #define Py_HUGE_VAL HUGE_VAL to #define PY_HUGE_VAL DBL_MAX. DBL_MAX is found in float.h Versions used: Python 2.4 gcc 3.4.3 Solaris 10 x86 GA release. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-10 04:23 Message: Logged In: YES user_id=21627 I have the Solaris 10 iso/math_c99.h in front of me, but no gcc, so it is somewhat difficult to get through the ifdefery. It appears that we should have _XOPEN_SOURCE - 0 >= 600, so we should be using #define HUGE_VAL __builtin_huge_val The problem apparently is that in Sun CC, __builtin_huge_val appears to be a constant, whereas in gcc, it probably is a function, so the definition should read #define HUGE_VAL __builtin_huge_val() So there is a bug in the gcc port of Solaris here - fixincludes should adjust the definition of HUGE_VAL when installing its adjusted copy of math_c99.h. I'm willing to accept patches to work around this gcc bug, but only if the bug gets reported to gcc first. So, please, 1. find out the gcc installation directory on your system, using gcc --print-search-dirs 2a. check whether /include/iso/math_c99.h exists 2b. if it does not exist, copy if from /usr/include/iso/math_c99.h 3. edit /include/iso/math_c99.h to add the parentheses after builtin_huge_val 4. check whether this fixes the problem 5a. if not, provide the preprocessor output for complexobject.i, using --save-temps 5b. if it does, make a bug report to gcc, indicating that the program #include int main() { double f=HUGE_VAL; } fails on Solaris 10. For that report - check whether it actually fails without the update math_c99, and succeeds with it (you might have to #define _XOPEN_SOURCE to make it fail) - include the preprocessor output for this sample program, using the original math_c99 - indicate that a solution is to add parentheses 6. Come up with a patch that checks for Solaris 10 and all gcc versions showing the problem (i.e. 3.4.x, with x<=3, perhaps also 3.y, y<=3), and defines Py_HUGE_VAL correctly for this system. 7. Report the gcc bug number and the patch in this report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-10 02:43 Message: Logged In: YES user_id=31435 The C standard requires that "The macro HUGE_VAL expands to a positive double constant expression, not necessarily representable as a float". Python requires that too. #define'ing to worm around a broken compilation environment isn't acceptable to me; finding a switch to make this environment conform to the standard would be OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 From noreply at sourceforge.net Thu Feb 10 04:25:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 04:25:26 2005 Subject: [Patches] [ python-Patches-1119626 ] patches to compile for AIX 4.1.x Message-ID: Patches item #1119626, was opened at 2005-02-09 16:18 Message generated for change (Comment added) made by customdesigned You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1119626&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) Assigned to: Nobody/Anonymous (nobody) Summary: patches to compile for AIX 4.1.x Initial Comment: Support for AIX 4.1 got lost, or was dropped with python 2.3. The only thing AIX 4.1 needs over generic AIX support is a call to loadbind when loading dynamic modules. This patch also provides stubs for openpty in posixmodule and wgetnstr in cursesmodule. The openpty stub is non-functional. The wgetnstr stub is functional, but uses a fixed size temporary buffer. ---------------------------------------------------------------------- >Comment By: Stuart D. Gathman (customdesigned) Date: 2005-02-09 22:25 Message: Logged In: YES user_id=142072 As to assigning priority. We have only 2 machines left which still run AIX 4.1. I wouldn't be mad if you simply said "we don't support AIX 4.1 any more" so as not to clutter the code with ifdefs for an older release that not many people are still using. However, those unix servers just keep going and going, and python is a great scripting language. Maybe there should be a separate download page for patches to get python to work with obscure/obsolete systems - just so others don't have to repeat my debugging. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2005-02-09 20:26 Message: Logged In: YES user_id=142072 openpty patch: The openpty stub is nonfunctional. I spent a day trying to emulate enough pty stuff on AIX 4.1 to get it to work - but failed. At least with the stub it compiles. Almost everything else works on AIX 4.1 (need to get db4.2 installed for bsddb to work, curses has a few bugs). AIX 4.1 has BSD style ptys (with matching pty and tty pairs), and also sysv style where opening a magic device assigns you an arbitrary minor device number. I'm pretty sure it is possible to make ptys work reasonably with python on aix 4.1, but I haven't had time to get it to work. By returning ENOENT, python code that depends on pty support thinks that none are available - which is effectively the case at present. dynload_aix patch: The change to dynload_aix.c was correct for aix 4.2 and later. It is only aix 4.1 that requires the call to loadbind. That is why the restored code is ifdefed for _AIX41 specifically. I did notice during the lifecycle of python 2.3, in that I never got python2.3 to run on aix4.1 - but I didn't have time to track down the problem. I am just getting around to it now, but thought I'd go for 2.4 instead. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-02-09 18:55 Message: Logged In: YES user_id=6380 Sorry, I don't have a clue any more. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-09 18:46 Message: Logged In: YES user_id=21627 I don't understand the patch. Why do you provide an implementation of openpty that says it creates a pseudo tty master slave pair, and is implementented by setting errno to ENOENT? The changes to remove loadbind were made in dynload_aix.c 2.12, where Guido applied #568629, which in turn was from Oren Tirosh. It was meant to replace the new module, so I presume the change to dynload_aix was unintentional (but then, it is probably no problem, as nobody noticed during the entire life of Python 2.3). Assigning this to gvanrossum for further comments, and also asking orenti to comment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1119626&group_id=5470 From noreply at sourceforge.net Thu Feb 10 04:45:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 04:45:42 2005 Subject: [Patches] [ python-Patches-968728 ] Py_HUGE_VAL HUGE_VAL HUGE undefined Message-ID: Patches item #968728, was opened at 2004-06-08 10:48 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968728&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Michael Schloh von Bennewitz (michaesc) Assigned to: Nobody/Anonymous (nobody) Summary: Py_HUGE_VAL HUGE_VAL HUGE undefined Initial Comment: In Python 2.3.4 (as well as the trunk revision on CVS), Py_HUGE_VAL is conditionally defined as HUGE_VAL. On at least Solaris 10 x86 and Solaris 10 SPARC, this causes a build failure. I'm ashamed to say that I wasn't able to 100% diagnose this problem (I didn't have time). My first guess was that somehow HUGE_VAL was not getting properly defined on Solaris 10 due to its rewritten /usr/include/iso/math_iso.h file (now conditionally defining HUGE_VAL depending on a _STDC_C99 and _XOPEN_SOURCE definition). Because I noticed that the identifier HUGE is unconditionally defined on Solaris 10 and seemingly all earlier Solaris releases, I tried using that instead and the build problem disappeared. You can make your own conclusion as to whether my fix is correct, or if there is a better way to solve this problem. There may be a faulty assumption made by configure or in some Makefile of how the compiler is being used, or maybe python depends on a certain GCC release. CC: GCC 3.4.0 CXX: GCC 3.4.0 CFLAGS: -O2 -pipe CXXFLAGS: -O2 -pipe CPPFLAGS: None Make: GNU Make 3.80 LDFLAGS: None mich@dev:/tmp/Python-2.3.4$ ./configure --prefix=/cw checking MACHDEP... freebsd4 checking EXTRAPLATDIR... checking for --without-gcc... no checking for --with-cxx=... no ... The OpenPKG Python package and patch: http://cvs.openpkg.org/dir?d=openpkg-src/python http://cvs.openpkg.org/rlog?f=openpkg-src/python/python.patch Lots of luck, and thanks for maintaining Python. Regards, Michael, OpenPKG http://www.openpkg.org/ ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-10 04:45 Message: Logged In: YES user_id=21627 In GCC, __builtin_huge_val() is indeed a constant expression. The compiler just knows this function, and knows that the function call is indeed a constant expression. The compiler is entitled to that conclusion: __builtin_huge_val is a reserved name, and the compiler can associate any semantics with a reserved name (e.g. treat it as a keyword - just like sizeof(), which also yields a constant). (As a side note: you take the address of __builtin_huge_val, but that gives a linker error, as this function is nowhere implemented; the implementation of it in the compiler returns +INF) The header itself is certainly compliant - one just has to use the "right" compiler, i.e. Sun cc (aka SunPRO, aka Forte, aka whatever they're calling it now). Apparently, __builtin_huge_val is a constant (not a function) in Sun CC - and that is also standards compliant. I just remarked in #1116722 that this is a gcc bug, which should use its fixincludes magic to add the missing parentheses, or replace the definition of HUGE_VAL altogether with something else. Of course, the gcc bug shows only up if _XOPEN_SOURCE is defined (or _STDC_C99 or __C99FEATURES__) - otherwise, gcc will probably provide its own definition of HUGE_VAL. So it is likely that none of the gcc developers has noticed yet, as you need both Solaris 10 *and* a software that turns on _XOPEN_SOURCE. You might want to coordinate with casevh to report the gcc bug and come up with a patch, as outlined in #1116722. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-23 21:25 Message: Logged In: YES user_id=6656 Maaybe the parens are meant to be present in the macro definition? That would make some kind of sense, apart from probably still not meeting the letter of the standard (don't think the result of a function call is a "constant expression", somehow). ---------------------------------------------------------------------- Comment By: Chris P. Ross (cross) Date: 2004-12-23 19:40 Message: Logged In: YES user_id=12814 Oops. My bad. I failed to mention that I'm using gcc 3.4.x on Solaris 10. I assume those options are for the Forte suite (or whatever they're calling it now). Hmm. I wonder how to tell sun that they're header isn't compliant? I wonder if it fails in the same way with Forte? I should try to find out... It *is* a beta OS after-all. :-) Thanks! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-23 19:09 Message: Logged In: YES user_id=31435 >From C99: """ The macro HUGE_VAL expands to a positive double constant expression, not necessarily representable as a float. ... (footnote) HUGE_VAL, HUGE_VALF, and HUGE_VALL can be positive infinities in an implementation that supports infinities. """ Of course a function pointer is not "a positive double constant expression", so doesn't meet the standard's requirements. Some Googling suggested that the "-Xc or -Xa compliation options" may be needed to get standard behavior on Solaris, but that's just hearsay and I really have no idea. Reports of HUGE_VAL creating compilation problems on Solaris for other projects are also easy to find. ---------------------------------------------------------------------- Comment By: Chris P. Ross (cross) Date: 2004-12-23 18:43 Message: Logged In: YES user_id=12814 Hi. I found this today as well. However, a little research shows that what it's defined to (__builtin_huge_val) is actually a function pointer, not a number. So, if I changed Py_HUGE_VAL to be #def'd to HUGE_VAL(), it worked just find on my Solaris 10 machine. What does the c89 and c99 spec say that HUGE_VAL macro should be? A number? Or is having it be a function reference legal? ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-07-17 16:05 Message: Logged In: YES user_id=55188 This doesn't look like a bug in Python per Tim's comment. (Reviewed by Seo Sanghyeon and me at KLDP CodeFest) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-08 21:02 Message: Logged In: YES user_id=31435 I don't see a reason to call this a Python bug. The C89 and C99 standards both require that math.h supply the HUGE_VAL macro. If the compilation system you're using doesn't do so, it's a bug in that system, and should be fixed there. Python doesn't ask for much, but does require an ANSI C compiler. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968728&group_id=5470 From noreply at sourceforge.net Thu Feb 10 05:40:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 05:40:16 2005 Subject: [Patches] [ python-Patches-1119626 ] patches to compile for AIX 4.1.x Message-ID: Patches item #1119626, was opened at 2005-02-09 22:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1119626&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) Assigned to: Nobody/Anonymous (nobody) Summary: patches to compile for AIX 4.1.x Initial Comment: Support for AIX 4.1 got lost, or was dropped with python 2.3. The only thing AIX 4.1 needs over generic AIX support is a call to loadbind when loading dynamic modules. This patch also provides stubs for openpty in posixmodule and wgetnstr in cursesmodule. The openpty stub is non-functional. The wgetnstr stub is functional, but uses a fixed size temporary buffer. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-10 05:40 Message: Logged In: YES user_id=21627 We have PEP 11 (http://www.python.org/peps/pep-0011.html) for such cases. If you don't mind, I can list you as the maintainer of the AIX 4.1 port, and claim that we won't support any AIX versions before that (I long wanted to find out what the oldest AIX version is that we need to support). Then, if you lose interest, or become unresponsive to questions, we would mark AIX 4.1 as unsupported, removal of the code to follow a release later. We are certainly willing to take patches as long as people want to contribute them in a timely manner; we don't want to support Python on systems which don't have any users anymore. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2005-02-10 04:25 Message: Logged In: YES user_id=142072 As to assigning priority. We have only 2 machines left which still run AIX 4.1. I wouldn't be mad if you simply said "we don't support AIX 4.1 any more" so as not to clutter the code with ifdefs for an older release that not many people are still using. However, those unix servers just keep going and going, and python is a great scripting language. Maybe there should be a separate download page for patches to get python to work with obscure/obsolete systems - just so others don't have to repeat my debugging. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2005-02-10 02:26 Message: Logged In: YES user_id=142072 openpty patch: The openpty stub is nonfunctional. I spent a day trying to emulate enough pty stuff on AIX 4.1 to get it to work - but failed. At least with the stub it compiles. Almost everything else works on AIX 4.1 (need to get db4.2 installed for bsddb to work, curses has a few bugs). AIX 4.1 has BSD style ptys (with matching pty and tty pairs), and also sysv style where opening a magic device assigns you an arbitrary minor device number. I'm pretty sure it is possible to make ptys work reasonably with python on aix 4.1, but I haven't had time to get it to work. By returning ENOENT, python code that depends on pty support thinks that none are available - which is effectively the case at present. dynload_aix patch: The change to dynload_aix.c was correct for aix 4.2 and later. It is only aix 4.1 that requires the call to loadbind. That is why the restored code is ifdefed for _AIX41 specifically. I did notice during the lifecycle of python 2.3, in that I never got python2.3 to run on aix4.1 - but I didn't have time to track down the problem. I am just getting around to it now, but thought I'd go for 2.4 instead. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-02-10 00:55 Message: Logged In: YES user_id=6380 Sorry, I don't have a clue any more. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-10 00:46 Message: Logged In: YES user_id=21627 I don't understand the patch. Why do you provide an implementation of openpty that says it creates a pseudo tty master slave pair, and is implementented by setting errno to ENOENT? The changes to remove loadbind were made in dynload_aix.c 2.12, where Guido applied #568629, which in turn was from Oren Tirosh. It was meant to replace the new module, so I presume the change to dynload_aix was unintentional (but then, it is probably no problem, as nobody noticed during the entire life of Python 2.3). Assigning this to gvanrossum for further comments, and also asking orenti to comment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1119626&group_id=5470 From noreply at sourceforge.net Thu Feb 10 05:44:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 05:44:05 2005 Subject: [Patches] [ python-Patches-1116722 ] Solaris 10 fails to compile complexobject.c [FIX incl.] Message-ID: Patches item #1116722, was opened at 2005-02-05 02:02 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Case Van Horsen (casevh) Assigned to: Martin v. L?wis (loewis) Summary: Solaris 10 fails to compile complexobject.c [FIX incl.] Initial Comment: This is a duplicate of 970334. The fix I used was to make the following change in pyport.h: Change #define Py_HUGE_VAL HUGE_VAL to #define PY_HUGE_VAL DBL_MAX. DBL_MAX is found in float.h Versions used: Python 2.4 gcc 3.4.3 Solaris 10 x86 GA release. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-02-09 23:44 Message: Logged In: YES user_id=31435 Doubt this will help: googling suggests that -Xc has to be passed to Sun's native C compiler to get HUGE_VAL defined correctly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-09 22:23 Message: Logged In: YES user_id=21627 I have the Solaris 10 iso/math_c99.h in front of me, but no gcc, so it is somewhat difficult to get through the ifdefery. It appears that we should have _XOPEN_SOURCE - 0 >= 600, so we should be using #define HUGE_VAL __builtin_huge_val The problem apparently is that in Sun CC, __builtin_huge_val appears to be a constant, whereas in gcc, it probably is a function, so the definition should read #define HUGE_VAL __builtin_huge_val() So there is a bug in the gcc port of Solaris here - fixincludes should adjust the definition of HUGE_VAL when installing its adjusted copy of math_c99.h. I'm willing to accept patches to work around this gcc bug, but only if the bug gets reported to gcc first. So, please, 1. find out the gcc installation directory on your system, using gcc --print-search-dirs 2a. check whether /include/iso/math_c99.h exists 2b. if it does not exist, copy if from /usr/include/iso/math_c99.h 3. edit /include/iso/math_c99.h to add the parentheses after builtin_huge_val 4. check whether this fixes the problem 5a. if not, provide the preprocessor output for complexobject.i, using --save-temps 5b. if it does, make a bug report to gcc, indicating that the program #include int main() { double f=HUGE_VAL; } fails on Solaris 10. For that report - check whether it actually fails without the update math_c99, and succeeds with it (you might have to #define _XOPEN_SOURCE to make it fail) - include the preprocessor output for this sample program, using the original math_c99 - indicate that a solution is to add parentheses 6. Come up with a patch that checks for Solaris 10 and all gcc versions showing the problem (i.e. 3.4.x, with x<=3, perhaps also 3.y, y<=3), and defines Py_HUGE_VAL correctly for this system. 7. Report the gcc bug number and the patch in this report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-09 20:43 Message: Logged In: YES user_id=31435 The C standard requires that "The macro HUGE_VAL expands to a positive double constant expression, not necessarily representable as a float". Python requires that too. #define'ing to worm around a broken compilation environment isn't acceptable to me; finding a switch to make this environment conform to the standard would be OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 From noreply at sourceforge.net Thu Feb 10 06:13:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 06:13:09 2005 Subject: [Patches] [ python-Patches-1119626 ] patches to compile for AIX 4.1.x Message-ID: Patches item #1119626, was opened at 2005-02-09 16:18 Message generated for change (Comment added) made by customdesigned You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1119626&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) Assigned to: Nobody/Anonymous (nobody) Summary: patches to compile for AIX 4.1.x Initial Comment: Support for AIX 4.1 got lost, or was dropped with python 2.3. The only thing AIX 4.1 needs over generic AIX support is a call to loadbind when loading dynamic modules. This patch also provides stubs for openpty in posixmodule and wgetnstr in cursesmodule. The openpty stub is non-functional. The wgetnstr stub is functional, but uses a fixed size temporary buffer. ---------------------------------------------------------------------- >Comment By: Stuart D. Gathman (customdesigned) Date: 2005-02-10 00:13 Message: Logged In: YES user_id=142072 I am happy to be the aix-4.1 maintainer as long as we have the systems. You should list aix-4.1.5 as the oldest supported version (since that is what I have.) When the last two 4.1 systems are gone in a few years, the oldest AIX systems we have will be AIX 4.3.x - which is what the majority of AIX4 users will have. AIX rpms are available at http://bmsi.com/aix/ (and a tar.gz of a binary rpm-3.0.6). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-09 23:40 Message: Logged In: YES user_id=21627 We have PEP 11 (http://www.python.org/peps/pep-0011.html) for such cases. If you don't mind, I can list you as the maintainer of the AIX 4.1 port, and claim that we won't support any AIX versions before that (I long wanted to find out what the oldest AIX version is that we need to support). Then, if you lose interest, or become unresponsive to questions, we would mark AIX 4.1 as unsupported, removal of the code to follow a release later. We are certainly willing to take patches as long as people want to contribute them in a timely manner; we don't want to support Python on systems which don't have any users anymore. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2005-02-09 22:25 Message: Logged In: YES user_id=142072 As to assigning priority. We have only 2 machines left which still run AIX 4.1. I wouldn't be mad if you simply said "we don't support AIX 4.1 any more" so as not to clutter the code with ifdefs for an older release that not many people are still using. However, those unix servers just keep going and going, and python is a great scripting language. Maybe there should be a separate download page for patches to get python to work with obscure/obsolete systems - just so others don't have to repeat my debugging. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2005-02-09 20:26 Message: Logged In: YES user_id=142072 openpty patch: The openpty stub is nonfunctional. I spent a day trying to emulate enough pty stuff on AIX 4.1 to get it to work - but failed. At least with the stub it compiles. Almost everything else works on AIX 4.1 (need to get db4.2 installed for bsddb to work, curses has a few bugs). AIX 4.1 has BSD style ptys (with matching pty and tty pairs), and also sysv style where opening a magic device assigns you an arbitrary minor device number. I'm pretty sure it is possible to make ptys work reasonably with python on aix 4.1, but I haven't had time to get it to work. By returning ENOENT, python code that depends on pty support thinks that none are available - which is effectively the case at present. dynload_aix patch: The change to dynload_aix.c was correct for aix 4.2 and later. It is only aix 4.1 that requires the call to loadbind. That is why the restored code is ifdefed for _AIX41 specifically. I did notice during the lifecycle of python 2.3, in that I never got python2.3 to run on aix4.1 - but I didn't have time to track down the problem. I am just getting around to it now, but thought I'd go for 2.4 instead. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-02-09 18:55 Message: Logged In: YES user_id=6380 Sorry, I don't have a clue any more. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-09 18:46 Message: Logged In: YES user_id=21627 I don't understand the patch. Why do you provide an implementation of openpty that says it creates a pseudo tty master slave pair, and is implementented by setting errno to ENOENT? The changes to remove loadbind were made in dynload_aix.c 2.12, where Guido applied #568629, which in turn was from Oren Tirosh. It was meant to replace the new module, so I presume the change to dynload_aix was unintentional (but then, it is probably no problem, as nobody noticed during the entire life of Python 2.3). Assigning this to gvanrossum for further comments, and also asking orenti to comment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1119626&group_id=5470 From noreply at sourceforge.net Thu Feb 10 17:50:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 17:50:38 2005 Subject: [Patches] [ python-Patches-1116722 ] Solaris 10 fails to compile complexobject.c [FIX incl.] Message-ID: Patches item #1116722, was opened at 2005-02-04 23:02 Message generated for change (Comment added) made by casevh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Case Van Horsen (casevh) Assigned to: Martin v. L?wis (loewis) Summary: Solaris 10 fails to compile complexobject.c [FIX incl.] Initial Comment: This is a duplicate of 970334. The fix I used was to make the following change in pyport.h: Change #define Py_HUGE_VAL HUGE_VAL to #define PY_HUGE_VAL DBL_MAX. DBL_MAX is found in float.h Versions used: Python 2.4 gcc 3.4.3 Solaris 10 x86 GA release. ---------------------------------------------------------------------- >Comment By: Case Van Horsen (casevh) Date: 2005-02-10 08:50 Message: Logged In: YES user_id=1212585 I tried steps 1 through 4 and it fails, with and with the (). I'm not sure how to do step 5. I will try the short program snippet later and report back. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-09 20:44 Message: Logged In: YES user_id=31435 Doubt this will help: googling suggests that -Xc has to be passed to Sun's native C compiler to get HUGE_VAL defined correctly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-09 19:23 Message: Logged In: YES user_id=21627 I have the Solaris 10 iso/math_c99.h in front of me, but no gcc, so it is somewhat difficult to get through the ifdefery. It appears that we should have _XOPEN_SOURCE - 0 >= 600, so we should be using #define HUGE_VAL __builtin_huge_val The problem apparently is that in Sun CC, __builtin_huge_val appears to be a constant, whereas in gcc, it probably is a function, so the definition should read #define HUGE_VAL __builtin_huge_val() So there is a bug in the gcc port of Solaris here - fixincludes should adjust the definition of HUGE_VAL when installing its adjusted copy of math_c99.h. I'm willing to accept patches to work around this gcc bug, but only if the bug gets reported to gcc first. So, please, 1. find out the gcc installation directory on your system, using gcc --print-search-dirs 2a. check whether /include/iso/math_c99.h exists 2b. if it does not exist, copy if from /usr/include/iso/math_c99.h 3. edit /include/iso/math_c99.h to add the parentheses after builtin_huge_val 4. check whether this fixes the problem 5a. if not, provide the preprocessor output for complexobject.i, using --save-temps 5b. if it does, make a bug report to gcc, indicating that the program #include int main() { double f=HUGE_VAL; } fails on Solaris 10. For that report - check whether it actually fails without the update math_c99, and succeeds with it (you might have to #define _XOPEN_SOURCE to make it fail) - include the preprocessor output for this sample program, using the original math_c99 - indicate that a solution is to add parentheses 6. Come up with a patch that checks for Solaris 10 and all gcc versions showing the problem (i.e. 3.4.x, with x<=3, perhaps also 3.y, y<=3), and defines Py_HUGE_VAL correctly for this system. 7. Report the gcc bug number and the patch in this report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-09 17:43 Message: Logged In: YES user_id=31435 The C standard requires that "The macro HUGE_VAL expands to a positive double constant expression, not necessarily representable as a float". Python requires that too. #define'ing to worm around a broken compilation environment isn't acceptable to me; finding a switch to make this environment conform to the standard would be OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 From noreply at sourceforge.net Thu Feb 10 22:25:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 22:25:56 2005 Subject: [Patches] [ python-Patches-1120353 ] better datetime support for xmlrpclib Message-ID: Patches item #1120353, was opened at 2005-02-10 16:25 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=1120353&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fredrik Lundh (effbot) Summary: better datetime support for xmlrpclib Initial Comment: This patch makes it possible for an application to ask that datetime objects be used instead of xmlrpclib.DateTime instances. I'm submitting this as a patch instead of checking this in since it's a more invasive change to Fredrik's module than my earlier change to make it accept datetime objects as valid date/time values. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1120353&group_id=5470 From noreply at sourceforge.net Thu Feb 10 23:25:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 23:25:27 2005 Subject: [Patches] [ python-Patches-1117398 ] cookielib LWPCookieJar and MozillaCookieJar exceptions Message-ID: Patches item #1117398, was opened at 2005-02-06 17:39 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: cookielib LWPCookieJar and MozillaCookieJar exceptions Initial Comment: cookielib.LWPCookieJar and .MozillaCookieJar are documented to raise cookielib.LoadError on attempt to load an invalid cookies file, but do not. I think this should be backported to the 2.4 maintenance branch. Reason: I suspect more people will be bitten by the bug than will be bitten by the patch, since cookies files will rarely be invalid, so people are likely to have written except statements based on the docs in this case, rather than based on the actual exception that currently occurs. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2005-02-10 22:25 Message: Logged In: YES user_id=261020 Jim, I don't understand the first sentence in your comment. Re a 2.4 backport that makes LoadError derive from IOError: it makes me wince, but I can't think of an argument against it. No, LoadError should not be a subclass of IOError in the trunk, because the cases where LoadError is documented to be raised do not involve failures of I/O, but rather invalid data. See the docs for IOError. (FWIW, EnvironmentError (IOError's base class) wouldn't be a suitable subclass either: eg. what would we want with an .errno attribute?) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-08 16:58 Message: Logged In: YES user_id=764593 I often look at the code in a second idle window rather than starting a web browser. Would it work to make LoadError a subclass of IOError, at least for the backport? People who followed the docs will get a bugfix, but people who followed the code would get no breakage. Should LoadError be a subclass of IOError even in the main trunk? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 From noreply at sourceforge.net Thu Feb 10 23:47:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 23:47:10 2005 Subject: [Patches] [ python-Patches-1096244 ] time.tzset() not built on Solaris Message-ID: Patches item #1096244, was opened at 2005-01-04 21:26 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1096244&group_id=5470 Category: Build Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gregory Bond (gnbond) Assigned to: Brett Cannon (bcannon) Summary: time.tzset() not built on Solaris Initial Comment: The time.tzset() function is not included in Solaris builds, because the code in configure.in that checks for the existence of tzset() relies on struct tm having a tm_zone member - which Solaris does not have (at least not up to 2.8). The attached patch to configure.in allows Solaris to detect the existence of tzset() and Python builds OK, and the resulting time.tzset() function seems to work just fine. diff -u configure.in.DIST configure.in --- configure.in.DIST 2005-01-05 16:25:24.830001000 +1100 +++ configure.in 2005-01-05 16:25:38.227000000 +1100 @@ -2912,10 +2912,6 @@ tzset(); if (localtime(&groundhogday)->tm_hour != 11) exit(1); - if (strcmp(localtime(&groundhogday)->tm_zone, "AEDT")) - exit(1); - if (strcmp(localtime(&midyear)->tm_zone, "AEST")) - exit(1); exit(0); } ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-02-10 14:47 Message: Logged In: YES user_id=357491 For configure.in, rev. 1.481 in 2.5 and rev. 1.475.2.6 in 2.4 have the fix. Only modified the comments of your patch. Thanks, Gregory! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-01-06 19:57 Message: Logged In: YES user_id=357491 Well, considering tzset can be called when HAVE_TZNAME is set it definitely does not hurt to check it. The patch basically looks good, but I don't have time right now for a thorough check so I am not going to check it in right away. But it will get in. ---------------------------------------------------------------------- Comment By: Gregory Bond (gnbond) Date: 2005-01-06 17:44 Message: Logged In: YES user_id=293157 I've added second patch with more comprehensive diffs that also checks whether tzset() affects tzname[] (for those systems without tm_zone). This may be considered overkill! ---------------------------------------------------------------------- Comment By: Gregory Bond (gnbond) Date: 2005-01-06 16:56 Message: Logged In: YES user_id=293157 Hmm, I'm no autoconf guru, but try the attached patch. It seems to do the right thing on Solaris (tzset but no tm_zone) and FreeBSD (tzset and tm_zone). Amazing what you can find with half an hour of Google! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-01-05 23:26 Message: Logged In: YES user_id=357491 But that fix removes a sanity check to detect broken tzset implementations. Is there a similar way to check on Solaris to make sure tzset is not broken? If so resubmit a patch (I reclassified this tracker item appropriately) that makes the test conditional on Solaris. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1096244&group_id=5470 From noreply at sourceforge.net Fri Feb 11 02:32:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 11 02:32:30 2005 Subject: [Patches] [ python-Patches-992750 ] zipfile and big zipped file Message-ID: Patches item #992750, was opened at 2004-07-17 02:45 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=992750&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Keyphrene (keyphrene) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile and big zipped file Initial Comment: read method decompress the zipped files, but this method returns bytes, more the file is big, more the bytes array is big. readFile method allows to send the bytes in a file. ---------------------------------------------------------------------- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-02-10 20:32 Message: Logged In: YES user_id=1115903 Ok, I ended up just starting from scratch and implementing a file-like class - it just implements read([size]) right now - and an instance of this class is returned when you call ZipFile.open. ZipFile.read was modified to use open(), as loewis suggested. I also added some code to test_zipfile.py to check the new open function, and tried using it to extract a 690MB file from a ZIP with copyfileobj. It seems to be working ok. Since I can't get into CVS at the moment, I don't have diff files to post. Even if I did, I don't see an option for me to post them to this patch. Should I post them as a new patch? ---------------------------------------------------------------------- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-02-09 17:29 Message: Logged In: YES user_id=1115903 The current behavior of ZipFile.read is an occasional annoyance for me. I will make the changes described in loewis' comments and submit the updated patch, unless somebody is already working on it. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-18 08:13 Message: Logged In: YES user_id=21627 The patch is unacceptable in its current form. It duplicates too much code; read and readfile should really share the common code (e.g. by read falling back to readfile). Also, as this really copies the data to fileobj, it probably is better called copyfile, instead of readfile. Finally, I would much prefer if zipfile would have an .open method, returning a file-like object. Then you would have such implementations def read(self, name): return self.open(name, "r").read() def readfile(self, name, dest): import shutil shutil.copyfileobj(self.open(name,"r"), dest) I would then probably leave the last method out, and encourage users to invoke shutil.copyfileobj directly if desired. Are you willing to make changes in this direction? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=992750&group_id=5470 From noreply at sourceforge.net Fri Feb 11 06:16:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 11 06:16:09 2005 Subject: [Patches] [ python-Patches-1116722 ] Solaris 10 fails to compile complexobject.c [FIX incl.] Message-ID: Patches item #1116722, was opened at 2005-02-04 23:02 Message generated for change (Comment added) made by casevh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Case Van Horsen (casevh) Assigned to: Martin v. L?wis (loewis) Summary: Solaris 10 fails to compile complexobject.c [FIX incl.] Initial Comment: This is a duplicate of 970334. The fix I used was to make the following change in pyport.h: Change #define Py_HUGE_VAL HUGE_VAL to #define PY_HUGE_VAL DBL_MAX. DBL_MAX is found in float.h Versions used: Python 2.4 gcc 3.4.3 Solaris 10 x86 GA release. ---------------------------------------------------------------------- >Comment By: Case Van Horsen (casevh) Date: 2005-02-10 21:16 Message: Logged In: YES user_id=1212585 I ran mkheaders to rebuild the gcc headers but that made no difference. The following program (hv.c) compiled correctly: #define _XOPEN_SOURCE 500 #include int main() { double f=HUGE_VAL; } The following program (hv2.c) did not compile. #define _XOPEN_SOURCE 1000 #include int main() { double f=HUGE_VAL; } Output is: $ gcc --save-temps hv.c $ gcc --save-temp hv2.c hv2.c: In function `main': hv2.c:5: error: incompatible types in initialization $ I have attached hv.i and hv2.i. I have also attached complexobject.i I'm not a C programmer so please let me know what else I can do to help. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-10 08:50 Message: Logged In: YES user_id=1212585 I tried steps 1 through 4 and it fails, with and with the (). I'm not sure how to do step 5. I will try the short program snippet later and report back. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-09 20:44 Message: Logged In: YES user_id=31435 Doubt this will help: googling suggests that -Xc has to be passed to Sun's native C compiler to get HUGE_VAL defined correctly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-09 19:23 Message: Logged In: YES user_id=21627 I have the Solaris 10 iso/math_c99.h in front of me, but no gcc, so it is somewhat difficult to get through the ifdefery. It appears that we should have _XOPEN_SOURCE - 0 >= 600, so we should be using #define HUGE_VAL __builtin_huge_val The problem apparently is that in Sun CC, __builtin_huge_val appears to be a constant, whereas in gcc, it probably is a function, so the definition should read #define HUGE_VAL __builtin_huge_val() So there is a bug in the gcc port of Solaris here - fixincludes should adjust the definition of HUGE_VAL when installing its adjusted copy of math_c99.h. I'm willing to accept patches to work around this gcc bug, but only if the bug gets reported to gcc first. So, please, 1. find out the gcc installation directory on your system, using gcc --print-search-dirs 2a. check whether /include/iso/math_c99.h exists 2b. if it does not exist, copy if from /usr/include/iso/math_c99.h 3. edit /include/iso/math_c99.h to add the parentheses after builtin_huge_val 4. check whether this fixes the problem 5a. if not, provide the preprocessor output for complexobject.i, using --save-temps 5b. if it does, make a bug report to gcc, indicating that the program #include int main() { double f=HUGE_VAL; } fails on Solaris 10. For that report - check whether it actually fails without the update math_c99, and succeeds with it (you might have to #define _XOPEN_SOURCE to make it fail) - include the preprocessor output for this sample program, using the original math_c99 - indicate that a solution is to add parentheses 6. Come up with a patch that checks for Solaris 10 and all gcc versions showing the problem (i.e. 3.4.x, with x<=3, perhaps also 3.y, y<=3), and defines Py_HUGE_VAL correctly for this system. 7. Report the gcc bug number and the patch in this report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-09 17:43 Message: Logged In: YES user_id=31435 The C standard requires that "The macro HUGE_VAL expands to a positive double constant expression, not necessarily representable as a float". Python requires that too. #define'ing to worm around a broken compilation environment isn't acceptable to me; finding a switch to make this environment conform to the standard would be OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 From noreply at sourceforge.net Fri Feb 11 07:03:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 11 07:03:15 2005 Subject: [Patches] [ python-Patches-1116722 ] Solaris 10 fails to compile complexobject.c [FIX incl.] Message-ID: Patches item #1116722, was opened at 2005-02-04 23:02 Message generated for change (Comment added) made by casevh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Case Van Horsen (casevh) Assigned to: Martin v. L?wis (loewis) Summary: Solaris 10 fails to compile complexobject.c [FIX incl.] Initial Comment: This is a duplicate of 970334. The fix I used was to make the following change in pyport.h: Change #define Py_HUGE_VAL HUGE_VAL to #define PY_HUGE_VAL DBL_MAX. DBL_MAX is found in float.h Versions used: Python 2.4 gcc 3.4.3 Solaris 10 x86 GA release. ---------------------------------------------------------------------- >Comment By: Case Van Horsen (casevh) Date: 2005-02-10 22:03 Message: Logged In: YES user_id=1212585 I poked around in the preprocessor outputs and it appears gcc doesn't its specific directory for math_c99.h. It only appears to look in /usr/include/iso. I changed the definition of HUGE_VAL in /usr/include/iso/math_c99.h to read: #define HUGE_VAL __builtin_huge_val() The hv2.c compiled completely and so did Python 2.4. I'll open a bug report with GCC and also with Sun since I used the version of GCC that was distributed by Sun. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-10 21:16 Message: Logged In: YES user_id=1212585 I ran mkheaders to rebuild the gcc headers but that made no difference. The following program (hv.c) compiled correctly: #define _XOPEN_SOURCE 500 #include int main() { double f=HUGE_VAL; } The following program (hv2.c) did not compile. #define _XOPEN_SOURCE 1000 #include int main() { double f=HUGE_VAL; } Output is: $ gcc --save-temps hv.c $ gcc --save-temp hv2.c hv2.c: In function `main': hv2.c:5: error: incompatible types in initialization $ I have attached hv.i and hv2.i. I have also attached complexobject.i I'm not a C programmer so please let me know what else I can do to help. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-10 08:50 Message: Logged In: YES user_id=1212585 I tried steps 1 through 4 and it fails, with and with the (). I'm not sure how to do step 5. I will try the short program snippet later and report back. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-09 20:44 Message: Logged In: YES user_id=31435 Doubt this will help: googling suggests that -Xc has to be passed to Sun's native C compiler to get HUGE_VAL defined correctly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-09 19:23 Message: Logged In: YES user_id=21627 I have the Solaris 10 iso/math_c99.h in front of me, but no gcc, so it is somewhat difficult to get through the ifdefery. It appears that we should have _XOPEN_SOURCE - 0 >= 600, so we should be using #define HUGE_VAL __builtin_huge_val The problem apparently is that in Sun CC, __builtin_huge_val appears to be a constant, whereas in gcc, it probably is a function, so the definition should read #define HUGE_VAL __builtin_huge_val() So there is a bug in the gcc port of Solaris here - fixincludes should adjust the definition of HUGE_VAL when installing its adjusted copy of math_c99.h. I'm willing to accept patches to work around this gcc bug, but only if the bug gets reported to gcc first. So, please, 1. find out the gcc installation directory on your system, using gcc --print-search-dirs 2a. check whether /include/iso/math_c99.h exists 2b. if it does not exist, copy if from /usr/include/iso/math_c99.h 3. edit /include/iso/math_c99.h to add the parentheses after builtin_huge_val 4. check whether this fixes the problem 5a. if not, provide the preprocessor output for complexobject.i, using --save-temps 5b. if it does, make a bug report to gcc, indicating that the program #include int main() { double f=HUGE_VAL; } fails on Solaris 10. For that report - check whether it actually fails without the update math_c99, and succeeds with it (you might have to #define _XOPEN_SOURCE to make it fail) - include the preprocessor output for this sample program, using the original math_c99 - indicate that a solution is to add parentheses 6. Come up with a patch that checks for Solaris 10 and all gcc versions showing the problem (i.e. 3.4.x, with x<=3, perhaps also 3.y, y<=3), and defines Py_HUGE_VAL correctly for this system. 7. Report the gcc bug number and the patch in this report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-09 17:43 Message: Logged In: YES user_id=31435 The C standard requires that "The macro HUGE_VAL expands to a positive double constant expression, not necessarily representable as a float". Python requires that too. #define'ing to worm around a broken compilation environment isn't acceptable to me; finding a switch to make this environment conform to the standard would be OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 From noreply at sourceforge.net Fri Feb 11 07:33:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 11 07:33:47 2005 Subject: [Patches] [ python-Patches-1116722 ] Solaris 10 fails to compile complexobject.c [FIX incl.] Message-ID: Patches item #1116722, was opened at 2005-02-04 23:02 Message generated for change (Comment added) made by casevh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Case Van Horsen (casevh) Assigned to: Martin v. L?wis (loewis) Summary: Solaris 10 fails to compile complexobject.c [FIX incl.] Initial Comment: This is a duplicate of 970334. The fix I used was to make the following change in pyport.h: Change #define Py_HUGE_VAL HUGE_VAL to #define PY_HUGE_VAL DBL_MAX. DBL_MAX is found in float.h Versions used: Python 2.4 gcc 3.4.3 Solaris 10 x86 GA release. ---------------------------------------------------------------------- >Comment By: Case Van Horsen (casevh) Date: 2005-02-10 22:33 Message: Logged In: YES user_id=1212585 Oops. I made a typo in one of my tests. It does include in /include/iso/math_c99.h when you type it correctly. I will work with Sun / gcc to determine a resolution. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-10 22:03 Message: Logged In: YES user_id=1212585 I poked around in the preprocessor outputs and it appears gcc doesn't its specific directory for math_c99.h. It only appears to look in /usr/include/iso. I changed the definition of HUGE_VAL in /usr/include/iso/math_c99.h to read: #define HUGE_VAL __builtin_huge_val() The hv2.c compiled completely and so did Python 2.4. I'll open a bug report with GCC and also with Sun since I used the version of GCC that was distributed by Sun. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-10 21:16 Message: Logged In: YES user_id=1212585 I ran mkheaders to rebuild the gcc headers but that made no difference. The following program (hv.c) compiled correctly: #define _XOPEN_SOURCE 500 #include int main() { double f=HUGE_VAL; } The following program (hv2.c) did not compile. #define _XOPEN_SOURCE 1000 #include int main() { double f=HUGE_VAL; } Output is: $ gcc --save-temps hv.c $ gcc --save-temp hv2.c hv2.c: In function `main': hv2.c:5: error: incompatible types in initialization $ I have attached hv.i and hv2.i. I have also attached complexobject.i I'm not a C programmer so please let me know what else I can do to help. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-10 08:50 Message: Logged In: YES user_id=1212585 I tried steps 1 through 4 and it fails, with and with the (). I'm not sure how to do step 5. I will try the short program snippet later and report back. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-09 20:44 Message: Logged In: YES user_id=31435 Doubt this will help: googling suggests that -Xc has to be passed to Sun's native C compiler to get HUGE_VAL defined correctly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-09 19:23 Message: Logged In: YES user_id=21627 I have the Solaris 10 iso/math_c99.h in front of me, but no gcc, so it is somewhat difficult to get through the ifdefery. It appears that we should have _XOPEN_SOURCE - 0 >= 600, so we should be using #define HUGE_VAL __builtin_huge_val The problem apparently is that in Sun CC, __builtin_huge_val appears to be a constant, whereas in gcc, it probably is a function, so the definition should read #define HUGE_VAL __builtin_huge_val() So there is a bug in the gcc port of Solaris here - fixincludes should adjust the definition of HUGE_VAL when installing its adjusted copy of math_c99.h. I'm willing to accept patches to work around this gcc bug, but only if the bug gets reported to gcc first. So, please, 1. find out the gcc installation directory on your system, using gcc --print-search-dirs 2a. check whether /include/iso/math_c99.h exists 2b. if it does not exist, copy if from /usr/include/iso/math_c99.h 3. edit /include/iso/math_c99.h to add the parentheses after builtin_huge_val 4. check whether this fixes the problem 5a. if not, provide the preprocessor output for complexobject.i, using --save-temps 5b. if it does, make a bug report to gcc, indicating that the program #include int main() { double f=HUGE_VAL; } fails on Solaris 10. For that report - check whether it actually fails without the update math_c99, and succeeds with it (you might have to #define _XOPEN_SOURCE to make it fail) - include the preprocessor output for this sample program, using the original math_c99 - indicate that a solution is to add parentheses 6. Come up with a patch that checks for Solaris 10 and all gcc versions showing the problem (i.e. 3.4.x, with x<=3, perhaps also 3.y, y<=3), and defines Py_HUGE_VAL correctly for this system. 7. Report the gcc bug number and the patch in this report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-09 17:43 Message: Logged In: YES user_id=31435 The C standard requires that "The macro HUGE_VAL expands to a positive double constant expression, not necessarily representable as a float". Python requires that too. #define'ing to worm around a broken compilation environment isn't acceptable to me; finding a switch to make this environment conform to the standard would be OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 From noreply at sourceforge.net Fri Feb 11 17:06:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 11 17:06:08 2005 Subject: [Patches] [ python-Patches-1117398 ] cookielib LWPCookieJar and MozillaCookieJar exceptions Message-ID: Patches item #1117398, was opened at 2005-02-06 12:39 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: cookielib LWPCookieJar and MozillaCookieJar exceptions Initial Comment: cookielib.LWPCookieJar and .MozillaCookieJar are documented to raise cookielib.LoadError on attempt to load an invalid cookies file, but do not. I think this should be backported to the 2.4 maintenance branch. Reason: I suspect more people will be bitten by the bug than will be bitten by the patch, since cookies files will rarely be invalid, so people are likely to have written except statements based on the docs in this case, rather than based on the actual exception that currently occurs. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 11:06 Message: Logged In: YES user_id=764593 The first sentence was pointing out that many people (including me) never see the pretty-for-printing documentation, and even the html form isn't generally convenient when I'm actually programming. So I rely on the introspection tools. I see object names, signatures, and docstrings. If I need more information, I look at the code, which raises IOError. While I don't yet have code catching this particular error, I do write in a way that would break; it wouldn't have occurred to me to put both types of error in an except clause just in case it changed later. (Well, unless the docstring or at least a comment in the code itself warned me to.) So I would definately prefer that it remain (at least a subclass of) IOError for at least 2.4.x I would also appreciate comments in the fixed 2.4 code if it is going to change for 2.5. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-10 17:25 Message: Logged In: YES user_id=261020 Jim, I don't understand the first sentence in your comment. Re a 2.4 backport that makes LoadError derive from IOError: it makes me wince, but I can't think of an argument against it. No, LoadError should not be a subclass of IOError in the trunk, because the cases where LoadError is documented to be raised do not involve failures of I/O, but rather invalid data. See the docs for IOError. (FWIW, EnvironmentError (IOError's base class) wouldn't be a suitable subclass either: eg. what would we want with an .errno attribute?) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-08 11:58 Message: Logged In: YES user_id=764593 I often look at the code in a second idle window rather than starting a web browser. Would it work to make LoadError a subclass of IOError, at least for the backport? People who followed the docs will get a bugfix, but people who followed the code would get no breakage. Should LoadError be a subclass of IOError even in the main trunk? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 From noreply at sourceforge.net Fri Feb 11 19:57:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 11 19:57:14 2005 Subject: [Patches] [ python-Patches-1117398 ] cookielib LWPCookieJar and MozillaCookieJar exceptions Message-ID: Patches item #1117398, was opened at 2005-02-06 17:39 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: cookielib LWPCookieJar and MozillaCookieJar exceptions Initial Comment: cookielib.LWPCookieJar and .MozillaCookieJar are documented to raise cookielib.LoadError on attempt to load an invalid cookies file, but do not. I think this should be backported to the 2.4 maintenance branch. Reason: I suspect more people will be bitten by the bug than will be bitten by the patch, since cookies files will rarely be invalid, so people are likely to have written except statements based on the docs in this case, rather than based on the actual exception that currently occurs. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2005-02-11 18:57 Message: Logged In: YES user_id=261020 I agree the backport (but not the trunk) should have LoadError derive from IOError. I'd be happy for comments to go in noting the change in all places where LoadError is raised, if that's considered good practice. Any committers reading: should I submit an updated patch with just those added comments? Should I submit a patch for the backport, with just that change plus the added (IOError) for backwards-compat.? (Jim: Besides the point for the matter at hand, but I should point out that the "pretty-for-printing" cookielib docs and the docstrings in cookielib.py form almost disjoint sets. Most of the documentation lives under Doc/lib, the stuff in the module source is the more obscure detail. And of course, you have just demonstrated to yourself how not reading the docs leaves you with an incomplete understanding of the intent, which can be useful! Not that I *ever* do that, of course ;-) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 16:06 Message: Logged In: YES user_id=764593 The first sentence was pointing out that many people (including me) never see the pretty-for-printing documentation, and even the html form isn't generally convenient when I'm actually programming. So I rely on the introspection tools. I see object names, signatures, and docstrings. If I need more information, I look at the code, which raises IOError. While I don't yet have code catching this particular error, I do write in a way that would break; it wouldn't have occurred to me to put both types of error in an except clause just in case it changed later. (Well, unless the docstring or at least a comment in the code itself warned me to.) So I would definately prefer that it remain (at least a subclass of) IOError for at least 2.4.x I would also appreciate comments in the fixed 2.4 code if it is going to change for 2.5. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-10 22:25 Message: Logged In: YES user_id=261020 Jim, I don't understand the first sentence in your comment. Re a 2.4 backport that makes LoadError derive from IOError: it makes me wince, but I can't think of an argument against it. No, LoadError should not be a subclass of IOError in the trunk, because the cases where LoadError is documented to be raised do not involve failures of I/O, but rather invalid data. See the docs for IOError. (FWIW, EnvironmentError (IOError's base class) wouldn't be a suitable subclass either: eg. what would we want with an .errno attribute?) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-08 16:58 Message: Logged In: YES user_id=764593 I often look at the code in a second idle window rather than starting a web browser. Would it work to make LoadError a subclass of IOError, at least for the backport? People who followed the docs will get a bugfix, but people who followed the code would get no breakage. Should LoadError be a subclass of IOError even in the main trunk? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 From noreply at sourceforge.net Sat Feb 12 00:01:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 12 00:01:48 2005 Subject: [Patches] [ python-Patches-1119016 ] fix for a bug in Header.__unicode__() Message-ID: Patches item #1119016, was opened at 2005-02-09 01:55 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1119016&group_id=5470 Category: Library (Lib) Group: Python 2.5 >Status: Closed Resolution: None Priority: 5 Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Barry A. Warsaw (bwarsaw) Summary: fix for a bug in Header.__unicode__() Initial Comment: In three places in the __unicode__ method there is a line that looks like this: if lastcs not in (None, 'us-ascii'): They will generate a TypeError because lastcs is a Charset object. This patch fixes this bug by using (None, Charset('us-ascii')) instead. ---------------------------------------------------------------------- >Comment By: Bj?rn Lindqvist (sonderblade) Date: 2005-02-12 00:01 Message: Logged In: YES user_id=51702 The bug was caused by an optimization in compile.c by rhettiger. The change was then rolled back so this bug is not a bug anymore. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-02-09 10:33 Message: Logged In: YES user_id=38388 Hi Barry, I think Bj?rn is talking about a problem in the email package. Note to Bj?rn: the patch does not seem to have made it. Please try again. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1119016&group_id=5470 From noreply at sourceforge.net Sat Feb 12 00:43:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 12 00:43:46 2005 Subject: [Patches] [ python-Patches-1117961 ] replace md5 impl. with one having a more free license Message-ID: Patches item #1117961, was opened at 2005-02-07 17:10 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117961&group_id=5470 Category: Modules Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 6 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: replace md5 impl. with one having a more free license Initial Comment: details at http://mail.python.org/pipermail/python-dev/2005-February/051450.html the code is taken from Debian's dpkg source package, which should at least build on Linux, the Hurd and the kfreebsd-gnu and knetbsd-gnu BSD variants. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-12 00:43 Message: Logged In: YES user_id=21627 As Jeremy Hylton explains on python-dev, this is unacceptable, as it relies on the notion of a "public domain". I agree, and believe this would make things worse than they are: the statement of the author that his work is in the public domain is legally void. Furthermore, the author does not provide a license (as he believes he doesn't need to), and it is questionable what license precisely can be implied - strictyl speaking, the author maintains the full rights to his work, licensing none. Rejecting the patch. It would be nice if the author could be asked to license the work under, say, the Academic Free License, with an additional permission to anybody to relicense it under any terms they please. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117961&group_id=5470 From noreply at sourceforge.net Sat Feb 12 01:08:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 12 01:08:33 2005 Subject: [Patches] [ python-Patches-1121142 ] ZipFile.open - read-only file-like obj for files in archive Message-ID: Patches item #1121142, was opened at 2005-02-11 19:08 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=1121142&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Alan McIntyre (ESRG) (alanmcintyre) Assigned to: Nobody/Anonymous (nobody) Summary: ZipFile.open - read-only file-like obj for files in archive Initial Comment: I originally started working on updating patch 992750, but decided after a short while to just start from scratch, so I'm posting it as a new patch. Sorry if this isn't appropriate. This patch provides a new open() method on ZipFile; this method returns a file-like object for the requested item in the archive. This file-like object only provides a read() method. ZipFile.read was modified to use the new open method (this was suggested by loewis in reference to patch 992750). The patched zipfile.py passed the existing tests in the test_zipfile.py from CVS. New tests were added to verify the operation of the object returned by open(). These tests were modeled after existing tests for ZipFile.read(); two read fixed-size chunks from the file-like object, and two others read random-sized chunks. I have only run the tests on Windows XP, using Python2.4 from the official Windows installer. I will test the patch out on Linux over the weekend. If the patch is accepted I'll also generate and submit patches for the appropriate documentation as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121142&group_id=5470 From noreply at sourceforge.net Sat Feb 12 04:00:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 12 04:00:10 2005 Subject: [Patches] [ python-Patches-1095541 ] fix for trivial flatten bug in astgen Message-ID: Patches item #1095541, was opened at 2005-01-04 09:15 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1095541&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: DSM (dsm001) Assigned to: Nobody/Anonymous (nobody) Summary: fix for trivial flatten bug in astgen Initial Comment: The flatten in compiler.ast (from astgen) doesn't work for sublists, although the source shows it tries to: >>> compiler.ast.flatten([1,2,(3,4)]) [1, 2, 3, 4] >>> compiler.ast.flatten([1,2,[3,4]]) [1, 2, [3, 4]] The dangers of calling your lists 'list'.. (type is list check fails.) A brief glance suggests it gets called with tuples instead so I don't think the bug has any obvious consequences. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2005-02-12 04:00 Message: Logged In: YES user_id=51702 The patch works but it would be nice if there was a test in test_compiler.py that checks for correctness of the flattens too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1095541&group_id=5470 From noreply at sourceforge.net Sat Feb 12 04:14:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 12 04:14:10 2005 Subject: [Patches] [ python-Patches-852995 ] tests and processors patch for urllib2 Message-ID: Patches item #852995, was opened at 2003-12-03 00:53 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852995&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Closed Resolution: Accepted Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Jeremy Hylton (jhylton) Summary: tests and processors patch for urllib2 Initial Comment: Here are some unit tests for urllib2 and a revised version of my urllib2 "processors" patch (originally posted as RFE 759792 -- I'm posting it here since it is a patch, not just a wish). The tests depend on the patch, but test more than just the changes introduced by the patch. A fuller discussion is in the original RFE tracker item, but briefly: the patch makes it possible to implement functionality like HTTP cookie handling, Refresh handling, etc. etc. using handler objects. At the moment urllib2's handler objects aren't quite up to the job, which results in a lot of cut-n-paste and subclassing. I believe the changes are backwards-compatible, with the exception of people who've reimplemented build_opener()'s functionality -- those people would need to call opener.add_handler(HTTPErrorProcessor). The main change is allowing handlers to implement methods like: http_request(request) http_response(request, response) In addition to the usual http_open(request) http_error{_*}(...) I call handlers that implement these methods "processors". These methods get called for *every* processor (in contrast to the ordinary handler methods, where the OpenerDirector stops calling the methods as soon as the first handler handles the request by returning a response) to pre-process requests and post-process responses. If this is accepted, I can submit patches for handlers (processors) that do HTTP Refresh redirection, cookie handling etc. Changes in the patch: -OpenerDirector changes to call new <protocol>_request and <protocol>_response methods. I haven't put all the documentation for this interface in this set of patches because there's no obvious place for it: handlers aren't really documented either. The urllib2 docs need a cleanup, but I'll do that in a separate patch. -Added .unredirected_hdrs dict to Request, together with .add_unredirected_headers() and .has_header() methods. These headers don't get copied to redirected requests. I didn't add this as a feature for people calling urlopen on a Request. Rather, the motivation comes from the fact that processors need to explicitly add headers to Requests (Cookie, Referer, Content-Length, etc.), rather than directly sending them over the wire. The problem is, if they add them to the regular .headers attribute of requests, processors will end up clobbering headers added by the user who called urlopen (which would break backwards-compatibility). Having processors use a separate set of headers that never get redirected makes this problem go away: users can add headers (with either .add_header() or .add_unredirected_header(), since processors don't clobber either) and know that they won't get clobbered by any handler. -HTTPErrorProcessor is necessary to allow response processors to see responses before redirections &c happen, by moving the call to parent.error() out of AbstractHTTPHandler.do_open(). It has the side-effect of stopping people grumbling that 200 is not the only success code in HTTP <0.5 wink>, since it makes it feasible to override urllib2's behaviour of raising an exception unless the HTTP code == 200. -Split part of AbstractHTTPHandler.do_open (which implements http_open / https_open in the HTTP/HTTPSHandler subclasses) into a new .do_request (which implements http_request in the subclasses). Just because I could, really (with the new *_request methods). It seems clearer to me. -Single string-formatting-character change to OpenerDirector.error() to allow "refresh" as an error code. -Added .code and .msg attributes to HTTP response objects, so that processors can know what the response code and message are. I haven't documented these, because they're HTTP-specific. -Renamed HTTPRedirectHandler.error_302_dict --> .redirect_dict -Finally, there's one bugfix to HTTPRedirectHandler included in the patch, because the tests test for it: multiple visits to a single URL with different redirect codes is no longer erroneously detected as a loop. http://a.com/a --> 302 --> http://a.com/b --> Refresh --> http://a.com/a Yes, I have seen a site where this really happens! There are a few other bugs that turned up while writing the tests, and those tests are commented out ATM. I'll file bug reports for those separately after this one is sorted out. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2005-02-12 03:14 Message: Logged In: YES user_id=261020 I added a detailed comment on the yum/urllib2 issue to the bugzilla tracker (as user jjl at pobox dot com). As I note there, though this is strictly a yum bug, if there is a good, safe way of fixing urllib2 here to be more forgiving, I think it should be done. If I think of one when I look at it again, will submit a patch... ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-02-08 13:09 Message: Logged In: YES user_id=2772 The fedora folks claim that this patch has caused "yum", an apt-like tool for RPMs, to break in python 2.4.0. I haven't been able to verify this, and nobody has come up with a simple, standalone script to produce the problem. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138535 ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2004-01-04 23:51 Message: Logged In: YES user_id=261020 Fixed tests in patch 870606. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 04:00 Message: Logged In: YES user_id=80475 FWIW, the test for urllib2 is currently failing and needs to be fixed. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-14 16:11 Message: Logged In: YES user_id=261020 Reopening to add a note to Misc/NEWS about the backwards-incompatibility for people who don't use build_opener(). I presume that's the right place for this note? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-14 15:17 Message: Logged In: YES user_id=261020 Just a note that my justification of Request.add_unredirected_hdrs above makes no sense. :-/ I mis-remembered my own reasons for adding this. My original comment from 759792 is correct: Some headers (Content-Length, Referer, ...) mustn't be copied to requests for a redirected URL. This requires the addition of a new dict to Request. I've added an add_unredirected_headers method, too. The old implementation just sends these headers directly, but that's not possible if you want to use procesors to implement these things. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-12-14 05:28 Message: Logged In: YES user_id=31392 Committed as rev 1.57 of urllib2.py ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-08 00:04 Message: Logged In: YES user_id=261020 Oops, I left a couple of lines in urllib2.py that add an HTTP debugging method and constructor arg. Please ignore that part of the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852995&group_id=5470 From noreply at sourceforge.net Sat Feb 12 07:02:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 12 07:03:01 2005 Subject: [Patches] [ python-Patches-1121234 ] Reference count bug fix Message-ID: Patches item #1121234, was opened at 2005-02-12 15: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=1121234&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Martin v. L?wis (loewis) Summary: Reference count bug fix Initial Comment: In the _loadtk method of the class Tk, there are two calls self.tk.createcommand, one for 'tkerror' and one for 'exit'. In the createcommand function in _tkinter.c, there is a Py_XINCREF for the Tk widget and one for the Python function (_tkerror or _exit). The corresponding Py_XDECREFs are called (via Tkapp_DeleteCommand) in PythonCmdDelete. The Tkapp_DeleteCommand is called by the deletecommand in the destroy method of class Misc in Tkinter.py. However, the deletecommand is called only for commands listed in self._tclCommands. Now, if a command is created via the _register method in class Misc, the command is appended to self._tclCommands. However, the 'tkerror' and 'exit' commands, created in the _loadtk method of the class Tk, are not appended to self._tclCommands. Hence, the '_tkerror' and '_exit' functions as well as the Tk widget itself have an incorrect reference count. The Tkapp_Dealloc routine in _tkinter.c is not called and the Tk widget is not destroyed. The attached patch simply adds a self._tclCommands.append for 'tkerror' and 'exit'. With this patch, a Tk widget is destroyed and Tkapp_Dealloc is called correctly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121234&group_id=5470 From noreply at sourceforge.net Sat Feb 12 07:27:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 12 07:27:52 2005 Subject: [Patches] [ python-Patches-989712 ] Support using Tk without a mainloop Message-ID: Patches item #989712, was opened at 2004-07-13 05:16 Message generated for change (Comment added) made by mdehoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=989712&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Kurt B. Kaiser (kbk) Summary: Support using Tk without a mainloop Initial Comment: In the regular python shell, you can open Tk windows, and they will operate even though you didn't call Tkinter.mainloop(). This is useful, for example, when you manipulate matplotlib graphs from within the python shell. This is done by a hook, installed when a tkapp object is being initialized, which handles Tk events while the shell is waiting for user input. I imitated this behaviour in IDLE: When the subprocess is idle, it checks whether Tkinter._default_root is set (this happens when the Tkinter.Tk class, which makes a tkapp object, is initialized, unless Tkinter._use_default_root is False), and if so, handles Tk events. For me it works very well. Have a good day, Noam Raphael ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-12 15:27 Message: Logged In: YES user_id=488897 Richard Madden was kind enough to test the patch at http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff. This led to the discovery of two bugs in my patch and one preexisting bug in Tkinter.py. For this second bug, I submitted a separate patch (#1121234). I uploaded a fixed patch at http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff; together with patch #1121234 the input hooks appear to be working correctly. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-08 17:53 Message: Logged In: YES user_id=488897 I have written a patch that solves this problem more generally via PyOS_InputHook, as suggested by Noam. This patch also solves the related bugs #1053687, #798058, and supersedes patch #1049855. The patch is available at http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff Currently, the EventHook function sits in a loop handling Tcl events until keyboard input is detected. The presence of Tcl events is checked every Tkinter_busywaitinterval milliseconds. If a Tcl event arrives during this interval, it won't be handled until the end of the interval. However, with the default value of Tkinter_busywaitinterval = 20 milliseconds, that delay is not noticable. Now consider the situation in which there can be more than one input hook, for example set by different extension modules. We cannot have EventHook sit in a loop until keyboard input is detected, because that would prevent other PyOS_InputHooks from being serviced. So in the EventHook in the patch, the function returns immediately after handling all Tcl events. If we use Python from the command line and open a Tkinter label: >>> from Tkinter import * >>> l = Label() then readline will call PyOS_InputHook ten times per second while Python is idle. Because PyOS_InputHook points to EventHook, we will return to the EventHook function almost immediately. Effectively, we are then in the same situation as before the patch. On Cygwin, however, previously mainloop needed to be run in order for the label to appear; this is no longer necessary with this patch. On Windows, currently PyOS_InputHook is partially broken, as it is called only once per command instead of ten times per second. This patch fixed that also (same as patch #1049855). If we have two or more input hooks, they are called successively by readline. Since each input hook returns after it has no more work to do, all of the input hooks are guaranteed to be serviced. To be able to have more than one input hook, we need to replace PyOS_InputHook by three functions: PyOS_AddInputHook, PyOS_RemoveInputHook, and PyOS_CallInputHooks. For the third function, the corresponding Python function call_input_hooks was created in the readline module. By adding a call to readline.call_input_hooks in run.py, as suggested by Noam, all input hook functions are serviced when IDLE is idle. So we can use Tkinter without calling mainloop, and we can use other extension packages that use input hooks. We can even do both: >>> import Tkinter >>> import gist # my extension module also needs input hooks >>> Tkinter.Label() # label appears >>> gist.window() # Graphics window appears. works both with command-line python and IDLE. I'm interested to hear your comments and suggestions. If this patch seems like the way to go, I'd be happy to write the documentation for it. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-04 22:08 Message: Logged In: YES user_id=488897 I agree, this is basically the same bug as #798058. The call to readline.call_input_hook sounds like a good solution. But the hook function should be different than the current EventHook in _tkinter.c. That hook function sits in a loop until a keyboard event is noticed. A problem occurs if there is more than one hook function. Currently, that is not possible in Python, since there is only one PyOS_InputHook. I am working on a patch in which PyOS_InputHook is replaced by PyOS_AddInputHook and PyOS_RemoveInputHook, so that there can be more than one hook functions. Now suppose that there is one hook function to handle Tk events, and another one e.g. handling messages to windows in Microsoft Windows. (This is a real issue for one of my extension modules). If python sits in a loop in _tkinter.c's EventHook until a key is pressed, the MS windows won't get their messages. The following structure might work better: while(there is no keyboard input or other interesting event) { Call PyOS_InputHook #1 Call PyOS_InputHook #2 etc. } where each of the PyOS_InputHook functions should return if there is no more work for them. The tricky part is to find out which events to wait for; some of the events may be handled by one of the PyOS_InputHook functions. Obviously I need to do some more thinking about this. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-04 10:02 Message: Logged In: YES user_id=149084 Hm, this seems closely related to Bug 798058 I'd lost track of it because it got switched to tkinter. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2005-01-30 20:58 Message: Logged In: YES user_id=679426 in _tkinter.c, look for EventHook - you'll find the EventHook function, which is called when the interpreter is idle, and the Enable/Disable EventHook functions. In readline.c, line 765, you'll find the call to PyOS_InputHook, when waiting for input. Perhaps a more general approach would be to let Python code call PyOS_InputHook, for example, by defining readline.call_input_hook() and readline.has_input_hook(). Then IDLE would be able to call them when idle, with no Tkinter-specific code. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-07-15 05:44 Message: Logged In: YES user_id=149084 Can you give me some more information on the hook in the Python interpreter? Where is it in the code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=989712&group_id=5470 From noreply at sourceforge.net Sun Feb 13 02:33:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 13 02:33:13 2005 Subject: [Patches] [ python-Patches-1121611 ] sha and md5 modules should use OpenSSL when possible Message-ID: Patches item #1121611, was opened at 2005-02-12 17:33 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=1121611&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory P. Smith (greg) Assigned to: Nobody/Anonymous (nobody) Summary: sha and md5 modules should use OpenSSL when possible Initial Comment: The md5 and sha (sha1) modules should use OpenSSL for the algorithms when it is available as its implementations are much faster than pythons own. Attached is an initial patch to use OpenSSL for the sha module. Its not ready for committing as is yet, but it is setup to be a generic base for all OpenSSL hashes with a little bit of work in the future. Tossing this out there for people to see how trivial it is and enjoy the speedups. diff is against HEAD but it should apply to 2.4 just fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121611&group_id=5470 From noreply at sourceforge.net Sun Feb 13 23:35:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 13 23:36:00 2005 Subject: [Patches] [ python-Patches-1090958 ] _AEModule.c patch Message-ID: Patches item #1090958, was opened at 2004-12-25 01:12 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1090958&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: has (hhas) Assigned to: Jack Jansen (jackjansen) Summary: _AEModule.c patch Initial Comment: _AEModule.c patch to fix broken AEReplaceDescData and add AEInstallCoercionHandler, AERemoveCoercionHandler and AEGetCoercionHandler. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2005-02-13 23:35 Message: Logged In: YES user_id=45365 Has, just to make sure I understand the individual bugs: 1. AEReplaceDescData should be a method of AEDesc 2. The other three just need to be added ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1090958&group_id=5470 From noreply at sourceforge.net Sun Feb 13 23:39:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 13 23:39:06 2005 Subject: [Patches] [ python-Patches-979784 ] OSATerminology extension fix Message-ID: Patches item #979784, was opened at 2004-06-25 16:55 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979784&group_id=5470 Category: Macintosh Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: has (hhas) Assigned to: Jack Jansen (jackjansen) Summary: OSATerminology extension fix Initial Comment: c.f. Original bug report: '[884085] OSATerminology is broken'. A corrected copy of OSATerminology.c is attached. This is working code taken from appscript package, tested myself on OS 10.2.6 + MacPython 2.3 and with no reports of any problems from other users. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2005-02-13 23:39 Message: Logged In: YES user_id=45365 Superseded by #1113328, according to the submitter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979784&group_id=5470 From noreply at sourceforge.net Mon Feb 14 00:28:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 14 00:28:46 2005 Subject: [Patches] [ python-Patches-1090958 ] _AEModule.c patch Message-ID: Patches item #1090958, was opened at 2004-12-25 00:12 Message generated for change (Comment added) made by hhas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1090958&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: has (hhas) Assigned to: Jack Jansen (jackjansen) Summary: _AEModule.c patch Initial Comment: _AEModule.c patch to fix broken AEReplaceDescData and add AEInstallCoercionHandler, AERemoveCoercionHandler and AEGetCoercionHandler. ---------------------------------------------------------------------- >Comment By: has (hhas) Date: 2005-02-13 23:28 Message: Logged In: YES user_id=996627 > 1. AEReplaceDescData should be a method of AEDesc Yes. > 2. The other three just need to be added Yes, along with the GenericCoercionHandler callback function that they all use. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2005-02-13 22:35 Message: Logged In: YES user_id=45365 Has, just to make sure I understand the individual bugs: 1. AEReplaceDescData should be a method of AEDesc 2. The other three just need to be added ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1090958&group_id=5470 From noreply at sourceforge.net Mon Feb 14 15:57:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 14 15:57:16 2005 Subject: [Patches] [ python-Patches-989712 ] Support using Tk without a mainloop Message-ID: Patches item #989712, was opened at 2004-07-12 20:16 Message generated for change (Comment added) made by dickmadden You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=989712&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Kurt B. Kaiser (kbk) Summary: Support using Tk without a mainloop Initial Comment: In the regular python shell, you can open Tk windows, and they will operate even though you didn't call Tkinter.mainloop(). This is useful, for example, when you manipulate matplotlib graphs from within the python shell. This is done by a hook, installed when a tkapp object is being initialized, which handles Tk events while the shell is waiting for user input. I imitated this behaviour in IDLE: When the subprocess is idle, it checks whether Tkinter._default_root is set (this happens when the Tkinter.Tk class, which makes a tkapp object, is initialized, unless Tkinter._use_default_root is False), and if so, handles Tk events. For me it works very well. Have a good day, Noam Raphael ---------------------------------------------------------------------- Comment By: Dick Madden (dickmadden) Date: 2005-02-14 14:57 Message: Logged In: YES user_id=1219007 I've tried the updated patches with Tkinter and my rasmol extension using the new inputhooks scheme and everything seems to be coexisting just fine. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-12 06:27 Message: Logged In: YES user_id=488897 Richard Madden was kind enough to test the patch at http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff. This led to the discovery of two bugs in my patch and one preexisting bug in Tkinter.py. For this second bug, I submitted a separate patch (#1121234). I uploaded a fixed patch at http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff; together with patch #1121234 the input hooks appear to be working correctly. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-08 08:53 Message: Logged In: YES user_id=488897 I have written a patch that solves this problem more generally via PyOS_InputHook, as suggested by Noam. This patch also solves the related bugs #1053687, #798058, and supersedes patch #1049855. The patch is available at http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff Currently, the EventHook function sits in a loop handling Tcl events until keyboard input is detected. The presence of Tcl events is checked every Tkinter_busywaitinterval milliseconds. If a Tcl event arrives during this interval, it won't be handled until the end of the interval. However, with the default value of Tkinter_busywaitinterval = 20 milliseconds, that delay is not noticable. Now consider the situation in which there can be more than one input hook, for example set by different extension modules. We cannot have EventHook sit in a loop until keyboard input is detected, because that would prevent other PyOS_InputHooks from being serviced. So in the EventHook in the patch, the function returns immediately after handling all Tcl events. If we use Python from the command line and open a Tkinter label: >>> from Tkinter import * >>> l = Label() then readline will call PyOS_InputHook ten times per second while Python is idle. Because PyOS_InputHook points to EventHook, we will return to the EventHook function almost immediately. Effectively, we are then in the same situation as before the patch. On Cygwin, however, previously mainloop needed to be run in order for the label to appear; this is no longer necessary with this patch. On Windows, currently PyOS_InputHook is partially broken, as it is called only once per command instead of ten times per second. This patch fixed that also (same as patch #1049855). If we have two or more input hooks, they are called successively by readline. Since each input hook returns after it has no more work to do, all of the input hooks are guaranteed to be serviced. To be able to have more than one input hook, we need to replace PyOS_InputHook by three functions: PyOS_AddInputHook, PyOS_RemoveInputHook, and PyOS_CallInputHooks. For the third function, the corresponding Python function call_input_hooks was created in the readline module. By adding a call to readline.call_input_hooks in run.py, as suggested by Noam, all input hook functions are serviced when IDLE is idle. So we can use Tkinter without calling mainloop, and we can use other extension packages that use input hooks. We can even do both: >>> import Tkinter >>> import gist # my extension module also needs input hooks >>> Tkinter.Label() # label appears >>> gist.window() # Graphics window appears. works both with command-line python and IDLE. I'm interested to hear your comments and suggestions. If this patch seems like the way to go, I'd be happy to write the documentation for it. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-04 13:08 Message: Logged In: YES user_id=488897 I agree, this is basically the same bug as #798058. The call to readline.call_input_hook sounds like a good solution. But the hook function should be different than the current EventHook in _tkinter.c. That hook function sits in a loop until a keyboard event is noticed. A problem occurs if there is more than one hook function. Currently, that is not possible in Python, since there is only one PyOS_InputHook. I am working on a patch in which PyOS_InputHook is replaced by PyOS_AddInputHook and PyOS_RemoveInputHook, so that there can be more than one hook functions. Now suppose that there is one hook function to handle Tk events, and another one e.g. handling messages to windows in Microsoft Windows. (This is a real issue for one of my extension modules). If python sits in a loop in _tkinter.c's EventHook until a key is pressed, the MS windows won't get their messages. The following structure might work better: while(there is no keyboard input or other interesting event) { Call PyOS_InputHook #1 Call PyOS_InputHook #2 etc. } where each of the PyOS_InputHook functions should return if there is no more work for them. The tricky part is to find out which events to wait for; some of the events may be handled by one of the PyOS_InputHook functions. Obviously I need to do some more thinking about this. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-04 01:02 Message: Logged In: YES user_id=149084 Hm, this seems closely related to Bug 798058 I'd lost track of it because it got switched to tkinter. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2005-01-30 11:58 Message: Logged In: YES user_id=679426 in _tkinter.c, look for EventHook - you'll find the EventHook function, which is called when the interpreter is idle, and the Enable/Disable EventHook functions. In readline.c, line 765, you'll find the call to PyOS_InputHook, when waiting for input. Perhaps a more general approach would be to let Python code call PyOS_InputHook, for example, by defining readline.call_input_hook() and readline.has_input_hook(). Then IDLE would be able to call them when idle, with no Tkinter-specific code. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-07-14 20:44 Message: Logged In: YES user_id=149084 Can you give me some more information on the hook in the Python interpreter? Where is it in the code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=989712&group_id=5470 From noreply at sourceforge.net Tue Feb 15 16:40:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 15 16:41:00 2005 Subject: [Patches] [ python-Patches-1104669 ] new-style exceptions Message-ID: Patches item #1104669, was opened at 2005-01-18 18:09 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: new-style exceptions Initial Comment: This patch allows new-style exceptions and makes Exception a new-style class. The test suite runs, apart from failures in test_tempfile (will dig, but doubt this is my fault) and test__locale (known OS X problem). ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-02-15 15:40 Message: Logged In: YES user_id=6656 I found the final wart (caught by test_tempfile of all things). I think the attached is good to go. Issues remaining: test_pickletools fails, because PickleError is now new- style and thus pickles differently. Docs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-09 14:18 Message: Logged In: YES user_id=6656 New patch attached. Did this a while ago, don't actually remember the details of what's new :-/ The problem with the previous patch was that one of my exception- checking macros had the side-effect of clearing any pending exception... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-01-19 13:25 Message: Logged In: YES user_id=6656 You're right! Odd. No time to fix it today, I'm afraid. ---------------------------------------------------------------------- Comment By: Simon Percivall (percivall) Date: 2005-01-18 19:47 Message: Logged In: YES user_id=329382 One thing: Raising an old-style class/instance doesn't give a traceback or populate sys.last_*. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 From noreply at sourceforge.net Tue Feb 15 17:03:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 15 17:07:19 2005 Subject: [Patches] [ python-Patches-1104669 ] new-style exceptions Message-ID: Patches item #1104669, was opened at 2005-01-18 13:09 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: new-style exceptions Initial Comment: This patch allows new-style exceptions and makes Exception a new-style class. The test suite runs, apart from failures in test_tempfile (will dig, but doubt this is my fault) and test__locale (known OS X problem). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-02-15 11:03 Message: Logged In: YES user_id=31435 FYI, there's nothing special about PicklingError in the pickletools doctest, it's just aiming at an example of an instance -- that it's also an exception instance is irrelevant to what the test is aiming at. Tell you what: I'll check in a suitable change to pickletools.py, so that the example it uses stops interfering with this patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-15 10:40 Message: Logged In: YES user_id=6656 I found the final wart (caught by test_tempfile of all things). I think the attached is good to go. Issues remaining: test_pickletools fails, because PickleError is now new- style and thus pickles differently. Docs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-09 09:18 Message: Logged In: YES user_id=6656 New patch attached. Did this a while ago, don't actually remember the details of what's new :-/ The problem with the previous patch was that one of my exception- checking macros had the side-effect of clearing any pending exception... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-01-19 08:25 Message: Logged In: YES user_id=6656 You're right! Odd. No time to fix it today, I'm afraid. ---------------------------------------------------------------------- Comment By: Simon Percivall (percivall) Date: 2005-01-18 14:47 Message: Logged In: YES user_id=329382 One thing: Raising an old-style class/instance doesn't give a traceback or populate sys.last_*. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 From noreply at sourceforge.net Tue Feb 15 17:17:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 15 17:17:24 2005 Subject: [Patches] [ python-Patches-1104669 ] new-style exceptions Message-ID: Patches item #1104669, was opened at 2005-01-18 13:09 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: new-style exceptions Initial Comment: This patch allows new-style exceptions and makes Exception a new-style class. The test suite runs, apart from failures in test_tempfile (will dig, but doubt this is my fault) and test__locale (known OS X problem). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-02-15 11:17 Message: Logged In: YES user_id=31435 FYI, there's nothing special about PicklingError in the pickletools doctest, it's just aiming at an example of an instance -- that it's also an exception instance is irrelevant to what the test is aiming at. Tell you what: I'll check in a suitable change to pickletools.py, so that the example it uses stops interfering with this patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-15 11:03 Message: Logged In: YES user_id=31435 FYI, there's nothing special about PicklingError in the pickletools doctest, it's just aiming at an example of an instance -- that it's also an exception instance is irrelevant to what the test is aiming at. Tell you what: I'll check in a suitable change to pickletools.py, so that the example it uses stops interfering with this patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-15 10:40 Message: Logged In: YES user_id=6656 I found the final wart (caught by test_tempfile of all things). I think the attached is good to go. Issues remaining: test_pickletools fails, because PickleError is now new- style and thus pickles differently. Docs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-09 09:18 Message: Logged In: YES user_id=6656 New patch attached. Did this a while ago, don't actually remember the details of what's new :-/ The problem with the previous patch was that one of my exception- checking macros had the side-effect of clearing any pending exception... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-01-19 08:25 Message: Logged In: YES user_id=6656 You're right! Odd. No time to fix it today, I'm afraid. ---------------------------------------------------------------------- Comment By: Simon Percivall (percivall) Date: 2005-01-18 14:47 Message: Logged In: YES user_id=329382 One thing: Raising an old-style class/instance doesn't give a traceback or populate sys.last_*. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 From noreply at sourceforge.net Tue Feb 15 18:34:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 15 18:34:41 2005 Subject: [Patches] [ python-Patches-1104669 ] new-style exceptions Message-ID: Patches item #1104669, was opened at 2005-01-18 13:09 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: new-style exceptions Initial Comment: This patch allows new-style exceptions and makes Exception a new-style class. The test suite runs, apart from failures in test_tempfile (will dig, but doubt this is my fault) and test__locale (known OS X problem). ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-15 12:34 Message: Logged In: YES user_id=764593 Several lines near the end of errors.c had no visible change. Was this a whitespace cleanup, or is this a risk of tab/space mixing? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-15 11:17 Message: Logged In: YES user_id=31435 FYI, there's nothing special about PicklingError in the pickletools doctest, it's just aiming at an example of an instance -- that it's also an exception instance is irrelevant to what the test is aiming at. Tell you what: I'll check in a suitable change to pickletools.py, so that the example it uses stops interfering with this patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-15 11:03 Message: Logged In: YES user_id=31435 FYI, there's nothing special about PicklingError in the pickletools doctest, it's just aiming at an example of an instance -- that it's also an exception instance is irrelevant to what the test is aiming at. Tell you what: I'll check in a suitable change to pickletools.py, so that the example it uses stops interfering with this patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-15 10:40 Message: Logged In: YES user_id=6656 I found the final wart (caught by test_tempfile of all things). I think the attached is good to go. Issues remaining: test_pickletools fails, because PickleError is now new- style and thus pickles differently. Docs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-09 09:18 Message: Logged In: YES user_id=6656 New patch attached. Did this a while ago, don't actually remember the details of what's new :-/ The problem with the previous patch was that one of my exception- checking macros had the side-effect of clearing any pending exception... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-01-19 08:25 Message: Logged In: YES user_id=6656 You're right! Odd. No time to fix it today, I'm afraid. ---------------------------------------------------------------------- Comment By: Simon Percivall (percivall) Date: 2005-01-18 14:47 Message: Logged In: YES user_id=329382 One thing: Raising an old-style class/instance doesn't give a traceback or populate sys.last_*. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 From noreply at sourceforge.net Tue Feb 15 18:39:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 15 18:39:49 2005 Subject: [Patches] [ python-Patches-1104669 ] new-style exceptions Message-ID: Patches item #1104669, was opened at 2005-01-18 18:09 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: new-style exceptions Initial Comment: This patch allows new-style exceptions and makes Exception a new-style class. The test suite runs, apart from failures in test_tempfile (will dig, but doubt this is my fault) and test__locale (known OS X problem). ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-02-15 17:39 Message: Logged In: YES user_id=6656 Jim: Yes. It looks like I ran delete-trailing-whitespace on the file at some point. I could redo the diff without them, but it would be tedious... Tim: thanks! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-15 17:34 Message: Logged In: YES user_id=764593 Several lines near the end of errors.c had no visible change. Was this a whitespace cleanup, or is this a risk of tab/space mixing? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-15 16:17 Message: Logged In: YES user_id=31435 FYI, there's nothing special about PicklingError in the pickletools doctest, it's just aiming at an example of an instance -- that it's also an exception instance is irrelevant to what the test is aiming at. Tell you what: I'll check in a suitable change to pickletools.py, so that the example it uses stops interfering with this patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-15 16:03 Message: Logged In: YES user_id=31435 FYI, there's nothing special about PicklingError in the pickletools doctest, it's just aiming at an example of an instance -- that it's also an exception instance is irrelevant to what the test is aiming at. Tell you what: I'll check in a suitable change to pickletools.py, so that the example it uses stops interfering with this patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-15 15:40 Message: Logged In: YES user_id=6656 I found the final wart (caught by test_tempfile of all things). I think the attached is good to go. Issues remaining: test_pickletools fails, because PickleError is now new- style and thus pickles differently. Docs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-09 14:18 Message: Logged In: YES user_id=6656 New patch attached. Did this a while ago, don't actually remember the details of what's new :-/ The problem with the previous patch was that one of my exception- checking macros had the side-effect of clearing any pending exception... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-01-19 13:25 Message: Logged In: YES user_id=6656 You're right! Odd. No time to fix it today, I'm afraid. ---------------------------------------------------------------------- Comment By: Simon Percivall (percivall) Date: 2005-01-18 19:47 Message: Logged In: YES user_id=329382 One thing: Raising an old-style class/instance doesn't give a traceback or populate sys.last_*. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 From noreply at sourceforge.net Tue Feb 15 18:51:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 15 18:51:31 2005 Subject: [Patches] [ python-Patches-1104669 ] new-style exceptions Message-ID: Patches item #1104669, was opened at 2005-01-18 13:09 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: new-style exceptions Initial Comment: This patch allows new-style exceptions and makes Exception a new-style class. The test suite runs, apart from failures in test_tempfile (will dig, but doubt this is my fault) and test__locale (known OS X problem). ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-15 12:51 Message: Logged In: YES user_id=764593 Is it worth adding a comment on parsing precedence? An object can be both an instance and a class, which puts some ambiguity between "raise class" and "raise classinstance". Assuming the class seems sensible; I'm just wondering whether it should be made explicit. (Making something both an instance and a subclass of anything besides object might be weird enough that you don't *want* to document the results yet.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-15 12:39 Message: Logged In: YES user_id=6656 Jim: Yes. It looks like I ran delete-trailing-whitespace on the file at some point. I could redo the diff without them, but it would be tedious... Tim: thanks! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-15 12:34 Message: Logged In: YES user_id=764593 Several lines near the end of errors.c had no visible change. Was this a whitespace cleanup, or is this a risk of tab/space mixing? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-15 11:17 Message: Logged In: YES user_id=31435 FYI, there's nothing special about PicklingError in the pickletools doctest, it's just aiming at an example of an instance -- that it's also an exception instance is irrelevant to what the test is aiming at. Tell you what: I'll check in a suitable change to pickletools.py, so that the example it uses stops interfering with this patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-15 11:03 Message: Logged In: YES user_id=31435 FYI, there's nothing special about PicklingError in the pickletools doctest, it's just aiming at an example of an instance -- that it's also an exception instance is irrelevant to what the test is aiming at. Tell you what: I'll check in a suitable change to pickletools.py, so that the example it uses stops interfering with this patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-15 10:40 Message: Logged In: YES user_id=6656 I found the final wart (caught by test_tempfile of all things). I think the attached is good to go. Issues remaining: test_pickletools fails, because PickleError is now new- style and thus pickles differently. Docs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-09 09:18 Message: Logged In: YES user_id=6656 New patch attached. Did this a while ago, don't actually remember the details of what's new :-/ The problem with the previous patch was that one of my exception- checking macros had the side-effect of clearing any pending exception... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-01-19 08:25 Message: Logged In: YES user_id=6656 You're right! Odd. No time to fix it today, I'm afraid. ---------------------------------------------------------------------- Comment By: Simon Percivall (percivall) Date: 2005-01-18 14:47 Message: Logged In: YES user_id=329382 One thing: Raising an old-style class/instance doesn't give a traceback or populate sys.last_*. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 From noreply at sourceforge.net Tue Feb 15 20:37:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 15 20:37:30 2005 Subject: [Patches] [ python-Patches-1104669 ] new-style exceptions Message-ID: Patches item #1104669, was opened at 2005-01-18 18:09 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: new-style exceptions Initial Comment: This patch allows new-style exceptions and makes Exception a new-style class. The test suite runs, apart from failures in test_tempfile (will dig, but doubt this is my fault) and test__locale (known OS X problem). ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-02-15 19:37 Message: Logged In: YES user_id=6656 > Is it worth adding a comment on parsing precedence? I've been studiously avoiding thinking about that :) > Making something both an instance and a subclass of > anything besides object might be weird enough that you > don't *want* to document the results yet. Quite. What happens, happens IMHO. I'm prepared to be argued into a different position on this, but I do think the only reason someone would do this is curiousity :) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-15 17:51 Message: Logged In: YES user_id=764593 Is it worth adding a comment on parsing precedence? An object can be both an instance and a class, which puts some ambiguity between "raise class" and "raise classinstance". Assuming the class seems sensible; I'm just wondering whether it should be made explicit. (Making something both an instance and a subclass of anything besides object might be weird enough that you don't *want* to document the results yet.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-15 17:39 Message: Logged In: YES user_id=6656 Jim: Yes. It looks like I ran delete-trailing-whitespace on the file at some point. I could redo the diff without them, but it would be tedious... Tim: thanks! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-15 17:34 Message: Logged In: YES user_id=764593 Several lines near the end of errors.c had no visible change. Was this a whitespace cleanup, or is this a risk of tab/space mixing? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-15 16:17 Message: Logged In: YES user_id=31435 FYI, there's nothing special about PicklingError in the pickletools doctest, it's just aiming at an example of an instance -- that it's also an exception instance is irrelevant to what the test is aiming at. Tell you what: I'll check in a suitable change to pickletools.py, so that the example it uses stops interfering with this patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-15 16:03 Message: Logged In: YES user_id=31435 FYI, there's nothing special about PicklingError in the pickletools doctest, it's just aiming at an example of an instance -- that it's also an exception instance is irrelevant to what the test is aiming at. Tell you what: I'll check in a suitable change to pickletools.py, so that the example it uses stops interfering with this patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-15 15:40 Message: Logged In: YES user_id=6656 I found the final wart (caught by test_tempfile of all things). I think the attached is good to go. Issues remaining: test_pickletools fails, because PickleError is now new- style and thus pickles differently. Docs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-09 14:18 Message: Logged In: YES user_id=6656 New patch attached. Did this a while ago, don't actually remember the details of what's new :-/ The problem with the previous patch was that one of my exception- checking macros had the side-effect of clearing any pending exception... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-01-19 13:25 Message: Logged In: YES user_id=6656 You're right! Odd. No time to fix it today, I'm afraid. ---------------------------------------------------------------------- Comment By: Simon Percivall (percivall) Date: 2005-01-18 19:47 Message: Logged In: YES user_id=329382 One thing: Raising an old-style class/instance doesn't give a traceback or populate sys.last_*. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 From noreply at sourceforge.net Tue Feb 15 22:27:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 15 22:27:14 2005 Subject: [Patches] [ python-Patches-1123430 ] Python memory allocator: Free memory Message-ID: Patches item #1123430, was opened at 2005-02-15 16:27 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=1123430&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Evan Jones (vulturex) Assigned to: Nobody/Anonymous (nobody) Summary: Python memory allocator: Free memory Initial Comment: This is the second version of my Python memory allocator patch. The first version was discussed on the python-dev mailing list here: http://mail.python.org/pipermail/python-dev/2005-January/ 051255.html This patch enables Python to actually return memory to the system. The current version's memory usage will only grow. This version maintains the same backwards compatability guarantees as the previous version: Calling PyObject_Free with a pointer that was returned by malloc() while NOT holding the GIL will work, and will not corrupt the state of the memory allocator. The patch modifies obmalloc.c. If it is accepted, other modifications to that file are required. In particular, I have not yet updated the WITH_MEMORY_LIMITS implementation, nor have I looked closely at the PYMALLOC_DEBUG code to see what changes (if any) are required. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1123430&group_id=5470 From noreply at sourceforge.net Wed Feb 16 08:16:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 08:16:39 2005 Subject: [Patches] [ python-Patches-1094542 ] add Bunch type to collections module Message-ID: Patches item #1094542, was opened at 2005-01-02 11:26 Message generated for change (Comment added) made by bediviere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094542&group_id=5470 Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: add Bunch type to collections module Initial Comment: This patch adds a proposed Bunch type to the collections module which complements Python's dict type, which provides a name-value mapping through the __getitem__ protocol, with the Bunch type, which provides an attribute-value mapping through dotted-attribute access. Example: >>> x = Bunch(spam=Bunch(rabbit=1, badger=[2, 3, 4]), ham='neewom') >>> x.spam.badger [2, 3, 4] >>> x.ham 'neewom' ---------------------------------------------------------------------- >Comment By: Steven Bethard (bediviere) Date: 2005-02-16 00:16 Message: Logged In: YES user_id=945502 For anyone still interested, development on this type has moved to: http://namespace.python-hosting.com/ The type has been renamed Namespace. I guess this patch should be withdrawn. We'll submit a better version (with an updated PEP) when more details have been hashed out, and we have a little more use data. ---------------------------------------------------------------------- Comment By: Alan Green (alanvgreen) Date: 2005-01-26 17:50 Message: Logged In: YES user_id=1174944 AttrMap and AttributeMapping aren't great names either, because a Bunch isn't like a Map. Here's two more suggestions: - Plain or PlainObject (implying that these are plain objects that the program can adorn in any way it likes) - Holder, AttributeHolder, DataHolder, or Data (If I were in a particularly whimsical mood, I might also suggest 'Eric', after the Monty Python song "Eric the half-a-bee", because a Bunch is only half-an-object - it only has data and no functions. But I'm not, so I won't.) ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-01-25 14:01 Message: Logged In: YES user_id=945502 Yes, I definitely agree. I only used Bunch because it was the least controversial (and was the name used in the Cookbook). Unfortunately, it's also too vague. I feel a little uneasy about Record or Struct because, to me, they seem to imply an ordering of the attributes, while the attributes of the type here are unordered. Struct also already has a meaning in the stdlib which is quite different. Namespace has the right meaning, but I think it's so overloaded for XML that this could be confusing. Perhaps something like AttributeMapping? AttrMap, maybe? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-25 13:42 Message: Logged In: YES user_id=80475 This needs a better name than Bunch. The clearly suggested a collection but is otherwise amorphous and fails to suggest any relevant properties. In language design, naming is vital. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-01-25 13:06 Message: Logged In: YES user_id=945502 Ok, I'll post the current PEP draft below. Of course, I welcome any suggestions to make its acceptance more likely. I'll definitely update the __eq__ docstring as suggested, but I'll probably wait until I've heard what other changes should be made. ---------------------------------------------------------------------- PEP: XXX Title: Generic Object Data Type Version: $Revision: 1.0 $ Last-Modified: $Date: 2004/11/29 16:00:00 $ Author: Steven Bethard Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 29-Nov-2004 Python-Version: 2.5 Post-History: 29-Nov-2004 Abstract ======== This PEP proposes a standard library addition to support the simple creation of 'generic' objects which can be given named attributes without the need to declare a class. Such attribute-value mappings are intended to complement the name-value mappings provided by Python's builtin dict objects. Motivation ========== Python's dict objects provide a simple way of creating anonymous name-value mappings. These mappings use the __getitem__ protocol to access the value associated with a name, so that code generally appears like:: mapping['name'] Occasionally, a programmer may decide that dotted-attribute style access is more appropriate to the domain than __getitem__ style access, and that their mapping should be accessed like:: mapping.name Currently, if a Python programmer makes this design decision, they are forced to declare a new class, and then build instances of this class. When no methods are to be associated with the attribute-value mappings, declaring a new class can be overkill. This PEP proposes adding a simple type to the collections module of the standard library that can be used to build such attribute-value mappings. Providing such a type allows the Python programmer to determine which type of mapping is most appropriate to their domain and apply this choice with minimal effort. Some of the suggested uses include: Returning Named Results ----------------------- It is often appropriate for a function that returns multiple items to give names to the different items returned. The type suggested in this PEP provides a simple means of doing this that allows the returned values to be accessed in the usual attribute-style access:: >>> def f(x): ... return Bunch(double=2*x, squared=x**2) ... >>> y = f(10) >>> y.double 20 >>> y.squared 100 Representing Hierarchical Data ------------------------------ The type suggested in this PEP also allows a simple means of representing hierarchical data that allows attribute-style access:: >>> x = Bunch(spam=Bunch(rabbit=1, badger=[2, 3, 4]), ham='neewom') >>> x.spam.badger [2, 3, 4] >>> x.ham 'neewom' Rationale ========= As Bunch objects are intended primarily to replace simple, data-only classes, simple Bunch construction was a primary concern. As such, the Bunch constructor supports creation from keyword arguments, dicts, and sequences of (attribute, value) pairs:: >>> Bunch(eggs=1, spam=2, ham=3) Bunch(eggs=1, ham=3, spam=2) >>> Bunch({'eggs':1, 'spam':2, 'ham':3}) Bunch(eggs=1, ham=3, spam=2) >>> Bunch([('eggs',1), ('spam',2), ('ham',3)]) Bunch(eggs=1, ham=3, spam=2) To allow attribute-value mappings to be easily combined, the update method of Bunch objects supports similar arguments. If Bunch objects are used to represent hierarchical data, comparison of such objects becomes a concern. For this reason, Bunch objects support object equality:: >>> x = Bunch(parrot=Bunch(lumberjack=True, spam=42), peng='shrub') >>> y = Bunch(peng='shrub', parrot=Bunch(spam=42, lumberjack=True)) >>> z = Bunch(parrot=Bunch(lumberjack=True), peng='shrub') >>> x == y True >>> x == z False Note that support for the various mapping methods, e.g. __(get|set|del)item__, __len__, __iter__, __contains__, items, keys, values, etc. was intentionally omitted as these methods did not seem to be necessary for the core uses of an attribute-value mapping. If such methods are truly necessary for a given use case, this may suggest that a dict object is a more appropriate type for that use. Examples ========= Converting an XML DOM tree into a tree of nested Bunch objects:: >>> import xml.dom.minidom >>> def getbunch(element): ... result = Bunch() ... if element.attributes: ... result.update(element.attributes.items()) ... children = {} ... for child in element.childNodes: ... if child.nodeType == xml.dom.minidom.Node.TEXT_NODE: ... children.setdefault('text', []).append( ... child.nodeValue) ... else: ... children.setdefault(child.nodeName, []).append( ... getbunch(child)) ... result.update(children) ... return result ... >>> doc = xml.dom.minidom.parseString(""" ... ... ... a text 1 ... ... b text ... a text 2 ... ... c text ... """) >>> b = getbunch(doc.documentElement) >>> b.a[0].b[1] Bunch(attr_b=u'3', text=[u' b text ']) Reference Implementation ======================== The code is available as SourceForge patch 1094542 [1]_. Open Issues =========== What should the type be named? Some suggestions include 'Bunch', 'Record', 'Struct' and 'Namespace'. Where should the type be placed? The current suggestion is the collections module. References ========== .. [1] http://sourceforge.net/tracker/index.php?func=detail&aid=1094542&group_id=5470&atid=305470 .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 End: ---------------------------------------------------------------------- Comment By: Alan Green (alanvgreen) Date: 2005-01-24 05:34 Message: Logged In: YES user_id=1174944 Some thoughts while we wait for the PEP: 1. This doesn't look like a collection class to me. It's more of a convenient substitute for a first-class object. The PEP would need to include a rationale as to why this class is in the collections module. 2. It may be desireable to make the core parts of Bunch (equality test, repr, and update) available as functions that other classes can use if appropriate. This might help developers building objects more complex than a Bunch. Then again, maybe not, but I'd like to see the PEP address this. 3. The docstring on __eq__ should explicitly say what consitutes equality for bunches: both bunches have the same attributes and the same values for those attributes. 4. It's easy enough to convert a dict to a Bunch (via the Bunch constructor), but I would have expected that there be a way to convert a Bunch to a dict. Overall, a useful concept, but I'd like to read the PEP - you could always upload your draft to this patch item :) ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-01-10 08:15 Message: Logged In: YES user_id=945502 I submitted a PEP for it on 2 Jan 2005, but I haven't heard back from peps@python.org yet. Sorry, I didn't realize it might take so long to get a PEP number. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2005-01-10 07:08 Message: Logged In: YES user_id=99874 Would someone be willing to provide the motivation for adding this class? I'm certainly willing to listen, but I'm not convinced this is worth adding to the std library. (I guess that's a -0 vote.) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-01-03 10:38 Message: Logged In: YES user_id=1188172 Let me add that the main functionality consists in the easy initializing and updating (otherwise, you just could use an empty class). I'm +1 on the class, but I would call it `bunch'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094542&group_id=5470 From noreply at sourceforge.net Wed Feb 16 10:45:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 10:45:45 2005 Subject: [Patches] [ python-Patches-790710 ] breakpoint command lists in pdb Message-ID: Patches item #790710, was opened at 2003-08-18 17:52 Message generated for change (Settings changed) made by dooms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790710&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gr?goire Dooms (dooms) >Assigned to: Martin v. L?wis (loewis) Summary: breakpoint command lists in pdb Initial Comment: This patch enables the user to define a list of commands associated to a breakpoint. Those commands are executed whenever the given breakpoint makes the program stop execution. The "commands [bpnumber]" command works like in gdb. This patch is against the CVS HEAD, it has been tested with python 2.3. The documentation is updated too. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-02-06 18:14 Message: Logged In: YES user_id=6380 Still no time, so unassigning. ---------------------------------------------------------------------- Comment By: Gr?goire Dooms (dooms) Date: 2005-02-06 13:06 Message: Logged In: YES user_id=846867 Patch against python 2.4 : pdb.py revision 1.73 ---------------------------------------------------------------------- Comment By: Gr?goire Dooms (dooms) Date: 2005-02-06 13:03 Message: Logged In: YES user_id=846867 I redid this patch according to your comments. The command list definition interaction is made by calling cmdloop again. onecmd is overriden to check if the line is entered in "normal mode" or in "command list definition mode". This way is much cleaner than before. I also renamed all additional data attributes so they contain "commands" as a substring. I add the new patch against revision 1.66 (python 2.3) and revision 1.73 (python 2.4). This patch does not contain the documentation changes as I did not rewrite the doc (refer to the old diff file for the doc patch). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-18 17:40 Message: Logged In: YES user_id=21627 Oops. Changing the prompt itself is fine - I just disliked the control flow that follows. IDLE things can be discussed on either list, I guess, or directly sent to kbk. If you mean changes, you best submit them as a patch here to SF. ---------------------------------------------------------------------- Comment By: Gr?goire Dooms (dooms) Date: 2004-08-18 12:48 Message: Logged In: YES user_id=846867 Ok, I see. This implementation is one year old. I'll recode this according to your comments. Why should'nt 'commands' change the prompt ? Should I assign to somebody else ? Are IDLE topics preferably discussed in idle-dev or python-dev mailing list ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-18 12:19 Message: Logged In: YES user_id=21627 I like the feature, but the implementation is not acceptable in its current form: it changes the prompt, and the rebinds all existing commands so that they add to self.commands. Instead of all this trickery, do_commands should invoke cmdloop directly, and add precmd and do_end implementations; overriding onecmd also might be an option. In addition, the patch should avoid setting member variables of pdb in cases where a local variable is sufficient (e.g. lastcmd_back). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-03-20 23:02 Message: Logged In: YES user_id=6380 I'm all for this, but don't have the bandwidth to review it. Who does? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790710&group_id=5470 From noreply at sourceforge.net Wed Feb 16 15:37:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 15:37:33 2005 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 wrobell 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: wrobell (wrobell) Date: 2005-02-16 15:37 Message: Logged In: YES user_id=387193 I am opening it again to discuss it a little more... Question to Josiah Carlson or anybody who can answer: How PEP 328 is going to solve problem I have described? If I name my script email.py, which will try to import email standard Python package. Then run the script, it will import itself instead of Python package, because directory where email.py is installed is added to sys.path. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2004-10-26 18:42 Message: Logged In: YES user_id=387193 i will not provide the patch for 328, so closing this issue ---------------------------------------------------------------------- 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 Wed Feb 16 17:50:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 17:50:20 2005 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 05:51 Message generated for change (Comment added) made by josiahcarlson 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: Josiah Carlson (josiahcarlson) Date: 2005-02-16 08:50 Message: Logged In: YES user_id=341410 If the entirety of PEP 328 made it into Python 2.4 (I don't have an installation of 2.4, so don't know), to import your 'email.py' module, you would use 'from . import email' after enabling the absolute import semantics with 'from __future__ import absolute_import'. You would then import the standard email package with 'import email'. Is this not clear by reading PEP 328? ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-16 06:37 Message: Logged In: YES user_id=387193 I am opening it again to discuss it a little more... Question to Josiah Carlson or anybody who can answer: How PEP 328 is going to solve problem I have described? If I name my script email.py, which will try to import email standard Python package. Then run the script, it will import itself instead of Python package, because directory where email.py is installed is added to sys.path. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2004-10-26 09:42 Message: Logged In: YES user_id=387193 i will not provide the patch for 328, so closing this issue ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-07 13: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-20 16: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 08: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-07 16: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 Wed Feb 16 18:31:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 18:31:56 2005 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 wrobell 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: wrobell (wrobell) Date: 2005-02-16 18:31 Message: Logged In: YES user_id=387193 But the problem is not with naming of my modules/packages (part about relative import of modules I do understand, of course), but with script naming. For example consider script: #!/usr/bin/python import email print 1 And name the script email.py, then run it, please. Python tries to be too smart (IMHO) and variable sys.path is polluted with directory of email.py script, therefore standard email Python package will not be imported. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-16 17:50 Message: Logged In: YES user_id=341410 If the entirety of PEP 328 made it into Python 2.4 (I don't have an installation of 2.4, so don't know), to import your 'email.py' module, you would use 'from . import email' after enabling the absolute import semantics with 'from __future__ import absolute_import'. You would then import the standard email package with 'import email'. Is this not clear by reading PEP 328? ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-16 15:37 Message: Logged In: YES user_id=387193 I am opening it again to discuss it a little more... Question to Josiah Carlson or anybody who can answer: How PEP 328 is going to solve problem I have described? If I name my script email.py, which will try to import email standard Python package. Then run the script, it will import itself instead of Python package, because directory where email.py is installed is added to sys.path. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2004-10-26 18:42 Message: Logged In: YES user_id=387193 i will not provide the patch for 328, so closing this issue ---------------------------------------------------------------------- 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 Wed Feb 16 18:43:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 18:43:10 2005 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 05:51 Message generated for change (Comment added) made by josiahcarlson 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: Josiah Carlson (josiahcarlson) Date: 2005-02-16 09:43 Message: Logged In: YES user_id=341410 If you were to make your 'email.py' file contain the following... #!/user/bin/python from __future__ import absolute_import import email print 1 It should import the email package. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-16 09:31 Message: Logged In: YES user_id=387193 But the problem is not with naming of my modules/packages (part about relative import of modules I do understand, of course), but with script naming. For example consider script: #!/usr/bin/python import email print 1 And name the script email.py, then run it, please. Python tries to be too smart (IMHO) and variable sys.path is polluted with directory of email.py script, therefore standard email Python package will not be imported. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-16 08:50 Message: Logged In: YES user_id=341410 If the entirety of PEP 328 made it into Python 2.4 (I don't have an installation of 2.4, so don't know), to import your 'email.py' module, you would use 'from . import email' after enabling the absolute import semantics with 'from __future__ import absolute_import'. You would then import the standard email package with 'import email'. Is this not clear by reading PEP 328? ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-16 06:37 Message: Logged In: YES user_id=387193 I am opening it again to discuss it a little more... Question to Josiah Carlson or anybody who can answer: How PEP 328 is going to solve problem I have described? If I name my script email.py, which will try to import email standard Python package. Then run the script, it will import itself instead of Python package, because directory where email.py is installed is added to sys.path. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2004-10-26 09:42 Message: Logged In: YES user_id=387193 i will not provide the patch for 328, so closing this issue ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-07 13: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-20 16: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 08: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-07 16: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 Wed Feb 16 20:37:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 20:37:17 2005 Subject: [Patches] [ python-Patches-1116362 ] date.strptime and time.strptime as well Message-ID: Patches item #1116362, was opened at 2005-02-04 13:16 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116362&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josh (josh-sf) Assigned to: Nobody/Anonymous (nobody) Summary: date.strptime and time.strptime as well Initial Comment: Add strptime constructor to date and time as well as datetime. This patch is really a followup to http://sourceforge.net/tracker/index.php?func=detail&aid=1100942&group_id=5470&atid=305470 , but re-posted here in order to attract attention :) ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 14:37 Message: Logged In: YES user_id=593130 I think maybe the additions are better added to the original patch. I would think that all three constructors are best reviewed together. Splitting across two tracker items makes this more difficult. As yet, there are no attachments (patches) to review. From the last line, perhaps this is intentional. Attention is not always positive ;-) Perhaps close this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116362&group_id=5470 From service at paypal.com Wed Feb 16 20:23:18 2005 From: service at paypal.com (service@paypal.com) Date: Wed Feb 16 20:57:05 2005 Subject: [Patches] PayPal Notification Message-ID: <20050216192318.10069.qmail@linux.webcontrol.ca> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20050216/c3d77253/attachment.html From noreply at sourceforge.net Thu Feb 17 07:46:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 07:46:28 2005 Subject: [Patches] [ python-Patches-1121611 ] sha and md5 modules should use OpenSSL when possible Message-ID: Patches item #1121611, was opened at 2005-02-12 17:33 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121611&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory P. Smith (greg) Assigned to: Nobody/Anonymous (nobody) Summary: sha and md5 modules should use OpenSSL when possible Initial Comment: The md5 and sha (sha1) modules should use OpenSSL for the algorithms when it is available as its implementations are much faster than pythons own. Attached is an initial patch to use OpenSSL for the sha module. Its not ready for committing as is yet, but it is setup to be a generic base for all OpenSSL hashes with a little bit of work in the future. Tossing this out there for people to see how trivial it is and enjoy the speedups. diff is against HEAD but it should apply to 2.4 just fine. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2005-02-16 22:46 Message: Logged In: YES user_id=413 hashes-openssl-002.patch replaces the sha and md5 modules with a general hashes module that wraps all hashes that OpenSSL supports. note that OpenSSLs implementations are much faster than the previous python versions as it choses versions optimized for your particular hardware. Incase python is compiled without openssl the hashes wrapper falls back on the old python sha and md5 module implementations. side note: This may be sufficient for the Debian folks to work around their random odd licensing issue. just have debian python depend on openssl; use this and remove the old md5 module/code that wouldn't get used anyways. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121611&group_id=5470 From noreply at sourceforge.net Thu Feb 17 18:09:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 18:09:44 2005 Subject: [Patches] [ python-Patches-1116362 ] date.strptime and time.strptime as well Message-ID: Patches item #1116362, was opened at 2005-02-04 18:16 Message generated for change (Settings changed) made by josh-sf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116362&group_id=5470 Category: Modules Group: None Status: Open >Resolution: Duplicate Priority: 5 Submitted By: Josh (josh-sf) Assigned to: Nobody/Anonymous (nobody) Summary: date.strptime and time.strptime as well Initial Comment: Add strptime constructor to date and time as well as datetime. This patch is really a followup to http://sourceforge.net/tracker/index.php?func=detail&aid=1100942&group_id=5470&atid=305470 , but re-posted here in order to attract attention :) ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 19:37 Message: Logged In: YES user_id=593130 I think maybe the additions are better added to the original patch. I would think that all three constructors are best reviewed together. Splitting across two tracker items makes this more difficult. As yet, there are no attachments (patches) to review. From the last line, perhaps this is intentional. Attention is not always positive ;-) Perhaps close this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116362&group_id=5470 From noreply at sourceforge.net Thu Feb 17 18:10:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 18:10:09 2005 Subject: [Patches] [ python-Patches-1116362 ] date.strptime and time.strptime as well Message-ID: Patches item #1116362, was opened at 2005-02-04 18:16 Message generated for change (Settings changed) made by josh-sf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116362&group_id=5470 Category: Modules Group: None >Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Josh (josh-sf) Assigned to: Nobody/Anonymous (nobody) Summary: date.strptime and time.strptime as well Initial Comment: Add strptime constructor to date and time as well as datetime. This patch is really a followup to http://sourceforge.net/tracker/index.php?func=detail&aid=1100942&group_id=5470&atid=305470 , but re-posted here in order to attract attention :) ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 19:37 Message: Logged In: YES user_id=593130 I think maybe the additions are better added to the original patch. I would think that all three constructors are best reviewed together. Splitting across two tracker items makes this more difficult. As yet, there are no attachments (patches) to review. From the last line, perhaps this is intentional. Attention is not always positive ;-) Perhaps close this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116362&group_id=5470 From noreply at sourceforge.net Thu Feb 17 18:15:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 18:15:51 2005 Subject: [Patches] [ python-Patches-1100942 ] datetime.strptime constructor added Message-ID: Patches item #1100942, was opened at 2005-01-12 14:53 Message generated for change (Comment added) made by josh-sf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100942&group_id=5470 Category: Modules >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josh (josh-sf) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.strptime constructor added Initial Comment: Alllow creating new datetime objects by parsing date strings. datetime already has strftime, so adding strptime is logical. The new constructor is equivalent to datetime(*(time.strptime(date_string, format)[0:6])). Patch includes documentation and unit test. ---------------------------------------------------------------------- >Comment By: Josh (josh-sf) Date: 2005-02-17 17:15 Message: Logged In: YES user_id=1194964 The first patch has been applied, now just the second needs to be. (strptime2.diff). That adds support for date and time as well as datetime, as per alanvgreen's suggestion. ---------------------------------------------------------------------- Comment By: Josh (josh-sf) Date: 2005-02-02 00:50 Message: Logged In: YES user_id=1194964 Regarding support by datetime.time and datetime.date, if a date component or a time component is specified, respectively, do you think that we should raise an exception? or should we just ignore it? ---------------------------------------------------------------------- Comment By: Alan Green (alanvgreen) Date: 2005-01-25 12:05 Message: Logged In: YES user_id=1174944 This patch will be welcomed by all of that have had to write "datetime(*(time.strptime(date_string, format)[0:6]))". I don't understand the C API well enough to check if reference counts are handled properly, but otherwise the implementation looks straight forward. Documentation looks good and the test passes on my machine. Two suggestions: 1. In the time module, the strptime() function's format parameter is optional. For consistency's sake, I'd expect datetime.strptime()'s format parameter also to be optional. (On the other hand, the default value for the format is not very useful.) 2. Since strftime is supported by datetime.time, datetime.date and datetime.datetime, I'd also expect strptime to be supported by all three classes. Could you add that now, or would it be better to do it as a separate patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100942&group_id=5470 From noreply at sourceforge.net Thu Feb 17 20:43:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 20:43:49 2005 Subject: [Patches] [ python-Patches-1126187 ] isapi.samples.advanced.py fix Message-ID: Patches item #1126187, was opened at 2005-02-17 11: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=1126187&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Philippe Kirsanov (phwp) Assigned to: Nobody/Anonymous (nobody) Summary: isapi.samples.advanced.py fix Initial Comment: This fix is to support win32 files in fotmat: \?\drive:\dir\name.ext It's valid file format in win32. I've got that kind of file name trying to use __file__ when script is used as isapi extension. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1126187&group_id=5470 From noreply at sourceforge.net Fri Feb 18 01:42:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 18 01:42:25 2005 Subject: [Patches] [ python-Patches-1141428 ] more __contains__ tests Message-ID: Patches item #1141428, was opened at 2005-02-17 19:42 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=1141428&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: more __contains__ tests Initial Comment: Recently, there was a change to speed up __contains__. x in (1, 2, 3) would be compiled as x in frozenset(1, 2, 3). This was backed out, because frozensets raise a typeerror when asked about unhashable objects. These objects *can't* be in the set, but there was concern about supporting objects in which a mutable and an immutable compare equal. So long as that is a requirement, it should be tested. The new test for sequences ensures that they will use __eq__ (and not rely on __hash__) in the future. The change to the rich compare tests is just a comment, pointing out that dicts can rely on __hash__ as well as __eq__. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1141428&group_id=5470 From noreply at sourceforge.net Fri Feb 18 01:46:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 18 01:46:20 2005 Subject: [Patches] [ python-Patches-1141428 ] more __contains__ tests Message-ID: Patches item #1141428, was opened at 2005-02-17 19:42 Message generated for change (Settings changed) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1141428&group_id=5470 >Category: Tests >Group: Python 2.4 Status: Open Resolution: None >Priority: 4 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: more __contains__ tests Initial Comment: Recently, there was a change to speed up __contains__. x in (1, 2, 3) would be compiled as x in frozenset(1, 2, 3). This was backed out, because frozensets raise a typeerror when asked about unhashable objects. These objects *can't* be in the set, but there was concern about supporting objects in which a mutable and an immutable compare equal. So long as that is a requirement, it should be tested. The new test for sequences ensures that they will use __eq__ (and not rely on __hash__) in the future. The change to the rich compare tests is just a comment, pointing out that dicts can rely on __hash__ as well as __eq__. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1141428&group_id=5470 From wamu-Notification-Urgelqht at wamu.com Fri Feb 18 03:32:11 2005 From: wamu-Notification-Urgelqht at wamu.com (wamu-Notification-Urgelqht@wamu.com) Date: Fri Feb 18 03:59:53 2005 Subject: [Patches] Re-Submit: wamu.com Urgent requirementvu', the last 2 letters are Message-ID: <200502180232.j1I2WBhm002794@localhost.localdomain> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20050218/c1aea5d9/attachment.html From noreply at sourceforge.net Fri Feb 18 08:21:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 18 08:21:35 2005 Subject: [Patches] [ python-Patches-1141428 ] more __contains__ tests Message-ID: Patches item #1141428, was opened at 2005-02-17 19:42 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1141428&group_id=5470 Category: Tests >Group: Python 2.5 Status: Open Resolution: None Priority: 4 Submitted By: Jim Jewett (jimjjewett) >Assigned to: Raymond Hettinger (rhettinger) Summary: more __contains__ tests Initial Comment: Recently, there was a change to speed up __contains__. x in (1, 2, 3) would be compiled as x in frozenset(1, 2, 3). This was backed out, because frozensets raise a typeerror when asked about unhashable objects. These objects *can't* be in the set, but there was concern about supporting objects in which a mutable and an immutable compare equal. So long as that is a requirement, it should be tested. The new test for sequences ensures that they will use __eq__ (and not rely on __hash__) in the future. The change to the rich compare tests is just a comment, pointing out that dicts can rely on __hash__ as well as __eq__. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1141428&group_id=5470 From noreply at sourceforge.net Fri Feb 18 12:14:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 18 12:14:38 2005 Subject: [Patches] [ python-Patches-1143695 ] Fix to allow urllib2 digest auth to talk to livejournal.com Message-ID: Patches item #1143695, was opened at 2005-02-18 22:14 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=1143695&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Benno Rice (benno) Assigned to: Nobody/Anonymous (nobody) Summary: Fix to allow urllib2 digest auth to talk to livejournal.com Initial Comment: When trying to use feedparser.py to deal with RSS feeds from livejournal.com using digest auth (needed to access locked posts), urllib2 would report a digest auth failure. The solution appears to be to always specify the algorithm, even when it's MD5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1143695&group_id=5470 From noreply at sourceforge.net Fri Feb 18 20:21:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 18 20:21:56 2005 Subject: [Patches] [ python-Patches-1121611 ] sha and md5 modules should use OpenSSL when possible Message-ID: Patches item #1121611, was opened at 2005-02-12 20:33 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121611&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory P. Smith (greg) Assigned to: Nobody/Anonymous (nobody) Summary: sha and md5 modules should use OpenSSL when possible Initial Comment: The md5 and sha (sha1) modules should use OpenSSL for the algorithms when it is available as its implementations are much faster than pythons own. Attached is an initial patch to use OpenSSL for the sha module. Its not ready for committing as is yet, but it is setup to be a generic base for all OpenSSL hashes with a little bit of work in the future. Tossing this out there for people to see how trivial it is and enjoy the speedups. diff is against HEAD but it should apply to 2.4 just fine. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-18 14:21 Message: Logged In: YES user_id=764593 Should the private modules (such as _sha) be placed in a crypto package, instead of directly in the parent/everything library? ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-02-17 01:46 Message: Logged In: YES user_id=413 hashes-openssl-002.patch replaces the sha and md5 modules with a general hashes module that wraps all hashes that OpenSSL supports. note that OpenSSLs implementations are much faster than the previous python versions as it choses versions optimized for your particular hardware. Incase python is compiled without openssl the hashes wrapper falls back on the old python sha and md5 module implementations. side note: This may be sufficient for the Debian folks to work around their random odd licensing issue. just have debian python depend on openssl; use this and remove the old md5 module/code that wouldn't get used anyways. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121611&group_id=5470 From noreply at sourceforge.net Fri Feb 18 23:08:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 18 23:08:44 2005 Subject: [Patches] [ python-Patches-1123430 ] Python memory allocator: Free memory Message-ID: Patches item #1123430, was opened at 2005-02-15 16:27 Message generated for change (Comment added) made by vulturex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1123430&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Evan Jones (vulturex) Assigned to: Nobody/Anonymous (nobody) Summary: Python memory allocator: Free memory Initial Comment: This is the second version of my Python memory allocator patch. The first version was discussed on the python-dev mailing list here: http://mail.python.org/pipermail/python-dev/2005-January/ 051255.html This patch enables Python to actually return memory to the system. The current version's memory usage will only grow. This version maintains the same backwards compatability guarantees as the previous version: Calling PyObject_Free with a pointer that was returned by malloc() while NOT holding the GIL will work, and will not corrupt the state of the memory allocator. The patch modifies obmalloc.c. If it is accepted, other modifications to that file are required. In particular, I have not yet updated the WITH_MEMORY_LIMITS implementation, nor have I looked closely at the PYMALLOC_DEBUG code to see what changes (if any) are required. ---------------------------------------------------------------------- >Comment By: Evan Jones (vulturex) Date: 2005-02-18 17:08 Message: Logged In: YES user_id=539295 Please ignore this patch for the moment: I'm in the process of making some fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1123430&group_id=5470 From service at paypal.com Thu Feb 17 12:39:13 2005 From: service at paypal.com (service@paypal.com) Date: Fri Feb 18 23:50:47 2005 Subject: [Patches] PayPal Notification Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20050217/63eb1eb3/attachment.html From noreply at sourceforge.net Sat Feb 19 09:57:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 19 09:57:19 2005 Subject: [Patches] [ python-Patches-1143695 ] Fix to allow urllib2 digest auth to talk to livejournal.com Message-ID: Patches item #1143695, was opened at 2005-02-18 22:14 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1143695&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Benno Rice (benno) Assigned to: Nobody/Anonymous (nobody) Summary: Fix to allow urllib2 digest auth to talk to livejournal.com Initial Comment: When trying to use feedparser.py to deal with RSS feeds from livejournal.com using digest auth (needed to access locked posts), urllib2 would report a digest auth failure. The solution appears to be to always specify the algorithm, even when it's MD5. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-02-19 19:57 Message: Logged In: YES user_id=29957 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1143695&group_id=5470 From noreply at sourceforge.net Sat Feb 19 10:02:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 19 10:02:13 2005 Subject: [Patches] [ python-Patches-1143695 ] Fix to allow urllib2 digest auth to talk to livejournal.com Message-ID: Patches item #1143695, was opened at 2005-02-18 22:14 Message generated for change (Comment added) made by benno You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1143695&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Benno Rice (benno) Assigned to: Nobody/Anonymous (nobody) Summary: Fix to allow urllib2 digest auth to talk to livejournal.com Initial Comment: When trying to use feedparser.py to deal with RSS feeds from livejournal.com using digest auth (needed to access locked posts), urllib2 would report a digest auth failure. The solution appears to be to always specify the algorithm, even when it's MD5. ---------------------------------------------------------------------- >Comment By: Benno Rice (benno) Date: 2005-02-19 20:02 Message: Logged In: YES user_id=9925 SourceForge is teh suxx0r. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-02-19 19:57 Message: Logged In: YES user_id=29957 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1143695&group_id=5470 From noreply at sourceforge.net Sat Feb 19 15:07:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 19 15:07:07 2005 Subject: [Patches] [ python-Patches-1123430 ] Python memory allocator: Free memory Message-ID: Patches item #1123430, was opened at 2005-02-15 16:27 Message generated for change (Comment added) made by vulturex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1123430&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Evan Jones (vulturex) Assigned to: Nobody/Anonymous (nobody) Summary: Python memory allocator: Free memory Initial Comment: This is the second version of my Python memory allocator patch. The first version was discussed on the python-dev mailing list here: http://mail.python.org/pipermail/python-dev/2005-January/ 051255.html This patch enables Python to actually return memory to the system. The current version's memory usage will only grow. This version maintains the same backwards compatability guarantees as the previous version: Calling PyObject_Free with a pointer that was returned by malloc() while NOT holding the GIL will work, and will not corrupt the state of the memory allocator. The patch modifies obmalloc.c. If it is accepted, other modifications to that file are required. In particular, I have not yet updated the WITH_MEMORY_LIMITS implementation, nor have I looked closely at the PYMALLOC_DEBUG code to see what changes (if any) are required. ---------------------------------------------------------------------- >Comment By: Evan Jones (vulturex) Date: 2005-02-19 09:07 Message: Logged In: YES user_id=539295 As per the discussion on python-dev, I've removed the concurrency hack. The routines in obmalloc.c now *must* be called while holding the GIL, even if the pointer was allocated with malloc(). I also finally fixed the PYMALLOC_DEBUG routines, so I believe this patch is now "complete." ---------------------------------------------------------------------- Comment By: Evan Jones (vulturex) Date: 2005-02-18 17:08 Message: Logged In: YES user_id=539295 Please ignore this patch for the moment: I'm in the process of making some fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1123430&group_id=5470 From noreply at sourceforge.net Sat Feb 19 21:02:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 19 21:02:48 2005 Subject: [Patches] [ python-Patches-1144504 ] Add IEEE Float support to wave.py Message-ID: Patches item #1144504, was opened at 2005-02-19 20: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=1144504&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ben Schwartz (bensatmit_edu) Assigned to: Nobody/Anonymous (nobody) Summary: Add IEEE Float support to wave.py Initial Comment: IEEE Float .wav files have almost identical structure to standard PCM .wav files. Currently, wave.py gives an unknown format error when attempting to read IEEE Float .wav files. This patch causes wave.py to read those files properly. No changes were made to wave_write, only wave_read. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144504&group_id=5470 From noreply at sourceforge.net Sat Feb 19 21:38:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 19 21:38:14 2005 Subject: [Patches] [ python-Patches-941881 ] PEP309 Partial implementation Message-ID: Patches item #941881, was opened at 2004-04-25 12:05 Message generated for change (Comment added) made by bediviere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: PEP309 Partial implementation Initial Comment: This patch implements functional module which is introduced by PEP309. It has only 'partial' function as its member in this stage. Unittest code is copied and modified slightly from Patch #931010 by Peter Harris. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-19 13:38 Message: Logged In: YES user_id=945502 It might be nice if partial objects were usable as instancemethods, like functions are. Note the following behavior with the current patch: >>> import functional >>> class C(object): ... pass ... >>> def func(self, arg): ... return arg ... >>> for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... >>> C().a() Traceback (most recent call last): File "", line 1, in ? TypeError: func() takes exactly 2 arguments (1 given) If functional.partial was instead defined like: class partial(object): def __init__(*args, **kwargs): self = args[0] try: self.func = args[1] except IndexError: raise TypeError('expected 2 or more arguments, got ' % len(args)) self.obj = () self.args = args[2:] self.kwargs = kwargs def __call__(self, *args, **kwargs): if kwargs and self.kwargs: d = self.kwargs.copy() d.update(kwargs) else: d = kwargs or self.kwargs return self.func(*(self.obj + self.args + args), **d) def __get__(self, obj, type=None): if obj is None: return self result = partial(self.func, *self.args, **self.kwargs) result.obj = (obj,) return result where an appropriate __get__ method is provided, then partial objects behave properly when set as attributes to a class: py> def test(): ... class C(object): ... pass ... def func(self, arg): ... return arg ... for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... c = C() ... return c.a(), c.b(), c.c() ... py> test() ('a', 'b', 'c') ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-10 18:11 Message: Logged In: YES user_id=1038590 I have tested this patch on Windows, and it passes its own test suite, without affecting any other tests. However, PCBuild\pythoncore.vcproj & PC\config.c require modification to allow Python to pick up the new module correctly. Patch #1006948 created with the needed changes (also removes unneeded ODBC references from pythoncore.vcproj as I am using the free MS toolkits to build here) My patch definitely needs to be checked by someone with a copy of Vis Studio 2003! ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-08-03 14:23 Message: Logged In: YES user_id=113328 OK, a real need beats my theoretical worries :-) Consider me convinced. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-05-17 22:05 Message: Logged In: YES user_id=139309 I would use partial in situations where speed can matter (imap, commonly used event handlers, etc.), so a fast C implementation would be nice to have. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 02:03 Message: Logged In: YES user_id=113328 Yes, that looks like a significant speed improvement :-) I was basing my assumptions on the comments made in the PEP. Sorry. But I still wonder if having the implementation in Python wouldn't be better from a maintenance point of view. (As well as all the arguments about usefulness as sample code, ability to backport, etc etc, that have come up on python-dev regarding moving other Python library modules into C...). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-04-26 20:05 Message: Logged In: YES user_id=55188 Python-version (function) ... 1.19 2.69 Python-version (class) ... 2.61 2.38 C-version ... 0.50 0.37 (former value is for 100000 instanciations and latter is for 100000 calls.) And, C version have a facility that changing attributes after the instantiation that is supported by class version only. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-26 13:30 Message: Logged In: YES user_id=113328 Why implement this in C? I can't imagine that the performance improvement will be that significant. A pure Python module in the standard library seems to me to be a far better idea. As the PEP says, "the case for a built-in coded in C is not very strong". And a Python module is good self-documentation. I prefer the function version suggested in the PEP (credited to Carl Banks) over the class-based one. You need to take a little care to avoid capturing argument names: def partial(*args, **kwds): def callit(*moreargs, **morekwds): kw = kwds.copy() kw.update(morekwds) return args[0](*(args[1:]+moreargs), **kw) return callit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 From noreply at sourceforge.net Sat Feb 19 22:14:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 19 22:14:49 2005 Subject: [Patches] [ python-Patches-890203 ] DragonFly BSD support Message-ID: Patches item #890203, was opened at 2004-02-04 07:30 Message generated for change (Comment added) made by cameuh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=890203&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jon Parise (jparise) Assigned to: Nobody/Anonymous (nobody) Summary: DragonFly BSD support Initial Comment: I spent some time building a simple little patch that gets Python up and running under DragonFly BSD. At the moment, DragonFly (as a platform) is nearly identical to FreeBSD (from which is was forked), so the generated the patch was largely mechanical. I'll continue to make efforts to support Python on DragonFly should things become more complicated. The only known issue is a test case failure for test_fcntl. I don't know whether this failure is unique to DragonFly at this time. I'll investigate that soon. This patch is valid for DragonFly 1.0-CURRENT using either GCC 2.95.4 or GCC 3.3.3 20040126. ---------------------------------------------------------------------- Comment By: cam (cameuh) Date: 2005-02-19 22:14 Message: Logged In: YES user_id=463600 I'm experiencing the same issue, here is my config: DragonFly 1.1-Stable gcc version 2.95.4 20020320 [DragonFly] Python cvs # ./configure --prefix=/usr --with-fpectl --enable-shared --infodir=/usr/share/ info --mandir=/usr/share/man --with-threads You can see the full configure/make here: http://www.cameuh.net/dfbsd-python.txt.gz Python is compiled fine, but there is no modules: # ls /usr/lib/python2.3/lib-dynload/ cPickle_failed.so struct_failed.so ---------------------------------------------------------------------- Comment By: Jon Parise (jparise) Date: 2004-08-04 06:48 Message: Logged In: YES user_id=485579 That's strange. I just built Python HEAD under DragonFly 1.1-CURRENT. I've updated the patch to reflect the latest changes to the Python repository. What configure arguments are you using? ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-07-25 06:33 Message: Logged In: YES user_id=55188 I got massive errors while compiling some extension modules. (DragonflyBSD 1.0A, python HEAD as of today) ld build/temp.dragonfly-1.0A-RELEASE-i386-2.4/dlmodule.o -L/usr/local/lib -o build/lib.dragonfly-1.0A-RELEASE-i386-2.4/dl.so /usr/libexec/binutils212/elf/ld: warning: cannot find entry symbol _start; defaulting to 08048074 build/temp.dragonfly-1.0A-RELEASE-i386-2.4/dlmodule.o: In function `dl_call': /home/perky/python/Modules/dlmodule.c:82: undefined reference to `PyTuple_Size' /home/perky/python/Modules/dlmodule.c:84: undefined reference to `PyExc_TypeError' /home/perky/python/Modules/dlmodule.c:84: undefined reference to `PyErr_SetString' /home/perky/python/Modules/dlmodule.c:87: undefined reference to `PyTuple_GetItem' /home/perky/python/Modules/dlmodule.c:88: undefined reference to `PyString_Type' /home/perky/python/Modules/dlmodule.c:88: undefined reference to `PyString_Type' /home/perky/python/Modules/dlmodule.c:88: undefined reference to `PyType_IsSubtype' ---------------------------------------------------------------------- Comment By: Jon Parise (jparise) Date: 2004-03-15 03:43 Message: Logged In: YES user_id=485579 The test_fcnlt failure has been corrected in the latest patch. ---------------------------------------------------------------------- Comment By: Jon Parise (jparise) Date: 2004-03-05 08:26 Message: Logged In: YES user_id=485579 Updated the patch against the latest Python 2.4a (cvs) code. ---------------------------------------------------------------------- Comment By: Jon Parise (jparise) Date: 2004-02-05 01:00 Message: Logged In: YES user_id=485579 Yes, I'm comfortable with that. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-04 23:36 Message: Logged In: YES user_id=21627 Are you willing to act as a maintainer and contact point for the Dragonfly port? ---------------------------------------------------------------------- Comment By: Jon Parise (jparise) Date: 2004-02-04 07:32 Message: Logged In: YES user_id=485579 Also, attached in the generated IN.py Lib/plat-dragonfly1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=890203&group_id=5470 From noreply at sourceforge.net Sat Feb 19 23:23:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 19 23:23:27 2005 Subject: [Patches] [ python-Patches-1144549 ] cgitb: make more usable for 'binary-only' sw (new patch) Message-ID: Patches item #1144549, was opened at 2005-02-19 23:23 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=1144549&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: cgitb: make more usable for 'binary-only' sw (new patch) Initial Comment: see patch #751943: """ I am abusing cgitb to show a traceback window for a GUI application in Qt. In such a case, the source code to the program is not always available. The stack trace is anyway useful to be submitted to the developers of the code. I attach a patch that should add some info to the HTML traceback made by cgitb in case the source file is not available. """ This new patch, however, does not generate a link to "file://?" if the filename is not known. At the same time, it stops shadowing file() by renaming local vars. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144549&group_id=5470 From noreply at sourceforge.net Sat Feb 19 23:47:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 19 23:47:20 2005 Subject: [Patches] [ python-Patches-1144555 ] allow UNIX mmap size to default to current file size (new) Message-ID: Patches item #1144555, was opened at 2005-02-19 23:47 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=1144555&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: allow UNIX mmap size to default to current file size (new) Initial Comment: see patch #749830: """ This patch makes the UNIX mmap behave like the Windows mmap in that if you pass 0 as the mmap size, the map size will default to the current length of the file being mmapped. This allows avoids a call to os.stat if you want to map the entire file. It also makes code using this feature of the Windows mmap to be portable to UNIX. """ This new patch applies cleanly on current CVS HEAD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144555&group_id=5470 From noreply at sourceforge.net Sun Feb 20 02:45:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 20 02:45:29 2005 Subject: [Patches] [ python-Patches-1117588 ] urllib2 .getheaders attribute error Message-ID: Patches item #1117588, was opened at 2005-02-07 00:18 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117588&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 .getheaders attribute error Initial Comment: The headers arguments to all methods are dictionaries, however the http_error_302 method calls headers.getheaders() which results in an attribute error. The attached patch against current CVS fixes this by using headers.get() instead of .getheaders(). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-20 01:45 Message: Logged In: YES user_id=261020 I can't see where your AttributeError is coming from. Thankyou very much for the bug report, but *please* supply some means of reproducing the problem! > The headers arguments to all methods are dictionaries, They are in fact always httplib.HTTPMessage instances, as far as I can see. That class inherits a .getheaders() method from rfc822.Message. (And FWIW, so far as I can see, the type of the "hdrs" arguments to the .http_error_*() handler methods are not documented.) Moreover, .getheaders() and .get() don't mean the same thing in general: HTTPMessage.getheaders(name)[0] preserves header ordering information, where eg. dict.get(name) does not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117588&group_id=5470 From noreply at sourceforge.net Sun Feb 20 03:01:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 20 03:01:55 2005 Subject: [Patches] [ python-Patches-1143695 ] Fix to allow urllib2 digest auth to talk to livejournal.com Message-ID: Patches item #1143695, was opened at 2005-02-18 11:14 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1143695&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Benno Rice (benno) Assigned to: Nobody/Anonymous (nobody) Summary: Fix to allow urllib2 digest auth to talk to livejournal.com Initial Comment: When trying to use feedparser.py to deal with RSS feeds from livejournal.com using digest auth (needed to access locked posts), urllib2 would report a digest auth failure. The solution appears to be to always specify the algorithm, even when it's MD5. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-20 02:01 Message: Logged In: YES user_id=261020 Patch appears correct, and RFC 2617 allows always sending the algorithm. Haven't tested the patch, or verified that real browsers do indeed always send algorithm even when it'd MD5. ---------------------------------------------------------------------- Comment By: Benno Rice (benno) Date: 2005-02-19 09:02 Message: Logged In: YES user_id=9925 SourceForge is teh suxx0r. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-02-19 08:57 Message: Logged In: YES user_id=29957 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1143695&group_id=5470 From noreply at sourceforge.net Sun Feb 20 03:14:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 20 03:14:20 2005 Subject: [Patches] [ python-Patches-1144549 ] cgitb: make more usable for 'binary-only' sw (new patch) Message-ID: Patches item #1144549, was opened at 2005-02-19 14:23 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144549&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: cgitb: make more usable for 'binary-only' sw (new patch) Initial Comment: see patch #751943: """ I am abusing cgitb to show a traceback window for a GUI application in Qt. In such a case, the source code to the program is not always available. The stack trace is anyway useful to be submitted to the developers of the code. I attach a patch that should add some info to the HTML traceback made by cgitb in case the source file is not available. """ This new patch, however, does not generate a link to "file://?" if the filename is not known. At the same time, it stops shadowing file() by renaming local vars. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-02-19 18:14 Message: Logged In: NO ! filename = os.path.abspath(filename) or '?' Why is the 'or ?' still there? Also, patches are preferred to be against CVS HEAD, rather than against a previous patched version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144549&group_id=5470 From noreply at sourceforge.net Sun Feb 20 03:48:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 20 03:48:48 2005 Subject: [Patches] [ python-Patches-1144636 ] Make OpenerDirector instances pickle-able Message-ID: Patches item #1144636, was opened at 2005-02-20 02:48 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=1144636&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: Make OpenerDirector instances pickle-able Initial Comment: urllib2.OpenerDirector would be pickleable if it were not for the fact that a couple of urllib2 handlers (which build_opener() adds by default) have function instance attributes. It's trivial to replace these instance attributes with a method that delegates to the appropriate function, thus allowing pickling. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144636&group_id=5470 From noreply at sourceforge.net Sun Feb 20 03:49:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 20 03:49:46 2005 Subject: [Patches] [ python-Patches-1144636 ] Make urllib2.OpenerDirector instances pickle-able Message-ID: Patches item #1144636, was opened at 2005-02-20 02:48 Message generated for change (Settings changed) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144636&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) >Summary: Make urllib2.OpenerDirector instances pickle-able Initial Comment: urllib2.OpenerDirector would be pickleable if it were not for the fact that a couple of urllib2 handlers (which build_opener() adds by default) have function instance attributes. It's trivial to replace these instance attributes with a method that delegates to the appropriate function, thus allowing pickling. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144636&group_id=5470 From noreply at sourceforge.net Sun Feb 20 08:17:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 20 08:17:14 2005 Subject: [Patches] [ python-Patches-1144549 ] cgitb: make more usable for 'binary-only' sw (new patch) Message-ID: Patches item #1144549, was opened at 2005-02-19 23:23 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144549&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: cgitb: make more usable for 'binary-only' sw (new patch) Initial Comment: see patch #751943: """ I am abusing cgitb to show a traceback window for a GUI application in Qt. In such a case, the source code to the program is not always available. The stack trace is anyway useful to be submitted to the developers of the code. I attach a patch that should add some info to the HTML traceback made by cgitb in case the source file is not available. """ This new patch, however, does not generate a link to "file://?" if the filename is not known. At the same time, it stops shadowing file() by renaming local vars. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-02-20 08:17 Message: Logged In: YES user_id=1188172 You're right, the 'or ?' must vanish; see attached second patch. But I did diff against CVS HEAD, didn't I? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-02-20 03:14 Message: Logged In: NO ! filename = os.path.abspath(filename) or '?' Why is the 'or ?' still there? Also, patches are preferred to be against CVS HEAD, rather than against a previous patched version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144549&group_id=5470 From noreply at sourceforge.net Sun Feb 20 15:58:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 20 15:58:30 2005 Subject: [Patches] [ python-Patches-1144816 ] webbrowser.Netscape.open bug fix Message-ID: Patches item #1144816, was opened at 2005-02-20 14:58 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=1144816&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pernici Mario (pernici) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser.Netscape.open bug fix Initial Comment: My system: Python 2.4.1a0 (#2, Feb 9 2005, 12:50:04) [GCC 3.3.5 (Debian 1:3.3.5-8)] on linux2 In webbrowser.Netscape.open the command passed to the browser should not have blank spaces (see http://www.mozilla.org/unix/remote.html); due to the space in "openURL(%s, new-window)" mozilla-firefox opens my home page instead of the requested page. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144816&group_id=5470 From noreply at sourceforge.net Sun Feb 20 16:41:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 20 16:41:51 2005 Subject: [Patches] [ python-Patches-1144842 ] Replace store/load pair with a single new opcode Message-ID: Patches item #1144842, was opened at 2005-02-20 10: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=1144842&group_id=5470 Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Replace store/load pair with a single new opcode Initial Comment: The folds the two steps into a new opcode. In the case of store_name/load_name, it saves one three byte instruction, a trip around the eval-loop, two stack mutations, a incref/decref pair, a dictionary lookup, and an error check (for the lookup). While it acts like a dup followed by a store, it is implemented more simply as a store that doesn?t pop the stack. The transformation is broadly applicable and occurs thousands of times in the standard library and test suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144842&group_id=5470 From noreply at sourceforge.net Sun Feb 20 22:31:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 20 22:31:35 2005 Subject: [Patches] [ python-Patches-1145039 ] Remove some invariant conditions and assert in ceval Message-ID: Patches item #1145039, was opened at 2005-02-20 16:31 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=1145039&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: Remove some invariant conditions and assert in ceval Initial Comment: ISTM that if frame->f_exc_type == NULL then exc_value and exc_traceback will also be NULL. I didn't see that this is documented, perhaps I missed it or there is some case when this can occur. If it can occur, we shoul develop a test for it. Assuming this condition is invariant, some simplifications can be made in reset_exc_info which is called once per eval_frame (on function exit). Also, I think there is currently an extra Py_INCREF on Py_None. This occurs when tstate->exc_type == NULL. This patch seems to have little to no effect on performance. I did measure a 0.3% speed improvement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1145039&group_id=5470 From noreply at sourceforge.net Mon Feb 21 00:24:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 21 00:24:12 2005 Subject: [Patches] [ python-Patches-1144842 ] Replace store/load pair with a single new opcode Message-ID: Patches item #1144842, was opened at 2005-02-20 16:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144842&group_id=5470 Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Replace store/load pair with a single new opcode Initial Comment: The folds the two steps into a new opcode. In the case of store_name/load_name, it saves one three byte instruction, a trip around the eval-loop, two stack mutations, a incref/decref pair, a dictionary lookup, and an error check (for the lookup). While it acts like a dup followed by a store, it is implemented more simply as a store that doesn?t pop the stack. The transformation is broadly applicable and occurs thousands of times in the standard library and test suite. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-21 00:24 Message: Logged In: YES user_id=21627 Please add a patch to Doc/lib/libdis.tex. Also, it would be good if a comment explained why these (all of the peephole optimizations) can never read over the end of the string. It appears that this patch introduces a change in semantics for STORE_NAME if f_locals is not a dictionary - with the patch, the dictionary-like object will see one less call to GetItem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144842&group_id=5470 From noreply at sourceforge.net Mon Feb 21 17:05:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 21 17:05:48 2005 Subject: [Patches] [ python-Patches-935454 ] sha256 module Message-ID: Patches item #935454, was opened at 2004-04-14 23:57 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=935454&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Trevor Perrin (trevp) >Assigned to: Gregory P. Smith (greg) Summary: sha256 module Initial Comment: This module is a copy of shamodule.c, with the SHA-1 compression function replaced with the SHA-256 compression function (copied from the LibTomCrypt public-domain crypto library). SHA-256 is similar to SHA-1: it's a US Federal Standard hash algorithm (FIPS 180-2). The difference is that it produces a 256 bit hash value, instead of a 160 bit hash value. SHA-256 thus has 128 bits of resistance against birthday attacks, which makes it secure in certain protocols where SHA-1 is questionable (e.g. digital signatures; or RNGs or Key-Derivation Functions where you want to produce keys for 256-bit ciphers). There's other flavors of SHA, but they're not as useful: SHA-384 and SHA-512 are defined on 64-bit values, so are slow on 32-bit architectures. SHA-224 is just silly (it saves 32 bits over SHA-256; that's its sole rationale). ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2005-02-21 08:05 Message: Logged In: YES user_id=413 i'll take care of this patch along with patch 1121611 using these sha 256/512 implementations when openssl doesn't include its own implementations (current common versions of openssl don't, future versions will). ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-14 00:04 Message: Logged In: YES user_id=973611 New set of files - full source, patches, and docs for all new SHA versions. Cleans things up a bit: - sha256.c, sha512.c - sha224.py, sha384.py (wrappers) - test_sha*.py - libsha*.tex ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-13 01:10 Message: Logged In: YES user_id=973611 2nd version of documentation for sha256 and sha512 ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-02 01:00 Message: Logged In: YES user_id=973611 Uploading a new sha256 module with a sha224 function, and a sha512 module with a sha384 function. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-06-30 23:48 Message: Logged In: YES user_id=973611 I'm uploading an attempt at documentation for this module. I had trouble installing the tex tools so I'm not sure if it's correct, but it should be easy to fix if not. I'll try to straighten myself out with the tools so I can make sure. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-06-29 07:23 Message: Logged In: YES user_id=11375 I can't rule on whether the module should be added or not, so I'll bring it up on python-dev. Feel free to join the resulting thread. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=935454&group_id=5470 From noreply at sourceforge.net Mon Feb 21 17:12:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 21 17:12:54 2005 Subject: [Patches] [ python-Patches-1144842 ] Replace store/load pair with a single new opcode Message-ID: Patches item #1144842, was opened at 2005-02-20 10:41 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144842&group_id=5470 Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Replace store/load pair with a single new opcode Initial Comment: The folds the two steps into a new opcode. In the case of store_name/load_name, it saves one three byte instruction, a trip around the eval-loop, two stack mutations, a incref/decref pair, a dictionary lookup, and an error check (for the lookup). While it acts like a dup followed by a store, it is implemented more simply as a store that doesn?t pop the stack. The transformation is broadly applicable and occurs thousands of times in the standard library and test suite. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-21 11:12 Message: Logged In: YES user_id=80475 Thanks for looking at the patch. Added patch to Doc/lib/libdis.tex. Added a comment and assertion documenting how the pattern recognizer stays within the string boundaries (it uses RETURN_VALUE as a guard). The transformations are invariant with respect to the preconditions and postconditions (in terms of stack effect and dictionary state). They change the how without changing the what. In this case, saving the unnecessary dictionary lookup is the point of the transformation. The code generator is free to produce STORE x LOAD x or the equivalent DUP STORE x. This is the lead example in Skip's paper on the subject: http://www.foretec.com/python/workshops/1998-11/proceedings/papers/montanaro/montanaro.html The pattern is generated by code in the form: x = f() y = x + 1 The postcondition states of x and y remain unchanged by the transformation. The other peepholer transforms work the same way (i.e. the condition jump to conditional jump simplification results in fewer comparisons because the results of identical comparisons are expected to be the same). There is a limit to this. For instance, x * 2 cannot be replaced with x + x because it results in a different method being called. The multiply call is guaranteed. This contrasts with the incidental getitem call in x=f(); y=x+1 where the compiler guarantees the call to f() and the final states of x and y. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-20 18:24 Message: Logged In: YES user_id=21627 Please add a patch to Doc/lib/libdis.tex. Also, it would be good if a comment explained why these (all of the peephole optimizations) can never read over the end of the string. It appears that this patch introduces a change in semantics for STORE_NAME if f_locals is not a dictionary - with the patch, the dictionary-like object will see one less call to GetItem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144842&group_id=5470 From noreply at sourceforge.net Mon Feb 21 23:37:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 21 23:37:46 2005 Subject: [Patches] [ python-Patches-1144842 ] Replace store/load pair with a single new opcode Message-ID: Patches item #1144842, was opened at 2005-02-20 16:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144842&group_id=5470 Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Replace store/load pair with a single new opcode Initial Comment: The folds the two steps into a new opcode. In the case of store_name/load_name, it saves one three byte instruction, a trip around the eval-loop, two stack mutations, a incref/decref pair, a dictionary lookup, and an error check (for the lookup). While it acts like a dup followed by a store, it is implemented more simply as a store that doesn?t pop the stack. The transformation is broadly applicable and occurs thousands of times in the standard library and test suite. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-21 23:37 Message: Logged In: YES user_id=21627 As for the semantic change: I believe (without testing) that the patch will change the output of the attached script (a.py). Now, I agree that this is almost the point of the patch, but it is still a change in observable behaviour. I say almost, because the point of the patch is to omit *unnecessary* dict lookups. Whether or not the lookup is unnecessary is difficult to tell if the dictionary is a dict subtype. It might be relevant to some users - for example, I meant to implement expression evaluation in the context of a CORBA NamingService::NamingContext a few years ago (the application could not be implemented because exec would not accept non-dict objects at the time). In this context, the namespace for the exec would be a live object, and there would be no guarantee that a read gives you back what a write just set (e.g. due to interleaving with other activities, or due to a custom implementation of NamingContext). All that said, I do believe that the change in semantics is minor, and should not stop the patch. All I want is that it is understood that there *is* a change in semantics. I'm personally more worried about the change in the byte code format, because it means that the next release won't be able to share byte code files with the current release *again*. This is for python-dev discussion, though. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-21 17:12 Message: Logged In: YES user_id=80475 Thanks for looking at the patch. Added patch to Doc/lib/libdis.tex. Added a comment and assertion documenting how the pattern recognizer stays within the string boundaries (it uses RETURN_VALUE as a guard). The transformations are invariant with respect to the preconditions and postconditions (in terms of stack effect and dictionary state). They change the how without changing the what. In this case, saving the unnecessary dictionary lookup is the point of the transformation. The code generator is free to produce STORE x LOAD x or the equivalent DUP STORE x. This is the lead example in Skip's paper on the subject: http://www.foretec.com/python/workshops/1998-11/proceedings/papers/montanaro/montanaro.html The pattern is generated by code in the form: x = f() y = x + 1 The postcondition states of x and y remain unchanged by the transformation. The other peepholer transforms work the same way (i.e. the condition jump to conditional jump simplification results in fewer comparisons because the results of identical comparisons are expected to be the same). There is a limit to this. For instance, x * 2 cannot be replaced with x + x because it results in a different method being called. The multiply call is guaranteed. This contrasts with the incidental getitem call in x=f(); y=x+1 where the compiler guarantees the call to f() and the final states of x and y. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-21 00:24 Message: Logged In: YES user_id=21627 Please add a patch to Doc/lib/libdis.tex. Also, it would be good if a comment explained why these (all of the peephole optimizations) can never read over the end of the string. It appears that this patch introduces a change in semantics for STORE_NAME if f_locals is not a dictionary - with the patch, the dictionary-like object will see one less call to GetItem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144842&group_id=5470 From noreply at sourceforge.net Tue Feb 22 00:00:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 22 00:00:28 2005 Subject: [Patches] [ python-Patches-1144842 ] Replace store/load pair with a single new opcode Message-ID: Patches item #1144842, was opened at 2005-02-20 10:41 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144842&group_id=5470 Category: Parser/Compiler Group: Python 2.5 >Status: Pending >Resolution: Remind Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Raymond Hettinger (rhettinger) Summary: Replace store/load pair with a single new opcode Initial Comment: The folds the two steps into a new opcode. In the case of store_name/load_name, it saves one three byte instruction, a trip around the eval-loop, two stack mutations, a incref/decref pair, a dictionary lookup, and an error check (for the lookup). While it acts like a dup followed by a store, it is implemented more simply as a store that doesn?t pop the stack. The transformation is broadly applicable and occurs thousands of times in the standard library and test suite. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-21 18:00 Message: Logged In: YES user_id=80475 Marking this as deferred. By itself, there is not enough gain to warrant losing pyc sharing with Py2.4. If something else changes the bytecode, will put this in as the issue will be moot. Out of curiousity, would the COBRA naming service have needed the getitem immediately following a setitem to the same key? Would it have returned something different than the value just set? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-21 17:37 Message: Logged In: YES user_id=21627 As for the semantic change: I believe (without testing) that the patch will change the output of the attached script (a.py). Now, I agree that this is almost the point of the patch, but it is still a change in observable behaviour. I say almost, because the point of the patch is to omit *unnecessary* dict lookups. Whether or not the lookup is unnecessary is difficult to tell if the dictionary is a dict subtype. It might be relevant to some users - for example, I meant to implement expression evaluation in the context of a CORBA NamingService::NamingContext a few years ago (the application could not be implemented because exec would not accept non-dict objects at the time). In this context, the namespace for the exec would be a live object, and there would be no guarantee that a read gives you back what a write just set (e.g. due to interleaving with other activities, or due to a custom implementation of NamingContext). All that said, I do believe that the change in semantics is minor, and should not stop the patch. All I want is that it is understood that there *is* a change in semantics. I'm personally more worried about the change in the byte code format, because it means that the next release won't be able to share byte code files with the current release *again*. This is for python-dev discussion, though. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-21 11:12 Message: Logged In: YES user_id=80475 Thanks for looking at the patch. Added patch to Doc/lib/libdis.tex. Added a comment and assertion documenting how the pattern recognizer stays within the string boundaries (it uses RETURN_VALUE as a guard). The transformations are invariant with respect to the preconditions and postconditions (in terms of stack effect and dictionary state). They change the how without changing the what. In this case, saving the unnecessary dictionary lookup is the point of the transformation. The code generator is free to produce STORE x LOAD x or the equivalent DUP STORE x. This is the lead example in Skip's paper on the subject: http://www.foretec.com/python/workshops/1998-11/proceedings/papers/montanaro/montanaro.html The pattern is generated by code in the form: x = f() y = x + 1 The postcondition states of x and y remain unchanged by the transformation. The other peepholer transforms work the same way (i.e. the condition jump to conditional jump simplification results in fewer comparisons because the results of identical comparisons are expected to be the same). There is a limit to this. For instance, x * 2 cannot be replaced with x + x because it results in a different method being called. The multiply call is guaranteed. This contrasts with the incidental getitem call in x=f(); y=x+1 where the compiler guarantees the call to f() and the final states of x and y. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-20 18:24 Message: Logged In: YES user_id=21627 Please add a patch to Doc/lib/libdis.tex. Also, it would be good if a comment explained why these (all of the peephole optimizations) can never read over the end of the string. It appears that this patch introduces a change in semantics for STORE_NAME if f_locals is not a dictionary - with the patch, the dictionary-like object will see one less call to GetItem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144842&group_id=5470 From noreply at sourceforge.net Tue Feb 22 00:07:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 22 00:07:59 2005 Subject: [Patches] [ python-Patches-1144842 ] Replace store/load pair with a single new opcode Message-ID: Patches item #1144842, was opened at 2005-02-20 16:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144842&group_id=5470 Category: Parser/Compiler Group: Python 2.5 Status: Pending Resolution: Remind Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Replace store/load pair with a single new opcode Initial Comment: The folds the two steps into a new opcode. In the case of store_name/load_name, it saves one three byte instruction, a trip around the eval-loop, two stack mutations, a incref/decref pair, a dictionary lookup, and an error check (for the lookup). While it acts like a dup followed by a store, it is implemented more simply as a store that doesn?t pop the stack. The transformation is broadly applicable and occurs thousands of times in the standard library and test suite. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-22 00:07 Message: Logged In: YES user_id=21627 In the specific naming service implementation, it would have been extremely unlikely that you get a different value on reading; out of its own, it would have always returned the same objects. There was a small (but real) chance that a different application interfered (CORBA being a distributed system), in which case you would have read that the value stored by the other application. This would have likely occurred only in overload situations (i.e. when the naming service starts queueing requests from clients) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-22 00:00 Message: Logged In: YES user_id=80475 Marking this as deferred. By itself, there is not enough gain to warrant losing pyc sharing with Py2.4. If something else changes the bytecode, will put this in as the issue will be moot. Out of curiousity, would the COBRA naming service have needed the getitem immediately following a setitem to the same key? Would it have returned something different than the value just set? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-21 23:37 Message: Logged In: YES user_id=21627 As for the semantic change: I believe (without testing) that the patch will change the output of the attached script (a.py). Now, I agree that this is almost the point of the patch, but it is still a change in observable behaviour. I say almost, because the point of the patch is to omit *unnecessary* dict lookups. Whether or not the lookup is unnecessary is difficult to tell if the dictionary is a dict subtype. It might be relevant to some users - for example, I meant to implement expression evaluation in the context of a CORBA NamingService::NamingContext a few years ago (the application could not be implemented because exec would not accept non-dict objects at the time). In this context, the namespace for the exec would be a live object, and there would be no guarantee that a read gives you back what a write just set (e.g. due to interleaving with other activities, or due to a custom implementation of NamingContext). All that said, I do believe that the change in semantics is minor, and should not stop the patch. All I want is that it is understood that there *is* a change in semantics. I'm personally more worried about the change in the byte code format, because it means that the next release won't be able to share byte code files with the current release *again*. This is for python-dev discussion, though. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-21 17:12 Message: Logged In: YES user_id=80475 Thanks for looking at the patch. Added patch to Doc/lib/libdis.tex. Added a comment and assertion documenting how the pattern recognizer stays within the string boundaries (it uses RETURN_VALUE as a guard). The transformations are invariant with respect to the preconditions and postconditions (in terms of stack effect and dictionary state). They change the how without changing the what. In this case, saving the unnecessary dictionary lookup is the point of the transformation. The code generator is free to produce STORE x LOAD x or the equivalent DUP STORE x. This is the lead example in Skip's paper on the subject: http://www.foretec.com/python/workshops/1998-11/proceedings/papers/montanaro/montanaro.html The pattern is generated by code in the form: x = f() y = x + 1 The postcondition states of x and y remain unchanged by the transformation. The other peepholer transforms work the same way (i.e. the condition jump to conditional jump simplification results in fewer comparisons because the results of identical comparisons are expected to be the same). There is a limit to this. For instance, x * 2 cannot be replaced with x + x because it results in a different method being called. The multiply call is guaranteed. This contrasts with the incidental getitem call in x=f(); y=x+1 where the compiler guarantees the call to f() and the final states of x and y. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-21 00:24 Message: Logged In: YES user_id=21627 Please add a patch to Doc/lib/libdis.tex. Also, it would be good if a comment explained why these (all of the peephole optimizations) can never read over the end of the string. It appears that this patch introduces a change in semantics for STORE_NAME if f_locals is not a dictionary - with the patch, the dictionary-like object will see one less call to GetItem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144842&group_id=5470 From noreply at sourceforge.net Wed Feb 23 10:21:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 10:21:51 2005 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 jvr 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: Just van Rossum (jvr) Date: 2005-02-23 10:21 Message: Logged In: YES user_id=92689 That doesn't follow at all. The script email.py will _still_ be found first instead of the email module. Like wrobell, I don't see what this has _anything_ to do with relative vs. absolute imports. While a common newbie gotcha, I don't think it's worth the trouble to try to "fix" this. Recommending "won't fix". ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-16 18:43 Message: Logged In: YES user_id=341410 If you were to make your 'email.py' file contain the following... #!/user/bin/python from __future__ import absolute_import import email print 1 It should import the email package. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-16 18:31 Message: Logged In: YES user_id=387193 But the problem is not with naming of my modules/packages (part about relative import of modules I do understand, of course), but with script naming. For example consider script: #!/usr/bin/python import email print 1 And name the script email.py, then run it, please. Python tries to be too smart (IMHO) and variable sys.path is polluted with directory of email.py script, therefore standard email Python package will not be imported. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-16 17:50 Message: Logged In: YES user_id=341410 If the entirety of PEP 328 made it into Python 2.4 (I don't have an installation of 2.4, so don't know), to import your 'email.py' module, you would use 'from . import email' after enabling the absolute import semantics with 'from __future__ import absolute_import'. You would then import the standard email package with 'import email'. Is this not clear by reading PEP 328? ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-16 15:37 Message: Logged In: YES user_id=387193 I am opening it again to discuss it a little more... Question to Josiah Carlson or anybody who can answer: How PEP 328 is going to solve problem I have described? If I name my script email.py, which will try to import email standard Python package. Then run the script, it will import itself instead of Python package, because directory where email.py is installed is added to sys.path. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2004-10-26 18:42 Message: Logged In: YES user_id=387193 i will not provide the patch for 328, so closing this issue ---------------------------------------------------------------------- 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 Wed Feb 23 11:42:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 11:42:10 2005 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 13:51 Message generated for change (Comment added) made by pmoore 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: Paul Moore (pmoore) Date: 2005-02-23 10:42 Message: Logged In: YES user_id=113328 Another point - given a program which comprises a couple of .py files in the same directory (say main.py and support.py) it would be quite normal (at least for me!) to do "import support" from main.py. This patch would break this - and I'd find it difficult to accept what I'm doing as "a mistake". Fixing this would involve adding something like sys.path.insert(0, os.path.dirname(os.path.abspath(sys.argv[0])) at the top of my main script. I'd hate to try to explain that to a beginner... The use case here seems to be when a script itself has the same name as a standard library module. I'd have to say that this seems a fairly unlikely case - and easy to fix when it happens. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-23 09:21 Message: Logged In: YES user_id=92689 That doesn't follow at all. The script email.py will _still_ be found first instead of the email module. Like wrobell, I don't see what this has _anything_ to do with relative vs. absolute imports. While a common newbie gotcha, I don't think it's worth the trouble to try to "fix" this. Recommending "won't fix". ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-16 17:43 Message: Logged In: YES user_id=341410 If you were to make your 'email.py' file contain the following... #!/user/bin/python from __future__ import absolute_import import email print 1 It should import the email package. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-16 17:31 Message: Logged In: YES user_id=387193 But the problem is not with naming of my modules/packages (part about relative import of modules I do understand, of course), but with script naming. For example consider script: #!/usr/bin/python import email print 1 And name the script email.py, then run it, please. Python tries to be too smart (IMHO) and variable sys.path is polluted with directory of email.py script, therefore standard email Python package will not be imported. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-16 16:50 Message: Logged In: YES user_id=341410 If the entirety of PEP 328 made it into Python 2.4 (I don't have an installation of 2.4, so don't know), to import your 'email.py' module, you would use 'from . import email' after enabling the absolute import semantics with 'from __future__ import absolute_import'. You would then import the standard email package with 'import email'. Is this not clear by reading PEP 328? ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-16 14:37 Message: Logged In: YES user_id=387193 I am opening it again to discuss it a little more... Question to Josiah Carlson or anybody who can answer: How PEP 328 is going to solve problem I have described? If I name my script email.py, which will try to import email standard Python package. Then run the script, it will import itself instead of Python package, because directory where email.py is installed is added to sys.path. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2004-10-26 17:42 Message: Logged In: YES user_id=387193 i will not provide the patch for 328, so closing this issue ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-07 21: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 00: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 16: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 00: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 Wed Feb 23 12:10:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 12:10:48 2005 Subject: [Patches] [ python-Patches-1054967 ] bdist_deb - Debian packager Message-ID: Patches item #1054967, was opened at 2004-10-27 02:48 Message generated for change (Comment added) made by alberanid You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1054967&group_id=5470 Category: Distutils and setup.py Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Sean Reifschneider (jafo) Summary: bdist_deb - Debian packager Initial Comment: Here's a first crack at a bdist_deb. This patch implements two new distutils commands: bdist_deb: Build Debian packages debianize: Create and populate a top-level debian subdirectory. (Essentially dh_make for distutils packages.) There is a slightly detailed README.bdist_deb included in the patches. I'm open to suggestions for improvements and bug-fixes. ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2005-02-23 12:10 Message: Logged In: YES user_id=170840 Sometimes you need to install the same package for many different releases of Python; unfortunately this will fail, because dpkg refuses to override the dummy man page, present in both packages. Would it be a good idea to modify line 453 of dh_make to include pyver in the name of the manpage file? ---------------------------------------------------------------------- Comment By: Marek Kubica (leonidasxiv) Date: 2005-01-11 17:53 Message: Logged In: YES user_id=872713 I was looking a long time for something like this. I really hope seeing this in Python 2.5, although I'm not familiar with Python's development process. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-11-11 17:18 Message: Logged In: YES user_id=45814 Another updated patch set. The only change is a bug fix: when using a hand-build set of debian/* files, dh_make will now deduce the correct Debian revision and build architecture. (Bug reported by Bastian Kleineidam.) Patches, as always are on today's CVS version of distutils. ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2004-11-09 16:39 Message: Logged In: YES user_id=170840 I've created a patch to make your bdist_deb/dh_make commands compatible with Python 1.5.2; it can be found here: http://erlug.linux.it/~da/tmp/distutils-cvs_debpy152-20041109.patch Beware that I've tested it for a very short time, so double check everything (especially the permissions on file/umasks). Moreover, the patch changes also some other files like build_py.py, install_lib.py, bdist_rpm.py, that were not 1.5.2 compatible - these changes are part of another patch I've posted today. HTH. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-11-08 22:38 Message: Logged In: YES user_id=45814 Another updated patch set: As suggested by Bastian Kleineidam, when the source distribution includes it's own debian subdirectory, bdist_deb (rather than just crapping out) will now skip the dh_make stage, and just run debuild. As always, patches on the current CVS version of distutils are attached below. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-11-02 23:20 Message: Logged In: YES user_id=45814 Here's try number three! Changes are mostly fixes for woody. The README.bdist_deb (included in the patch set) enumerates the changes in more detail. (I've bitten the bullet and installed woody on one of my machines, so I'm fairly confident it should work now.) The patches, on todays CVS are, as always, attached below. ==== Note to Davide, Thank you, again, very much for all the testing. A couple of the lintian warnings ('prerm-does-not-remove-usr-doc-link' and 'postinst-does-not-set-usr-doc-link') that are listed in your test suite output are due, I think, to your mixed system. Specifically, I suspect you've got the woody version of lintian (which wants to see symlinks from /usr/doc/ to /usr/share/doc/), but a later version of debhelper. (Woody's dh_installdocs (in the debhelper package) automatically generates those links, later versions don't; /usr/doc has been phased out.) Anyhow, I'm not going to fix those warnings (unless it turns out that you're seeing them on your pure woody system.) On package with python scripts (in /usr/bin) Woody's lintian generates an 'unusual-interpreter' warning which I think is spurious (i.e. it is not a valid warning.) (Lintian 1.20.17 doesn't recognize things like /usr/bin/python2.1 as a valid interpreter --- it seems valid enough to me.) Best Regards, Jeff ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2004-10-30 10:57 Message: Logged In: YES user_id=170840 I've tried the 29/10 patch with my home system (dpkg-dev 1.10, debhelper 4.1.90 and dh-make 0.30) and another "pure woody" system (dpkg-dev 1.9.21, debhelper 4.0.2 and dh-make 0.30). I've used your test suite and some of my personal projects (using both bdist_deb and dh_make); as far as I can tell, it works very well. :-) bdist_deb always worked as expected, producing good debian packages. I've used dh_make and then I've run "dpkg-buildpackage -rfakeroot" and I got some errors (but I'm not sure they depends on your code). Also your test suite produced some failures. Here you can find the output of "dpkg-buildpackage -rfakeroot" and of your tests suite (both were running on my home system): http://erlug.linux.it/~da/tmp/dpkg-buildpackage http://erlug.linux.it/~da/tmp/testsuite Thank you for your great effort! ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-10-29 21:38 Message: Logged In: YES user_id=45814 Thanks for the comments. Here's a second attempt. Changes include: It might work with woody. (I'd appreciate it if you could try again, Davide) 'debianize' command renamed to 'dh_make'. Use debchange to create debian/changelog. This eliminates the need to duplicate debchange's logic to deduce the packagers name and e-mail. A more complete test script. Patches are on today's CVS. ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2004-10-27 16:47 Message: Logged In: YES user_id=170840 I've a woody with some packages backported from sarge (debhelper 4.1.90 and dpkg-dev 1.10). Running python2.3 ./setup.py bdist_deb with some of my projects, I got the error: dpkg-buildpackage: unknown option or argument --check-dirname-level=1 Debian dpkg-buildpackage . Commenting out the "check-dirname-level" and "check-dirname-regex" options in the bdist_deb.py file the script can go on, but it exits with the error: debian/rules:11: *** first argument to `word' function must be greater than 0. Stop. Hope this helps. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2004-10-27 05:44 Message: Logged In: YES user_id=81797 I'm just doing a review of this code. A couple of things: There's been some concern expressed about get_default_maintainer. Namely, that if debchange changes it's algorithm, it won't be reflected in this code. It seems like one possible way around that would be to build a directory with a "debian" directory under it, a fake "changelog", and then call debchange to write the data out, and parse it. Too bad there's not a direct hook into debchange to get that information. Can _formatdate, if email doesn't exist, use rfc822.formatdate()? Ditto for _parseaddr? It looks pretty good. However, when trying to build a .deb of my jotweb2 package, it's failing with: [...] dh_testdir dh_testroot dh_installchangelogs- dh_installdocs cp: cannot stat `doc': No such file or directory dh_installdocs: command returned error code 256 [...] I'm not sure exactly why. I do have a "doc" directory in my main package directory, but I don't reference to it in my setup.py or MANIFEST. Adding it to the MANIFEST doesn't seem to help this. Sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1054967&group_id=5470 From noreply at sourceforge.net Wed Feb 23 14:11:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 14:11:29 2005 Subject: [Patches] [ python-Patches-1144504 ] Add IEEE Float support to wave.py Message-ID: Patches item #1144504, was opened at 2005-02-19 15:02 Message generated for change (Comment added) made by mcherm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144504&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ben Schwartz (bensatmit_edu) Assigned to: Nobody/Anonymous (nobody) Summary: Add IEEE Float support to wave.py Initial Comment: IEEE Float .wav files have almost identical structure to standard PCM .wav files. Currently, wave.py gives an unknown format error when attempting to read IEEE Float .wav files. This patch causes wave.py to read those files properly. No changes were made to wave_write, only wave_read. ---------------------------------------------------------------------- >Comment By: Michael Chermside (mcherm) Date: 2005-02-23 08:11 Message: Logged In: YES user_id=99874 I don't know anything about the .wav format, but the patch is particularly inoffensive... it simply allows a second format constant in the WAVE header without raising an error. I recomend applying the patch as soon as someone else who DOES know the .wav format can confirm that it's being done right. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144504&group_id=5470 From noreply at sourceforge.net Wed Feb 23 14:26:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 14:26:51 2005 Subject: [Patches] [ python-Patches-1141428 ] more __contains__ tests Message-ID: Patches item #1141428, was opened at 2005-02-17 19:42 Message generated for change (Comment added) made by mcherm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1141428&group_id=5470 Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 4 Submitted By: Jim Jewett (jimjjewett) Assigned to: Raymond Hettinger (rhettinger) Summary: more __contains__ tests Initial Comment: Recently, there was a change to speed up __contains__. x in (1, 2, 3) would be compiled as x in frozenset(1, 2, 3). This was backed out, because frozensets raise a typeerror when asked about unhashable objects. These objects *can't* be in the set, but there was concern about supporting objects in which a mutable and an immutable compare equal. So long as that is a requirement, it should be tested. The new test for sequences ensures that they will use __eq__ (and not rely on __hash__) in the future. The change to the rich compare tests is just a comment, pointing out that dicts can rely on __hash__ as well as __eq__. ---------------------------------------------------------------------- >Comment By: Michael Chermside (mcherm) Date: 2005-02-23 08:26 Message: Logged In: YES user_id=99874 In the change to test_richcmp.diff, you should move the period to the end of the sentence. That being said, I'm +1 on applying this patch. I certainly agree that we should add the test since we care about preserving the behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1141428&group_id=5470 From noreply at sourceforge.net Wed Feb 23 15:44:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 15:44:10 2005 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 wrobell 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: wrobell (wrobell) Date: 2005-02-23 15:44 Message: Logged In: YES user_id=387193 I do understand that the patch will not be accepted. :-) That's ok. Too much fight with people's habits for me. :] But, let's see what common script names are forbidden now (among others): array.py, binascii.py, bz2.py, collections.py, crypt.py, datetime.py, math.py, md5.py, mmap.py, parser.py, pwd.py, regex.py, resource.py, select.py, sha.py, syslog.py, time.py, timing.py, timeit.py, binhex.py, calendar.py, cgi.py, chunk.py, cmd.py, code.py, commands.py, compileall.py, compiler.py, copy.py, csv.py, decimal.py... And in the future there can be even more depending on the new modules in Python itself and third party modules (i.e. spread.py, dbus.py, eca.py, etc.). If new module or package appears, then you will have to change your name of the script. I do understand that it is not frequent situation, but we should not to be forced to avoid certain _common_ words for script naming. IMHO, it is a problem and should be fixed. The question is "How?". Maybe page listed below should be discussed (again I think): http://hkn.eecs.berkeley.edu/~dyoo/python/__std__/ I would set Resolution to "Remind" if you agree to discuss it later and fix the problem somehow in the future. If not, then "Won't fix". ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-02-23 11:42 Message: Logged In: YES user_id=113328 Another point - given a program which comprises a couple of .py files in the same directory (say main.py and support.py) it would be quite normal (at least for me!) to do "import support" from main.py. This patch would break this - and I'd find it difficult to accept what I'm doing as "a mistake". Fixing this would involve adding something like sys.path.insert(0, os.path.dirname(os.path.abspath(sys.argv[0])) at the top of my main script. I'd hate to try to explain that to a beginner... The use case here seems to be when a script itself has the same name as a standard library module. I'd have to say that this seems a fairly unlikely case - and easy to fix when it happens. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-23 10:21 Message: Logged In: YES user_id=92689 That doesn't follow at all. The script email.py will _still_ be found first instead of the email module. Like wrobell, I don't see what this has _anything_ to do with relative vs. absolute imports. While a common newbie gotcha, I don't think it's worth the trouble to try to "fix" this. Recommending "won't fix". ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-16 18:43 Message: Logged In: YES user_id=341410 If you were to make your 'email.py' file contain the following... #!/user/bin/python from __future__ import absolute_import import email print 1 It should import the email package. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-16 18:31 Message: Logged In: YES user_id=387193 But the problem is not with naming of my modules/packages (part about relative import of modules I do understand, of course), but with script naming. For example consider script: #!/usr/bin/python import email print 1 And name the script email.py, then run it, please. Python tries to be too smart (IMHO) and variable sys.path is polluted with directory of email.py script, therefore standard email Python package will not be imported. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-16 17:50 Message: Logged In: YES user_id=341410 If the entirety of PEP 328 made it into Python 2.4 (I don't have an installation of 2.4, so don't know), to import your 'email.py' module, you would use 'from . import email' after enabling the absolute import semantics with 'from __future__ import absolute_import'. You would then import the standard email package with 'import email'. Is this not clear by reading PEP 328? ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-16 15:37 Message: Logged In: YES user_id=387193 I am opening it again to discuss it a little more... Question to Josiah Carlson or anybody who can answer: How PEP 328 is going to solve problem I have described? If I name my script email.py, which will try to import email standard Python package. Then run the script, it will import itself instead of Python package, because directory where email.py is installed is added to sys.path. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2004-10-26 18:42 Message: Logged In: YES user_id=387193 i will not provide the patch for 328, so closing this issue ---------------------------------------------------------------------- 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 Wed Feb 23 18:02:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 18:02:49 2005 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 05:51 Message generated for change (Comment added) made by josiahcarlson 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: Josiah Carlson (josiahcarlson) Date: 2005-02-23 09:02 Message: Logged In: YES user_id=341410 I'm sorry, the bit I quoted shouldn't go into your email.py file, it should go into the module that wants to import Python's email package, and not your email.py module (my brain was fuzzy on the 16th). Standard library name masking is exactly what the absolute imports PEP was seeking to fix. You use "from __future__ import absolute_imports", and from then on, you can do relative imports via "import .modulename" (note the leading period), and stdlib imports via "import modulename" (note the lack of a leading period). It also allows you to go higher up in paths via additional leading periods. This /does/ in fact fix the problem mentioned, at the cost of having to change the import lines because of the changed import semantic. This allows users to choose names that they desire, even if it mirrors a standard library module name. It also doesn't require any patches. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-23 06:44 Message: Logged In: YES user_id=387193 I do understand that the patch will not be accepted. :-) That's ok. Too much fight with people's habits for me. :] But, let's see what common script names are forbidden now (among others): array.py, binascii.py, bz2.py, collections.py, crypt.py, datetime.py, math.py, md5.py, mmap.py, parser.py, pwd.py, regex.py, resource.py, select.py, sha.py, syslog.py, time.py, timing.py, timeit.py, binhex.py, calendar.py, cgi.py, chunk.py, cmd.py, code.py, commands.py, compileall.py, compiler.py, copy.py, csv.py, decimal.py... And in the future there can be even more depending on the new modules in Python itself and third party modules (i.e. spread.py, dbus.py, eca.py, etc.). If new module or package appears, then you will have to change your name of the script. I do understand that it is not frequent situation, but we should not to be forced to avoid certain _common_ words for script naming. IMHO, it is a problem and should be fixed. The question is "How?". Maybe page listed below should be discussed (again I think): http://hkn.eecs.berkeley.edu/~dyoo/python/__std__/ I would set Resolution to "Remind" if you agree to discuss it later and fix the problem somehow in the future. If not, then "Won't fix". ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-02-23 02:42 Message: Logged In: YES user_id=113328 Another point - given a program which comprises a couple of .py files in the same directory (say main.py and support.py) it would be quite normal (at least for me!) to do "import support" from main.py. This patch would break this - and I'd find it difficult to accept what I'm doing as "a mistake". Fixing this would involve adding something like sys.path.insert(0, os.path.dirname(os.path.abspath(sys.argv[0])) at the top of my main script. I'd hate to try to explain that to a beginner... The use case here seems to be when a script itself has the same name as a standard library module. I'd have to say that this seems a fairly unlikely case - and easy to fix when it happens. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-23 01:21 Message: Logged In: YES user_id=92689 That doesn't follow at all. The script email.py will _still_ be found first instead of the email module. Like wrobell, I don't see what this has _anything_ to do with relative vs. absolute imports. While a common newbie gotcha, I don't think it's worth the trouble to try to "fix" this. Recommending "won't fix". ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-16 09:43 Message: Logged In: YES user_id=341410 If you were to make your 'email.py' file contain the following... #!/user/bin/python from __future__ import absolute_import import email print 1 It should import the email package. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-16 09:31 Message: Logged In: YES user_id=387193 But the problem is not with naming of my modules/packages (part about relative import of modules I do understand, of course), but with script naming. For example consider script: #!/usr/bin/python import email print 1 And name the script email.py, then run it, please. Python tries to be too smart (IMHO) and variable sys.path is polluted with directory of email.py script, therefore standard email Python package will not be imported. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-16 08:50 Message: Logged In: YES user_id=341410 If the entirety of PEP 328 made it into Python 2.4 (I don't have an installation of 2.4, so don't know), to import your 'email.py' module, you would use 'from . import email' after enabling the absolute import semantics with 'from __future__ import absolute_import'. You would then import the standard email package with 'import email'. Is this not clear by reading PEP 328? ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-16 06:37 Message: Logged In: YES user_id=387193 I am opening it again to discuss it a little more... Question to Josiah Carlson or anybody who can answer: How PEP 328 is going to solve problem I have described? If I name my script email.py, which will try to import email standard Python package. Then run the script, it will import itself instead of Python package, because directory where email.py is installed is added to sys.path. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2004-10-26 09:42 Message: Logged In: YES user_id=387193 i will not provide the patch for 328, so closing this issue ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-07 13: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-20 16: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 08: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-07 16: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 Wed Feb 23 18:43:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 18:43:56 2005 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 jvr 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: Just van Rossum (jvr) Date: 2005-02-23 18:43 Message: Logged In: YES user_id=92689 > Standard library name masking is exactly what > the absolute imports PEP was seeking to fix Only in the context of submodule imports within packages. Which is _not_ at _all_ what is being described here. There is a main _script_ called email.py which wants to import the email module (that email happens to be a package is not relevant). There is _no_ relative import going on here, it just so happens that the script's parent dir is in sys.path before the std lib. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-23 18:02 Message: Logged In: YES user_id=341410 I'm sorry, the bit I quoted shouldn't go into your email.py file, it should go into the module that wants to import Python's email package, and not your email.py module (my brain was fuzzy on the 16th). Standard library name masking is exactly what the absolute imports PEP was seeking to fix. You use "from __future__ import absolute_imports", and from then on, you can do relative imports via "import .modulename" (note the leading period), and stdlib imports via "import modulename" (note the lack of a leading period). It also allows you to go higher up in paths via additional leading periods. This /does/ in fact fix the problem mentioned, at the cost of having to change the import lines because of the changed import semantic. This allows users to choose names that they desire, even if it mirrors a standard library module name. It also doesn't require any patches. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-23 15:44 Message: Logged In: YES user_id=387193 I do understand that the patch will not be accepted. :-) That's ok. Too much fight with people's habits for me. :] But, let's see what common script names are forbidden now (among others): array.py, binascii.py, bz2.py, collections.py, crypt.py, datetime.py, math.py, md5.py, mmap.py, parser.py, pwd.py, regex.py, resource.py, select.py, sha.py, syslog.py, time.py, timing.py, timeit.py, binhex.py, calendar.py, cgi.py, chunk.py, cmd.py, code.py, commands.py, compileall.py, compiler.py, copy.py, csv.py, decimal.py... And in the future there can be even more depending on the new modules in Python itself and third party modules (i.e. spread.py, dbus.py, eca.py, etc.). If new module or package appears, then you will have to change your name of the script. I do understand that it is not frequent situation, but we should not to be forced to avoid certain _common_ words for script naming. IMHO, it is a problem and should be fixed. The question is "How?". Maybe page listed below should be discussed (again I think): http://hkn.eecs.berkeley.edu/~dyoo/python/__std__/ I would set Resolution to "Remind" if you agree to discuss it later and fix the problem somehow in the future. If not, then "Won't fix". ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-02-23 11:42 Message: Logged In: YES user_id=113328 Another point - given a program which comprises a couple of .py files in the same directory (say main.py and support.py) it would be quite normal (at least for me!) to do "import support" from main.py. This patch would break this - and I'd find it difficult to accept what I'm doing as "a mistake". Fixing this would involve adding something like sys.path.insert(0, os.path.dirname(os.path.abspath(sys.argv[0])) at the top of my main script. I'd hate to try to explain that to a beginner... The use case here seems to be when a script itself has the same name as a standard library module. I'd have to say that this seems a fairly unlikely case - and easy to fix when it happens. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-23 10:21 Message: Logged In: YES user_id=92689 That doesn't follow at all. The script email.py will _still_ be found first instead of the email module. Like wrobell, I don't see what this has _anything_ to do with relative vs. absolute imports. While a common newbie gotcha, I don't think it's worth the trouble to try to "fix" this. Recommending "won't fix". ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-16 18:43 Message: Logged In: YES user_id=341410 If you were to make your 'email.py' file contain the following... #!/user/bin/python from __future__ import absolute_import import email print 1 It should import the email package. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-16 18:31 Message: Logged In: YES user_id=387193 But the problem is not with naming of my modules/packages (part about relative import of modules I do understand, of course), but with script naming. For example consider script: #!/usr/bin/python import email print 1 And name the script email.py, then run it, please. Python tries to be too smart (IMHO) and variable sys.path is polluted with directory of email.py script, therefore standard email Python package will not be imported. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-16 17:50 Message: Logged In: YES user_id=341410 If the entirety of PEP 328 made it into Python 2.4 (I don't have an installation of 2.4, so don't know), to import your 'email.py' module, you would use 'from . import email' after enabling the absolute import semantics with 'from __future__ import absolute_import'. You would then import the standard email package with 'import email'. Is this not clear by reading PEP 328? ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-16 15:37 Message: Logged In: YES user_id=387193 I am opening it again to discuss it a little more... Question to Josiah Carlson or anybody who can answer: How PEP 328 is going to solve problem I have described? If I name my script email.py, which will try to import email standard Python package. Then run the script, it will import itself instead of Python package, because directory where email.py is installed is added to sys.path. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2004-10-26 18:42 Message: Logged In: YES user_id=387193 i will not provide the patch for 328, so closing this issue ---------------------------------------------------------------------- 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 Wed Feb 23 18:52:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 18:52:05 2005 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 05:51 Message generated for change (Comment added) made by josiahcarlson 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: Josiah Carlson (josiahcarlson) Date: 2005-02-23 09:52 Message: Logged In: YES user_id=341410 Absolute imports will also fix that. A bare "from __future__ import absolute_imports;import email" will import the email package, at the cost of changing the semantics of relative imports. What is the problem? Why cannot it be used? What in this entire problem is not solved by absolute imports with its changed import semantic that already exists in Python 2.4? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-23 09:43 Message: Logged In: YES user_id=92689 > Standard library name masking is exactly what > the absolute imports PEP was seeking to fix Only in the context of submodule imports within packages. Which is _not_ at _all_ what is being described here. There is a main _script_ called email.py which wants to import the email module (that email happens to be a package is not relevant). There is _no_ relative import going on here, it just so happens that the script's parent dir is in sys.path before the std lib. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-23 09:02 Message: Logged In: YES user_id=341410 I'm sorry, the bit I quoted shouldn't go into your email.py file, it should go into the module that wants to import Python's email package, and not your email.py module (my brain was fuzzy on the 16th). Standard library name masking is exactly what the absolute imports PEP was seeking to fix. You use "from __future__ import absolute_imports", and from then on, you can do relative imports via "import .modulename" (note the leading period), and stdlib imports via "import modulename" (note the lack of a leading period). It also allows you to go higher up in paths via additional leading periods. This /does/ in fact fix the problem mentioned, at the cost of having to change the import lines because of the changed import semantic. This allows users to choose names that they desire, even if it mirrors a standard library module name. It also doesn't require any patches. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-23 06:44 Message: Logged In: YES user_id=387193 I do understand that the patch will not be accepted. :-) That's ok. Too much fight with people's habits for me. :] But, let's see what common script names are forbidden now (among others): array.py, binascii.py, bz2.py, collections.py, crypt.py, datetime.py, math.py, md5.py, mmap.py, parser.py, pwd.py, regex.py, resource.py, select.py, sha.py, syslog.py, time.py, timing.py, timeit.py, binhex.py, calendar.py, cgi.py, chunk.py, cmd.py, code.py, commands.py, compileall.py, compiler.py, copy.py, csv.py, decimal.py... And in the future there can be even more depending on the new modules in Python itself and third party modules (i.e. spread.py, dbus.py, eca.py, etc.). If new module or package appears, then you will have to change your name of the script. I do understand that it is not frequent situation, but we should not to be forced to avoid certain _common_ words for script naming. IMHO, it is a problem and should be fixed. The question is "How?". Maybe page listed below should be discussed (again I think): http://hkn.eecs.berkeley.edu/~dyoo/python/__std__/ I would set Resolution to "Remind" if you agree to discuss it later and fix the problem somehow in the future. If not, then "Won't fix". ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-02-23 02:42 Message: Logged In: YES user_id=113328 Another point - given a program which comprises a couple of .py files in the same directory (say main.py and support.py) it would be quite normal (at least for me!) to do "import support" from main.py. This patch would break this - and I'd find it difficult to accept what I'm doing as "a mistake". Fixing this would involve adding something like sys.path.insert(0, os.path.dirname(os.path.abspath(sys.argv[0])) at the top of my main script. I'd hate to try to explain that to a beginner... The use case here seems to be when a script itself has the same name as a standard library module. I'd have to say that this seems a fairly unlikely case - and easy to fix when it happens. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-23 01:21 Message: Logged In: YES user_id=92689 That doesn't follow at all. The script email.py will _still_ be found first instead of the email module. Like wrobell, I don't see what this has _anything_ to do with relative vs. absolute imports. While a common newbie gotcha, I don't think it's worth the trouble to try to "fix" this. Recommending "won't fix". ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-16 09:43 Message: Logged In: YES user_id=341410 If you were to make your 'email.py' file contain the following... #!/user/bin/python from __future__ import absolute_import import email print 1 It should import the email package. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-16 09:31 Message: Logged In: YES user_id=387193 But the problem is not with naming of my modules/packages (part about relative import of modules I do understand, of course), but with script naming. For example consider script: #!/usr/bin/python import email print 1 And name the script email.py, then run it, please. Python tries to be too smart (IMHO) and variable sys.path is polluted with directory of email.py script, therefore standard email Python package will not be imported. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-16 08:50 Message: Logged In: YES user_id=341410 If the entirety of PEP 328 made it into Python 2.4 (I don't have an installation of 2.4, so don't know), to import your 'email.py' module, you would use 'from . import email' after enabling the absolute import semantics with 'from __future__ import absolute_import'. You would then import the standard email package with 'import email'. Is this not clear by reading PEP 328? ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-16 06:37 Message: Logged In: YES user_id=387193 I am opening it again to discuss it a little more... Question to Josiah Carlson or anybody who can answer: How PEP 328 is going to solve problem I have described? If I name my script email.py, which will try to import email standard Python package. Then run the script, it will import itself instead of Python package, because directory where email.py is installed is added to sys.path. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2004-10-26 09:42 Message: Logged In: YES user_id=387193 i will not provide the patch for 328, so closing this issue ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-07 13: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-20 16: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 08: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-07 16: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 Wed Feb 23 19:27:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 19:27:03 2005 Subject: [Patches] [ python-Patches-547176 ] rlcompleter does not expand on [ ] Message-ID: Patches item #547176, was opened at 2002-04-22 19:39 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=547176&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jaco Schieke (schiekjd) Assigned to: Nobody/Anonymous (nobody) Summary: rlcompleter does not expand on [ ] Initial Comment: A thread on comp.lang.python details the problem: http://groups.google.com/groups? hl=en&threadm=b5ddd682.0204180902.2866a9c0% 40posting.google.com&rnum=1&prev=/groups%3Fhl%3Den% 26selm%3Db5ddd682.0204180902.2866a9c0% 2540posting.google.com rlcompleter.py does not expand correctly on something like: >>> sim[0].<tab> since m = re.match(r"(\w+(\.\w+)*)\.(\w*)", text) does not allow for brackets in the match. I propose: m = re.match(r"([\w\[\]]+(\.[\w\[\]]+)*)\.(\w*)", text) to fix this on line 127 in cvs version 1.11 ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-02-23 19:27 Message: Logged In: YES user_id=1188172 As the other commentors point out, this easily leads to execution of arbitrary code via __getitem__, which is IMHO a too big side effect of completing (though IPython does this). Recommend reject. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-17 04:02 Message: Logged In: YES user_id=357491 Making this a patch since one is included. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-04 21:26 Message: Logged In: YES user_id=670441 This isn't really a bug, as (at least currently) this behavior is mentioned in the documentation for rlcompleter (at least it's in the docstring). The reason a[0].<tab> isn't completed is that we want to avoid executing arbitrary code. The current completion mechanism is already a bit dangerous as an object's getattr could be called to execute code with unknown side effects while completing. It just seems to dangerous to allow indexing, as lots of objects use this for their own purposes. If this behavior is determined desirable despite the danger, someone with commit privileges should say so, and then someone can submit a patch (I could do it). Probably this bug should just be closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=547176&group_id=5470 From noreply at sourceforge.net Wed Feb 23 19:28:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 19:28:16 2005 Subject: [Patches] [ python-Patches-645894 ] better timer resolution for profile.py Message-ID: Patches item #645894, was opened at 2002-11-30 01:17 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645894&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: John-Mark Gurney (jmg) Assigned to: Nobody/Anonymous (nobody) Summary: better timer resolution for profile.py Initial Comment: On some platforms time.clock() does not return a high resolution counter. On FreeBSD, it's resolution is only 1/128th of a second. In order to get microsecond accuracy, the getrusage syscall from resource needs to be used. Attached is a patch that uses getrusage from the resource library in preference of os.clock. This was done on behalf of Vernier Networks, Inc. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-02-23 19:28 Message: Logged In: YES user_id=1188172 If this leads to better resolution on FreeBSD, it seems like a good idea. However, if you don't know about other OS, what about restricting the patch to FreeBSD? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-06 22:28 Message: Logged In: YES user_id=357491 Is there any possibility that using this could lead to worse timing under another OS? And I assume this is still an issue under FreeBSD 5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645894&group_id=5470 From noreply at sourceforge.net Wed Feb 23 19:29:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 19:29:11 2005 Subject: [Patches] [ python-Patches-697613 ] fix bug #670311: sys.exit and PYTHONINSPECT Message-ID: Patches item #697613, was opened at 2003-03-05 00:24 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=697613&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Nobody/Anonymous (nobody) Summary: fix bug #670311: sys.exit and PYTHONINSPECT Initial Comment: So we want to stop SystemExit from causing an actual exit() when using python -i. This patch introduces two new API calls, PyRun_BlockSysExit and PyRun_UnblockSysExit, to set a flag toavoid the exit() call in PyErr_PrintEx. There are several other ways to fix this bug, but I think all of the others I came up with would cause more backwards compatibilty problems and/or be a lot more work. Some possibilities, if anyone is interested, would be: 1) Add a new PyCompilerFlags flag This seems a bit ugly, as it's not really a "compile flag". 2) Add some special run routines that block the exit. 3) Add another parameter to existing run routines. 4) Change PyErr_PrintEx so it doesn't exit when printing a SystemError, instead having the run routines responsible for exiting when catching that exception. What do you think? Is my patch good enough, or would you like something else? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-02-23 19:29 Message: Logged In: YES user_id=1188172 While it works for me, I am not sure whether this is too much overhead for fixing a glitch no one else complained about. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=697613&group_id=5470 From noreply at sourceforge.net Wed Feb 23 19:30:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 19:30:25 2005 Subject: [Patches] [ python-Patches-802188 ] better parser error message for non-EOL following line cont. Message-ID: Patches item #802188, was opened at 2003-09-08 02:03 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=802188&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mathieu Fenniak (laotzu0) Assigned to: Nobody/Anonymous (nobody) Summary: better parser error message for non-EOL following line cont. Initial Comment: This small patch adds a specific error message for when a line continuation character (\) is followed by something other than a newline. If the character following the \ is whitespace, it can be difficult to see why it is an 'invalid token' as the error message used to say. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-02-23 19:30 Message: Logged In: YES user_id=1188172 While this may be helpful when the invalid token is whitespace, Python usually shows the exact location of the invalid token, so you can examine this line and find the error. On the other hand, the patch is no big deal, so if a specific error message is welcome, it may as well be applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=802188&group_id=5470 From noreply at sourceforge.net Wed Feb 23 19:31:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 19:31:36 2005 Subject: [Patches] [ python-Patches-749830 ] allow UNIX mmap size to default to current file size Message-ID: Patches item #749830, was opened at 2003-06-06 00:02 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=749830&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Boedicker (mboedick) Assigned to: Nobody/Anonymous (nobody) Summary: allow UNIX mmap size to default to current file size Initial Comment: This patch makes the UNIX mmap behave like the Windows mmap in that if you pass 0 as the mmap size, the map size will default to the current length of the file being mmapped. This allows avoids a call to os.stat if you want to map the entire file. It also makes code using this feature of the Windows mmap to be portable to UNIX. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-02-23 19:31 Message: Logged In: YES user_id=1188172 see new patch #1144555 which applies cleanly on today's CVS HEAD. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-06-23 15:10 Message: Logged In: YES user_id=250749 Tested on FreeBSD 4.8 & 5.1 - updated test_mmap passes. I don't have any mmap reliant code to check more thoroughly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=749830&group_id=5470 From noreply at sourceforge.net Wed Feb 23 19:32:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 19:32:40 2005 Subject: [Patches] [ python-Patches-751943 ] cgitb: make more usable for 'binary-only' software Message-ID: Patches item #751943, was opened at 2003-06-10 16:31 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751943&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Rob W.W. Hooft (hooft) Assigned to: Nobody/Anonymous (nobody) Summary: cgitb: make more usable for 'binary-only' software Initial Comment: I am abusing cgitb to show a traceback window for a GUI application in Qt. In such a case, the source code to the program is not always available. The stack trace is anyway useful to be submitted to the developers of the code. I attach a patch that should add some info to the HTML traceback made by cgitb in case the source file is not available. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-02-23 19:32 Message: Logged In: YES user_id=1188172 see new patch #1144549 which applies on today's CVS HEAD. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-19 09:46 Message: Logged In: YES user_id=21627 Is that really generating a URL of "file://?"? It should not do that; instead, I think it should not generate a hyperlink for the file at all. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751943&group_id=5470 From noreply at sourceforge.net Wed Feb 23 19:53:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 19:53:42 2005 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 13:51 Message generated for change (Comment added) made by mwh 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: Michael Hudson (mwh) Date: 2005-02-23 18:53 Message: Logged In: YES user_id=6656 > Absolute imports will also fix that. No it won't! The directory containing email.py is on sys.path, at the front. So "import email" will find it. > What in this entire problem is not solved by absolute > imports with its changed import semantic that already exists > in Python 2.4? Nothing at all is solved by a change that isn't in Python 2.4! I still think this bug should be closed won't fix. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-23 17:52 Message: Logged In: YES user_id=341410 Absolute imports will also fix that. A bare "from __future__ import absolute_imports;import email" will import the email package, at the cost of changing the semantics of relative imports. What is the problem? Why cannot it be used? What in this entire problem is not solved by absolute imports with its changed import semantic that already exists in Python 2.4? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-23 17:43 Message: Logged In: YES user_id=92689 > Standard library name masking is exactly what > the absolute imports PEP was seeking to fix Only in the context of submodule imports within packages. Which is _not_ at _all_ what is being described here. There is a main _script_ called email.py which wants to import the email module (that email happens to be a package is not relevant). There is _no_ relative import going on here, it just so happens that the script's parent dir is in sys.path before the std lib. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-23 17:02 Message: Logged In: YES user_id=341410 I'm sorry, the bit I quoted shouldn't go into your email.py file, it should go into the module that wants to import Python's email package, and not your email.py module (my brain was fuzzy on the 16th). Standard library name masking is exactly what the absolute imports PEP was seeking to fix. You use "from __future__ import absolute_imports", and from then on, you can do relative imports via "import .modulename" (note the leading period), and stdlib imports via "import modulename" (note the lack of a leading period). It also allows you to go higher up in paths via additional leading periods. This /does/ in fact fix the problem mentioned, at the cost of having to change the import lines because of the changed import semantic. This allows users to choose names that they desire, even if it mirrors a standard library module name. It also doesn't require any patches. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-23 14:44 Message: Logged In: YES user_id=387193 I do understand that the patch will not be accepted. :-) That's ok. Too much fight with people's habits for me. :] But, let's see what common script names are forbidden now (among others): array.py, binascii.py, bz2.py, collections.py, crypt.py, datetime.py, math.py, md5.py, mmap.py, parser.py, pwd.py, regex.py, resource.py, select.py, sha.py, syslog.py, time.py, timing.py, timeit.py, binhex.py, calendar.py, cgi.py, chunk.py, cmd.py, code.py, commands.py, compileall.py, compiler.py, copy.py, csv.py, decimal.py... And in the future there can be even more depending on the new modules in Python itself and third party modules (i.e. spread.py, dbus.py, eca.py, etc.). If new module or package appears, then you will have to change your name of the script. I do understand that it is not frequent situation, but we should not to be forced to avoid certain _common_ words for script naming. IMHO, it is a problem and should be fixed. The question is "How?". Maybe page listed below should be discussed (again I think): http://hkn.eecs.berkeley.edu/~dyoo/python/__std__/ I would set Resolution to "Remind" if you agree to discuss it later and fix the problem somehow in the future. If not, then "Won't fix". ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-02-23 10:42 Message: Logged In: YES user_id=113328 Another point - given a program which comprises a couple of .py files in the same directory (say main.py and support.py) it would be quite normal (at least for me!) to do "import support" from main.py. This patch would break this - and I'd find it difficult to accept what I'm doing as "a mistake". Fixing this would involve adding something like sys.path.insert(0, os.path.dirname(os.path.abspath(sys.argv[0])) at the top of my main script. I'd hate to try to explain that to a beginner... The use case here seems to be when a script itself has the same name as a standard library module. I'd have to say that this seems a fairly unlikely case - and easy to fix when it happens. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-23 09:21 Message: Logged In: YES user_id=92689 That doesn't follow at all. The script email.py will _still_ be found first instead of the email module. Like wrobell, I don't see what this has _anything_ to do with relative vs. absolute imports. While a common newbie gotcha, I don't think it's worth the trouble to try to "fix" this. Recommending "won't fix". ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-16 17:43 Message: Logged In: YES user_id=341410 If you were to make your 'email.py' file contain the following... #!/user/bin/python from __future__ import absolute_import import email print 1 It should import the email package. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-16 17:31 Message: Logged In: YES user_id=387193 But the problem is not with naming of my modules/packages (part about relative import of modules I do understand, of course), but with script naming. For example consider script: #!/usr/bin/python import email print 1 And name the script email.py, then run it, please. Python tries to be too smart (IMHO) and variable sys.path is polluted with directory of email.py script, therefore standard email Python package will not be imported. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-16 16:50 Message: Logged In: YES user_id=341410 If the entirety of PEP 328 made it into Python 2.4 (I don't have an installation of 2.4, so don't know), to import your 'email.py' module, you would use 'from . import email' after enabling the absolute import semantics with 'from __future__ import absolute_import'. You would then import the standard email package with 'import email'. Is this not clear by reading PEP 328? ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-16 14:37 Message: Logged In: YES user_id=387193 I am opening it again to discuss it a little more... Question to Josiah Carlson or anybody who can answer: How PEP 328 is going to solve problem I have described? If I name my script email.py, which will try to import email standard Python package. Then run the script, it will import itself instead of Python package, because directory where email.py is installed is added to sys.path. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2004-10-26 17:42 Message: Logged In: YES user_id=387193 i will not provide the patch for 328, so closing this issue ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-07 21: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 00: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 16: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 00: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 Wed Feb 23 19:56:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 19:56:07 2005 Subject: [Patches] [ python-Patches-547176 ] rlcompleter does not expand on [ ] Message-ID: Patches item #547176, was opened at 2002-04-22 18:39 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=547176&group_id=5470 Category: None Group: None Status: Open >Resolution: Wont Fix Priority: 5 Submitted By: Jaco Schieke (schiekjd) >Assigned to: Michael Hudson (mwh) Summary: rlcompleter does not expand on [ ] Initial Comment: A thread on comp.lang.python details the problem: http://groups.google.com/groups? hl=en&threadm=b5ddd682.0204180902.2866a9c0% 40posting.google.com&rnum=1&prev=/groups%3Fhl%3Den% 26selm%3Db5ddd682.0204180902.2866a9c0% 2540posting.google.com rlcompleter.py does not expand correctly on something like: >>> sim[0].<tab> since m = re.match(r"(\w+(\.\w+)*)\.(\w*)", text) does not allow for brackets in the match. I propose: m = re.match(r"([\w\[\]]+(\.[\w\[\]]+)*)\.(\w*)", text) to fix this on line 127 in cvs version 1.11 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-02-23 18:56 Message: Logged In: YES user_id=6656 Closing. If you want a richer completion environment you can use IPython or rlcompleter2. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-02-23 18:27 Message: Logged In: YES user_id=1188172 As the other commentors point out, this easily leads to execution of arbitrary code via __getitem__, which is IMHO a too big side effect of completing (though IPython does this). Recommend reject. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-17 03:02 Message: Logged In: YES user_id=357491 Making this a patch since one is included. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-04 20:26 Message: Logged In: YES user_id=670441 This isn't really a bug, as (at least currently) this behavior is mentioned in the documentation for rlcompleter (at least it's in the docstring). The reason a[0].<tab> isn't completed is that we want to avoid executing arbitrary code. The current completion mechanism is already a bit dangerous as an object's getattr could be called to execute code with unknown side effects while completing. It just seems to dangerous to allow indexing, as lots of objects use this for their own purposes. If this behavior is determined desirable despite the danger, someone with commit privileges should say so, and then someone can submit a patch (I could do it). Probably this bug should just be closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=547176&group_id=5470 From noreply at sourceforge.net Wed Feb 23 20:08:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 20:08:47 2005 Subject: [Patches] [ python-Patches-547176 ] rlcompleter does not expand on [ ] Message-ID: Patches item #547176, was opened at 2002-04-22 18:39 Message generated for change (Settings changed) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=547176&group_id=5470 Category: None Group: None >Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Jaco Schieke (schiekjd) Assigned to: Michael Hudson (mwh) Summary: rlcompleter does not expand on [ ] Initial Comment: A thread on comp.lang.python details the problem: http://groups.google.com/groups? hl=en&threadm=b5ddd682.0204180902.2866a9c0% 40posting.google.com&rnum=1&prev=/groups%3Fhl%3Den% 26selm%3Db5ddd682.0204180902.2866a9c0% 2540posting.google.com rlcompleter.py does not expand correctly on something like: >>> sim[0].<tab> since m = re.match(r"(\w+(\.\w+)*)\.(\w*)", text) does not allow for brackets in the match. I propose: m = re.match(r"([\w\[\]]+(\.[\w\[\]]+)*)\.(\w*)", text) to fix this on line 127 in cvs version 1.11 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-23 18:56 Message: Logged In: YES user_id=6656 Closing. If you want a richer completion environment you can use IPython or rlcompleter2. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-02-23 18:27 Message: Logged In: YES user_id=1188172 As the other commentors point out, this easily leads to execution of arbitrary code via __getitem__, which is IMHO a too big side effect of completing (though IPython does this). Recommend reject. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-17 03:02 Message: Logged In: YES user_id=357491 Making this a patch since one is included. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-04 20:26 Message: Logged In: YES user_id=670441 This isn't really a bug, as (at least currently) this behavior is mentioned in the documentation for rlcompleter (at least it's in the docstring). The reason a[0].<tab> isn't completed is that we want to avoid executing arbitrary code. The current completion mechanism is already a bit dangerous as an object's getattr could be called to execute code with unknown side effects while completing. It just seems to dangerous to allow indexing, as lots of objects use this for their own purposes. If this behavior is determined desirable despite the danger, someone with commit privileges should say so, and then someone can submit a patch (I could do it). Probably this bug should just be closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=547176&group_id=5470 From noreply at sourceforge.net Wed Feb 23 20:32:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 20:32:05 2005 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 05:51 Message generated for change (Comment added) made by josiahcarlson 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: Josiah Carlson (josiahcarlson) Date: 2005-02-23 11:32 Message: Logged In: YES user_id=341410 A literal reading of "Guido's Decision" in PEP 328 says that if absolute imports were implemented, then the only thing missing is a future import, and an __init__.py file in the same path as email.py. I finally got around to installing 2.4, and (unfortunately) it seems as though absolute_import is not offered in the __future__ module. What happened? I thought PEP 328 was accepted for inclusion in 2.4. Did someone not have the time to write the import hook? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-23 10:53 Message: Logged In: YES user_id=6656 > Absolute imports will also fix that. No it won't! The directory containing email.py is on sys.path, at the front. So "import email" will find it. > What in this entire problem is not solved by absolute > imports with its changed import semantic that already exists > in Python 2.4? Nothing at all is solved by a change that isn't in Python 2.4! I still think this bug should be closed won't fix. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-23 09:52 Message: Logged In: YES user_id=341410 Absolute imports will also fix that. A bare "from __future__ import absolute_imports;import email" will import the email package, at the cost of changing the semantics of relative imports. What is the problem? Why cannot it be used? What in this entire problem is not solved by absolute imports with its changed import semantic that already exists in Python 2.4? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-23 09:43 Message: Logged In: YES user_id=92689 > Standard library name masking is exactly what > the absolute imports PEP was seeking to fix Only in the context of submodule imports within packages. Which is _not_ at _all_ what is being described here. There is a main _script_ called email.py which wants to import the email module (that email happens to be a package is not relevant). There is _no_ relative import going on here, it just so happens that the script's parent dir is in sys.path before the std lib. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-23 09:02 Message: Logged In: YES user_id=341410 I'm sorry, the bit I quoted shouldn't go into your email.py file, it should go into the module that wants to import Python's email package, and not your email.py module (my brain was fuzzy on the 16th). Standard library name masking is exactly what the absolute imports PEP was seeking to fix. You use "from __future__ import absolute_imports", and from then on, you can do relative imports via "import .modulename" (note the leading period), and stdlib imports via "import modulename" (note the lack of a leading period). It also allows you to go higher up in paths via additional leading periods. This /does/ in fact fix the problem mentioned, at the cost of having to change the import lines because of the changed import semantic. This allows users to choose names that they desire, even if it mirrors a standard library module name. It also doesn't require any patches. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-23 06:44 Message: Logged In: YES user_id=387193 I do understand that the patch will not be accepted. :-) That's ok. Too much fight with people's habits for me. :] But, let's see what common script names are forbidden now (among others): array.py, binascii.py, bz2.py, collections.py, crypt.py, datetime.py, math.py, md5.py, mmap.py, parser.py, pwd.py, regex.py, resource.py, select.py, sha.py, syslog.py, time.py, timing.py, timeit.py, binhex.py, calendar.py, cgi.py, chunk.py, cmd.py, code.py, commands.py, compileall.py, compiler.py, copy.py, csv.py, decimal.py... And in the future there can be even more depending on the new modules in Python itself and third party modules (i.e. spread.py, dbus.py, eca.py, etc.). If new module or package appears, then you will have to change your name of the script. I do understand that it is not frequent situation, but we should not to be forced to avoid certain _common_ words for script naming. IMHO, it is a problem and should be fixed. The question is "How?". Maybe page listed below should be discussed (again I think): http://hkn.eecs.berkeley.edu/~dyoo/python/__std__/ I would set Resolution to "Remind" if you agree to discuss it later and fix the problem somehow in the future. If not, then "Won't fix". ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-02-23 02:42 Message: Logged In: YES user_id=113328 Another point - given a program which comprises a couple of .py files in the same directory (say main.py and support.py) it would be quite normal (at least for me!) to do "import support" from main.py. This patch would break this - and I'd find it difficult to accept what I'm doing as "a mistake". Fixing this would involve adding something like sys.path.insert(0, os.path.dirname(os.path.abspath(sys.argv[0])) at the top of my main script. I'd hate to try to explain that to a beginner... The use case here seems to be when a script itself has the same name as a standard library module. I'd have to say that this seems a fairly unlikely case - and easy to fix when it happens. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-23 01:21 Message: Logged In: YES user_id=92689 That doesn't follow at all. The script email.py will _still_ be found first instead of the email module. Like wrobell, I don't see what this has _anything_ to do with relative vs. absolute imports. While a common newbie gotcha, I don't think it's worth the trouble to try to "fix" this. Recommending "won't fix". ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-16 09:43 Message: Logged In: YES user_id=341410 If you were to make your 'email.py' file contain the following... #!/user/bin/python from __future__ import absolute_import import email print 1 It should import the email package. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-16 09:31 Message: Logged In: YES user_id=387193 But the problem is not with naming of my modules/packages (part about relative import of modules I do understand, of course), but with script naming. For example consider script: #!/usr/bin/python import email print 1 And name the script email.py, then run it, please. Python tries to be too smart (IMHO) and variable sys.path is polluted with directory of email.py script, therefore standard email Python package will not be imported. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-16 08:50 Message: Logged In: YES user_id=341410 If the entirety of PEP 328 made it into Python 2.4 (I don't have an installation of 2.4, so don't know), to import your 'email.py' module, you would use 'from . import email' after enabling the absolute import semantics with 'from __future__ import absolute_import'. You would then import the standard email package with 'import email'. Is this not clear by reading PEP 328? ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-16 06:37 Message: Logged In: YES user_id=387193 I am opening it again to discuss it a little more... Question to Josiah Carlson or anybody who can answer: How PEP 328 is going to solve problem I have described? If I name my script email.py, which will try to import email standard Python package. Then run the script, it will import itself instead of Python package, because directory where email.py is installed is added to sys.path. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2004-10-26 09:42 Message: Logged In: YES user_id=387193 i will not provide the patch for 328, so closing this issue ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-07 13: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-20 16: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 08: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-07 16: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 Wed Feb 23 20:48:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 20:48:18 2005 Subject: [Patches] [ python-Patches-1101726 ] Patch for potential buffer overrun in tokenizer.c Message-ID: Patches item #1101726, was opened at 2005-01-13 16:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1101726&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for potential buffer overrun in tokenizer.c Initial Comment: The fp_readl function in tokenizer.c has a potential buffer overrun; see: www.python.org/sf/1089395 It is also triggered by trying to generate the pycom file for the Excel 11.0 typelib, which is where I ran into it. The attached patch allows successful generation of the Excel file; it also runs the fail.py script from the above report without an access violation. It also doesn't break any of the tests in the regression suite (probably something like fail.py should be added as a test). It is not as efficient as it might be; with a function for determining the number of unicode characters in a utf8 string, you could avoid some memory allocations. Perhaps such a function should be added to unicodeobject.c? And, of course, the patch definitely needs review. I'm especially concerned that my use of tok->decoding_buffer might be violating some kind of assumption that I missed. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-02-23 20:48 Message: Logged In: YES user_id=89016 I think the patch looks good. Staring at it for a while I believe the reference counts are OK. Can you incorporate fail.py into the test suite? ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-01-23 15:26 Message: Logged In: YES user_id=86307 I'm attaching a new patch (tokenizer.c.2.diff), which should be better since it avoids some unnecessary allocations and decoding/encoding. Hopefully, I haven't made any unwarranted assumptions about UTF8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1101726&group_id=5470 From noreply at sourceforge.net Wed Feb 23 20:54:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 20:54:51 2005 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 13:51 Message generated for change (Comment added) made by mwh 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: Michael Hudson (mwh) Date: 2005-02-23 19:54 Message: Logged In: YES user_id=6656 > A literal reading of "Guido's Decision" in PEP 328 says that > if absolute imports were implemented, then the only thing > missing is a future import, and an __init__.py file in the > same path as email.py. I don't think this __init__.py file had been mentioned before. However, even if it is there, THE DIRECTORY CONTAINING email.py IS ON sys.path! What's hard to understand about this? > I finally got around to installing 2.4, and (unfortunately) > it seems as though absolute_import is not offered in the > __future__ module. What happened? It's awaiting an implementation, AFAIK. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-23 19:32 Message: Logged In: YES user_id=341410 A literal reading of "Guido's Decision" in PEP 328 says that if absolute imports were implemented, then the only thing missing is a future import, and an __init__.py file in the same path as email.py. I finally got around to installing 2.4, and (unfortunately) it seems as though absolute_import is not offered in the __future__ module. What happened? I thought PEP 328 was accepted for inclusion in 2.4. Did someone not have the time to write the import hook? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-23 18:53 Message: Logged In: YES user_id=6656 > Absolute imports will also fix that. No it won't! The directory containing email.py is on sys.path, at the front. So "import email" will find it. > What in this entire problem is not solved by absolute > imports with its changed import semantic that already exists > in Python 2.4? Nothing at all is solved by a change that isn't in Python 2.4! I still think this bug should be closed won't fix. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-23 17:52 Message: Logged In: YES user_id=341410 Absolute imports will also fix that. A bare "from __future__ import absolute_imports;import email" will import the email package, at the cost of changing the semantics of relative imports. What is the problem? Why cannot it be used? What in this entire problem is not solved by absolute imports with its changed import semantic that already exists in Python 2.4? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-23 17:43 Message: Logged In: YES user_id=92689 > Standard library name masking is exactly what > the absolute imports PEP was seeking to fix Only in the context of submodule imports within packages. Which is _not_ at _all_ what is being described here. There is a main _script_ called email.py which wants to import the email module (that email happens to be a package is not relevant). There is _no_ relative import going on here, it just so happens that the script's parent dir is in sys.path before the std lib. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-23 17:02 Message: Logged In: YES user_id=341410 I'm sorry, the bit I quoted shouldn't go into your email.py file, it should go into the module that wants to import Python's email package, and not your email.py module (my brain was fuzzy on the 16th). Standard library name masking is exactly what the absolute imports PEP was seeking to fix. You use "from __future__ import absolute_imports", and from then on, you can do relative imports via "import .modulename" (note the leading period), and stdlib imports via "import modulename" (note the lack of a leading period). It also allows you to go higher up in paths via additional leading periods. This /does/ in fact fix the problem mentioned, at the cost of having to change the import lines because of the changed import semantic. This allows users to choose names that they desire, even if it mirrors a standard library module name. It also doesn't require any patches. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-23 14:44 Message: Logged In: YES user_id=387193 I do understand that the patch will not be accepted. :-) That's ok. Too much fight with people's habits for me. :] But, let's see what common script names are forbidden now (among others): array.py, binascii.py, bz2.py, collections.py, crypt.py, datetime.py, math.py, md5.py, mmap.py, parser.py, pwd.py, regex.py, resource.py, select.py, sha.py, syslog.py, time.py, timing.py, timeit.py, binhex.py, calendar.py, cgi.py, chunk.py, cmd.py, code.py, commands.py, compileall.py, compiler.py, copy.py, csv.py, decimal.py... And in the future there can be even more depending on the new modules in Python itself and third party modules (i.e. spread.py, dbus.py, eca.py, etc.). If new module or package appears, then you will have to change your name of the script. I do understand that it is not frequent situation, but we should not to be forced to avoid certain _common_ words for script naming. IMHO, it is a problem and should be fixed. The question is "How?". Maybe page listed below should be discussed (again I think): http://hkn.eecs.berkeley.edu/~dyoo/python/__std__/ I would set Resolution to "Remind" if you agree to discuss it later and fix the problem somehow in the future. If not, then "Won't fix". ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-02-23 10:42 Message: Logged In: YES user_id=113328 Another point - given a program which comprises a couple of .py files in the same directory (say main.py and support.py) it would be quite normal (at least for me!) to do "import support" from main.py. This patch would break this - and I'd find it difficult to accept what I'm doing as "a mistake". Fixing this would involve adding something like sys.path.insert(0, os.path.dirname(os.path.abspath(sys.argv[0])) at the top of my main script. I'd hate to try to explain that to a beginner... The use case here seems to be when a script itself has the same name as a standard library module. I'd have to say that this seems a fairly unlikely case - and easy to fix when it happens. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-23 09:21 Message: Logged In: YES user_id=92689 That doesn't follow at all. The script email.py will _still_ be found first instead of the email module. Like wrobell, I don't see what this has _anything_ to do with relative vs. absolute imports. While a common newbie gotcha, I don't think it's worth the trouble to try to "fix" this. Recommending "won't fix". ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-16 17:43 Message: Logged In: YES user_id=341410 If you were to make your 'email.py' file contain the following... #!/user/bin/python from __future__ import absolute_import import email print 1 It should import the email package. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-16 17:31 Message: Logged In: YES user_id=387193 But the problem is not with naming of my modules/packages (part about relative import of modules I do understand, of course), but with script naming. For example consider script: #!/usr/bin/python import email print 1 And name the script email.py, then run it, please. Python tries to be too smart (IMHO) and variable sys.path is polluted with directory of email.py script, therefore standard email Python package will not be imported. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-16 16:50 Message: Logged In: YES user_id=341410 If the entirety of PEP 328 made it into Python 2.4 (I don't have an installation of 2.4, so don't know), to import your 'email.py' module, you would use 'from . import email' after enabling the absolute import semantics with 'from __future__ import absolute_import'. You would then import the standard email package with 'import email'. Is this not clear by reading PEP 328? ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-16 14:37 Message: Logged In: YES user_id=387193 I am opening it again to discuss it a little more... Question to Josiah Carlson or anybody who can answer: How PEP 328 is going to solve problem I have described? If I name my script email.py, which will try to import email standard Python package. Then run the script, it will import itself instead of Python package, because directory where email.py is installed is added to sys.path. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2004-10-26 17:42 Message: Logged In: YES user_id=387193 i will not provide the patch for 328, so closing this issue ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-07 21: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 00: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 16: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 00: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 Wed Feb 23 21:18:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 21:19:01 2005 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 05:51 Message generated for change (Comment added) made by josiahcarlson 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: Josiah Carlson (josiahcarlson) Date: 2005-02-23 12:18 Message: Logged In: YES user_id=341410 It's not hard to understand, but I could have sworn that in the discussion about absolute imports from the spring of last year that it wasn't just a package thing, it was supposed to functionally do-away with "" being in sys.path for all modules in which the future import had been performed. It seems as though I was mistaken as to the reasons behind the PEP, but can you blame me? A single mechanism for handling stdlib vs. non-stdlib imports would be great (I would say should be the one true solution), and would solve the 10/week questions about imports in comp.lang.python. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-23 11:54 Message: Logged In: YES user_id=6656 > A literal reading of "Guido's Decision" in PEP 328 says that > if absolute imports were implemented, then the only thing > missing is a future import, and an __init__.py file in the > same path as email.py. I don't think this __init__.py file had been mentioned before. However, even if it is there, THE DIRECTORY CONTAINING email.py IS ON sys.path! What's hard to understand about this? > I finally got around to installing 2.4, and (unfortunately) > it seems as though absolute_import is not offered in the > __future__ module. What happened? It's awaiting an implementation, AFAIK. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-23 11:32 Message: Logged In: YES user_id=341410 A literal reading of "Guido's Decision" in PEP 328 says that if absolute imports were implemented, then the only thing missing is a future import, and an __init__.py file in the same path as email.py. I finally got around to installing 2.4, and (unfortunately) it seems as though absolute_import is not offered in the __future__ module. What happened? I thought PEP 328 was accepted for inclusion in 2.4. Did someone not have the time to write the import hook? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-23 10:53 Message: Logged In: YES user_id=6656 > Absolute imports will also fix that. No it won't! The directory containing email.py is on sys.path, at the front. So "import email" will find it. > What in this entire problem is not solved by absolute > imports with its changed import semantic that already exists > in Python 2.4? Nothing at all is solved by a change that isn't in Python 2.4! I still think this bug should be closed won't fix. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-23 09:52 Message: Logged In: YES user_id=341410 Absolute imports will also fix that. A bare "from __future__ import absolute_imports;import email" will import the email package, at the cost of changing the semantics of relative imports. What is the problem? Why cannot it be used? What in this entire problem is not solved by absolute imports with its changed import semantic that already exists in Python 2.4? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-23 09:43 Message: Logged In: YES user_id=92689 > Standard library name masking is exactly what > the absolute imports PEP was seeking to fix Only in the context of submodule imports within packages. Which is _not_ at _all_ what is being described here. There is a main _script_ called email.py which wants to import the email module (that email happens to be a package is not relevant). There is _no_ relative import going on here, it just so happens that the script's parent dir is in sys.path before the std lib. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-23 09:02 Message: Logged In: YES user_id=341410 I'm sorry, the bit I quoted shouldn't go into your email.py file, it should go into the module that wants to import Python's email package, and not your email.py module (my brain was fuzzy on the 16th). Standard library name masking is exactly what the absolute imports PEP was seeking to fix. You use "from __future__ import absolute_imports", and from then on, you can do relative imports via "import .modulename" (note the leading period), and stdlib imports via "import modulename" (note the lack of a leading period). It also allows you to go higher up in paths via additional leading periods. This /does/ in fact fix the problem mentioned, at the cost of having to change the import lines because of the changed import semantic. This allows users to choose names that they desire, even if it mirrors a standard library module name. It also doesn't require any patches. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-23 06:44 Message: Logged In: YES user_id=387193 I do understand that the patch will not be accepted. :-) That's ok. Too much fight with people's habits for me. :] But, let's see what common script names are forbidden now (among others): array.py, binascii.py, bz2.py, collections.py, crypt.py, datetime.py, math.py, md5.py, mmap.py, parser.py, pwd.py, regex.py, resource.py, select.py, sha.py, syslog.py, time.py, timing.py, timeit.py, binhex.py, calendar.py, cgi.py, chunk.py, cmd.py, code.py, commands.py, compileall.py, compiler.py, copy.py, csv.py, decimal.py... And in the future there can be even more depending on the new modules in Python itself and third party modules (i.e. spread.py, dbus.py, eca.py, etc.). If new module or package appears, then you will have to change your name of the script. I do understand that it is not frequent situation, but we should not to be forced to avoid certain _common_ words for script naming. IMHO, it is a problem and should be fixed. The question is "How?". Maybe page listed below should be discussed (again I think): http://hkn.eecs.berkeley.edu/~dyoo/python/__std__/ I would set Resolution to "Remind" if you agree to discuss it later and fix the problem somehow in the future. If not, then "Won't fix". ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-02-23 02:42 Message: Logged In: YES user_id=113328 Another point - given a program which comprises a couple of .py files in the same directory (say main.py and support.py) it would be quite normal (at least for me!) to do "import support" from main.py. This patch would break this - and I'd find it difficult to accept what I'm doing as "a mistake". Fixing this would involve adding something like sys.path.insert(0, os.path.dirname(os.path.abspath(sys.argv[0])) at the top of my main script. I'd hate to try to explain that to a beginner... The use case here seems to be when a script itself has the same name as a standard library module. I'd have to say that this seems a fairly unlikely case - and easy to fix when it happens. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-23 01:21 Message: Logged In: YES user_id=92689 That doesn't follow at all. The script email.py will _still_ be found first instead of the email module. Like wrobell, I don't see what this has _anything_ to do with relative vs. absolute imports. While a common newbie gotcha, I don't think it's worth the trouble to try to "fix" this. Recommending "won't fix". ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-16 09:43 Message: Logged In: YES user_id=341410 If you were to make your 'email.py' file contain the following... #!/user/bin/python from __future__ import absolute_import import email print 1 It should import the email package. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-16 09:31 Message: Logged In: YES user_id=387193 But the problem is not with naming of my modules/packages (part about relative import of modules I do understand, of course), but with script naming. For example consider script: #!/usr/bin/python import email print 1 And name the script email.py, then run it, please. Python tries to be too smart (IMHO) and variable sys.path is polluted with directory of email.py script, therefore standard email Python package will not be imported. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-16 08:50 Message: Logged In: YES user_id=341410 If the entirety of PEP 328 made it into Python 2.4 (I don't have an installation of 2.4, so don't know), to import your 'email.py' module, you would use 'from . import email' after enabling the absolute import semantics with 'from __future__ import absolute_import'. You would then import the standard email package with 'import email'. Is this not clear by reading PEP 328? ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2005-02-16 06:37 Message: Logged In: YES user_id=387193 I am opening it again to discuss it a little more... Question to Josiah Carlson or anybody who can answer: How PEP 328 is going to solve problem I have described? If I name my script email.py, which will try to import email standard Python package. Then run the script, it will import itself instead of Python package, because directory where email.py is installed is added to sys.path. ---------------------------------------------------------------------- Comment By: wrobell (wrobell) Date: 2004-10-26 09:42 Message: Logged In: YES user_id=387193 i will not provide the patch for 328, so closing this issue ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-07 13: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-20 16: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 08: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-07 16: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 Feb 24 20:59:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 24 20:59:08 2005 Subject: [Patches] [ python-Patches-946207 ] Non-blocking Socket Server Message-ID: Patches item #946207, was opened at 2004-05-02 04:45 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=946207&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Jesper ?JJ? Jurcenoks (jesperjurcenoks) Assigned to: Nobody/Anonymous (nobody) Summary: Non-blocking Socket Server Initial Comment: Changed the included Python 2.3.3 SocketServer.py to be non-blocking. I have made a web-server on BaseHTTPServer, but the server could get shot down externally by sending malformed request. Making it very Easy to Perform a Denial of Service. The problem also exists in "Module Docs" web-server To experience problem run Module Docs, and verify that web-server is working telnet to webserver (telnet 127.0.0.1 7464#) type "GET /\r" access any web-page on web-server and notice how it is hung. Replace existing SocketServer.py with included SocketServer.py and re-test noticing that the problem is gone. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-24 20:59 Message: Logged In: YES user_id=21627 I agree with Irmen's review. The BaseHTTPServer is deliberately single-threaded. If you want a threaded server, use SocketServer.ThreadingMixIn. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-16 16:23 Message: Logged In: YES user_id=129426 There's nothing wrong with the default socket server. It is blocking by design. The module provides a few mixins that change the way the requests are handled (see mmangino's comment) Making it threaded by default wouldn't work because not all systems support threading. That's why there is also the forking mixin. ---------------------------------------------------------------------- Comment By: Mike Mangino (mmangino) Date: 2004-07-13 21:46 Message: Logged In: YES user_id=74879 Actually, forget the previous request. The better change would be for you to create a ThreadedHTTPServer that inherits from SocketServer.ThreadingTCPServer, i.e. you could use class ThreadingHTTPServer(SocketServer.ThreadingTCPServer): allow_reuse_address = 1 # Seems to make sense in testing environment def server_bind(self): """Override server_bind to store the server name.""" SocketServer.TCPServer.server_bind(self) host, port = self.socket.getsockname()[:2] self.server_name = socket.getfqdn(host) self.server_port = port And then start the server with httpd = ThreadingHTTPServer(server_address,handler) ---------------------------------------------------------------------- Comment By: Mike Mangino (mmangino) Date: 2004-07-13 21:21 Message: Logged In: YES user_id=74879 Can you post a diff for this to make it easier to understand what has changed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=946207&group_id=5470 From noreply at sourceforge.net Thu Feb 24 21:02:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 24 21:02:32 2005 Subject: [Patches] [ python-Patches-740827 ] add urldecode() method to urllib Message-ID: Patches item #740827, was opened at 2003-05-21 02:43 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=740827&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Matthew Boedicker (mboedick) Assigned to: Nobody/Anonymous (nobody) Summary: add urldecode() method to urllib Initial Comment: Adds a urldecode() method to urllib. The method does the opposite of urlencode, turns a url-encoded string into a list of two-tuples of name/value pairs. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-24 21:02 Message: Logged In: YES user_id=21627 It appears that all reviewers agree that the patch should not be applied. Rejecting it. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-16 16:41 Message: Logged In: YES user_id=129426 I've always found it strange that url-manipulating methods were present in the cgi module. I agree that it would be nicer to have them grouped together in a single module such as urlparse. So I wouldn't add urldecode to urllib. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-21 18:00 Message: Logged In: YES user_id=357491 I think so, but I don't know which one. I only use urllib.urlopen ever so if you have a specific suggestion from experience please make it and submit a patch. Since I don't use either modules extensively someone else is going to need to step in and help make any final decisions. ---------------------------------------------------------------------- Comment By: Matthew Boedicker (mboedick) Date: 2003-05-21 16:25 Message: Logged In: YES user_id=119895 It is not different than cgi.parse_qsl. Must have missed that module when I was looking for this functionality. To me it seems like urlencode and urldecode (as well as quote, quote_plus, unquote, etc.) belong in urlparse. Do you think it would be valuable to include a pointer to cgi.parse_qsl in urllib or urllparse? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-21 05:21 Message: Logged In: YES user_id=357491 How is this different from cgi.parse_sql ? If it is not different, consider just having a wrapper for urldecode that calls cgi.parse_sql . Do you think urllib is the best place for this? What about urlparse? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=740827&group_id=5470 From noreply at sourceforge.net Thu Feb 24 21:06:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 24 21:06:38 2005 Subject: [Patches] [ python-Patches-1151323 ] New fpconst module Message-ID: Patches item #1151323, was opened at 2005-02-24 15:06 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=1151323&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Warnes (warnes) Assigned to: Nobody/Anonymous (nobody) Summary: New fpconst module Initial Comment: This patch adds the 'fpconst' module, described in PEP754 to the standard python library. It includes both the source code and the documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1151323&group_id=5470 From noreply at sourceforge.net Thu Feb 24 21:14:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 24 21:14:52 2005 Subject: [Patches] [ python-Patches-1093468 ] socket leak in SocketServer Message-ID: Patches item #1093468, was opened at 2004-12-30 21:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093468&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Shannon -jj Behrens (jjinux) Assigned to: Nobody/Anonymous (nobody) Summary: socket leak in SocketServer Initial Comment: Found in Python 2.3.4 but still present in 2.5. FreeBSD 4.9 Summary: Fixed a socket leak in SocketServer.StreamRequestHandler that happens during certain exceptions. Longer version: SocketServer.StreamRequestHandler.setup sets up self.rfile and self.wfile. The parent class, SocketServer.BaseRequestHandler.__init__ does not call self.finish() if there is an exception thrown in self.handle(). Hence, such an exception leads to a leaked socket, because SocketServer.StreamRequestHandler.finish never gets called. This is a one line patch that fixes that. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-24 21:14 Message: Logged In: YES user_id=21627 jjinux, I find it hard to believe that the sockets don't get closed. Normally, with an exception, local variables survive in the traceback. Therefore, SocketServer.py sets sys.exc_traceback to None. It still might be that the SocketServer is part of a cyclic object, in which case the socket won't be closed until the GC actually runs. However, I believe the intention is that the SocketServer normally isn't cyclic. Can you provide a test case showing the problem? ---------------------------------------------------------------------- Comment By: Shannon -jj Behrens (jjinux) Date: 2005-01-18 20:59 Message: Logged In: YES user_id=30164 Unfortunately, that is not the case according to my testing. I can get it to leak sockets and never reclaim them. :-/ ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-16 16:55 Message: Logged In: YES user_id=129426 Looks harmless enough but aren't the sockets just garbage collected once the request has been handled? Because the request handler class is instantiated for each request and so it will be removed once done, taking the sockets with it, right? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093468&group_id=5470 From noreply at sourceforge.net Thu Feb 24 21:23:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 24 21:23:13 2005 Subject: [Patches] [ python-Patches-1049151 ] adding bool support to xdrlib.py Message-ID: Patches item #1049151, was opened at 2004-10-18 13:35 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1049151&group_id=5470 Category: Library (Lib) Group: Python 2.5 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: adding bool support to xdrlib.py Initial Comment: xdrlib's Unpacker method unpack_bool() is just an alias to the unpack_int() method, therefore it returns an integer. The attached patch adds bool object support to unpack_bool(). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-24 21:23 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as xdrlib.py 1.17 test_sundry.py 1.17 test_xdrlib.py 1.1 output/test_xdrlib 1.1 NEWS 1.1245 ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-16 17:00 Message: Logged In: YES user_id=129426 It would be nice indeed to have unpack_bool return the type that was put into there by pack_bool :) And now that 2.4 is out... ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-10-20 08:04 Message: Logged In: YES user_id=29957 Nope. This can go in after 2.4 final is out. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-10-19 22:23 Message: Logged In: YES user_id=21627 The patch itself is fine. However, it comes too late for 2.4 - unless Anthony accepts it for 2.4, anyway. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1049151&group_id=5470 From noreply at sourceforge.net Thu Feb 24 21:42:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 24 21:42:20 2005 Subject: [Patches] [ python-Patches-1102879 ] Fix for 926423: socket timeouts + Ctrl-C don't play nice Message-ID: Patches item #1102879, was opened at 2005-01-15 12:37 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1102879&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for 926423: socket timeouts + Ctrl-C don't play nice Initial Comment: Please have a close look at the attached patch. Essentially, it fixes internal_select to not return zero on error condition, and also adds a test for errno at all calls to internal_select. A few remarks: 1) as indicated in the patch, I'm not sure if errno should also be tested in the internal_connect function; 2) 'timeout' is no longer a boolean indicating a timeout condition, it should probably be renamed to 'selectresult' or something similar; 3) I'm not too happy with the fact that the if(timeout==-1 && erro) test must be duplicated in a lot of functions; 4) does it do the right thing? The check for timeout==-1 MUST be there otherwise a lot of errors turn up in the regression tests. With this patch they run fine, btw ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-24 21:42 Message: Logged In: YES user_id=21627 Thanks for the patch. 1) I could not see where you dealt with internal_connect in the patch. However, as a connect can also be cancelled with Ctrl-C, I think you need to deal with it, too. 2) I agree, renaming it would be good 3) you could come up with a macro to avoid code duplication (relying on consistent naming of variables, but that might confure more than help 4) This is almost right. The critical thing is that you read errno much too late. errno is meant to be read immediately after the system call. Any later system call can modify the value - including all of the pthread calls that we do in-between. So the right solution is to copy errno right after select, into a local variable of the caller, and read *that* variable. In order to avoid modifying SetFromErrno, you can assign back to errno before calling it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1102879&group_id=5470 From noreply at sourceforge.net Thu Feb 24 21:55:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 24 21:55:07 2005 Subject: [Patches] [ python-Patches-1103213 ] Adding the missing socket.recvall() method Message-ID: Patches item #1103213, was opened at 2005-01-16 05:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103213&group_id=5470 Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: Adding the missing socket.recvall() method Initial Comment: This patch is a first take at adding a recvall method to the socket object, to mirror the existence of the sendall method. If the MSG_WAITALL flag is available, the recvall method just calls recv() with that flag. If it is not available, it uses an internal loop (during the loop, threads are allowed, so this improves concurrency). Having this method makes Python code much simpler; before you had to test for MSG_WAITALL yourself and write your own loop in Python if the flag is not there (on Windows for instance). (also, having the loop in C improves performance and concurrency compared to the same loop in Python) Note: the patch hasn't been tested very well yet. (code is based on a separate extension module found here: http://www.it-ernst.de/python/ ) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-24 21:55 Message: Logged In: YES user_id=21627 I like the feature (but see below). The patch is incomplete, though: - there are no changes to Doc/lib/libsocket.tex - there are no changes to Lib/test/test_socket.py Furthermore, the patch is also wrong: if a later recv call fails, all data read so far are discarded. I believe this is different from the WAITALL flag, which I hope will preserve the data in the socket, for a subsequent recv call. As keeping the data in the socket seems unimplementable, the partial data should somehow be returned to the application. A note on coding style: please omit the spaces after the opening paren and before the closing in while ( (bytes_got 0) ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103213&group_id=5470 From noreply at sourceforge.net Thu Feb 24 22:07:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 24 22:08:02 2005 Subject: [Patches] [ python-Patches-1062060 ] fix for 1016880 urllib.urlretrieve silently truncates dwnld Message-ID: Patches item #1062060, was opened at 2004-11-07 21:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062060&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: fix for 1016880 urllib.urlretrieve silently truncates dwnld Initial Comment: The patch makes urllib.urlretrieve raise an IOError if the actual download size is different from the expected size (taken from the content-length header). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-24 22:07 Message: Logged In: YES user_id=21627 I think the patch is essentially right. However, I'm concerned with losing the data that got just downloaded - I propose to stick them into the IOError (or, better, subclass IOError to keep the data, and document where to find them). ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-12-24 15:30 Message: Logged In: YES user_id=129426 Suggested addition to the doc of urllib (liburllib.tex, if I'm not mistaken): """ urlretrieve will raise IOError when it detects that the amount of data available was less than the expected amount (which is the size reported by a Content-Length header). This can occur, for example, when the download is interrupted. The Content-Length is treated as a lower bound (just like tools such as wget and Ffirefox appear to do): if there's more data to read, urlretrieve reads more data, but if less data is available, it raises IOError. If no Content-Length header was supplied, urlretrieve can not check the size of the data it has downloaded, and just returns it. In this case you just have to assume that the download was successful. """ ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-12-24 15:10 Message: Logged In: YES user_id=129426 Yes I'm having trouble building the docs from source, so I will just add the text that I would like to change in the docs. When I have some time left (it's Christmas after all :) ) I'll also create a regression test for the new behavior. In the meantime, the "urllib.patch" may be deleted because "urllib.patch2" is the correct patch (I seem to be unable to delete the attachment myself) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-21 01:00 Message: Logged In: YES user_id=80475 Irmin, please attach the new patch. If you're having trouble with the docs, that's fine, just include the text you want changed. Do include tests with your patch. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-12-06 22:48 Message: Logged In: YES user_id=469548 Sorry Irmen, I'm a bit late with this, but now is the time to get new "features" checked into the trunk. Could you add a doc patch that explains the behavior as you did in your previous message and a tests patch? I can check it in then. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-11-07 21:54 Message: Logged In: YES user_id=129426 NOTE: urllib.patch2 may be a bit better. It fixes a misspelling, and also is more relaxed about a 'wrong' download size. To be more precise: it treats content-length as a lower bound (just like wget and firefox appear to do). So if there's more data to read, it reads more data, but if less data is available, it gives an IOError ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062060&group_id=5470 From noreply at sourceforge.net Thu Feb 24 23:10:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 24 23:10:18 2005 Subject: [Patches] [ python-Patches-1093468 ] socket leak in SocketServer Message-ID: Patches item #1093468, was opened at 2004-12-30 12:57 Message generated for change (Comment added) made by jjinux You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093468&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Shannon -jj Behrens (jjinux) Assigned to: Nobody/Anonymous (nobody) Summary: socket leak in SocketServer Initial Comment: Found in Python 2.3.4 but still present in 2.5. FreeBSD 4.9 Summary: Fixed a socket leak in SocketServer.StreamRequestHandler that happens during certain exceptions. Longer version: SocketServer.StreamRequestHandler.setup sets up self.rfile and self.wfile. The parent class, SocketServer.BaseRequestHandler.__init__ does not call self.finish() if there is an exception thrown in self.handle(). Hence, such an exception leads to a leaked socket, because SocketServer.StreamRequestHandler.finish never gets called. This is a one line patch that fixes that. ---------------------------------------------------------------------- >Comment By: Shannon -jj Behrens (jjinux) Date: 2005-02-24 14:10 Message: Logged In: YES user_id=30164 Edit SimpleHTTPServer.do_GET: Add "raise ValueError" at the top of the method. python SimpleHTTPServer.py Now, using a browser, go to http://localhost:8000, and reload the page many times. netstat -A inet --tcp | grep 8000 You will see many sockets open. They do go away (so I was wrong), but it may take a minute or two (literally). Just as a proof of concept, I tested to see whether I could bring the box down via this. Fortunately, it doesn't work :-/ It hovers at around 9000 open sockets, with the GC fighting to keep them down. The GC will occassionally take 10-15 seconds trying to clear everything up. Despite the fact the my patch is very simple, I think I'm going to lose this argument :-/ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-24 12:14 Message: Logged In: YES user_id=21627 jjinux, I find it hard to believe that the sockets don't get closed. Normally, with an exception, local variables survive in the traceback. Therefore, SocketServer.py sets sys.exc_traceback to None. It still might be that the SocketServer is part of a cyclic object, in which case the socket won't be closed until the GC actually runs. However, I believe the intention is that the SocketServer normally isn't cyclic. Can you provide a test case showing the problem? ---------------------------------------------------------------------- Comment By: Shannon -jj Behrens (jjinux) Date: 2005-01-18 11:59 Message: Logged In: YES user_id=30164 Unfortunately, that is not the case according to my testing. I can get it to leak sockets and never reclaim them. :-/ ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-16 07:55 Message: Logged In: YES user_id=129426 Looks harmless enough but aren't the sockets just garbage collected once the request has been handled? Because the request handler class is instantiated for each request and so it will be removed once done, taking the sockets with it, right? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093468&group_id=5470 From noreply at sourceforge.net Thu Feb 24 23:23:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 24 23:23:06 2005 Subject: [Patches] [ python-Patches-1093468 ] socket leak in SocketServer Message-ID: Patches item #1093468, was opened at 2004-12-30 12:57 Message generated for change (Comment added) made by jjinux You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093468&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Shannon -jj Behrens (jjinux) Assigned to: Nobody/Anonymous (nobody) Summary: socket leak in SocketServer Initial Comment: Found in Python 2.3.4 but still present in 2.5. FreeBSD 4.9 Summary: Fixed a socket leak in SocketServer.StreamRequestHandler that happens during certain exceptions. Longer version: SocketServer.StreamRequestHandler.setup sets up self.rfile and self.wfile. The parent class, SocketServer.BaseRequestHandler.__init__ does not call self.finish() if there is an exception thrown in self.handle(). Hence, such an exception leads to a leaked socket, because SocketServer.StreamRequestHandler.finish never gets called. This is a one line patch that fixes that. ---------------------------------------------------------------------- >Comment By: Shannon -jj Behrens (jjinux) Date: 2005-02-24 14:23 Message: Logged In: YES user_id=30164 I guess the reason this bothers me so much is that if you have a nasty exception in your subclass of SimpleHTTPServer, because the server doesn't close the connection to the browser, the browser will just sit and wait instead of telling the user something bad happened. My patch fixes that. ---------------------------------------------------------------------- Comment By: Shannon -jj Behrens (jjinux) Date: 2005-02-24 14:10 Message: Logged In: YES user_id=30164 Edit SimpleHTTPServer.do_GET: Add "raise ValueError" at the top of the method. python SimpleHTTPServer.py Now, using a browser, go to http://localhost:8000, and reload the page many times. netstat -A inet --tcp | grep 8000 You will see many sockets open. They do go away (so I was wrong), but it may take a minute or two (literally). Just as a proof of concept, I tested to see whether I could bring the box down via this. Fortunately, it doesn't work :-/ It hovers at around 9000 open sockets, with the GC fighting to keep them down. The GC will occassionally take 10-15 seconds trying to clear everything up. Despite the fact the my patch is very simple, I think I'm going to lose this argument :-/ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-24 12:14 Message: Logged In: YES user_id=21627 jjinux, I find it hard to believe that the sockets don't get closed. Normally, with an exception, local variables survive in the traceback. Therefore, SocketServer.py sets sys.exc_traceback to None. It still might be that the SocketServer is part of a cyclic object, in which case the socket won't be closed until the GC actually runs. However, I believe the intention is that the SocketServer normally isn't cyclic. Can you provide a test case showing the problem? ---------------------------------------------------------------------- Comment By: Shannon -jj Behrens (jjinux) Date: 2005-01-18 11:59 Message: Logged In: YES user_id=30164 Unfortunately, that is not the case according to my testing. I can get it to leak sockets and never reclaim them. :-/ ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-16 07:55 Message: Logged In: YES user_id=129426 Looks harmless enough but aren't the sockets just garbage collected once the request has been handled? Because the request handler class is instantiated for each request and so it will be removed once done, taking the sockets with it, right? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093468&group_id=5470 From noreply at sourceforge.net Fri Feb 25 01:22:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 25 01:22:16 2005 Subject: [Patches] [ python-Patches-1141428 ] more __contains__ tests Message-ID: Patches item #1141428, was opened at 2005-02-17 19:42 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1141428&group_id=5470 Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 4 Submitted By: Jim Jewett (jimjjewett) Assigned to: Raymond Hettinger (rhettinger) Summary: more __contains__ tests Initial Comment: Recently, there was a change to speed up __contains__. x in (1, 2, 3) would be compiled as x in frozenset(1, 2, 3). This was backed out, because frozensets raise a typeerror when asked about unhashable objects. These objects *can't* be in the set, but there was concern about supporting objects in which a mutable and an immutable compare equal. So long as that is a requirement, it should be tested. The new test for sequences ensures that they will use __eq__ (and not rely on __hash__) in the future. The change to the rich compare tests is just a comment, pointing out that dicts can rely on __hash__ as well as __eq__. ---------------------------------------------------------------------- >Comment By: Jim Jewett (jimjjewett) Date: 2005-02-24 19:22 Message: Logged In: YES user_id=764593 Period moved, per mcherm's comment. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2005-02-23 08:26 Message: Logged In: YES user_id=99874 In the change to test_richcmp.diff, you should move the period to the end of the sentence. That being said, I'm +1 on applying this patch. I certainly agree that we should add the test since we care about preserving the behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1141428&group_id=5470 From noreply at sourceforge.net Fri Feb 25 01:25:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 25 01:25:16 2005 Subject: [Patches] [ python-Patches-1151323 ] New fpconst module Message-ID: Patches item #1151323, was opened at 2005-02-24 15:06 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1151323&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Warnes (warnes) Assigned to: Nobody/Anonymous (nobody) Summary: New fpconst module Initial Comment: This patch adds the 'fpconst' module, described in PEP754 to the standard python library. It includes both the source code and the documentation. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-02-24 19:25 Message: Logged In: YES user_id=139309 Is there a reason why you don't use the struct.pack endian markers? You could get rid of all the code that deals with _big_endian if you just prefixed the formats with ! or > ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1151323&group_id=5470 From noreply at sourceforge.net Fri Feb 25 03:57:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 25 03:57:06 2005 Subject: [Patches] [ python-Patches-1109424 ] type conversion methods and subclasses Message-ID: Patches item #1109424, was opened at 2005-01-25 14:04 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1109424&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) >Assigned to: Brett Cannon (bcannon) Summary: type conversion methods and subclasses Initial Comment: This patch fixes the classes int, long, float and unicode so that type conversion methods (i.e. __int__, __long__, __float__, __unicode__) are used for type conversion in subclasses of int/long/float/unicode. (See the following thread on python-dev for more info: http://mail.python.org/pipermail/python-dev/2005-January/051175.html) It also fixes the bug reported by Nick Coghlan here: http://mail.python.org/pipermail/python-dev/2005-January/051196.html. For int/long/float converting the instance of the subclasses to the base class has been moved from PyNumber_(Int|Long|Float) to the apropriate slot nb_int, nb_long, nb_float of int/long/float. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-02-24 18:57 Message: Logged In: YES user_id=357491 OK, BDFL pronounced on this saying the semantic change was fine. I will have a look at the patch when I can and get it in. Won't touch 2.4 since it is a semantic change, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1109424&group_id=5470 From noreply at sourceforge.net Fri Feb 25 21:34:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 25 21:34:44 2005 Subject: [Patches] [ python-Patches-941881 ] PEP309 Partial implementation Message-ID: Patches item #941881, was opened at 2004-04-25 20:05 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: PEP309 Partial implementation Initial Comment: This patch implements functional module which is introduced by PEP309. It has only 'partial' function as its member in this stage. Unittest code is copied and modified slightly from Patch #931010 by Peter Harris. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-25 21:34 Message: Logged In: YES user_id=21627 In this form, the patch cannot be applied, since it lacks documentation changes. It might be that perky does not consider himself fluent enough in English to write the documentation - any other volunteers? I also think there is value to bediviere's point, even though the PEP currently specifies partial() differently. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-19 21:38 Message: Logged In: YES user_id=945502 It might be nice if partial objects were usable as instancemethods, like functions are. Note the following behavior with the current patch: >>> import functional >>> class C(object): ... pass ... >>> def func(self, arg): ... return arg ... >>> for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... >>> C().a() Traceback (most recent call last): File "", line 1, in ? TypeError: func() takes exactly 2 arguments (1 given) If functional.partial was instead defined like: class partial(object): def __init__(*args, **kwargs): self = args[0] try: self.func = args[1] except IndexError: raise TypeError('expected 2 or more arguments, got ' % len(args)) self.obj = () self.args = args[2:] self.kwargs = kwargs def __call__(self, *args, **kwargs): if kwargs and self.kwargs: d = self.kwargs.copy() d.update(kwargs) else: d = kwargs or self.kwargs return self.func(*(self.obj + self.args + args), **d) def __get__(self, obj, type=None): if obj is None: return self result = partial(self.func, *self.args, **self.kwargs) result.obj = (obj,) return result where an appropriate __get__ method is provided, then partial objects behave properly when set as attributes to a class: py> def test(): ... class C(object): ... pass ... def func(self, arg): ... return arg ... for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... c = C() ... return c.a(), c.b(), c.c() ... py> test() ('a', 'b', 'c') ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 02:11 Message: Logged In: YES user_id=1038590 I have tested this patch on Windows, and it passes its own test suite, without affecting any other tests. However, PCBuild\pythoncore.vcproj & PC\config.c require modification to allow Python to pick up the new module correctly. Patch #1006948 created with the needed changes (also removes unneeded ODBC references from pythoncore.vcproj as I am using the free MS toolkits to build here) My patch definitely needs to be checked by someone with a copy of Vis Studio 2003! ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-08-03 22:23 Message: Logged In: YES user_id=113328 OK, a real need beats my theoretical worries :-) Consider me convinced. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-05-18 06:05 Message: Logged In: YES user_id=139309 I would use partial in situations where speed can matter (imap, commonly used event handlers, etc.), so a fast C implementation would be nice to have. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 10:03 Message: Logged In: YES user_id=113328 Yes, that looks like a significant speed improvement :-) I was basing my assumptions on the comments made in the PEP. Sorry. But I still wonder if having the implementation in Python wouldn't be better from a maintenance point of view. (As well as all the arguments about usefulness as sample code, ability to backport, etc etc, that have come up on python-dev regarding moving other Python library modules into C...). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-04-27 04:05 Message: Logged In: YES user_id=55188 Python-version (function) ... 1.19 2.69 Python-version (class) ... 2.61 2.38 C-version ... 0.50 0.37 (former value is for 100000 instanciations and latter is for 100000 calls.) And, C version have a facility that changing attributes after the instantiation that is supported by class version only. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-26 21:30 Message: Logged In: YES user_id=113328 Why implement this in C? I can't imagine that the performance improvement will be that significant. A pure Python module in the standard library seems to me to be a far better idea. As the PEP says, "the case for a built-in coded in C is not very strong". And a Python module is good self-documentation. I prefer the function version suggested in the PEP (credited to Carl Banks) over the class-based one. You need to take a little care to avoid capturing argument names: def partial(*args, **kwds): def callit(*moreargs, **morekwds): kw = kwds.copy() kw.update(morekwds) return args[0](*(args[1:]+moreargs), **kw) return callit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 From noreply at sourceforge.net Fri Feb 25 21:54:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 25 21:54:13 2005 Subject: [Patches] [ python-Patches-1146231 ] bsddb3 build problems on FreeBSD (2.4 + 2.5) Message-ID: Patches item #1146231, was opened at 2005-02-22 14:10 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1146231&group_id=5470 >Category: Build >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Nobody/Anonymous (nobody) Summary: bsddb3 build problems on FreeBSD (2.4 + 2.5) Initial Comment: FreeBSD's ports system has another variation on naming the Sleepcat DB library. The attached patch adds support for this naming variation. The patch is actually for CVS head, but applies to the 2.4 maintenance branch (with an offset). In my particular case, my FreeBSD box has both DB 4.1 and DB 4.0 installed; the build was finding the 4.1 headers and compiling against them, but then linking to the 4.0 library. In consequence, all the tests which depend on the _bsddb module (test_anydbm, test_bsddb, test_bsddb185, test_shelve, test_whichdb) were failing or dumping core. This patch (or something with similar effect) should be applied in time for 2.4.1 in my opinion (I could do that, but would like the release manager's approval). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1146231&group_id=5470 From noreply at sourceforge.net Sat Feb 26 04:17:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 26 04:17:18 2005 Subject: [Patches] [ python-Patches-941881 ] PEP309 Partial implementation Message-ID: Patches item #941881, was opened at 2004-04-26 04:05 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: PEP309 Partial implementation Initial Comment: This patch implements functional module which is introduced by PEP309. It has only 'partial' function as its member in this stage. Unittest code is copied and modified slightly from Patch #931010 by Peter Harris. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 13:17 Message: Logged In: YES user_id=1038590 Peter Harris already wrote docs in Patch 931007. Presumably they are still accurate, or perky would have said something. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-26 06:34 Message: Logged In: YES user_id=21627 In this form, the patch cannot be applied, since it lacks documentation changes. It might be that perky does not consider himself fluent enough in English to write the documentation - any other volunteers? I also think there is value to bediviere's point, even though the PEP currently specifies partial() differently. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-20 06:38 Message: Logged In: YES user_id=945502 It might be nice if partial objects were usable as instancemethods, like functions are. Note the following behavior with the current patch: >>> import functional >>> class C(object): ... pass ... >>> def func(self, arg): ... return arg ... >>> for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... >>> C().a() Traceback (most recent call last): File "", line 1, in ? TypeError: func() takes exactly 2 arguments (1 given) If functional.partial was instead defined like: class partial(object): def __init__(*args, **kwargs): self = args[0] try: self.func = args[1] except IndexError: raise TypeError('expected 2 or more arguments, got ' % len(args)) self.obj = () self.args = args[2:] self.kwargs = kwargs def __call__(self, *args, **kwargs): if kwargs and self.kwargs: d = self.kwargs.copy() d.update(kwargs) else: d = kwargs or self.kwargs return self.func(*(self.obj + self.args + args), **d) def __get__(self, obj, type=None): if obj is None: return self result = partial(self.func, *self.args, **self.kwargs) result.obj = (obj,) return result where an appropriate __get__ method is provided, then partial objects behave properly when set as attributes to a class: py> def test(): ... class C(object): ... pass ... def func(self, arg): ... return arg ... for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... c = C() ... return c.a(), c.b(), c.c() ... py> test() ('a', 'b', 'c') ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 10:11 Message: Logged In: YES user_id=1038590 I have tested this patch on Windows, and it passes its own test suite, without affecting any other tests. However, PCBuild\pythoncore.vcproj & PC\config.c require modification to allow Python to pick up the new module correctly. Patch #1006948 created with the needed changes (also removes unneeded ODBC references from pythoncore.vcproj as I am using the free MS toolkits to build here) My patch definitely needs to be checked by someone with a copy of Vis Studio 2003! ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-08-04 06:23 Message: Logged In: YES user_id=113328 OK, a real need beats my theoretical worries :-) Consider me convinced. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-05-18 14:05 Message: Logged In: YES user_id=139309 I would use partial in situations where speed can matter (imap, commonly used event handlers, etc.), so a fast C implementation would be nice to have. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 18:03 Message: Logged In: YES user_id=113328 Yes, that looks like a significant speed improvement :-) I was basing my assumptions on the comments made in the PEP. Sorry. But I still wonder if having the implementation in Python wouldn't be better from a maintenance point of view. (As well as all the arguments about usefulness as sample code, ability to backport, etc etc, that have come up on python-dev regarding moving other Python library modules into C...). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-04-27 12:05 Message: Logged In: YES user_id=55188 Python-version (function) ... 1.19 2.69 Python-version (class) ... 2.61 2.38 C-version ... 0.50 0.37 (former value is for 100000 instanciations and latter is for 100000 calls.) And, C version have a facility that changing attributes after the instantiation that is supported by class version only. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 05:30 Message: Logged In: YES user_id=113328 Why implement this in C? I can't imagine that the performance improvement will be that significant. A pure Python module in the standard library seems to me to be a far better idea. As the PEP says, "the case for a built-in coded in C is not very strong". And a Python module is good self-documentation. I prefer the function version suggested in the PEP (credited to Carl Banks) over the class-based one. You need to take a little care to avoid capturing argument names: def partial(*args, **kwds): def callit(*moreargs, **morekwds): kw = kwds.copy() kw.update(morekwds) return args[0](*(args[1:]+moreargs), **kw) return callit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 From noreply at sourceforge.net Sat Feb 26 04:27:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 26 04:27:32 2005 Subject: [Patches] [ python-Patches-941881 ] PEP309 Partial implementation Message-ID: Patches item #941881, was opened at 2004-04-26 04:05 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: PEP309 Partial implementation Initial Comment: This patch implements functional module which is introduced by PEP309. It has only 'partial' function as its member in this stage. Unittest code is copied and modified slightly from Patch #931010 by Peter Harris. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 13:27 Message: Logged In: YES user_id=1038590 Steve's suggestion does sound good, but can't it simply be implemented with the PEP implementation and the following __get__ method?: def __get__(self, obj, type=None): if obj is None: return self return partial(self.func, obj, *self.args, **self.kwargs) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 13:17 Message: Logged In: YES user_id=1038590 Peter Harris already wrote docs in Patch 931007. Presumably they are still accurate, or perky would have said something. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-26 06:34 Message: Logged In: YES user_id=21627 In this form, the patch cannot be applied, since it lacks documentation changes. It might be that perky does not consider himself fluent enough in English to write the documentation - any other volunteers? I also think there is value to bediviere's point, even though the PEP currently specifies partial() differently. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-20 06:38 Message: Logged In: YES user_id=945502 It might be nice if partial objects were usable as instancemethods, like functions are. Note the following behavior with the current patch: >>> import functional >>> class C(object): ... pass ... >>> def func(self, arg): ... return arg ... >>> for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... >>> C().a() Traceback (most recent call last): File "", line 1, in ? TypeError: func() takes exactly 2 arguments (1 given) If functional.partial was instead defined like: class partial(object): def __init__(*args, **kwargs): self = args[0] try: self.func = args[1] except IndexError: raise TypeError('expected 2 or more arguments, got ' % len(args)) self.obj = () self.args = args[2:] self.kwargs = kwargs def __call__(self, *args, **kwargs): if kwargs and self.kwargs: d = self.kwargs.copy() d.update(kwargs) else: d = kwargs or self.kwargs return self.func(*(self.obj + self.args + args), **d) def __get__(self, obj, type=None): if obj is None: return self result = partial(self.func, *self.args, **self.kwargs) result.obj = (obj,) return result where an appropriate __get__ method is provided, then partial objects behave properly when set as attributes to a class: py> def test(): ... class C(object): ... pass ... def func(self, arg): ... return arg ... for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... c = C() ... return c.a(), c.b(), c.c() ... py> test() ('a', 'b', 'c') ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 10:11 Message: Logged In: YES user_id=1038590 I have tested this patch on Windows, and it passes its own test suite, without affecting any other tests. However, PCBuild\pythoncore.vcproj & PC\config.c require modification to allow Python to pick up the new module correctly. Patch #1006948 created with the needed changes (also removes unneeded ODBC references from pythoncore.vcproj as I am using the free MS toolkits to build here) My patch definitely needs to be checked by someone with a copy of Vis Studio 2003! ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-08-04 06:23 Message: Logged In: YES user_id=113328 OK, a real need beats my theoretical worries :-) Consider me convinced. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-05-18 14:05 Message: Logged In: YES user_id=139309 I would use partial in situations where speed can matter (imap, commonly used event handlers, etc.), so a fast C implementation would be nice to have. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 18:03 Message: Logged In: YES user_id=113328 Yes, that looks like a significant speed improvement :-) I was basing my assumptions on the comments made in the PEP. Sorry. But I still wonder if having the implementation in Python wouldn't be better from a maintenance point of view. (As well as all the arguments about usefulness as sample code, ability to backport, etc etc, that have come up on python-dev regarding moving other Python library modules into C...). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-04-27 12:05 Message: Logged In: YES user_id=55188 Python-version (function) ... 1.19 2.69 Python-version (class) ... 2.61 2.38 C-version ... 0.50 0.37 (former value is for 100000 instanciations and latter is for 100000 calls.) And, C version have a facility that changing attributes after the instantiation that is supported by class version only. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 05:30 Message: Logged In: YES user_id=113328 Why implement this in C? I can't imagine that the performance improvement will be that significant. A pure Python module in the standard library seems to me to be a far better idea. As the PEP says, "the case for a built-in coded in C is not very strong". And a Python module is good self-documentation. I prefer the function version suggested in the PEP (credited to Carl Banks) over the class-based one. You need to take a little care to avoid capturing argument names: def partial(*args, **kwds): def callit(*moreargs, **morekwds): kw = kwds.copy() kw.update(morekwds) return args[0](*(args[1:]+moreargs), **kw) return callit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 From noreply at sourceforge.net Sat Feb 26 04:45:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 26 04:45:17 2005 Subject: [Patches] [ python-Patches-941881 ] PEP309 Partial implementation Message-ID: Patches item #941881, was opened at 2004-04-26 04:05 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: PEP309 Partial implementation Initial Comment: This patch implements functional module which is introduced by PEP309. It has only 'partial' function as its member in this stage. Unittest code is copied and modified slightly from Patch #931010 by Peter Harris. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 13:45 Message: Logged In: YES user_id=1038590 If the __get__ method is added to make partial functions behave like instance methods, the documentation should probably mention that classmethod() and staticmethod() can then be used to alter the behaviour: Py> def f(*args): ... print args ... Py> class C: ... a = functional.partial(f) ... b = classmethod(functional.partial(f)) ... c = staticmethod(functional.partial(f)) ... Py> C().a Py> C().a() (<__main__.C instance at 0x009E6698>,) Py> C().b() (,) Py> C().c() () (This example used the simpler __get__ implementation I posted earlier) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 13:27 Message: Logged In: YES user_id=1038590 Steve's suggestion does sound good, but can't it simply be implemented with the PEP implementation and the following __get__ method?: def __get__(self, obj, type=None): if obj is None: return self return partial(self.func, obj, *self.args, **self.kwargs) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 13:17 Message: Logged In: YES user_id=1038590 Peter Harris already wrote docs in Patch 931007. Presumably they are still accurate, or perky would have said something. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-26 06:34 Message: Logged In: YES user_id=21627 In this form, the patch cannot be applied, since it lacks documentation changes. It might be that perky does not consider himself fluent enough in English to write the documentation - any other volunteers? I also think there is value to bediviere's point, even though the PEP currently specifies partial() differently. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-20 06:38 Message: Logged In: YES user_id=945502 It might be nice if partial objects were usable as instancemethods, like functions are. Note the following behavior with the current patch: >>> import functional >>> class C(object): ... pass ... >>> def func(self, arg): ... return arg ... >>> for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... >>> C().a() Traceback (most recent call last): File "", line 1, in ? TypeError: func() takes exactly 2 arguments (1 given) If functional.partial was instead defined like: class partial(object): def __init__(*args, **kwargs): self = args[0] try: self.func = args[1] except IndexError: raise TypeError('expected 2 or more arguments, got ' % len(args)) self.obj = () self.args = args[2:] self.kwargs = kwargs def __call__(self, *args, **kwargs): if kwargs and self.kwargs: d = self.kwargs.copy() d.update(kwargs) else: d = kwargs or self.kwargs return self.func(*(self.obj + self.args + args), **d) def __get__(self, obj, type=None): if obj is None: return self result = partial(self.func, *self.args, **self.kwargs) result.obj = (obj,) return result where an appropriate __get__ method is provided, then partial objects behave properly when set as attributes to a class: py> def test(): ... class C(object): ... pass ... def func(self, arg): ... return arg ... for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... c = C() ... return c.a(), c.b(), c.c() ... py> test() ('a', 'b', 'c') ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 10:11 Message: Logged In: YES user_id=1038590 I have tested this patch on Windows, and it passes its own test suite, without affecting any other tests. However, PCBuild\pythoncore.vcproj & PC\config.c require modification to allow Python to pick up the new module correctly. Patch #1006948 created with the needed changes (also removes unneeded ODBC references from pythoncore.vcproj as I am using the free MS toolkits to build here) My patch definitely needs to be checked by someone with a copy of Vis Studio 2003! ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-08-04 06:23 Message: Logged In: YES user_id=113328 OK, a real need beats my theoretical worries :-) Consider me convinced. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-05-18 14:05 Message: Logged In: YES user_id=139309 I would use partial in situations where speed can matter (imap, commonly used event handlers, etc.), so a fast C implementation would be nice to have. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 18:03 Message: Logged In: YES user_id=113328 Yes, that looks like a significant speed improvement :-) I was basing my assumptions on the comments made in the PEP. Sorry. But I still wonder if having the implementation in Python wouldn't be better from a maintenance point of view. (As well as all the arguments about usefulness as sample code, ability to backport, etc etc, that have come up on python-dev regarding moving other Python library modules into C...). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-04-27 12:05 Message: Logged In: YES user_id=55188 Python-version (function) ... 1.19 2.69 Python-version (class) ... 2.61 2.38 C-version ... 0.50 0.37 (former value is for 100000 instanciations and latter is for 100000 calls.) And, C version have a facility that changing attributes after the instantiation that is supported by class version only. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 05:30 Message: Logged In: YES user_id=113328 Why implement this in C? I can't imagine that the performance improvement will be that significant. A pure Python module in the standard library seems to me to be a far better idea. As the PEP says, "the case for a built-in coded in C is not very strong". And a Python module is good self-documentation. I prefer the function version suggested in the PEP (credited to Carl Banks) over the class-based one. You need to take a little care to avoid capturing argument names: def partial(*args, **kwds): def callit(*moreargs, **morekwds): kw = kwds.copy() kw.update(morekwds) return args[0](*(args[1:]+moreargs), **kw) return callit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 From noreply at sourceforge.net Sat Feb 26 04:53:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 26 04:53:15 2005 Subject: [Patches] [ python-Patches-941881 ] PEP309 Partial implementation Message-ID: Patches item #941881, was opened at 2004-04-25 12:05 Message generated for change (Comment added) made by bediviere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: PEP309 Partial implementation Initial Comment: This patch implements functional module which is introduced by PEP309. It has only 'partial' function as its member in this stage. Unittest code is copied and modified slightly from Patch #931010 by Peter Harris. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-25 20:53 Message: Logged In: YES user_id=945502 Yes, that's much clearer. I don't remember why I couldn't get it to work this way before (I tried something quite similar to this), but I'm glad someone could figure out the simpler way to do it. ;-) One potential problem with my proposal -- it doesn't work for nested partials: py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186470>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() ('a', <__main__.C object at 0x01186370>, 'b') One possible solution would be to merge nested partials, but I'm not at all certain this solves all the problems: py> class partial(object): ... def __init__(*args, **kw): ... self = args[0] ... func = args[1] ... if isinstance(func, partial): ... self.fn = func.fn ... self.args = args[2:] + func.args ... d = func.kw.copy() ... d.update(kw) ... self.kw = d ... else: ... self.fn, self.args, self.kw = (args[1], args[2:], kw) ... def __call__(self, *args, **kw): ... if kw and self.kw: ... d = self.kw.copy() ... d.update(kw) ... else: ... d = kw or self.kw ... return self.fn(*(self.args + args), **d) ... def __get__(self, obj, type=None): ... if obj is None: ... return self ... return partial(self.fn, obj, *self.args, **self.kw) ... py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186BB0>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() (<__main__.C object at 0x01186650>, 'b', 'a') On the other hand, merging nested partials does reduce the number of function calls, so perhaps it's useful in and of itself... ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-25 20:45 Message: Logged In: YES user_id=1038590 If the __get__ method is added to make partial functions behave like instance methods, the documentation should probably mention that classmethod() and staticmethod() can then be used to alter the behaviour: Py> def f(*args): ... print args ... Py> class C: ... a = functional.partial(f) ... b = classmethod(functional.partial(f)) ... c = staticmethod(functional.partial(f)) ... Py> C().a Py> C().a() (<__main__.C instance at 0x009E6698>,) Py> C().b() (,) Py> C().c() () (This example used the simpler __get__ implementation I posted earlier) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-25 20:27 Message: Logged In: YES user_id=1038590 Steve's suggestion does sound good, but can't it simply be implemented with the PEP implementation and the following __get__ method?: def __get__(self, obj, type=None): if obj is None: return self return partial(self.func, obj, *self.args, **self.kwargs) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-25 20:17 Message: Logged In: YES user_id=1038590 Peter Harris already wrote docs in Patch 931007. Presumably they are still accurate, or perky would have said something. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-25 13:34 Message: Logged In: YES user_id=21627 In this form, the patch cannot be applied, since it lacks documentation changes. It might be that perky does not consider himself fluent enough in English to write the documentation - any other volunteers? I also think there is value to bediviere's point, even though the PEP currently specifies partial() differently. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-19 13:38 Message: Logged In: YES user_id=945502 It might be nice if partial objects were usable as instancemethods, like functions are. Note the following behavior with the current patch: >>> import functional >>> class C(object): ... pass ... >>> def func(self, arg): ... return arg ... >>> for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... >>> C().a() Traceback (most recent call last): File "", line 1, in ? TypeError: func() takes exactly 2 arguments (1 given) If functional.partial was instead defined like: class partial(object): def __init__(*args, **kwargs): self = args[0] try: self.func = args[1] except IndexError: raise TypeError('expected 2 or more arguments, got ' % len(args)) self.obj = () self.args = args[2:] self.kwargs = kwargs def __call__(self, *args, **kwargs): if kwargs and self.kwargs: d = self.kwargs.copy() d.update(kwargs) else: d = kwargs or self.kwargs return self.func(*(self.obj + self.args + args), **d) def __get__(self, obj, type=None): if obj is None: return self result = partial(self.func, *self.args, **self.kwargs) result.obj = (obj,) return result where an appropriate __get__ method is provided, then partial objects behave properly when set as attributes to a class: py> def test(): ... class C(object): ... pass ... def func(self, arg): ... return arg ... for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... c = C() ... return c.a(), c.b(), c.c() ... py> test() ('a', 'b', 'c') ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-10 18:11 Message: Logged In: YES user_id=1038590 I have tested this patch on Windows, and it passes its own test suite, without affecting any other tests. However, PCBuild\pythoncore.vcproj & PC\config.c require modification to allow Python to pick up the new module correctly. Patch #1006948 created with the needed changes (also removes unneeded ODBC references from pythoncore.vcproj as I am using the free MS toolkits to build here) My patch definitely needs to be checked by someone with a copy of Vis Studio 2003! ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-08-03 14:23 Message: Logged In: YES user_id=113328 OK, a real need beats my theoretical worries :-) Consider me convinced. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-05-17 22:05 Message: Logged In: YES user_id=139309 I would use partial in situations where speed can matter (imap, commonly used event handlers, etc.), so a fast C implementation would be nice to have. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 02:03 Message: Logged In: YES user_id=113328 Yes, that looks like a significant speed improvement :-) I was basing my assumptions on the comments made in the PEP. Sorry. But I still wonder if having the implementation in Python wouldn't be better from a maintenance point of view. (As well as all the arguments about usefulness as sample code, ability to backport, etc etc, that have come up on python-dev regarding moving other Python library modules into C...). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-04-26 20:05 Message: Logged In: YES user_id=55188 Python-version (function) ... 1.19 2.69 Python-version (class) ... 2.61 2.38 C-version ... 0.50 0.37 (former value is for 100000 instanciations and latter is for 100000 calls.) And, C version have a facility that changing attributes after the instantiation that is supported by class version only. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-26 13:30 Message: Logged In: YES user_id=113328 Why implement this in C? I can't imagine that the performance improvement will be that significant. A pure Python module in the standard library seems to me to be a far better idea. As the PEP says, "the case for a built-in coded in C is not very strong". And a Python module is good self-documentation. I prefer the function version suggested in the PEP (credited to Carl Banks) over the class-based one. You need to take a little care to avoid capturing argument names: def partial(*args, **kwds): def callit(*moreargs, **morekwds): kw = kwds.copy() kw.update(morekwds) return args[0](*(args[1:]+moreargs), **kw) return callit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 From noreply at sourceforge.net Sat Feb 26 04:58:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 26 04:58:16 2005 Subject: [Patches] [ python-Patches-941881 ] PEP309 Partial implementation Message-ID: Patches item #941881, was opened at 2004-04-25 12:05 Message generated for change (Comment added) made by bediviere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: PEP309 Partial implementation Initial Comment: This patch implements functional module which is introduced by PEP309. It has only 'partial' function as its member in this stage. Unittest code is copied and modified slightly from Patch #931010 by Peter Harris. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-25 20:58 Message: Logged In: YES user_id=945502 Oops -- wrong order of association. ... self.args = args[2:] + func.args ... d = func.kw.copy() ... d.update(kw) should have been ... self.args = func.args + args[2:] ... kw.update(func.kw) ... self.kw = kw hopefully these errors didn't confuse my intent too much. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-25 20:53 Message: Logged In: YES user_id=945502 Yes, that's much clearer. I don't remember why I couldn't get it to work this way before (I tried something quite similar to this), but I'm glad someone could figure out the simpler way to do it. ;-) One potential problem with my proposal -- it doesn't work for nested partials: py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186470>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() ('a', <__main__.C object at 0x01186370>, 'b') One possible solution would be to merge nested partials, but I'm not at all certain this solves all the problems: py> class partial(object): ... def __init__(*args, **kw): ... self = args[0] ... func = args[1] ... if isinstance(func, partial): ... self.fn = func.fn ... self.args = args[2:] + func.args ... d = func.kw.copy() ... d.update(kw) ... self.kw = d ... else: ... self.fn, self.args, self.kw = (args[1], args[2:], kw) ... def __call__(self, *args, **kw): ... if kw and self.kw: ... d = self.kw.copy() ... d.update(kw) ... else: ... d = kw or self.kw ... return self.fn(*(self.args + args), **d) ... def __get__(self, obj, type=None): ... if obj is None: ... return self ... return partial(self.fn, obj, *self.args, **self.kw) ... py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186BB0>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() (<__main__.C object at 0x01186650>, 'b', 'a') On the other hand, merging nested partials does reduce the number of function calls, so perhaps it's useful in and of itself... ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-25 20:45 Message: Logged In: YES user_id=1038590 If the __get__ method is added to make partial functions behave like instance methods, the documentation should probably mention that classmethod() and staticmethod() can then be used to alter the behaviour: Py> def f(*args): ... print args ... Py> class C: ... a = functional.partial(f) ... b = classmethod(functional.partial(f)) ... c = staticmethod(functional.partial(f)) ... Py> C().a Py> C().a() (<__main__.C instance at 0x009E6698>,) Py> C().b() (,) Py> C().c() () (This example used the simpler __get__ implementation I posted earlier) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-25 20:27 Message: Logged In: YES user_id=1038590 Steve's suggestion does sound good, but can't it simply be implemented with the PEP implementation and the following __get__ method?: def __get__(self, obj, type=None): if obj is None: return self return partial(self.func, obj, *self.args, **self.kwargs) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-25 20:17 Message: Logged In: YES user_id=1038590 Peter Harris already wrote docs in Patch 931007. Presumably they are still accurate, or perky would have said something. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-25 13:34 Message: Logged In: YES user_id=21627 In this form, the patch cannot be applied, since it lacks documentation changes. It might be that perky does not consider himself fluent enough in English to write the documentation - any other volunteers? I also think there is value to bediviere's point, even though the PEP currently specifies partial() differently. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-19 13:38 Message: Logged In: YES user_id=945502 It might be nice if partial objects were usable as instancemethods, like functions are. Note the following behavior with the current patch: >>> import functional >>> class C(object): ... pass ... >>> def func(self, arg): ... return arg ... >>> for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... >>> C().a() Traceback (most recent call last): File "", line 1, in ? TypeError: func() takes exactly 2 arguments (1 given) If functional.partial was instead defined like: class partial(object): def __init__(*args, **kwargs): self = args[0] try: self.func = args[1] except IndexError: raise TypeError('expected 2 or more arguments, got ' % len(args)) self.obj = () self.args = args[2:] self.kwargs = kwargs def __call__(self, *args, **kwargs): if kwargs and self.kwargs: d = self.kwargs.copy() d.update(kwargs) else: d = kwargs or self.kwargs return self.func(*(self.obj + self.args + args), **d) def __get__(self, obj, type=None): if obj is None: return self result = partial(self.func, *self.args, **self.kwargs) result.obj = (obj,) return result where an appropriate __get__ method is provided, then partial objects behave properly when set as attributes to a class: py> def test(): ... class C(object): ... pass ... def func(self, arg): ... return arg ... for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... c = C() ... return c.a(), c.b(), c.c() ... py> test() ('a', 'b', 'c') ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-10 18:11 Message: Logged In: YES user_id=1038590 I have tested this patch on Windows, and it passes its own test suite, without affecting any other tests. However, PCBuild\pythoncore.vcproj & PC\config.c require modification to allow Python to pick up the new module correctly. Patch #1006948 created with the needed changes (also removes unneeded ODBC references from pythoncore.vcproj as I am using the free MS toolkits to build here) My patch definitely needs to be checked by someone with a copy of Vis Studio 2003! ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-08-03 14:23 Message: Logged In: YES user_id=113328 OK, a real need beats my theoretical worries :-) Consider me convinced. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-05-17 22:05 Message: Logged In: YES user_id=139309 I would use partial in situations where speed can matter (imap, commonly used event handlers, etc.), so a fast C implementation would be nice to have. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 02:03 Message: Logged In: YES user_id=113328 Yes, that looks like a significant speed improvement :-) I was basing my assumptions on the comments made in the PEP. Sorry. But I still wonder if having the implementation in Python wouldn't be better from a maintenance point of view. (As well as all the arguments about usefulness as sample code, ability to backport, etc etc, that have come up on python-dev regarding moving other Python library modules into C...). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-04-26 20:05 Message: Logged In: YES user_id=55188 Python-version (function) ... 1.19 2.69 Python-version (class) ... 2.61 2.38 C-version ... 0.50 0.37 (former value is for 100000 instanciations and latter is for 100000 calls.) And, C version have a facility that changing attributes after the instantiation that is supported by class version only. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-26 13:30 Message: Logged In: YES user_id=113328 Why implement this in C? I can't imagine that the performance improvement will be that significant. A pure Python module in the standard library seems to me to be a far better idea. As the PEP says, "the case for a built-in coded in C is not very strong". And a Python module is good self-documentation. I prefer the function version suggested in the PEP (credited to Carl Banks) over the class-based one. You need to take a little care to avoid capturing argument names: def partial(*args, **kwds): def callit(*moreargs, **morekwds): kw = kwds.copy() kw.update(morekwds) return args[0](*(args[1:]+moreargs), **kw) return callit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 From noreply at sourceforge.net Sat Feb 26 06:27:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 26 06:27:25 2005 Subject: [Patches] [ python-Patches-941881 ] PEP309 Partial implementation Message-ID: Patches item #941881, was opened at 2004-04-26 04:05 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: PEP309 Partial implementation Initial Comment: This patch implements functional module which is introduced by PEP309. It has only 'partial' function as its member in this stage. Unittest code is copied and modified slightly from Patch #931010 by Peter Harris. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 15:27 Message: Logged In: YES user_id=1038590 Moving the discussion to python-dev :) ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-26 13:58 Message: Logged In: YES user_id=945502 Oops -- wrong order of association. ... self.args = args[2:] + func.args ... d = func.kw.copy() ... d.update(kw) should have been ... self.args = func.args + args[2:] ... kw.update(func.kw) ... self.kw = kw hopefully these errors didn't confuse my intent too much. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-26 13:53 Message: Logged In: YES user_id=945502 Yes, that's much clearer. I don't remember why I couldn't get it to work this way before (I tried something quite similar to this), but I'm glad someone could figure out the simpler way to do it. ;-) One potential problem with my proposal -- it doesn't work for nested partials: py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186470>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() ('a', <__main__.C object at 0x01186370>, 'b') One possible solution would be to merge nested partials, but I'm not at all certain this solves all the problems: py> class partial(object): ... def __init__(*args, **kw): ... self = args[0] ... func = args[1] ... if isinstance(func, partial): ... self.fn = func.fn ... self.args = args[2:] + func.args ... d = func.kw.copy() ... d.update(kw) ... self.kw = d ... else: ... self.fn, self.args, self.kw = (args[1], args[2:], kw) ... def __call__(self, *args, **kw): ... if kw and self.kw: ... d = self.kw.copy() ... d.update(kw) ... else: ... d = kw or self.kw ... return self.fn(*(self.args + args), **d) ... def __get__(self, obj, type=None): ... if obj is None: ... return self ... return partial(self.fn, obj, *self.args, **self.kw) ... py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186BB0>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() (<__main__.C object at 0x01186650>, 'b', 'a') On the other hand, merging nested partials does reduce the number of function calls, so perhaps it's useful in and of itself... ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 13:45 Message: Logged In: YES user_id=1038590 If the __get__ method is added to make partial functions behave like instance methods, the documentation should probably mention that classmethod() and staticmethod() can then be used to alter the behaviour: Py> def f(*args): ... print args ... Py> class C: ... a = functional.partial(f) ... b = classmethod(functional.partial(f)) ... c = staticmethod(functional.partial(f)) ... Py> C().a Py> C().a() (<__main__.C instance at 0x009E6698>,) Py> C().b() (,) Py> C().c() () (This example used the simpler __get__ implementation I posted earlier) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 13:27 Message: Logged In: YES user_id=1038590 Steve's suggestion does sound good, but can't it simply be implemented with the PEP implementation and the following __get__ method?: def __get__(self, obj, type=None): if obj is None: return self return partial(self.func, obj, *self.args, **self.kwargs) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 13:17 Message: Logged In: YES user_id=1038590 Peter Harris already wrote docs in Patch 931007. Presumably they are still accurate, or perky would have said something. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-26 06:34 Message: Logged In: YES user_id=21627 In this form, the patch cannot be applied, since it lacks documentation changes. It might be that perky does not consider himself fluent enough in English to write the documentation - any other volunteers? I also think there is value to bediviere's point, even though the PEP currently specifies partial() differently. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-20 06:38 Message: Logged In: YES user_id=945502 It might be nice if partial objects were usable as instancemethods, like functions are. Note the following behavior with the current patch: >>> import functional >>> class C(object): ... pass ... >>> def func(self, arg): ... return arg ... >>> for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... >>> C().a() Traceback (most recent call last): File "", line 1, in ? TypeError: func() takes exactly 2 arguments (1 given) If functional.partial was instead defined like: class partial(object): def __init__(*args, **kwargs): self = args[0] try: self.func = args[1] except IndexError: raise TypeError('expected 2 or more arguments, got ' % len(args)) self.obj = () self.args = args[2:] self.kwargs = kwargs def __call__(self, *args, **kwargs): if kwargs and self.kwargs: d = self.kwargs.copy() d.update(kwargs) else: d = kwargs or self.kwargs return self.func(*(self.obj + self.args + args), **d) def __get__(self, obj, type=None): if obj is None: return self result = partial(self.func, *self.args, **self.kwargs) result.obj = (obj,) return result where an appropriate __get__ method is provided, then partial objects behave properly when set as attributes to a class: py> def test(): ... class C(object): ... pass ... def func(self, arg): ... return arg ... for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... c = C() ... return c.a(), c.b(), c.c() ... py> test() ('a', 'b', 'c') ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 10:11 Message: Logged In: YES user_id=1038590 I have tested this patch on Windows, and it passes its own test suite, without affecting any other tests. However, PCBuild\pythoncore.vcproj & PC\config.c require modification to allow Python to pick up the new module correctly. Patch #1006948 created with the needed changes (also removes unneeded ODBC references from pythoncore.vcproj as I am using the free MS toolkits to build here) My patch definitely needs to be checked by someone with a copy of Vis Studio 2003! ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-08-04 06:23 Message: Logged In: YES user_id=113328 OK, a real need beats my theoretical worries :-) Consider me convinced. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-05-18 14:05 Message: Logged In: YES user_id=139309 I would use partial in situations where speed can matter (imap, commonly used event handlers, etc.), so a fast C implementation would be nice to have. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 18:03 Message: Logged In: YES user_id=113328 Yes, that looks like a significant speed improvement :-) I was basing my assumptions on the comments made in the PEP. Sorry. But I still wonder if having the implementation in Python wouldn't be better from a maintenance point of view. (As well as all the arguments about usefulness as sample code, ability to backport, etc etc, that have come up on python-dev regarding moving other Python library modules into C...). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-04-27 12:05 Message: Logged In: YES user_id=55188 Python-version (function) ... 1.19 2.69 Python-version (class) ... 2.61 2.38 C-version ... 0.50 0.37 (former value is for 100000 instanciations and latter is for 100000 calls.) And, C version have a facility that changing attributes after the instantiation that is supported by class version only. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 05:30 Message: Logged In: YES user_id=113328 Why implement this in C? I can't imagine that the performance improvement will be that significant. A pure Python module in the standard library seems to me to be a far better idea. As the PEP says, "the case for a built-in coded in C is not very strong". And a Python module is good self-documentation. I prefer the function version suggested in the PEP (credited to Carl Banks) over the class-based one. You need to take a little care to avoid capturing argument names: def partial(*args, **kwds): def callit(*moreargs, **morekwds): kw = kwds.copy() kw.update(morekwds) return args[0](*(args[1:]+moreargs), **kw) return callit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 From noreply at sourceforge.net Sat Feb 26 22:39:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 26 22:39:50 2005 Subject: [Patches] [ python-Patches-909005 ] asyncore fixes and improvements Message-ID: Patches item #909005, was opened at 2004-03-03 16:07 Message generated for change (Comment added) made by klimkin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=909005&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexey Klimkin (klimkin) Assigned to: A.M. Kuchling (akuchling) Summary: asyncore fixes and improvements Initial Comment: Minor: * 0/1 for boolean values replaced with False/True. * (887279) Added handling of POLLPRI as POLLIN. POLLERR, POLLHUP, POLLNVAL are handled as exception event. handle_expt_event gets recent error from self.socket object and raises socket.error. * Default readable()/writable() returns False. * Added "map" parameter for file_dispatcher. * file_wrapper: removed "return" in close(), recv/read and send/write swapped because of their nature. * mac code for writable() removed. Manual for accept() on mac is similar to the one on linux. * Repeating exception changed from "raise socket.error, why" to raise. * Added connected/accepting/addr reset on close(). Initialization of variables moved to __init__. * close_all() now calls close for dispatcher object, EBADF treated as already closed socket/file. * Added channel id to "unhandled..." messages. Bugs: * Fixed bug (654766,889153): client never gets connected, nor errored. Connecting client gets writable event from select(), however, some client may want always be non writable. Such client may never get connected. The fix adds _readable() - always True for accepting and always False for connecting socket; and _writable() - always False for accepting and always True for connecting socket. This implies, that listening dispatcher's readable() and writable() will never be called. ("man accept" and "man connect" for non-blocking sockets). * Fixed bug: error handling after accept(). It's said, that accept can return EWOULDBLOCK even for readable socket. This mean, that even after handle_accept(), dispatcher's accept() still raise EWOULDBLOCK. New code does accept() itself and stores accepted socket in self.__pending_accept. If there was socket.error, it's treated as EWOULDBLOCK. dispatcher's accept returns self.__pending_accept and resets it to None. Features: * Added pending_read() and pending_write(). The functions helps to use dispatcher over non socket objects with buffering capabilities. In original dispatcher, if socket makes buffered read and some data is in buffer, entering asyncore.poll() doesn't finishes, since there is no data in real file/socket. This feature allow to use SSL socket, since the socket reads data by 16k chunks. ---------------------------------------------------------------------- >Comment By: Alexey Klimkin (klimkin) Date: 2005-02-27 00:39 Message: Logged In: YES user_id=410460 Minor improvements: * Added handle_close_event(): calls handle_close(), then closes channel. No need to write self.close() in each handle_close (). * Improved exception handling. KeyboardInterrupt is not blocked. For python exception handle_error_event() is called, which checks for KeyboardInterrupt and closes socket, if handle_error didn't. Bugs: * Calling connect() could raise exception and doesn't hit handle_error(). Now if there was an exception, handle_error_event() is called. Features: * set_timeout(): Sets timeout for dispatcher object, if there was no io for the object, raises ETIMEDOUT, which handled by handle_error_event(). * Fixed issue with Windows - too many descriptors in select(). The list of sockets shuffled and only first asyncore.max_channels used in select(). * Added set_prio(): Sets priority for dispatcher. After shuffle the list of sockets sorted by priority. You may also check asynhttplib - asynchronous version of httplib. ---------------------------------------------------------------------- Comment By: Alexey Klimkin (klimkin) Date: 2004-07-02 17:44 Message: Logged In: YES user_id=410460 In addition to "[ 909005 ] asyncore fixes and improvements" and CVS version "asyncore.py,v 2.51" this patch provides: * Added handling of buffered socket layer (pending_read(), pending_write()). * Added fd number for __repr__. * Initialized self.socket = socket._closedsocket() instead of None for verbose error output (like closed socket.socket). * asyncore and asynchat implements idispatcher and iasync_chat. * Fixed self.addr initialization. * Removed import exceptions. * Don't filter KeyboardInterrupt, just pass through. * Added queue of sockets, solves the problem of select() on too many descriptors. I have run make test in python cvs distrib without problems. Examples of using i* included. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-06-05 21:54 Message: Logged In: YES user_id=11375 I've struggled to get the test suite running without errors on my machine, but have failed. ---------------------------------------------------------------------- Comment By: Alexey Klimkin (klimkin) Date: 2004-03-22 09:15 Message: Logged In: YES user_id=410460 There is no real reason for this change, please undo. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-03-21 23:18 Message: Logged In: YES user_id=11375 In your version of file_dispatch.__init__, the .set_file() call is moved earlier; can you say why? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-03-21 23:13 Message: Logged In: YES user_id=11375 Added "map" parameter for file_dispatcher and dispatcher_with_send in CVS HEAD. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-03-21 23:08 Message: Logged In: YES user_id=11375 Repeating exception changes ('raise socket.error' -> just 'raise') checked into HEAD. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-03-21 23:02 Message: Logged In: YES user_id=11375 Mac code for writable() removed from HEAD. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-03-21 23:02 Message: Logged In: YES user_id=11375 Patch to use True/False applied to HEAD. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-03-21 22:55 Message: Logged In: YES user_id=11375 Fix for bug #887279 applied to HEAD. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-03-21 22:48 Message: Logged In: YES user_id=11375 The many number of changes in this patch make it difficult to figure out which changes fix which problem. I've created a new directory in CVS, nondist/sandbox/asyncore, that contains copies of the module with these patches applied, and will work on applying changes to the copy in dist/src. ---------------------------------------------------------------------- Comment By: Alexey Klimkin (klimkin) Date: 2004-03-17 10:15 Message: Logged In: YES user_id=410460 Sorry, unfortunately I have lost old patch file. I have atached new one. In addition to fixes, listed above, the patch includes: 1. Fix for operating on uninitialized socket. self.socket now initializes with _closed_socket(), so any operation throws EBADF. 2. Added class idispatcher - base class for dispatcher. The purpose of this class is to allow simple replacement of media(dispatcher interface) in classes, derived from dispatcher class. This is based on 'object'. I have also attached asynchat.diff - example for new-style dispatcher. Old asynchat works as well. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2004-03-11 18:49 Message: Logged In: YES user_id=9205 There is no file attached! You have to click on the checkbox next to the upload filename. This is a Sourceforge annoyance :( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=909005&group_id=5470 From noreply at sourceforge.net Sun Feb 27 05:36:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 27 05:36:09 2005 Subject: [Patches] [ python-Patches-1110248 ] patch for gzip.GzipFile.flush() Message-ID: Patches item #1110248, was opened at 2005-01-26 16:57 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1110248&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: David Schnepper (dschnepper) Assigned to: Nobody/Anonymous (nobody) Summary: patch for gzip.GzipFile.flush() Initial Comment: Ensure the compress buffer is flushed prior to the file buffer being flushed when gzip.GzipFile.flush() is invoked. Patch for bug 1110242 ---------------------------------------------------------------------- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-02-26 23:36 Message: Logged In: YES user_id=1115903 This patch appears to fix the bug as described, and running the regression tests on Python 2.5a0 (CVS HEAD) turns up no problems. Since the documentation says that a GzipFile "simulates most of the methods of a file object," I would expect GzipFile.flush() to act in the way that David described in the first paragraph of the bug report, and his patch seems to provide that as far as I can tell. Note: I only ran tests on Python 2.5a0 built with MSVC .NET on Windows XP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1110248&group_id=5470 From noreply at sourceforge.net Sun Feb 27 07:10:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 27 07:10:22 2005 Subject: [Patches] [ python-Patches-1107973 ] tarfile.ExFileObject iterators Message-ID: Patches item #1107973, was opened at 2005-01-23 16:58 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1107973&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Mitch Chapman (mitchchapman) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.ExFileObject iterators Initial Comment: Since Python 2.2 it has been possible to iterate over the lines of a file object (PEP 234). This patch provides line-by-line iterators for TarFile.extractfile. The attachment contains forward diffs for both Lib/tarfile.py and Lib/test/test_tarfile.py. ---------------------------------------------------------------------- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-02-27 01:10 Message: Logged In: YES user_id=1115903 The patch seems to work as advertised; all regression tests pass when run against 2.5a0 (CVS HEAD, built with MSVC .NET) + this patch on Windows XP. Improving the file-likeness of ExFileObject seems like a good idea to me, so I'm all for seeing this get accepted. :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1107973&group_id=5470 From noreply at sourceforge.net Sun Feb 27 07:28:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 27 07:28:13 2005 Subject: [Patches] [ python-Patches-1121142 ] ZipFile.open - read-only file-like obj for files in archive Message-ID: Patches item #1121142, was opened at 2005-02-11 19:08 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121142&group_id=5470 Category: Library (Lib) >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Alan McIntyre (ESRG) (alanmcintyre) Assigned to: Nobody/Anonymous (nobody) Summary: ZipFile.open - read-only file-like obj for files in archive Initial Comment: I originally started working on updating patch 992750, but decided after a short while to just start from scratch, so I'm posting it as a new patch. Sorry if this isn't appropriate. This patch provides a new open() method on ZipFile; this method returns a file-like object for the requested item in the archive. This file-like object only provides a read() method. ZipFile.read was modified to use the new open method (this was suggested by loewis in reference to patch 992750). The patched zipfile.py passed the existing tests in the test_zipfile.py from CVS. New tests were added to verify the operation of the object returned by open(). These tests were modeled after existing tests for ZipFile.read(); two read fixed-size chunks from the file-like object, and two others read random-sized chunks. I have only run the tests on Windows XP, using Python2.4 from the official Windows installer. I will test the patch out on Linux over the weekend. If the patch is accepted I'll also generate and submit patches for the appropriate documentation as well. ---------------------------------------------------------------------- >Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-02-27 01:28 Message: Logged In: YES user_id=1115903 zipfile_patch2.tgz: I updated the file-like object to support readline, readlines, __iter__ and next(). Added tests for those new methods. Also added a patch for the documentation. Passes regression tests on 2.5a0 built from CVS HEAD with MSVC .NET on Windows XP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121142&group_id=5470 From noreply at sourceforge.net Sun Feb 27 15:41:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 27 15:41:29 2005 Subject: [Patches] [ python-Patches-985713 ] bug skipping optional keyword arguments of type "w#" Message-ID: Patches item #985713, was opened at 2004-07-06 13:37 Message generated for change (Comment added) made by mdehoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=985713&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark D. Roth (mdr0) Assigned to: Nobody/Anonymous (nobody) Summary: bug skipping optional keyword arguments of type "w#" Initial Comment: When using PyArg_ParseTupleAndKeywords(), if you use "w#" as an optional keyword argument, you cannot skip it and still specify an optional argument that follows it. For example, take the following function: static PyObject * dummy_func(PyObject *self, PyObject *args, PyObject *kwds) { char *string; char *buf = NULL; int bufsize = 0; unsigned short ushort = 5; static char *kwlist[] = { "string", "buffer", "ushort", NULL }; if (! PyArg_ParseTupleAndKeywords(args, kwds, "s|w#H", kwlist, &string, &buf, &bufsize, &ushort)) return NULL; printf("buf=%p, bufsize=%d, ushort=%hu\n", buf, bufsize, ushort); snprintf(buf, bufsize, "you said \%s\\n", hostname); return Py_BuildValue("s", hostname); } You can call this function successfully as follows: # don't specify buffer or ushort dummy_func("text") Or like this: # specify buffer buf = array.array('c', [' ' for x in range(0, 1023)]) dummy_func("text", buffer=buf) Or like this: # specify buffer and ushort buf = array.array('c', [' ' for x in range(0, 1023)]) dummy_func("text", buffer=buf, ushort=10) However, the following does NOT work: # specify ushort without first specifying buffer dummy_func("text", ushort=10) It fails with the following error: Traceback (most recent call last): File "", line 1, in ? TypeError: argument 2 impossible This is because the skipitem() function in Python/getargs.c does not know how to skip arguments for the "w#" format unit. I've attached a patch that fixes this. Note that skipitem() is also missing code for many other legal format units, in addition to "w" and "w#". In particular: u, u# (see patch #853890) es, es# et, et# I (capital i) k K D S U t# (tuple) It might be a good idea to refactor the code so that if/when new format units are added, the same code will handle them for both skipitem() and convertsimple(). ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-27 23:41 Message: Logged In: YES user_id=488897 I applied your patch and ran the Python test suite, finding no problems with this patch. I'll send a patch review to python-dev. ---------------------------------------------------------------------- Comment By: Mark D. Roth (mdr0) Date: 2004-07-06 13:42 Message: Logged In: YES user_id=994239 Whoops! You'll need to change "hostname" to "string" in that example function. I missed a few occurances of that variable when I renamed it to make the example more clear... *sheepish grin* ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=985713&group_id=5470 From noreply at sourceforge.net Sun Feb 27 16:22:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 27 16:23:00 2005 Subject: [Patches] [ python-Patches-1101726 ] Patch for potential buffer overrun in tokenizer.c Message-ID: Patches item #1101726, was opened at 2005-01-13 06:45 Message generated for change (Comment added) made by glchapman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1101726&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for potential buffer overrun in tokenizer.c Initial Comment: The fp_readl function in tokenizer.c has a potential buffer overrun; see: www.python.org/sf/1089395 It is also triggered by trying to generate the pycom file for the Excel 11.0 typelib, which is where I ran into it. The attached patch allows successful generation of the Excel file; it also runs the fail.py script from the above report without an access violation. It also doesn't break any of the tests in the regression suite (probably something like fail.py should be added as a test). It is not as efficient as it might be; with a function for determining the number of unicode characters in a utf8 string, you could avoid some memory allocations. Perhaps such a function should be added to unicodeobject.c? And, of course, the patch definitely needs review. I'm especially concerned that my use of tok->decoding_buffer might be violating some kind of assumption that I missed. ---------------------------------------------------------------------- >Comment By: Greg Chapman (glchapman) Date: 2005-02-27 06:22 Message: Logged In: YES user_id=86307 After thinking about it some more, I realized that fp_readl doesn?t have to do any utf8 manipulation. If the string it copies into the buffer does not include a \n, the buffer is expanded and fp_readl is called again until a \n is returned (or the end of the file is reached). It doesn?t matter if, during this loop, the buffer contains temporarily broken utf8 characters. So I?m attaching another new patch. This copies as many characters as fit into the buffer and saves any overflow into a new string object (stored in tok >decoding_buffer). When it is called again by the loop, it uses this overflow string to copy characters into the buffer. I?m also attaching a zip file with a modified test_pep263.py and some ancillary files. To test fp_readl, python needs to read from a file. Perhaps it would be better to generate temporary files rather than include these extra files. Also, although the tests will trigger the assert using a debug build of the 2.4 source, I?m not getting an access violation running regrtest against a release build (of 2.4) ? perhaps different tests are in order? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-02-23 10:48 Message: Logged In: YES user_id=89016 I think the patch looks good. Staring at it for a while I believe the reference counts are OK. Can you incorporate fail.py into the test suite? ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-01-23 05:26 Message: Logged In: YES user_id=86307 I'm attaching a new patch (tokenizer.c.2.diff), which should be better since it avoids some unnecessary allocations and decoding/encoding. Hopefully, I haven't made any unwarranted assumptions about UTF8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1101726&group_id=5470 From noreply at sourceforge.net Sun Feb 27 17:59:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 27 18:00:00 2005 Subject: [Patches] [ python-Patches-977553 ] Speed up EnumKey call Message-ID: Patches item #977553, was opened at 2004-06-22 10:22 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=977553&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Garth Bushell (garth42) Assigned to: Nobody/Anonymous (nobody) Summary: Speed up EnumKey call Initial Comment: This patch removes the RegQueryInfoKey call and replaces it with a call to EnumKeyEx. This greatly speeds up this call. The script below times python 2.3 5531 89.7130000591 python 2.4 +patch 5531 0.0469999313354 start = time.time() i = 0 try: while 1: _winreg.EnumKey(_winreg.HKEY_CLASSES_ROOT, i) i += 1 except WindowsError: pass print i, time.time() - start ---------------------------------------------------------------------- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-02-27 11:59 Message: Logged In: YES user_id=1115903 I think it's a good idea to get 16-bit Windows functions out of Python per Microsoft's recommendation, especially when doing so can also help performance. It looks like this patch still needs some cleanup and a test or two. If nobody else wants to do it I can probably finish it up. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-26 07:31 Message: Logged In: YES user_id=21627 Also, please follow the Python style guide for C code, PEP 7. In particular: - use tabs for indentation, with a tab being worth 8 spaces - omit spaces after opening and before closing parens - put the opening brace of a code block on the same line as the keyword ---------------------------------------------------------------------- Comment By: Garth Bushell (garth42) Date: 2004-07-14 11:12 Message: Logged In: YES user_id=45280 mmangino: Yes you're correct it should be 256 in both cases. Doh! I'll attach a new patch in a while. but It's easy to mmodify the patch and up the linit to 256 theller: The advantage of the latter is it returns the Length of the string returned so we can pass it straight back to the string creation funtion in python without a strlen. also the SDK says this.... Note This function is provided only for compatibility with 16-bit versions of Windows. Applications should use the RegEnumKeyEx function. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-14 10:54 Message: Logged In: YES user_id=11105 I'm curious: Why did you replace RegEnumKey with RegEnumKeyEx? Are there any advantages of the latter? ---------------------------------------------------------------------- Comment By: Mike Mangino (mmangino) Date: 2004-07-14 09:12 Message: Logged In: YES user_id=74879 This looks good to me, but I think the buffer size is off by one. I read the SDK to say tha they key can be 255 characters. That means you need to allocate 256 characters to allow for the null terminator. Could you create a test case for a max length registry key? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=977553&group_id=5470 From noreply at sourceforge.net Sun Feb 27 18:01:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 27 18:01:27 2005 Subject: [Patches] [ python-Patches-1075147 ] Flush stdout/stderr if closed (fix for bug 1074011) Message-ID: Patches item #1075147, was opened at 2004-11-29 05:50 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1075147&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ben Hutchings (wom-work) Assigned to: Nobody/Anonymous (nobody) Summary: Flush stdout/stderr if closed (fix for bug 1074011) Initial Comment: This sets the close function pointers for sys.stdout and sys.stderr to point to fflush rather than be NULL, so that if a program explicitly closes stdout or stderr it can detect a write error then. ---------------------------------------------------------------------- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-02-27 12:01 Message: Logged In: YES user_id=1115903 This change already seems to have been made (in a slightly different form), and the referenced bug is closed out. Recommend closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1075147&group_id=5470 From noreply at sourceforge.net Sun Feb 27 18:03:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 27 18:03:33 2005 Subject: [Patches] [ python-Patches-1104111 ] setup.py --help and --help-commands altered. Message-ID: Patches item #1104111, was opened at 2005-01-17 14:51 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104111&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Titus Brown (titus) Assigned to: Nobody/Anonymous (nobody) Summary: setup.py --help and --help-commands altered. Initial Comment: (discussed on the distutils-sig list) Altered --help output to give some example commands up front. Altered --help-commands to give a clearer description of 'clean'. ---------------------------------------------------------------------- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-02-27 12:03 Message: Logged In: YES user_id=1115903 This doesn't break anything, adds some helpful content to the help text, and got one 1+ (and no negative comments) over on distutils-sig: http://mail.python.org/pipermail/distutils-sig/2005-January/004378.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104111&group_id=5470 From noreply at sourceforge.net Sun Feb 27 19:58:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 27 19:58:13 2005 Subject: [Patches] [ python-Patches-709744 ] CALL_ATTR opcode Message-ID: Patches item #709744, was opened at 2003-03-25 23:16 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: CALL_ATTR opcode Initial Comment: The result of the PyCore sprint of me and Brett: the CALL_ATTR opcode (LOAD_ATTR and CALL_FUNCTION combined) that skips the PyMethod creation and destruction for classic classes (but not newstyle classes, yet.) The code is somewhat rough yet, it needs commenting, some renaming, and most importantly testing. It seems to work, however, and provides between a 35% and 5% speedup. (5% in 'average' code, up to 35% in instance method calls and instance creation alone.) It also needs to be updated to include newstyle classes. I will likely work on this on the flight home. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-02-27 18:58 Message: Logged In: YES user_id=4771 By the way, I didn't see discussed anywhere the fact that the present optimization introduces a semantic change: in 'x.name(expr)' it evaluates 'expr' before calling 'x.__getattribute__("name")'. If we don't care, fine. If we do, it seems to me the whole approach is doomed... ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-05-02 12:53 Message: Logged In: YES user_id=34209 Well, I just re-used the call-profiling stuff that Jeremy (I think) already put in, but I don't see much use for getting people to run it. It shows the expected number of CALL_ATTR uses in e.g. pystone, no unexpected overheads inside modules or anything. The problem with the code isn't mispredicted branches, but general slowdown if *none* of the branches are taken. The only result I can think of of having people run with call-profiling on would be to find out we need to special-case other common tp_getattro functions -- which would result in more code and thus likely more general slowdown. However, patch with CALL_PROFILEing atatched. The call profile code changed somewhat, as this code returns a dict of counters, instead of a tuple. I found a 21-element tuple somewhat unwieldy :) I use a code snippet like: print "Call stats:" items = sys.callstats().items() items = [(value, key) for key, value in items] items.sort() items.reverse() for value,key in items: print "%30s: %30s"%(key, value) at the end of testing code (pystone, regrtest, etc.) Don't forget to #define CALL_PROFILE somewhere. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-23 18:11 Message: Logged In: YES user_id=6380 A suggestion: put some static global counters in the new code that count how many times each of the significant branches are taken, and a little routine that prints out the counts on exit. Then people can run various benchmarks and report the numbers, and that may help you decide which paths are worth more work... ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-23 11:43 Message: Logged In: YES user_id=34209 I'd not be proud in any case; neither the concept nor most of the implementation was my idea :-) But my questions still stand; the 3% slowdown in pystone is a lot if all you see is a 1.5% gain in Zope3 startup time, but I can't think of any ways to fix that before next friday, or before 2.3 is released. (The problem is either code size or switch length, which can be 'fixed' by culling code, re-ordering the switch again or changing the switch into a computed-goto.) And I'd need to find me a machine with less cache to actually notice the slowdown :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 12:38 Message: Logged In: YES user_id=6380 However, you should be proud of yourself nevertheless. On the same Zope3 startup "benchmark", Raymond Hettinger's bytecode optimizations scored 0% improvement. Python -O didn't make any difference either. So it's a touch benchmark! (And yes, I did remove the .pyc/.pyo files each time.) (And no, I can't test -OO because Zope uses the docstrings.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 12:20 Message: Logged In: YES user_id=6380 OK, I did a more realistic benchmark: startup time of Zope3. With more or less current CVS Python 2.3 (but not Raymond H's bytecode optimizations), it took 3.52 seconds. With your patch (and all .pyc files rebuilt) it took 3.47 seconds. That's about a percent and a half. (With Python 2.2 it took 4.08 seconds.) ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-21 22:48 Message: Logged In: YES user_id=34209 Pystone is not likely to show much speedup, as it contains exactly 2 instances of CALL_ATTR, only barely in the main loop. However, it should not slow down because of CALL_ATTR either; the two CALL_ATTRs are of the most optimized sort, old-style instance methods, and none of the other code paths have changed *at all* (in the fast-and-ugly mode of the patch, which is the default.) There are only two reasons I can think of that explain a slower pystone: code cache and the switch statement layout. This apparently does not influence my (somewhat high-end-ish) test machines, but does yours (and others.) Both are more or less outside my control. They might be fixed by switch reordering or rearranging of the code so the compiler optimizes it better, but that's very platform specific and lacking a proper test-bed for that situation, I can't do it. Alternatively, there may be some funk with regards to bytecode version. If bytecode wasn't properly regenerated, I can imagine not seeing *any* speedup. Have you tried something as simple as ./python timeit.py -s 'class X:' -s ' def spam(self): pass' -s 'x = X()' 'x.spam()' ? This gives a good 30% speedup on my home PC. Bytecode problems wouldn't influence pystone though. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-19 18:42 Message: Logged In: YES user_id=6380 Alas, like others, I see a tiny slowdown on pystone (maybe 3 percent). This is with the default version of patch version 4 (fixed). ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-18 22:48 Message: Logged In: YES user_id=34209 Oops, that patch contained a C++-ism, ceval.c:3504 and 3505 needed to be swapped. Uploaded a new version. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-18 22:22 Message: Logged In: YES user_id=34209 Alright, here is a re-worked patch, with a toggle to choose between a blatant copy-paste and some refactoring; see below. The patch works by creating a new opcode, CALL_ATTR, which is used for all <expression>.<name>(<args>) occurances. What <expression> and <args> are, is not important, they are compiled separately. The CALL_ATTR opcode implementation is optimized for two special cases: one where <expression> resulted in an (old-style) instance, and one where <expression> resulted in an instance of a new-style type of which the tp_getattro is PyObject_GenericGetAttr. The PyInstance part is done by savagely short-cutting the usual getattr dance for instances; if it sees anything but a PyFunction, it will fall back to a slow path. The rationale is that if X in 'X.spam(' is an old-style class, and that expression is not going to raise an exception, it is very rare for 'spam' to be anything but a PyFunction. Trying to cope with all the idiosyncracies of would slow down the common case too much. The PyObject_GenericGetAttr version uses a slightly modified version of PyObject_GenericGetAttr that, when finding a descr of the desired name, doesn't call the 'descr_get' method but returns a status flag. The caller (call_attr) then decides based on the type of the descr whether to call descr_get or not. It currently only specialcases PyFunctions. PyCFunctions, PyStaticMethods and PyClassMethods are tricky to specialcase and/or need some of the massaging that descr_get would do. I have not yet looked at other callable descr's. I had initially rewritten PyObject_GenericGetAttr() to use the modified version, but this appears to be a significant performance hit in normal attribute retrieval (quite common, on newstyle classes.) Likewise, Brett and I had refactored the call_function part of call_attr and call_function into a separate function, but that, too, was a big hit in the common function-calling case. Unfortunately, not doing that refactoring means a lot of copied code, so I included both in the patch. It may be that the slow path can be optimized by simplyfying the refactored parts so that the compiler understands how to inline them (e.g. the stackpointer fudging call_function/call_callable does.) The default is the ugly-but-fast way, define CALL_ATTR_SLOW_BUT_PRETTY_PATH to use the slow(er) path. The slow(er) path is enough slower to nullify the benefit of the patch in most of the benchmarks I ran; the fast path is only slightly slower in some areas (probably due to cache dynamics) but faster in every other situations, including unexpected areas (that's not cache dynamics, of course, that's just coder brilliance. :-) However, finding a good benchmark is near impossible. I added some newstyle-classes tests to PyBench, but even normal tests were giving bizarrely negative results. Checking those results with small scripts of timeit.py showed entirely different results. And when pybench reported a total 2% slowdown in the 'slow path' new code, it managed to report that about 5% faster, consistently. timeit.py is more consistent, and helped me determine the 'slow path' was really slowing things down. Calling an empty method with no arguments is about 20% faster for newstyle classes and about 30% for oldstyle classes, according to timeit.py. Still no test for call_attr though. I would love for people to test the code, both paths, and give me input. I also welcome ideas on handling more descr's, I may have missed a few unwritten rules about them. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-18 00:42 Message: Logged In: YES user_id=34209 Well, currently, the neutered getattr functions just bail out and return NULL whenever they don't get what they expect. I guess they go back to being 'full' getattr's, with the exception that they 'return' two values: the retrieved object, and a status indicator (to indicate found-method and found-thing-but-not-method) Maybe the real getattr functions should be implemented in terms of the neutered version then, that would at least solve some maintenance issues :-) But time enough for that tomorrow or this weekend (if the weather doesn't keep being so terribly sunny and warm.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-18 00:29 Message: Logged In: YES user_id=6380 I would think that you should avoid the double lookups somehow... How difficult is that? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-17 23:41 Message: Logged In: YES user_id=34209 Revised patch that includes avoiding the wrapping of (Python) methods on newstyle classes as well as oldstyle classes. The patch checks to see if a particular type uses PyObject_GenericGetAttr, and if so, uses a near-copy of that function to get an unwrapped PyFunction object. PyCFunctionObject objects are not magically treated, and fall back to the slow path... PyCFunction's descr's don't have direct access to an 'unwrapped' version, they create PyCFunctionObjectss on demand based on a PyCFunction -- a function pointer. Some simple testing (using timeit.py) suggests about a 20% increase in speed for 'x.foo()' where 'x' is a newstyle class instance. However, a real-world-ish benchmark (very hard to find, for newstyle classes) suggests otherwise: running 'timeit.py' on "pass" consistently takes about 3% longer. I'm certain the problem lies in the fact that the patch doesn't consider PyCFunctions, which forces part of the slow MRO lookup and instnace-dict checking to be re-done for C-functions on newstyle types (of which there are a heck of a lot.) Either handling PyMethodDescrs the same way as PyFunctionObjects, or circumventing the slow path in some way (by returning non-method-but-found objects) will probably fix that. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-03-25 23:18 Message: Logged In: YES user_id=34209 attaching patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 From noreply at sourceforge.net Sun Feb 27 20:27:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 27 20:27:23 2005 Subject: [Patches] [ python-Patches-1121234 ] Reference count bug fix Message-ID: Patches item #1121234, was opened at 2005-02-12 07:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121234&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Martin v. L?wis (loewis) Summary: Reference count bug fix Initial Comment: In the _loadtk method of the class Tk, there are two calls self.tk.createcommand, one for 'tkerror' and one for 'exit'. In the createcommand function in _tkinter.c, there is a Py_XINCREF for the Tk widget and one for the Python function (_tkerror or _exit). The corresponding Py_XDECREFs are called (via Tkapp_DeleteCommand) in PythonCmdDelete. The Tkapp_DeleteCommand is called by the deletecommand in the destroy method of class Misc in Tkinter.py. However, the deletecommand is called only for commands listed in self._tclCommands. Now, if a command is created via the _register method in class Misc, the command is appended to self._tclCommands. However, the 'tkerror' and 'exit' commands, created in the _loadtk method of the class Tk, are not appended to self._tclCommands. Hence, the '_tkerror' and '_exit' functions as well as the Tk widget itself have an incorrect reference count. The Tkapp_Dealloc routine in _tkinter.c is not called and the Tk widget is not destroyed. The attached patch simply adds a self._tclCommands.append for 'tkerror' and 'exit'. With this patch, a Tk widget is destroyed and Tkapp_Dealloc is called correctly. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-27 20:27 Message: Logged In: YES user_id=21627 Wouldn't it be better to use _register for _tkerror and _exit as well? This patch overwrites self._tclCommands, but the object may already have a _tclCommands attribute. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121234&group_id=5470 From noreply at sourceforge.net Sun Feb 27 20:58:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 27 20:58:35 2005 Subject: [Patches] [ python-Patches-1113421 ] New tutorial tests in test_generators.py Message-ID: Patches item #1113421, was opened at 2005-01-31 15:16 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1113421&group_id=5470 Category: Tests Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Francis Girard (francisgirard) >Assigned to: Raymond Hettinger (rhettinger) Summary: New tutorial tests in test_generators.py Initial Comment: Two tests in test_generators.py makes use of an ad-hoc "LazyList" class which was a courageous attempt when it was written. This class have some problems though. This patch adds two more tests using the new itertools.tee function which favourably solves the problem -- with accompanying prose. More importantly, it shows what I think is now the best way to implement a whole family of classical FP algorithm in Python. The patch has been produce on the single file test_generators.py (without directory information). To apply it, change directory to : python/dist/src/Lib/test and simply, patch -p0 < test_generators.py.310105.diff The patch is here submitted after Craig Ringer had suggested me to do so on the python discussion list "python-list". Francis Girard FRANCE ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1113421&group_id=5470 From noreply at sourceforge.net Sun Feb 27 21:34:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 27 21:34:42 2005 Subject: [Patches] [ python-Patches-1093585 ] sanity check for readline remove/replace Message-ID: Patches item #1093585, was opened at 2004-12-31 03:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093585&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: DSM (dsm001) Assigned to: Nobody/Anonymous (nobody) Summary: sanity check for readline remove/replace Initial Comment: Fix bug 1086603 (segfault in readline) by checking for negative input indices in remove_history_item and replace_history_item; GNU code doesn't always return NULL. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-27 21:34 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as NEWS 1.1246 and 1.1193.2.22 readline.c 2.80 and 2.79.2.1 ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-01-21 06:26 Message: Logged In: YES user_id=488897 I think that both solutions would be good (certainly better than segfaulting). I'll write a patch review to the python-dev mailing list outlining the pros and cons, so hopefully a developer will look at this patch (I don't have CVS write access, so I can't apply the patch myself). ---------------------------------------------------------------------- Comment By: DSM (dsm001) Date: 2005-01-21 03:57 Message: Logged In: YES user_id=1175690 You could do it, but it'd be a larger change: e.g. get_history_item should change as well. The API isn't very listish. Right now get_history_item(-1) returns None, which I left alone because I didn't want to change any previously-working behaviour of the code, though I doubt many people are depending on that.. This comes at the cost of introducing an arguable inconsistency: get_history_item(-1) simply returns None but remove_history_item(-1) raises an error. I wasn't sure to what degree py-gnu-readline is supposed to hew to gnu-readline, so I left everything alone but the case that was segfaulting my fuzz test. :-) ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-01-21 03:20 Message: Logged In: YES user_id=488897 I have run the test suite after applying this patch, and I found no problems with it. The bug does indeed originate in the readline library, which does not return NULL if the index is negative. I sent a patch to bug-readline@gnu.org, so this will probably be fixed in future versions of readline. But I agree that for now, we need a workaround in Python. Note that there is one more way to fix this bug, which is to interpret negative indeces as counting from the end. So remove_history_item(-1) removes the last item added to the history etc. This would be more consistent with lists etc. in Python, and users may even expect this behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093585&group_id=5470 From noreply at sourceforge.net Sun Feb 27 21:43:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 27 21:43:45 2005 Subject: [Patches] [ python-Patches-941881 ] PEP309 Partial implementation Message-ID: Patches item #941881, was opened at 2004-04-25 19:05 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: PEP309 Partial implementation Initial Comment: This patch implements functional module which is introduced by PEP309. It has only 'partial' function as its member in this stage. Unittest code is copied and modified slightly from Patch #931010 by Peter Harris. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-02-27 20:43 Message: Logged In: YES user_id=113328 To build on Windows (at least with mingw gcc, I don't know about MSVC) you need to assign members of partial_type which are symbols in the Python DLL at runtime, not compile time. The following diff probably explains better: --- functionalmodule.c.orig 2005-02-27 20:41:41.000000000 +000 +++ functionalmodule.c 2005-02-26 21:41:14.000000000 +0000 @@ -197,7 +197,7 @@ 0, /* tp_hash */ (ternaryfunc)partial_call, /* tp_call */ 0, /* tp_str */ - PyObject_GenericGetAttr, /* tp_getattro */ + 0, /* tp_getattro */ 0, /* tp_setattro */ 0, /* tp_as_buffer */ Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC | @@ -220,7 +220,7 @@ 0, /* tp_init */ 0, /* tp_alloc */ partial_new, /* tp_new */ - PyObject_GC_Del, /* tp_free */ + 0, /* tp_free */ }; @@ -239,6 +239,8 @@ int i; PyObject *m; char *name; + partial_type.tp_getattro = PyObject_GenericGetAttr; + partial_type.tp_free = PyObject_GC_Del; PyTypeObject *typelist[] = { &partial_type, NULL ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 05:27 Message: Logged In: YES user_id=1038590 Moving the discussion to python-dev :) ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-26 03:58 Message: Logged In: YES user_id=945502 Oops -- wrong order of association. ... self.args = args[2:] + func.args ... d = func.kw.copy() ... d.update(kw) should have been ... self.args = func.args + args[2:] ... kw.update(func.kw) ... self.kw = kw hopefully these errors didn't confuse my intent too much. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-26 03:53 Message: Logged In: YES user_id=945502 Yes, that's much clearer. I don't remember why I couldn't get it to work this way before (I tried something quite similar to this), but I'm glad someone could figure out the simpler way to do it. ;-) One potential problem with my proposal -- it doesn't work for nested partials: py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186470>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() ('a', <__main__.C object at 0x01186370>, 'b') One possible solution would be to merge nested partials, but I'm not at all certain this solves all the problems: py> class partial(object): ... def __init__(*args, **kw): ... self = args[0] ... func = args[1] ... if isinstance(func, partial): ... self.fn = func.fn ... self.args = args[2:] + func.args ... d = func.kw.copy() ... d.update(kw) ... self.kw = d ... else: ... self.fn, self.args, self.kw = (args[1], args[2:], kw) ... def __call__(self, *args, **kw): ... if kw and self.kw: ... d = self.kw.copy() ... d.update(kw) ... else: ... d = kw or self.kw ... return self.fn(*(self.args + args), **d) ... def __get__(self, obj, type=None): ... if obj is None: ... return self ... return partial(self.fn, obj, *self.args, **self.kw) ... py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186BB0>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() (<__main__.C object at 0x01186650>, 'b', 'a') On the other hand, merging nested partials does reduce the number of function calls, so perhaps it's useful in and of itself... ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 03:45 Message: Logged In: YES user_id=1038590 If the __get__ method is added to make partial functions behave like instance methods, the documentation should probably mention that classmethod() and staticmethod() can then be used to alter the behaviour: Py> def f(*args): ... print args ... Py> class C: ... a = functional.partial(f) ... b = classmethod(functional.partial(f)) ... c = staticmethod(functional.partial(f)) ... Py> C().a Py> C().a() (<__main__.C instance at 0x009E6698>,) Py> C().b() (,) Py> C().c() () (This example used the simpler __get__ implementation I posted earlier) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 03:27 Message: Logged In: YES user_id=1038590 Steve's suggestion does sound good, but can't it simply be implemented with the PEP implementation and the following __get__ method?: def __get__(self, obj, type=None): if obj is None: return self return partial(self.func, obj, *self.args, **self.kwargs) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 03:17 Message: Logged In: YES user_id=1038590 Peter Harris already wrote docs in Patch 931007. Presumably they are still accurate, or perky would have said something. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-25 20:34 Message: Logged In: YES user_id=21627 In this form, the patch cannot be applied, since it lacks documentation changes. It might be that perky does not consider himself fluent enough in English to write the documentation - any other volunteers? I also think there is value to bediviere's point, even though the PEP currently specifies partial() differently. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-19 20:38 Message: Logged In: YES user_id=945502 It might be nice if partial objects were usable as instancemethods, like functions are. Note the following behavior with the current patch: >>> import functional >>> class C(object): ... pass ... >>> def func(self, arg): ... return arg ... >>> for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... >>> C().a() Traceback (most recent call last): File "", line 1, in ? TypeError: func() takes exactly 2 arguments (1 given) If functional.partial was instead defined like: class partial(object): def __init__(*args, **kwargs): self = args[0] try: self.func = args[1] except IndexError: raise TypeError('expected 2 or more arguments, got ' % len(args)) self.obj = () self.args = args[2:] self.kwargs = kwargs def __call__(self, *args, **kwargs): if kwargs and self.kwargs: d = self.kwargs.copy() d.update(kwargs) else: d = kwargs or self.kwargs return self.func(*(self.obj + self.args + args), **d) def __get__(self, obj, type=None): if obj is None: return self result = partial(self.func, *self.args, **self.kwargs) result.obj = (obj,) return result where an appropriate __get__ method is provided, then partial objects behave properly when set as attributes to a class: py> def test(): ... class C(object): ... pass ... def func(self, arg): ... return arg ... for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... c = C() ... return c.a(), c.b(), c.c() ... py> test() ('a', 'b', 'c') ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 01:11 Message: Logged In: YES user_id=1038590 I have tested this patch on Windows, and it passes its own test suite, without affecting any other tests. However, PCBuild\pythoncore.vcproj & PC\config.c require modification to allow Python to pick up the new module correctly. Patch #1006948 created with the needed changes (also removes unneeded ODBC references from pythoncore.vcproj as I am using the free MS toolkits to build here) My patch definitely needs to be checked by someone with a copy of Vis Studio 2003! ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-08-03 21:23 Message: Logged In: YES user_id=113328 OK, a real need beats my theoretical worries :-) Consider me convinced. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-05-18 05:05 Message: Logged In: YES user_id=139309 I would use partial in situations where speed can matter (imap, commonly used event handlers, etc.), so a fast C implementation would be nice to have. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 09:03 Message: Logged In: YES user_id=113328 Yes, that looks like a significant speed improvement :-) I was basing my assumptions on the comments made in the PEP. Sorry. But I still wonder if having the implementation in Python wouldn't be better from a maintenance point of view. (As well as all the arguments about usefulness as sample code, ability to backport, etc etc, that have come up on python-dev regarding moving other Python library modules into C...). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-04-27 03:05 Message: Logged In: YES user_id=55188 Python-version (function) ... 1.19 2.69 Python-version (class) ... 2.61 2.38 C-version ... 0.50 0.37 (former value is for 100000 instanciations and latter is for 100000 calls.) And, C version have a facility that changing attributes after the instantiation that is supported by class version only. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-26 20:30 Message: Logged In: YES user_id=113328 Why implement this in C? I can't imagine that the performance improvement will be that significant. A pure Python module in the standard library seems to me to be a far better idea. As the PEP says, "the case for a built-in coded in C is not very strong". And a Python module is good self-documentation. I prefer the function version suggested in the PEP (credited to Carl Banks) over the class-based one. You need to take a little care to avoid capturing argument names: def partial(*args, **kwds): def callit(*moreargs, **morekwds): kw = kwds.copy() kw.update(morekwds) return args[0](*(args[1:]+moreargs), **kw) return callit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 From noreply at sourceforge.net Sun Feb 27 21:43:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 27 21:43:51 2005 Subject: [Patches] [ python-Patches-941881 ] PEP309 Partial implementation Message-ID: Patches item #941881, was opened at 2004-04-25 13:05 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 Category: Library (Lib) >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: PEP309 Partial implementation Initial Comment: This patch implements functional module which is introduced by PEP309. It has only 'partial' function as its member in this stage. Unittest code is copied and modified slightly from Patch #931010 by Peter Harris. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-27 15:43 Message: Logged In: YES user_id=80475 Exposing the structure members for dynamic alteration exceeds the PEP specification. While making the tool more flexible, it slows it down (requiring type checks for every call) and it encourages strange uses. The notion of giving partial objects a changable state is at odds with the basis for functional programming (i.e. statelessness). The traverse function should use the new Py_VISIT macro. The PyCallable_Check() is unnecessary as it duplicates the check already existing in PyObject_Call(). I am not certain whether the PyDict_Copy() is necessary. Calls to f(**d) already pass a copy of d. Likewise, calling f(a=1) will create a new dictionary. If so, that dictionary can be updated in- place with pto->kw rather than creating a new dictionary. None of these issues are critical. Feel free to go forward with the patch. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-02-27 15:43 Message: Logged In: YES user_id=113328 To build on Windows (at least with mingw gcc, I don't know about MSVC) you need to assign members of partial_type which are symbols in the Python DLL at runtime, not compile time. The following diff probably explains better: --- functionalmodule.c.orig 2005-02-27 20:41:41.000000000 +000 +++ functionalmodule.c 2005-02-26 21:41:14.000000000 +0000 @@ -197,7 +197,7 @@ 0, /* tp_hash */ (ternaryfunc)partial_call, /* tp_call */ 0, /* tp_str */ - PyObject_GenericGetAttr, /* tp_getattro */ + 0, /* tp_getattro */ 0, /* tp_setattro */ 0, /* tp_as_buffer */ Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC | @@ -220,7 +220,7 @@ 0, /* tp_init */ 0, /* tp_alloc */ partial_new, /* tp_new */ - PyObject_GC_Del, /* tp_free */ + 0, /* tp_free */ }; @@ -239,6 +239,8 @@ int i; PyObject *m; char *name; + partial_type.tp_getattro = PyObject_GenericGetAttr; + partial_type.tp_free = PyObject_GC_Del; PyTypeObject *typelist[] = { &partial_type, NULL ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 00:27 Message: Logged In: YES user_id=1038590 Moving the discussion to python-dev :) ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-25 22:58 Message: Logged In: YES user_id=945502 Oops -- wrong order of association. ... self.args = args[2:] + func.args ... d = func.kw.copy() ... d.update(kw) should have been ... self.args = func.args + args[2:] ... kw.update(func.kw) ... self.kw = kw hopefully these errors didn't confuse my intent too much. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-25 22:53 Message: Logged In: YES user_id=945502 Yes, that's much clearer. I don't remember why I couldn't get it to work this way before (I tried something quite similar to this), but I'm glad someone could figure out the simpler way to do it. ;-) One potential problem with my proposal -- it doesn't work for nested partials: py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186470>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() ('a', <__main__.C object at 0x01186370>, 'b') One possible solution would be to merge nested partials, but I'm not at all certain this solves all the problems: py> class partial(object): ... def __init__(*args, **kw): ... self = args[0] ... func = args[1] ... if isinstance(func, partial): ... self.fn = func.fn ... self.args = args[2:] + func.args ... d = func.kw.copy() ... d.update(kw) ... self.kw = d ... else: ... self.fn, self.args, self.kw = (args[1], args[2:], kw) ... def __call__(self, *args, **kw): ... if kw and self.kw: ... d = self.kw.copy() ... d.update(kw) ... else: ... d = kw or self.kw ... return self.fn(*(self.args + args), **d) ... def __get__(self, obj, type=None): ... if obj is None: ... return self ... return partial(self.fn, obj, *self.args, **self.kw) ... py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186BB0>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() (<__main__.C object at 0x01186650>, 'b', 'a') On the other hand, merging nested partials does reduce the number of function calls, so perhaps it's useful in and of itself... ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-25 22:45 Message: Logged In: YES user_id=1038590 If the __get__ method is added to make partial functions behave like instance methods, the documentation should probably mention that classmethod() and staticmethod() can then be used to alter the behaviour: Py> def f(*args): ... print args ... Py> class C: ... a = functional.partial(f) ... b = classmethod(functional.partial(f)) ... c = staticmethod(functional.partial(f)) ... Py> C().a Py> C().a() (<__main__.C instance at 0x009E6698>,) Py> C().b() (,) Py> C().c() () (This example used the simpler __get__ implementation I posted earlier) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-25 22:27 Message: Logged In: YES user_id=1038590 Steve's suggestion does sound good, but can't it simply be implemented with the PEP implementation and the following __get__ method?: def __get__(self, obj, type=None): if obj is None: return self return partial(self.func, obj, *self.args, **self.kwargs) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-25 22:17 Message: Logged In: YES user_id=1038590 Peter Harris already wrote docs in Patch 931007. Presumably they are still accurate, or perky would have said something. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-25 15:34 Message: Logged In: YES user_id=21627 In this form, the patch cannot be applied, since it lacks documentation changes. It might be that perky does not consider himself fluent enough in English to write the documentation - any other volunteers? I also think there is value to bediviere's point, even though the PEP currently specifies partial() differently. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-19 15:38 Message: Logged In: YES user_id=945502 It might be nice if partial objects were usable as instancemethods, like functions are. Note the following behavior with the current patch: >>> import functional >>> class C(object): ... pass ... >>> def func(self, arg): ... return arg ... >>> for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... >>> C().a() Traceback (most recent call last): File "", line 1, in ? TypeError: func() takes exactly 2 arguments (1 given) If functional.partial was instead defined like: class partial(object): def __init__(*args, **kwargs): self = args[0] try: self.func = args[1] except IndexError: raise TypeError('expected 2 or more arguments, got ' % len(args)) self.obj = () self.args = args[2:] self.kwargs = kwargs def __call__(self, *args, **kwargs): if kwargs and self.kwargs: d = self.kwargs.copy() d.update(kwargs) else: d = kwargs or self.kwargs return self.func(*(self.obj + self.args + args), **d) def __get__(self, obj, type=None): if obj is None: return self result = partial(self.func, *self.args, **self.kwargs) result.obj = (obj,) return result where an appropriate __get__ method is provided, then partial objects behave properly when set as attributes to a class: py> def test(): ... class C(object): ... pass ... def func(self, arg): ... return arg ... for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... c = C() ... return c.a(), c.b(), c.c() ... py> test() ('a', 'b', 'c') ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-10 19:11 Message: Logged In: YES user_id=1038590 I have tested this patch on Windows, and it passes its own test suite, without affecting any other tests. However, PCBuild\pythoncore.vcproj & PC\config.c require modification to allow Python to pick up the new module correctly. Patch #1006948 created with the needed changes (also removes unneeded ODBC references from pythoncore.vcproj as I am using the free MS toolkits to build here) My patch definitely needs to be checked by someone with a copy of Vis Studio 2003! ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-08-03 15:23 Message: Logged In: YES user_id=113328 OK, a real need beats my theoretical worries :-) Consider me convinced. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-05-17 23:05 Message: Logged In: YES user_id=139309 I would use partial in situations where speed can matter (imap, commonly used event handlers, etc.), so a fast C implementation would be nice to have. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 03:03 Message: Logged In: YES user_id=113328 Yes, that looks like a significant speed improvement :-) I was basing my assumptions on the comments made in the PEP. Sorry. But I still wonder if having the implementation in Python wouldn't be better from a maintenance point of view. (As well as all the arguments about usefulness as sample code, ability to backport, etc etc, that have come up on python-dev regarding moving other Python library modules into C...). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-04-26 21:05 Message: Logged In: YES user_id=55188 Python-version (function) ... 1.19 2.69 Python-version (class) ... 2.61 2.38 C-version ... 0.50 0.37 (former value is for 100000 instanciations and latter is for 100000 calls.) And, C version have a facility that changing attributes after the instantiation that is supported by class version only. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-26 14:30 Message: Logged In: YES user_id=113328 Why implement this in C? I can't imagine that the performance improvement will be that significant. A pure Python module in the standard library seems to me to be a far better idea. As the PEP says, "the case for a built-in coded in C is not very strong". And a Python module is good self-documentation. I prefer the function version suggested in the PEP (credited to Carl Banks) over the class-based one. You need to take a little care to avoid capturing argument names: def partial(*args, **kwds): def callit(*moreargs, **morekwds): kw = kwds.copy() kw.update(morekwds) return args[0](*(args[1:]+moreargs), **kw) return callit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 From noreply at sourceforge.net Sun Feb 27 22:14:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 27 22:14:18 2005 Subject: [Patches] [ python-Patches-1153056 ] PyXxx_Check() speed-up Message-ID: Patches item #1153056, was opened at 2005-02-27 21:14 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=1153056&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: PyXxx_Check() speed-up Initial Comment: Once upon a time, the macros PyInt_Check(), PyString_Check(), etc., used to be very fast: just a pointer comparison. But 2.2 came. Suddenly, types could inherit from each other. Thus the macros became: (ob->type == &PyXxx_Check || PyType_IsSubType(ob->type, &PyXxx_Check) Subtyping of built-in types still being rare, the common cases here are: (1) ob is indeed exactly of type Xxx, (2) ob is absolutely not an instance of Xxx. The macro is fast for case 1 but becomes a call to a slow function in case 2. It sounds minor -- but a program can make half a million "case 2" calls in 5 seconds. The following patch proposes to fix that, based on a few measurements that show which are the more common "case 2" calls in a few applications. It adds a family of type flags meaning "this type is not at all an Xxx", for Xxx in [module, tuple, float, int, unicode, long, complex, str]. I cannot measure the performance gain on this machine (figures vary all the time) but it looks like some 0.2s for the above-mentioned 5s program. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1153056&group_id=5470 From noreply at sourceforge.net Sun Feb 27 23:14:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 27 23:14:38 2005 Subject: [Patches] [ python-Patches-1118341 ] unknown locale: lt_LT (patch) Message-ID: Patches item #1118341, was opened at 2005-02-08 04:39 Message generated for change (Comment added) made by nerijus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1118341&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None >Priority: 8 Submitted By: Nerijus Baliunas (nerijus) Assigned to: Nobody/Anonymous (nobody) Summary: unknown locale: lt_LT (patch) Initial Comment: When running wxPython app I get: ... from wx._core import * File "/usr/lib/python2.3/site-packages/wx-2.5.4-gtk2-ansi/wx/_core.py", line 11035, in ? default = locale.getdefaultlocale()[1] File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: lt_LT Attached patch helps. I also changed Latvian, as ISO8859-13 is an official standard in both Latvia and Lithuania, and Estonian, as they use ISO8859-15 now. Also added Windows language identifiers for all 3 languages. It can be applied to both 2.3 and 2.4. ---------------------------------------------------------------------- >Comment By: Nerijus Baliunas (nerijus) Date: 2005-02-28 00:14 Message: Logged In: YES user_id=3416 I'm increasing priority, as I have real world application (OpenDict using wxPython) not starting w/o this patch: $ opendict ... ValueError: unknown locale: lt_LT It's really a very simple patch, please apply it to both 2.3 and 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1118341&group_id=5470 From noreply at sourceforge.net Mon Feb 28 00:04:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 00:05:00 2005 Subject: [Patches] [ python-Patches-931007 ] PEP 309 LaTeX documentation Message-ID: Patches item #931007, was opened at 2004-04-07 13:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=931007&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Harris (scav) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 309 LaTeX documentation Initial Comment: Rough first draft of documentation for 'functional' module ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-28 00:04 Message: Logged In: YES user_id=21627 This patch is incorrect. It mentions a class functional.Partial which is not documented in the PEP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=931007&group_id=5470 From noreply at sourceforge.net Mon Feb 28 00:05:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 00:05:50 2005 Subject: [Patches] [ python-Patches-941881 ] PEP309 Partial implementation Message-ID: Patches item #941881, was opened at 2004-04-25 20:05 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: PEP309 Partial implementation Initial Comment: This patch implements functional module which is introduced by PEP309. It has only 'partial' function as its member in this stage. Unittest code is copied and modified slightly from Patch #931010 by Peter Harris. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-28 00:05 Message: Logged In: YES user_id=21627 It turns out that the documentation is incorrect, wrt. this patch, as it mentions a non-existing class functional.Partial. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-27 21:43 Message: Logged In: YES user_id=80475 Exposing the structure members for dynamic alteration exceeds the PEP specification. While making the tool more flexible, it slows it down (requiring type checks for every call) and it encourages strange uses. The notion of giving partial objects a changable state is at odds with the basis for functional programming (i.e. statelessness). The traverse function should use the new Py_VISIT macro. The PyCallable_Check() is unnecessary as it duplicates the check already existing in PyObject_Call(). I am not certain whether the PyDict_Copy() is necessary. Calls to f(**d) already pass a copy of d. Likewise, calling f(a=1) will create a new dictionary. If so, that dictionary can be updated in- place with pto->kw rather than creating a new dictionary. None of these issues are critical. Feel free to go forward with the patch. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-02-27 21:43 Message: Logged In: YES user_id=113328 To build on Windows (at least with mingw gcc, I don't know about MSVC) you need to assign members of partial_type which are symbols in the Python DLL at runtime, not compile time. The following diff probably explains better: --- functionalmodule.c.orig 2005-02-27 20:41:41.000000000 +000 +++ functionalmodule.c 2005-02-26 21:41:14.000000000 +0000 @@ -197,7 +197,7 @@ 0, /* tp_hash */ (ternaryfunc)partial_call, /* tp_call */ 0, /* tp_str */ - PyObject_GenericGetAttr, /* tp_getattro */ + 0, /* tp_getattro */ 0, /* tp_setattro */ 0, /* tp_as_buffer */ Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC | @@ -220,7 +220,7 @@ 0, /* tp_init */ 0, /* tp_alloc */ partial_new, /* tp_new */ - PyObject_GC_Del, /* tp_free */ + 0, /* tp_free */ }; @@ -239,6 +239,8 @@ int i; PyObject *m; char *name; + partial_type.tp_getattro = PyObject_GenericGetAttr; + partial_type.tp_free = PyObject_GC_Del; PyTypeObject *typelist[] = { &partial_type, NULL ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 06:27 Message: Logged In: YES user_id=1038590 Moving the discussion to python-dev :) ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-26 04:58 Message: Logged In: YES user_id=945502 Oops -- wrong order of association. ... self.args = args[2:] + func.args ... d = func.kw.copy() ... d.update(kw) should have been ... self.args = func.args + args[2:] ... kw.update(func.kw) ... self.kw = kw hopefully these errors didn't confuse my intent too much. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-26 04:53 Message: Logged In: YES user_id=945502 Yes, that's much clearer. I don't remember why I couldn't get it to work this way before (I tried something quite similar to this), but I'm glad someone could figure out the simpler way to do it. ;-) One potential problem with my proposal -- it doesn't work for nested partials: py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186470>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() ('a', <__main__.C object at 0x01186370>, 'b') One possible solution would be to merge nested partials, but I'm not at all certain this solves all the problems: py> class partial(object): ... def __init__(*args, **kw): ... self = args[0] ... func = args[1] ... if isinstance(func, partial): ... self.fn = func.fn ... self.args = args[2:] + func.args ... d = func.kw.copy() ... d.update(kw) ... self.kw = d ... else: ... self.fn, self.args, self.kw = (args[1], args[2:], kw) ... def __call__(self, *args, **kw): ... if kw and self.kw: ... d = self.kw.copy() ... d.update(kw) ... else: ... d = kw or self.kw ... return self.fn(*(self.args + args), **d) ... def __get__(self, obj, type=None): ... if obj is None: ... return self ... return partial(self.fn, obj, *self.args, **self.kw) ... py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186BB0>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() (<__main__.C object at 0x01186650>, 'b', 'a') On the other hand, merging nested partials does reduce the number of function calls, so perhaps it's useful in and of itself... ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 04:45 Message: Logged In: YES user_id=1038590 If the __get__ method is added to make partial functions behave like instance methods, the documentation should probably mention that classmethod() and staticmethod() can then be used to alter the behaviour: Py> def f(*args): ... print args ... Py> class C: ... a = functional.partial(f) ... b = classmethod(functional.partial(f)) ... c = staticmethod(functional.partial(f)) ... Py> C().a Py> C().a() (<__main__.C instance at 0x009E6698>,) Py> C().b() (,) Py> C().c() () (This example used the simpler __get__ implementation I posted earlier) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 04:27 Message: Logged In: YES user_id=1038590 Steve's suggestion does sound good, but can't it simply be implemented with the PEP implementation and the following __get__ method?: def __get__(self, obj, type=None): if obj is None: return self return partial(self.func, obj, *self.args, **self.kwargs) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 04:17 Message: Logged In: YES user_id=1038590 Peter Harris already wrote docs in Patch 931007. Presumably they are still accurate, or perky would have said something. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-25 21:34 Message: Logged In: YES user_id=21627 In this form, the patch cannot be applied, since it lacks documentation changes. It might be that perky does not consider himself fluent enough in English to write the documentation - any other volunteers? I also think there is value to bediviere's point, even though the PEP currently specifies partial() differently. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-19 21:38 Message: Logged In: YES user_id=945502 It might be nice if partial objects were usable as instancemethods, like functions are. Note the following behavior with the current patch: >>> import functional >>> class C(object): ... pass ... >>> def func(self, arg): ... return arg ... >>> for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... >>> C().a() Traceback (most recent call last): File "", line 1, in ? TypeError: func() takes exactly 2 arguments (1 given) If functional.partial was instead defined like: class partial(object): def __init__(*args, **kwargs): self = args[0] try: self.func = args[1] except IndexError: raise TypeError('expected 2 or more arguments, got ' % len(args)) self.obj = () self.args = args[2:] self.kwargs = kwargs def __call__(self, *args, **kwargs): if kwargs and self.kwargs: d = self.kwargs.copy() d.update(kwargs) else: d = kwargs or self.kwargs return self.func(*(self.obj + self.args + args), **d) def __get__(self, obj, type=None): if obj is None: return self result = partial(self.func, *self.args, **self.kwargs) result.obj = (obj,) return result where an appropriate __get__ method is provided, then partial objects behave properly when set as attributes to a class: py> def test(): ... class C(object): ... pass ... def func(self, arg): ... return arg ... for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... c = C() ... return c.a(), c.b(), c.c() ... py> test() ('a', 'b', 'c') ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 02:11 Message: Logged In: YES user_id=1038590 I have tested this patch on Windows, and it passes its own test suite, without affecting any other tests. However, PCBuild\pythoncore.vcproj & PC\config.c require modification to allow Python to pick up the new module correctly. Patch #1006948 created with the needed changes (also removes unneeded ODBC references from pythoncore.vcproj as I am using the free MS toolkits to build here) My patch definitely needs to be checked by someone with a copy of Vis Studio 2003! ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-08-03 22:23 Message: Logged In: YES user_id=113328 OK, a real need beats my theoretical worries :-) Consider me convinced. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-05-18 06:05 Message: Logged In: YES user_id=139309 I would use partial in situations where speed can matter (imap, commonly used event handlers, etc.), so a fast C implementation would be nice to have. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 10:03 Message: Logged In: YES user_id=113328 Yes, that looks like a significant speed improvement :-) I was basing my assumptions on the comments made in the PEP. Sorry. But I still wonder if having the implementation in Python wouldn't be better from a maintenance point of view. (As well as all the arguments about usefulness as sample code, ability to backport, etc etc, that have come up on python-dev regarding moving other Python library modules into C...). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-04-27 04:05 Message: Logged In: YES user_id=55188 Python-version (function) ... 1.19 2.69 Python-version (class) ... 2.61 2.38 C-version ... 0.50 0.37 (former value is for 100000 instanciations and latter is for 100000 calls.) And, C version have a facility that changing attributes after the instantiation that is supported by class version only. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-26 21:30 Message: Logged In: YES user_id=113328 Why implement this in C? I can't imagine that the performance improvement will be that significant. A pure Python module in the standard library seems to me to be a far better idea. As the PEP says, "the case for a built-in coded in C is not very strong". And a Python module is good self-documentation. I prefer the function version suggested in the PEP (credited to Carl Banks) over the class-based one. You need to take a little care to avoid capturing argument names: def partial(*args, **kwds): def callit(*moreargs, **morekwds): kw = kwds.copy() kw.update(morekwds) return args[0](*(args[1:]+moreargs), **kw) return callit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 From noreply at sourceforge.net Mon Feb 28 00:44:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 00:44:47 2005 Subject: [Patches] [ python-Patches-1153056 ] PyXxx_Check() speed-up Message-ID: Patches item #1153056, was opened at 2005-02-27 22:14 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1153056&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: PyXxx_Check() speed-up Initial Comment: Once upon a time, the macros PyInt_Check(), PyString_Check(), etc., used to be very fast: just a pointer comparison. But 2.2 came. Suddenly, types could inherit from each other. Thus the macros became: (ob->type == &PyXxx_Check || PyType_IsSubType(ob->type, &PyXxx_Check) Subtyping of built-in types still being rare, the common cases here are: (1) ob is indeed exactly of type Xxx, (2) ob is absolutely not an instance of Xxx. The macro is fast for case 1 but becomes a call to a slow function in case 2. It sounds minor -- but a program can make half a million "case 2" calls in 5 seconds. The following patch proposes to fix that, based on a few measurements that show which are the more common "case 2" calls in a few applications. It adds a family of type flags meaning "this type is not at all an Xxx", for Xxx in [module, tuple, float, int, unicode, long, complex, str]. I cannot measure the performance gain on this machine (figures vary all the time) but it looks like some 0.2s for the above-mentioned 5s program. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-28 00:44 Message: Logged In: YES user_id=21627 I would rather see a constant-time subtype check implemented in Python, using strategies that other interpreters have been using for a long time. Essentially, each type gets a unique number (e.g. in the order of PyType_Ready calls), and a bit-field of all supertypes, with a bit set for each type that is one of its supertypes. Creation of the bitfield could be delayed until a subtype check is actually needed. The tricky part is to update the supertype bitmask when __super__ is assigned. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1153056&group_id=5470 From noreply at sourceforge.net Mon Feb 28 00:56:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 00:56:27 2005 Subject: [Patches] [ python-Patches-1153056 ] PyXxx_Check() speed-up Message-ID: Patches item #1153056, was opened at 2005-02-27 21:14 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1153056&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: PyXxx_Check() speed-up Initial Comment: Once upon a time, the macros PyInt_Check(), PyString_Check(), etc., used to be very fast: just a pointer comparison. But 2.2 came. Suddenly, types could inherit from each other. Thus the macros became: (ob->type == &PyXxx_Check || PyType_IsSubType(ob->type, &PyXxx_Check) Subtyping of built-in types still being rare, the common cases here are: (1) ob is indeed exactly of type Xxx, (2) ob is absolutely not an instance of Xxx. The macro is fast for case 1 but becomes a call to a slow function in case 2. It sounds minor -- but a program can make half a million "case 2" calls in 5 seconds. The following patch proposes to fix that, based on a few measurements that show which are the more common "case 2" calls in a few applications. It adds a family of type flags meaning "this type is not at all an Xxx", for Xxx in [module, tuple, float, int, unicode, long, complex, str]. I cannot measure the performance gain on this machine (figures vary all the time) but it looks like some 0.2s for the above-mentioned 5s program. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-02-27 23:56 Message: Logged In: YES user_id=4771 I'm not sure I understand your suggestion. Would each type have an array of N bits, where N is the total number of types that exist? That looks quite unreasonable in any program that builds a lot of types (I know some that build them programatically in loops). What I did is a limited version of that: a bitfield with room for only some commonly checked-for superclasses. (With some care, my patch could be modified to build the bitfield in PyType_Ready(); this would allow the PyXxx_Check() macros to become a single bit check operation.) Changing the base classes isn't an issue in my limited patch because you cannot ever add or remove the core built-in types I check for from the bases of an existing type. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-27 23:44 Message: Logged In: YES user_id=21627 I would rather see a constant-time subtype check implemented in Python, using strategies that other interpreters have been using for a long time. Essentially, each type gets a unique number (e.g. in the order of PyType_Ready calls), and a bit-field of all supertypes, with a bit set for each type that is one of its supertypes. Creation of the bitfield could be delayed until a subtype check is actually needed. The tricky part is to update the supertype bitmask when __super__ is assigned. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1153056&group_id=5470 From noreply at sourceforge.net Mon Feb 28 01:24:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 01:24:30 2005 Subject: [Patches] [ python-Patches-931007 ] PEP 309 LaTeX documentation Message-ID: Patches item #931007, was opened at 2004-04-07 06:18 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=931007&group_id=5470 Category: None >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Peter Harris (scav) >Assigned to: Raymond Hettinger (rhettinger) Summary: PEP 309 LaTeX documentation Initial Comment: Rough first draft of documentation for 'functional' module ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-27 18:04 Message: Logged In: YES user_id=21627 This patch is incorrect. It mentions a class functional.Partial which is not documented in the PEP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=931007&group_id=5470 From noreply at sourceforge.net Mon Feb 28 01:25:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 01:25:22 2005 Subject: [Patches] [ python-Patches-941881 ] PEP309 Partial implementation Message-ID: Patches item #941881, was opened at 2004-04-25 13:05 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) >Assigned to: Raymond Hettinger (rhettinger) Summary: PEP309 Partial implementation Initial Comment: This patch implements functional module which is introduced by PEP309. It has only 'partial' function as its member in this stage. Unittest code is copied and modified slightly from Patch #931010 by Peter Harris. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-27 18:05 Message: Logged In: YES user_id=21627 It turns out that the documentation is incorrect, wrt. this patch, as it mentions a non-existing class functional.Partial. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-27 15:43 Message: Logged In: YES user_id=80475 Exposing the structure members for dynamic alteration exceeds the PEP specification. While making the tool more flexible, it slows it down (requiring type checks for every call) and it encourages strange uses. The notion of giving partial objects a changable state is at odds with the basis for functional programming (i.e. statelessness). The traverse function should use the new Py_VISIT macro. The PyCallable_Check() is unnecessary as it duplicates the check already existing in PyObject_Call(). I am not certain whether the PyDict_Copy() is necessary. Calls to f(**d) already pass a copy of d. Likewise, calling f(a=1) will create a new dictionary. If so, that dictionary can be updated in- place with pto->kw rather than creating a new dictionary. None of these issues are critical. Feel free to go forward with the patch. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-02-27 15:43 Message: Logged In: YES user_id=113328 To build on Windows (at least with mingw gcc, I don't know about MSVC) you need to assign members of partial_type which are symbols in the Python DLL at runtime, not compile time. The following diff probably explains better: --- functionalmodule.c.orig 2005-02-27 20:41:41.000000000 +000 +++ functionalmodule.c 2005-02-26 21:41:14.000000000 +0000 @@ -197,7 +197,7 @@ 0, /* tp_hash */ (ternaryfunc)partial_call, /* tp_call */ 0, /* tp_str */ - PyObject_GenericGetAttr, /* tp_getattro */ + 0, /* tp_getattro */ 0, /* tp_setattro */ 0, /* tp_as_buffer */ Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC | @@ -220,7 +220,7 @@ 0, /* tp_init */ 0, /* tp_alloc */ partial_new, /* tp_new */ - PyObject_GC_Del, /* tp_free */ + 0, /* tp_free */ }; @@ -239,6 +239,8 @@ int i; PyObject *m; char *name; + partial_type.tp_getattro = PyObject_GenericGetAttr; + partial_type.tp_free = PyObject_GC_Del; PyTypeObject *typelist[] = { &partial_type, NULL ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 00:27 Message: Logged In: YES user_id=1038590 Moving the discussion to python-dev :) ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-25 22:58 Message: Logged In: YES user_id=945502 Oops -- wrong order of association. ... self.args = args[2:] + func.args ... d = func.kw.copy() ... d.update(kw) should have been ... self.args = func.args + args[2:] ... kw.update(func.kw) ... self.kw = kw hopefully these errors didn't confuse my intent too much. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-25 22:53 Message: Logged In: YES user_id=945502 Yes, that's much clearer. I don't remember why I couldn't get it to work this way before (I tried something quite similar to this), but I'm glad someone could figure out the simpler way to do it. ;-) One potential problem with my proposal -- it doesn't work for nested partials: py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186470>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() ('a', <__main__.C object at 0x01186370>, 'b') One possible solution would be to merge nested partials, but I'm not at all certain this solves all the problems: py> class partial(object): ... def __init__(*args, **kw): ... self = args[0] ... func = args[1] ... if isinstance(func, partial): ... self.fn = func.fn ... self.args = args[2:] + func.args ... d = func.kw.copy() ... d.update(kw) ... self.kw = d ... else: ... self.fn, self.args, self.kw = (args[1], args[2:], kw) ... def __call__(self, *args, **kw): ... if kw and self.kw: ... d = self.kw.copy() ... d.update(kw) ... else: ... d = kw or self.kw ... return self.fn(*(self.args + args), **d) ... def __get__(self, obj, type=None): ... if obj is None: ... return self ... return partial(self.fn, obj, *self.args, **self.kw) ... py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186BB0>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() (<__main__.C object at 0x01186650>, 'b', 'a') On the other hand, merging nested partials does reduce the number of function calls, so perhaps it's useful in and of itself... ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-25 22:45 Message: Logged In: YES user_id=1038590 If the __get__ method is added to make partial functions behave like instance methods, the documentation should probably mention that classmethod() and staticmethod() can then be used to alter the behaviour: Py> def f(*args): ... print args ... Py> class C: ... a = functional.partial(f) ... b = classmethod(functional.partial(f)) ... c = staticmethod(functional.partial(f)) ... Py> C().a Py> C().a() (<__main__.C instance at 0x009E6698>,) Py> C().b() (,) Py> C().c() () (This example used the simpler __get__ implementation I posted earlier) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-25 22:27 Message: Logged In: YES user_id=1038590 Steve's suggestion does sound good, but can't it simply be implemented with the PEP implementation and the following __get__ method?: def __get__(self, obj, type=None): if obj is None: return self return partial(self.func, obj, *self.args, **self.kwargs) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-25 22:17 Message: Logged In: YES user_id=1038590 Peter Harris already wrote docs in Patch 931007. Presumably they are still accurate, or perky would have said something. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-25 15:34 Message: Logged In: YES user_id=21627 In this form, the patch cannot be applied, since it lacks documentation changes. It might be that perky does not consider himself fluent enough in English to write the documentation - any other volunteers? I also think there is value to bediviere's point, even though the PEP currently specifies partial() differently. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-19 15:38 Message: Logged In: YES user_id=945502 It might be nice if partial objects were usable as instancemethods, like functions are. Note the following behavior with the current patch: >>> import functional >>> class C(object): ... pass ... >>> def func(self, arg): ... return arg ... >>> for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... >>> C().a() Traceback (most recent call last): File "", line 1, in ? TypeError: func() takes exactly 2 arguments (1 given) If functional.partial was instead defined like: class partial(object): def __init__(*args, **kwargs): self = args[0] try: self.func = args[1] except IndexError: raise TypeError('expected 2 or more arguments, got ' % len(args)) self.obj = () self.args = args[2:] self.kwargs = kwargs def __call__(self, *args, **kwargs): if kwargs and self.kwargs: d = self.kwargs.copy() d.update(kwargs) else: d = kwargs or self.kwargs return self.func(*(self.obj + self.args + args), **d) def __get__(self, obj, type=None): if obj is None: return self result = partial(self.func, *self.args, **self.kwargs) result.obj = (obj,) return result where an appropriate __get__ method is provided, then partial objects behave properly when set as attributes to a class: py> def test(): ... class C(object): ... pass ... def func(self, arg): ... return arg ... for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... c = C() ... return c.a(), c.b(), c.c() ... py> test() ('a', 'b', 'c') ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-10 19:11 Message: Logged In: YES user_id=1038590 I have tested this patch on Windows, and it passes its own test suite, without affecting any other tests. However, PCBuild\pythoncore.vcproj & PC\config.c require modification to allow Python to pick up the new module correctly. Patch #1006948 created with the needed changes (also removes unneeded ODBC references from pythoncore.vcproj as I am using the free MS toolkits to build here) My patch definitely needs to be checked by someone with a copy of Vis Studio 2003! ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-08-03 15:23 Message: Logged In: YES user_id=113328 OK, a real need beats my theoretical worries :-) Consider me convinced. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-05-17 23:05 Message: Logged In: YES user_id=139309 I would use partial in situations where speed can matter (imap, commonly used event handlers, etc.), so a fast C implementation would be nice to have. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 03:03 Message: Logged In: YES user_id=113328 Yes, that looks like a significant speed improvement :-) I was basing my assumptions on the comments made in the PEP. Sorry. But I still wonder if having the implementation in Python wouldn't be better from a maintenance point of view. (As well as all the arguments about usefulness as sample code, ability to backport, etc etc, that have come up on python-dev regarding moving other Python library modules into C...). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-04-26 21:05 Message: Logged In: YES user_id=55188 Python-version (function) ... 1.19 2.69 Python-version (class) ... 2.61 2.38 C-version ... 0.50 0.37 (former value is for 100000 instanciations and latter is for 100000 calls.) And, C version have a facility that changing attributes after the instantiation that is supported by class version only. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-26 14:30 Message: Logged In: YES user_id=113328 Why implement this in C? I can't imagine that the performance improvement will be that significant. A pure Python module in the standard library seems to me to be a far better idea. As the PEP says, "the case for a built-in coded in C is not very strong". And a Python module is good self-documentation. I prefer the function version suggested in the PEP (credited to Carl Banks) over the class-based one. You need to take a little care to avoid capturing argument names: def partial(*args, **kwds): def callit(*moreargs, **morekwds): kw = kwds.copy() kw.update(morekwds) return args[0](*(args[1:]+moreargs), **kw) return callit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 From noreply at sourceforge.net Mon Feb 28 01:26:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 01:26:55 2005 Subject: [Patches] [ python-Patches-1006948 ] Build Patch #941881 (PEP 309 in C) on windows Message-ID: Patches item #1006948, was opened at 2004-08-10 19:10 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006948&group_id=5470 Category: Windows >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) >Assigned to: Raymond Hettinger (rhettinger) Summary: Build Patch #941881 (PEP 309 in C) on windows Initial Comment: Patch #941881 provides a C implementation for PEP 309. This patch allows _that_ patch to be used on Windows. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-10 19:13 Message: Logged In: YES user_id=1038590 This should be checked by someone with Vis Studio 2003, since it involves a hand-edited VCPROJ file. It also has a side effect of removing references to the ODBC libraries from pythoncore.vcproj (refer Patch #1006916) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006948&group_id=5470 From noreply at sourceforge.net Mon Feb 28 04:19:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 04:19:31 2005 Subject: [Patches] [ python-Patches-1121234 ] Reference count bug fix Message-ID: Patches item #1121234, was opened at 2005-02-12 15:02 Message generated for change (Comment added) made by mdehoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121234&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Martin v. L?wis (loewis) Summary: Reference count bug fix Initial Comment: In the _loadtk method of the class Tk, there are two calls self.tk.createcommand, one for 'tkerror' and one for 'exit'. In the createcommand function in _tkinter.c, there is a Py_XINCREF for the Tk widget and one for the Python function (_tkerror or _exit). The corresponding Py_XDECREFs are called (via Tkapp_DeleteCommand) in PythonCmdDelete. The Tkapp_DeleteCommand is called by the deletecommand in the destroy method of class Misc in Tkinter.py. However, the deletecommand is called only for commands listed in self._tclCommands. Now, if a command is created via the _register method in class Misc, the command is appended to self._tclCommands. However, the 'tkerror' and 'exit' commands, created in the _loadtk method of the class Tk, are not appended to self._tclCommands. Hence, the '_tkerror' and '_exit' functions as well as the Tk widget itself have an incorrect reference count. The Tkapp_Dealloc routine in _tkinter.c is not called and the Tk widget is not destroyed. The attached patch simply adds a self._tclCommands.append for 'tkerror' and 'exit'. With this patch, a Tk widget is destroyed and Tkapp_Dealloc is called correctly. ---------------------------------------------------------------------- >Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-28 12:19 Message: Logged In: YES user_id=488897 If we use _register without modification, we'll end up with a different command name: >>> from Tkinter import Label >>> l = Label(text="some text") + Tkinter created command -1214096332_tkerror + Tkinter created command -1208510068_exit + Tkinter created command -1208511348destroy >>> whereas the command names should be "_tkerror", "_exit". We can modify the _register functon so that it takes an optional "name" keyword argument. However, it will mean that we create the command through the CallWrapper instead of the command directly. For "_exit", if I understand the code correctly, it would mean that the raise in _exit is obscured by the raise in CallWrapper, which doesn't seem the right thing. So I would suggest to add a "if self._tclCommands==None:" to the patch instead of going through _register. I'll update the patch if you agree. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-28 04:27 Message: Logged In: YES user_id=21627 Wouldn't it be better to use _register for _tkerror and _exit as well? This patch overwrites self._tclCommands, but the object may already have a _tclCommands attribute. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121234&group_id=5470 From noreply at sourceforge.net Mon Feb 28 06:12:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 06:12:31 2005 Subject: [Patches] [ python-Patches-1006948 ] Build Patch #941881 (PEP 309 in C) on windows Message-ID: Patches item #1006948, was opened at 2004-08-10 19:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006948&group_id=5470 Category: Windows Group: Python 2.5 >Status: Closed Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Raymond Hettinger (rhettinger) Summary: Build Patch #941881 (PEP 309 in C) on windows Initial Comment: Patch #941881 provides a C implementation for PEP 309. This patch allows _that_ patch to be used on Windows. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-28 00:12 Message: Logged In: YES user_id=80475 Added the MSC6.0 project changes also. Closing this as a separate patch and submitting as part of the combined patch in 941881. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-10 19:13 Message: Logged In: YES user_id=1038590 This should be checked by someone with Vis Studio 2003, since it involves a hand-edited VCPROJ file. It also has a side effect of removing references to the ODBC libraries from pythoncore.vcproj (refer Patch #1006916) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006948&group_id=5470 From noreply at sourceforge.net Mon Feb 28 06:14:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 06:14:57 2005 Subject: [Patches] [ python-Patches-931007 ] PEP 309 LaTeX documentation Message-ID: Patches item #931007, was opened at 2004-04-07 06:18 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=931007&group_id=5470 Category: None Group: Python 2.5 >Status: Closed Resolution: None Priority: 5 Submitted By: Peter Harris (scav) Assigned to: Raymond Hettinger (rhettinger) Summary: PEP 309 LaTeX documentation Initial Comment: Rough first draft of documentation for 'functional' module ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-28 00:14 Message: Logged In: YES user_id=80475 Provided editting and minor rewrites. Eliminated references to the Partial class. Added doctest style example and an itertools style rough Python equivalent. Closing this as a separate patch and submitting as part of the combined patch in 941881. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-27 18:04 Message: Logged In: YES user_id=21627 This patch is incorrect. It mentions a class functional.Partial which is not documented in the PEP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=931007&group_id=5470 From noreply at sourceforge.net Mon Feb 28 06:25:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 06:25:26 2005 Subject: [Patches] [ python-Patches-941881 ] PEP309 Partial implementation Message-ID: Patches item #941881, was opened at 2004-04-25 13:05 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 >Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) >Assigned to: Martin v. L?wis (loewis) Summary: PEP309 Partial implementation Initial Comment: This patch implements functional module which is introduced by PEP309. It has only 'partial' function as its member in this stage. Unittest code is copied and modified slightly from Patch #931010 by Peter Harris. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-28 00:25 Message: Logged In: YES user_id=80475 * Significantly beefed-up the test suite. * Brought in docs from another patch and heavily editted. * Brought in setup/build code from another patch and enhanced for MSC6.0. * Made attributes read-only and improved their names * Did NOT change dict copy/update logic. * Improved docstring wording * Applied the Py_VISIT macro * Added a NEWS announcement * Added lib.tex Suggest that if Nick wants to add __get__, that it occur separately after this patch is applied. It would be a nice improvement. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-27 18:05 Message: Logged In: YES user_id=21627 It turns out that the documentation is incorrect, wrt. this patch, as it mentions a non-existing class functional.Partial. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-27 15:43 Message: Logged In: YES user_id=80475 Exposing the structure members for dynamic alteration exceeds the PEP specification. While making the tool more flexible, it slows it down (requiring type checks for every call) and it encourages strange uses. The notion of giving partial objects a changable state is at odds with the basis for functional programming (i.e. statelessness). The traverse function should use the new Py_VISIT macro. The PyCallable_Check() is unnecessary as it duplicates the check already existing in PyObject_Call(). I am not certain whether the PyDict_Copy() is necessary. Calls to f(**d) already pass a copy of d. Likewise, calling f(a=1) will create a new dictionary. If so, that dictionary can be updated in- place with pto->kw rather than creating a new dictionary. None of these issues are critical. Feel free to go forward with the patch. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-02-27 15:43 Message: Logged In: YES user_id=113328 To build on Windows (at least with mingw gcc, I don't know about MSVC) you need to assign members of partial_type which are symbols in the Python DLL at runtime, not compile time. The following diff probably explains better: --- functionalmodule.c.orig 2005-02-27 20:41:41.000000000 +000 +++ functionalmodule.c 2005-02-26 21:41:14.000000000 +0000 @@ -197,7 +197,7 @@ 0, /* tp_hash */ (ternaryfunc)partial_call, /* tp_call */ 0, /* tp_str */ - PyObject_GenericGetAttr, /* tp_getattro */ + 0, /* tp_getattro */ 0, /* tp_setattro */ 0, /* tp_as_buffer */ Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC | @@ -220,7 +220,7 @@ 0, /* tp_init */ 0, /* tp_alloc */ partial_new, /* tp_new */ - PyObject_GC_Del, /* tp_free */ + 0, /* tp_free */ }; @@ -239,6 +239,8 @@ int i; PyObject *m; char *name; + partial_type.tp_getattro = PyObject_GenericGetAttr; + partial_type.tp_free = PyObject_GC_Del; PyTypeObject *typelist[] = { &partial_type, NULL ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 00:27 Message: Logged In: YES user_id=1038590 Moving the discussion to python-dev :) ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-25 22:58 Message: Logged In: YES user_id=945502 Oops -- wrong order of association. ... self.args = args[2:] + func.args ... d = func.kw.copy() ... d.update(kw) should have been ... self.args = func.args + args[2:] ... kw.update(func.kw) ... self.kw = kw hopefully these errors didn't confuse my intent too much. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-25 22:53 Message: Logged In: YES user_id=945502 Yes, that's much clearer. I don't remember why I couldn't get it to work this way before (I tried something quite similar to this), but I'm glad someone could figure out the simpler way to do it. ;-) One potential problem with my proposal -- it doesn't work for nested partials: py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186470>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() ('a', <__main__.C object at 0x01186370>, 'b') One possible solution would be to merge nested partials, but I'm not at all certain this solves all the problems: py> class partial(object): ... def __init__(*args, **kw): ... self = args[0] ... func = args[1] ... if isinstance(func, partial): ... self.fn = func.fn ... self.args = args[2:] + func.args ... d = func.kw.copy() ... d.update(kw) ... self.kw = d ... else: ... self.fn, self.args, self.kw = (args[1], args[2:], kw) ... def __call__(self, *args, **kw): ... if kw and self.kw: ... d = self.kw.copy() ... d.update(kw) ... else: ... d = kw or self.kw ... return self.fn(*(self.args + args), **d) ... def __get__(self, obj, type=None): ... if obj is None: ... return self ... return partial(self.fn, obj, *self.args, **self.kw) ... py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186BB0>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() (<__main__.C object at 0x01186650>, 'b', 'a') On the other hand, merging nested partials does reduce the number of function calls, so perhaps it's useful in and of itself... ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-25 22:45 Message: Logged In: YES user_id=1038590 If the __get__ method is added to make partial functions behave like instance methods, the documentation should probably mention that classmethod() and staticmethod() can then be used to alter the behaviour: Py> def f(*args): ... print args ... Py> class C: ... a = functional.partial(f) ... b = classmethod(functional.partial(f)) ... c = staticmethod(functional.partial(f)) ... Py> C().a Py> C().a() (<__main__.C instance at 0x009E6698>,) Py> C().b() (,) Py> C().c() () (This example used the simpler __get__ implementation I posted earlier) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-25 22:27 Message: Logged In: YES user_id=1038590 Steve's suggestion does sound good, but can't it simply be implemented with the PEP implementation and the following __get__ method?: def __get__(self, obj, type=None): if obj is None: return self return partial(self.func, obj, *self.args, **self.kwargs) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-25 22:17 Message: Logged In: YES user_id=1038590 Peter Harris already wrote docs in Patch 931007. Presumably they are still accurate, or perky would have said something. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-25 15:34 Message: Logged In: YES user_id=21627 In this form, the patch cannot be applied, since it lacks documentation changes. It might be that perky does not consider himself fluent enough in English to write the documentation - any other volunteers? I also think there is value to bediviere's point, even though the PEP currently specifies partial() differently. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-19 15:38 Message: Logged In: YES user_id=945502 It might be nice if partial objects were usable as instancemethods, like functions are. Note the following behavior with the current patch: >>> import functional >>> class C(object): ... pass ... >>> def func(self, arg): ... return arg ... >>> for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... >>> C().a() Traceback (most recent call last): File "", line 1, in ? TypeError: func() takes exactly 2 arguments (1 given) If functional.partial was instead defined like: class partial(object): def __init__(*args, **kwargs): self = args[0] try: self.func = args[1] except IndexError: raise TypeError('expected 2 or more arguments, got ' % len(args)) self.obj = () self.args = args[2:] self.kwargs = kwargs def __call__(self, *args, **kwargs): if kwargs and self.kwargs: d = self.kwargs.copy() d.update(kwargs) else: d = kwargs or self.kwargs return self.func(*(self.obj + self.args + args), **d) def __get__(self, obj, type=None): if obj is None: return self result = partial(self.func, *self.args, **self.kwargs) result.obj = (obj,) return result where an appropriate __get__ method is provided, then partial objects behave properly when set as attributes to a class: py> def test(): ... class C(object): ... pass ... def func(self, arg): ... return arg ... for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... c = C() ... return c.a(), c.b(), c.c() ... py> test() ('a', 'b', 'c') ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-10 19:11 Message: Logged In: YES user_id=1038590 I have tested this patch on Windows, and it passes its own test suite, without affecting any other tests. However, PCBuild\pythoncore.vcproj & PC\config.c require modification to allow Python to pick up the new module correctly. Patch #1006948 created with the needed changes (also removes unneeded ODBC references from pythoncore.vcproj as I am using the free MS toolkits to build here) My patch definitely needs to be checked by someone with a copy of Vis Studio 2003! ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-08-03 15:23 Message: Logged In: YES user_id=113328 OK, a real need beats my theoretical worries :-) Consider me convinced. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-05-17 23:05 Message: Logged In: YES user_id=139309 I would use partial in situations where speed can matter (imap, commonly used event handlers, etc.), so a fast C implementation would be nice to have. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 03:03 Message: Logged In: YES user_id=113328 Yes, that looks like a significant speed improvement :-) I was basing my assumptions on the comments made in the PEP. Sorry. But I still wonder if having the implementation in Python wouldn't be better from a maintenance point of view. (As well as all the arguments about usefulness as sample code, ability to backport, etc etc, that have come up on python-dev regarding moving other Python library modules into C...). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-04-26 21:05 Message: Logged In: YES user_id=55188 Python-version (function) ... 1.19 2.69 Python-version (class) ... 2.61 2.38 C-version ... 0.50 0.37 (former value is for 100000 instanciations and latter is for 100000 calls.) And, C version have a facility that changing attributes after the instantiation that is supported by class version only. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-26 14:30 Message: Logged In: YES user_id=113328 Why implement this in C? I can't imagine that the performance improvement will be that significant. A pure Python module in the standard library seems to me to be a far better idea. As the PEP says, "the case for a built-in coded in C is not very strong". And a Python module is good self-documentation. I prefer the function version suggested in the PEP (credited to Carl Banks) over the class-based one. You need to take a little care to avoid capturing argument names: def partial(*args, **kwds): def callit(*moreargs, **morekwds): kw = kwds.copy() kw.update(morekwds) return args[0](*(args[1:]+moreargs), **kw) return callit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 From noreply at sourceforge.net Mon Feb 28 06:28:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 06:28:27 2005 Subject: [Patches] [ python-Patches-931010 ] PEP 309 unit tests Message-ID: Patches item #931010, was opened at 2004-04-07 06:21 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=931010&group_id=5470 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Peter Harris (scav) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 309 unit tests Initial Comment: Unit tests for functional module. 1. test positional arguments passed correctly 2. test keyword arguments passed correctly 3. test that using the partially-applied function or Partial object doesn't modify it so as to affect subsequent calls. All tests are applied to the function returned from partial() and the object returned from Partial ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-28 00:28 Message: Logged In: YES user_id=80475 Folded into patch 941881 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=931010&group_id=5470 From noreply at sourceforge.net Mon Feb 28 07:20:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 07:20:44 2005 Subject: [Patches] [ python-Patches-1153056 ] PyXxx_Check() speed-up Message-ID: Patches item #1153056, was opened at 2005-02-27 22:14 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1153056&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: PyXxx_Check() speed-up Initial Comment: Once upon a time, the macros PyInt_Check(), PyString_Check(), etc., used to be very fast: just a pointer comparison. But 2.2 came. Suddenly, types could inherit from each other. Thus the macros became: (ob->type == &PyXxx_Check || PyType_IsSubType(ob->type, &PyXxx_Check) Subtyping of built-in types still being rare, the common cases here are: (1) ob is indeed exactly of type Xxx, (2) ob is absolutely not an instance of Xxx. The macro is fast for case 1 but becomes a call to a slow function in case 2. It sounds minor -- but a program can make half a million "case 2" calls in 5 seconds. The following patch proposes to fix that, based on a few measurements that show which are the more common "case 2" calls in a few applications. It adds a family of type flags meaning "this type is not at all an Xxx", for Xxx in [module, tuple, float, int, unicode, long, complex, str]. I cannot measure the performance gain on this machine (figures vary all the time) but it looks like some 0.2s for the above-mentioned 5s program. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-28 07:20 Message: Logged In: YES user_id=21627 No. Each type would have an array of M bits, where M is the maximum number of a super class; each type would also store the value of M. As types are created and deleted dynamically, it might be necessary to keep track of assigned type numbers, and recycle them as types are deleted. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-28 00:56 Message: Logged In: YES user_id=4771 I'm not sure I understand your suggestion. Would each type have an array of N bits, where N is the total number of types that exist? That looks quite unreasonable in any program that builds a lot of types (I know some that build them programatically in loops). What I did is a limited version of that: a bitfield with room for only some commonly checked-for superclasses. (With some care, my patch could be modified to build the bitfield in PyType_Ready(); this would allow the PyXxx_Check() macros to become a single bit check operation.) Changing the base classes isn't an issue in my limited patch because you cannot ever add or remove the core built-in types I check for from the bases of an existing type. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-28 00:44 Message: Logged In: YES user_id=21627 I would rather see a constant-time subtype check implemented in Python, using strategies that other interpreters have been using for a long time. Essentially, each type gets a unique number (e.g. in the order of PyType_Ready calls), and a bit-field of all supertypes, with a bit set for each type that is one of its supertypes. Creation of the bitfield could be delayed until a subtype check is actually needed. The tricky part is to update the supertype bitmask when __super__ is assigned. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1153056&group_id=5470 From noreply at sourceforge.net Mon Feb 28 10:26:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 10:26:42 2005 Subject: [Patches] [ python-Patches-1153056 ] PyXxx_Check() speed-up Message-ID: Patches item #1153056, was opened at 2005-02-27 21:14 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1153056&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: PyXxx_Check() speed-up Initial Comment: Once upon a time, the macros PyInt_Check(), PyString_Check(), etc., used to be very fast: just a pointer comparison. But 2.2 came. Suddenly, types could inherit from each other. Thus the macros became: (ob->type == &PyXxx_Check || PyType_IsSubType(ob->type, &PyXxx_Check) Subtyping of built-in types still being rare, the common cases here are: (1) ob is indeed exactly of type Xxx, (2) ob is absolutely not an instance of Xxx. The macro is fast for case 1 but becomes a call to a slow function in case 2. It sounds minor -- but a program can make half a million "case 2" calls in 5 seconds. The following patch proposes to fix that, based on a few measurements that show which are the more common "case 2" calls in a few applications. It adds a family of type flags meaning "this type is not at all an Xxx", for Xxx in [module, tuple, float, int, unicode, long, complex, str]. I cannot measure the performance gain on this machine (figures vary all the time) but it looks like some 0.2s for the above-mentioned 5s program. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-02-28 09:26 Message: Logged In: YES user_id=4771 Ah, but that's not so different: M can still be arbitrarily large... However, see also bug #1153075. I think that PyInt_Check() using PyType_IsSubtype() is essentially buggy: the purpose of PyInt_Check() is to check if the PyObject* is a PyIntObject*, not if its type pretends to have 'int' in its mro. If we fix this, then making PyType_IsSubtype() faster will become unrelated to making PyXxx_Check() faster. If we want to fix PyXxx_Check() for the bug described above and make it fast too, then we probably only need an array of N bits, where N is the number of C-level PyXxxObject structures. The idea of only including the most common such structures instead of all of them was based on simplicity and performance (it's faster and easier to check for a known bit than for a bit which itself is computed at run-time). If we want to make PyType_IsSubtype() fast, it might be worth the effort or not; we should measure it. But I think it's unrelated. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-28 06:20 Message: Logged In: YES user_id=21627 No. Each type would have an array of M bits, where M is the maximum number of a super class; each type would also store the value of M. As types are created and deleted dynamically, it might be necessary to keep track of assigned type numbers, and recycle them as types are deleted. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-27 23:56 Message: Logged In: YES user_id=4771 I'm not sure I understand your suggestion. Would each type have an array of N bits, where N is the total number of types that exist? That looks quite unreasonable in any program that builds a lot of types (I know some that build them programatically in loops). What I did is a limited version of that: a bitfield with room for only some commonly checked-for superclasses. (With some care, my patch could be modified to build the bitfield in PyType_Ready(); this would allow the PyXxx_Check() macros to become a single bit check operation.) Changing the base classes isn't an issue in my limited patch because you cannot ever add or remove the core built-in types I check for from the bases of an existing type. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-27 23:44 Message: Logged In: YES user_id=21627 I would rather see a constant-time subtype check implemented in Python, using strategies that other interpreters have been using for a long time. Essentially, each type gets a unique number (e.g. in the order of PyType_Ready calls), and a bit-field of all supertypes, with a bit set for each type that is one of its supertypes. Creation of the bitfield could be delayed until a subtype check is actually needed. The tricky part is to update the supertype bitmask when __super__ is assigned. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1153056&group_id=5470 From noreply at sourceforge.net Mon Feb 28 12:44:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 12:44:32 2005 Subject: [Patches] [ python-Patches-1153417 ] os.remove error on Solaris Message-ID: Patches item #1153417, was opened at 2005-02-28 11: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=1153417&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Philips (rphilips) Assigned to: Nobody/Anonymous (nobody) Summary: os.remove error on Solaris Initial Comment: According to the documentation, when os.remove is applied to a directory, OSError should be raised. On Solaris, this is not the case: the directory is removed BUT the link count on the parent directory does NOT change. File system corruption is the result. Python details: Python 2.3.4 (#3, Jun 18 2004, 10:14:55) [GCC 3.2.2] on sunos5 Solaris details: Number of CPUs is 2 CPU Type is sparcv9+vis2 CPU Speed is 750 MHz App Architecture is sparc Kernel Architecture is sun4u Kernel Bit Size is 64 OS Name is SunOS OS Version is 5.8 OS Distribution is Solaris 8 7/01 s28s_u5wos_08 SPARC Libc Name is libc Libc Version is 1 Kernel Version is SunOS Release 5.8 Version Generic_108528-20 64-bit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1153417&group_id=5470 From noreply at sourceforge.net Mon Feb 28 13:41:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 13:42:05 2005 Subject: [Patches] [ python-Patches-941881 ] PEP309 Partial implementation Message-ID: Patches item #941881, was opened at 2004-04-26 04:05 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Martin v. L?wis (loewis) Summary: PEP309 Partial implementation Initial Comment: This patch implements functional module which is introduced by PEP309. It has only 'partial' function as its member in this stage. Unittest code is copied and modified slightly from Patch #931010 by Peter Harris. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-28 22:41 Message: Logged In: YES user_id=1038590 I agree with Raymond - put the basic left-binding partial in place, and we can look at options like partialmethod, rightpartial and so forth that give more control over the positional arguments later. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-28 15:25 Message: Logged In: YES user_id=80475 * Significantly beefed-up the test suite. * Brought in docs from another patch and heavily editted. * Brought in setup/build code from another patch and enhanced for MSC6.0. * Made attributes read-only and improved their names * Did NOT change dict copy/update logic. * Improved docstring wording * Applied the Py_VISIT macro * Added a NEWS announcement * Added lib.tex Suggest that if Nick wants to add __get__, that it occur separately after this patch is applied. It would be a nice improvement. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-28 09:05 Message: Logged In: YES user_id=21627 It turns out that the documentation is incorrect, wrt. this patch, as it mentions a non-existing class functional.Partial. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-28 06:43 Message: Logged In: YES user_id=80475 Exposing the structure members for dynamic alteration exceeds the PEP specification. While making the tool more flexible, it slows it down (requiring type checks for every call) and it encourages strange uses. The notion of giving partial objects a changable state is at odds with the basis for functional programming (i.e. statelessness). The traverse function should use the new Py_VISIT macro. The PyCallable_Check() is unnecessary as it duplicates the check already existing in PyObject_Call(). I am not certain whether the PyDict_Copy() is necessary. Calls to f(**d) already pass a copy of d. Likewise, calling f(a=1) will create a new dictionary. If so, that dictionary can be updated in- place with pto->kw rather than creating a new dictionary. None of these issues are critical. Feel free to go forward with the patch. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-02-28 06:43 Message: Logged In: YES user_id=113328 To build on Windows (at least with mingw gcc, I don't know about MSVC) you need to assign members of partial_type which are symbols in the Python DLL at runtime, not compile time. The following diff probably explains better: --- functionalmodule.c.orig 2005-02-27 20:41:41.000000000 +000 +++ functionalmodule.c 2005-02-26 21:41:14.000000000 +0000 @@ -197,7 +197,7 @@ 0, /* tp_hash */ (ternaryfunc)partial_call, /* tp_call */ 0, /* tp_str */ - PyObject_GenericGetAttr, /* tp_getattro */ + 0, /* tp_getattro */ 0, /* tp_setattro */ 0, /* tp_as_buffer */ Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC | @@ -220,7 +220,7 @@ 0, /* tp_init */ 0, /* tp_alloc */ partial_new, /* tp_new */ - PyObject_GC_Del, /* tp_free */ + 0, /* tp_free */ }; @@ -239,6 +239,8 @@ int i; PyObject *m; char *name; + partial_type.tp_getattro = PyObject_GenericGetAttr; + partial_type.tp_free = PyObject_GC_Del; PyTypeObject *typelist[] = { &partial_type, NULL ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 15:27 Message: Logged In: YES user_id=1038590 Moving the discussion to python-dev :) ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-26 13:58 Message: Logged In: YES user_id=945502 Oops -- wrong order of association. ... self.args = args[2:] + func.args ... d = func.kw.copy() ... d.update(kw) should have been ... self.args = func.args + args[2:] ... kw.update(func.kw) ... self.kw = kw hopefully these errors didn't confuse my intent too much. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-26 13:53 Message: Logged In: YES user_id=945502 Yes, that's much clearer. I don't remember why I couldn't get it to work this way before (I tried something quite similar to this), but I'm glad someone could figure out the simpler way to do it. ;-) One potential problem with my proposal -- it doesn't work for nested partials: py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186470>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() ('a', <__main__.C object at 0x01186370>, 'b') One possible solution would be to merge nested partials, but I'm not at all certain this solves all the problems: py> class partial(object): ... def __init__(*args, **kw): ... self = args[0] ... func = args[1] ... if isinstance(func, partial): ... self.fn = func.fn ... self.args = args[2:] + func.args ... d = func.kw.copy() ... d.update(kw) ... self.kw = d ... else: ... self.fn, self.args, self.kw = (args[1], args[2:], kw) ... def __call__(self, *args, **kw): ... if kw and self.kw: ... d = self.kw.copy() ... d.update(kw) ... else: ... d = kw or self.kw ... return self.fn(*(self.args + args), **d) ... def __get__(self, obj, type=None): ... if obj is None: ... return self ... return partial(self.fn, obj, *self.args, **self.kw) ... py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186BB0>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() (<__main__.C object at 0x01186650>, 'b', 'a') On the other hand, merging nested partials does reduce the number of function calls, so perhaps it's useful in and of itself... ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 13:45 Message: Logged In: YES user_id=1038590 If the __get__ method is added to make partial functions behave like instance methods, the documentation should probably mention that classmethod() and staticmethod() can then be used to alter the behaviour: Py> def f(*args): ... print args ... Py> class C: ... a = functional.partial(f) ... b = classmethod(functional.partial(f)) ... c = staticmethod(functional.partial(f)) ... Py> C().a Py> C().a() (<__main__.C instance at 0x009E6698>,) Py> C().b() (,) Py> C().c() () (This example used the simpler __get__ implementation I posted earlier) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 13:27 Message: Logged In: YES user_id=1038590 Steve's suggestion does sound good, but can't it simply be implemented with the PEP implementation and the following __get__ method?: def __get__(self, obj, type=None): if obj is None: return self return partial(self.func, obj, *self.args, **self.kwargs) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 13:17 Message: Logged In: YES user_id=1038590 Peter Harris already wrote docs in Patch 931007. Presumably they are still accurate, or perky would have said something. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-26 06:34 Message: Logged In: YES user_id=21627 In this form, the patch cannot be applied, since it lacks documentation changes. It might be that perky does not consider himself fluent enough in English to write the documentation - any other volunteers? I also think there is value to bediviere's point, even though the PEP currently specifies partial() differently. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-20 06:38 Message: Logged In: YES user_id=945502 It might be nice if partial objects were usable as instancemethods, like functions are. Note the following behavior with the current patch: >>> import functional >>> class C(object): ... pass ... >>> def func(self, arg): ... return arg ... >>> for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... >>> C().a() Traceback (most recent call last): File "", line 1, in ? TypeError: func() takes exactly 2 arguments (1 given) If functional.partial was instead defined like: class partial(object): def __init__(*args, **kwargs): self = args[0] try: self.func = args[1] except IndexError: raise TypeError('expected 2 or more arguments, got ' % len(args)) self.obj = () self.args = args[2:] self.kwargs = kwargs def __call__(self, *args, **kwargs): if kwargs and self.kwargs: d = self.kwargs.copy() d.update(kwargs) else: d = kwargs or self.kwargs return self.func(*(self.obj + self.args + args), **d) def __get__(self, obj, type=None): if obj is None: return self result = partial(self.func, *self.args, **self.kwargs) result.obj = (obj,) return result where an appropriate __get__ method is provided, then partial objects behave properly when set as attributes to a class: py> def test(): ... class C(object): ... pass ... def func(self, arg): ... return arg ... for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... c = C() ... return c.a(), c.b(), c.c() ... py> test() ('a', 'b', 'c') ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 10:11 Message: Logged In: YES user_id=1038590 I have tested this patch on Windows, and it passes its own test suite, without affecting any other tests. However, PCBuild\pythoncore.vcproj & PC\config.c require modification to allow Python to pick up the new module correctly. Patch #1006948 created with the needed changes (also removes unneeded ODBC references from pythoncore.vcproj as I am using the free MS toolkits to build here) My patch definitely needs to be checked by someone with a copy of Vis Studio 2003! ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-08-04 06:23 Message: Logged In: YES user_id=113328 OK, a real need beats my theoretical worries :-) Consider me convinced. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-05-18 14:05 Message: Logged In: YES user_id=139309 I would use partial in situations where speed can matter (imap, commonly used event handlers, etc.), so a fast C implementation would be nice to have. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 18:03 Message: Logged In: YES user_id=113328 Yes, that looks like a significant speed improvement :-) I was basing my assumptions on the comments made in the PEP. Sorry. But I still wonder if having the implementation in Python wouldn't be better from a maintenance point of view. (As well as all the arguments about usefulness as sample code, ability to backport, etc etc, that have come up on python-dev regarding moving other Python library modules into C...). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-04-27 12:05 Message: Logged In: YES user_id=55188 Python-version (function) ... 1.19 2.69 Python-version (class) ... 2.61 2.38 C-version ... 0.50 0.37 (former value is for 100000 instanciations and latter is for 100000 calls.) And, C version have a facility that changing attributes after the instantiation that is supported by class version only. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 05:30 Message: Logged In: YES user_id=113328 Why implement this in C? I can't imagine that the performance improvement will be that significant. A pure Python module in the standard library seems to me to be a far better idea. As the PEP says, "the case for a built-in coded in C is not very strong". And a Python module is good self-documentation. I prefer the function version suggested in the PEP (credited to Carl Banks) over the class-based one. You need to take a little care to avoid capturing argument names: def partial(*args, **kwds): def callit(*moreargs, **morekwds): kw = kwds.copy() kw.update(morekwds) return args[0](*(args[1:]+moreargs), **kw) return callit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 From noreply at sourceforge.net Mon Feb 28 15:21:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 15:21:52 2005 Subject: [Patches] [ python-Patches-941881 ] PEP309 Partial implementation Message-ID: Patches item #941881, was opened at 2004-04-25 13:05 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Martin v. L?wis (loewis) Summary: PEP309 Partial implementation Initial Comment: This patch implements functional module which is introduced by PEP309. It has only 'partial' function as its member in this stage. Unittest code is copied and modified slightly from Patch #931010 by Peter Harris. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-28 09:21 Message: Logged In: YES user_id=80475 Martin, if there are no objections, I'll go ahead an apply this one so we can move on. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-28 07:41 Message: Logged In: YES user_id=1038590 I agree with Raymond - put the basic left-binding partial in place, and we can look at options like partialmethod, rightpartial and so forth that give more control over the positional arguments later. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-28 00:25 Message: Logged In: YES user_id=80475 * Significantly beefed-up the test suite. * Brought in docs from another patch and heavily editted. * Brought in setup/build code from another patch and enhanced for MSC6.0. * Made attributes read-only and improved their names * Did NOT change dict copy/update logic. * Improved docstring wording * Applied the Py_VISIT macro * Added a NEWS announcement * Added lib.tex Suggest that if Nick wants to add __get__, that it occur separately after this patch is applied. It would be a nice improvement. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-27 18:05 Message: Logged In: YES user_id=21627 It turns out that the documentation is incorrect, wrt. this patch, as it mentions a non-existing class functional.Partial. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-27 15:43 Message: Logged In: YES user_id=80475 Exposing the structure members for dynamic alteration exceeds the PEP specification. While making the tool more flexible, it slows it down (requiring type checks for every call) and it encourages strange uses. The notion of giving partial objects a changable state is at odds with the basis for functional programming (i.e. statelessness). The traverse function should use the new Py_VISIT macro. The PyCallable_Check() is unnecessary as it duplicates the check already existing in PyObject_Call(). I am not certain whether the PyDict_Copy() is necessary. Calls to f(**d) already pass a copy of d. Likewise, calling f(a=1) will create a new dictionary. If so, that dictionary can be updated in- place with pto->kw rather than creating a new dictionary. None of these issues are critical. Feel free to go forward with the patch. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-02-27 15:43 Message: Logged In: YES user_id=113328 To build on Windows (at least with mingw gcc, I don't know about MSVC) you need to assign members of partial_type which are symbols in the Python DLL at runtime, not compile time. The following diff probably explains better: --- functionalmodule.c.orig 2005-02-27 20:41:41.000000000 +000 +++ functionalmodule.c 2005-02-26 21:41:14.000000000 +0000 @@ -197,7 +197,7 @@ 0, /* tp_hash */ (ternaryfunc)partial_call, /* tp_call */ 0, /* tp_str */ - PyObject_GenericGetAttr, /* tp_getattro */ + 0, /* tp_getattro */ 0, /* tp_setattro */ 0, /* tp_as_buffer */ Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC | @@ -220,7 +220,7 @@ 0, /* tp_init */ 0, /* tp_alloc */ partial_new, /* tp_new */ - PyObject_GC_Del, /* tp_free */ + 0, /* tp_free */ }; @@ -239,6 +239,8 @@ int i; PyObject *m; char *name; + partial_type.tp_getattro = PyObject_GenericGetAttr; + partial_type.tp_free = PyObject_GC_Del; PyTypeObject *typelist[] = { &partial_type, NULL ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 00:27 Message: Logged In: YES user_id=1038590 Moving the discussion to python-dev :) ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-25 22:58 Message: Logged In: YES user_id=945502 Oops -- wrong order of association. ... self.args = args[2:] + func.args ... d = func.kw.copy() ... d.update(kw) should have been ... self.args = func.args + args[2:] ... kw.update(func.kw) ... self.kw = kw hopefully these errors didn't confuse my intent too much. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-25 22:53 Message: Logged In: YES user_id=945502 Yes, that's much clearer. I don't remember why I couldn't get it to work this way before (I tried something quite similar to this), but I'm glad someone could figure out the simpler way to do it. ;-) One potential problem with my proposal -- it doesn't work for nested partials: py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186470>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() ('a', <__main__.C object at 0x01186370>, 'b') One possible solution would be to merge nested partials, but I'm not at all certain this solves all the problems: py> class partial(object): ... def __init__(*args, **kw): ... self = args[0] ... func = args[1] ... if isinstance(func, partial): ... self.fn = func.fn ... self.args = args[2:] + func.args ... d = func.kw.copy() ... d.update(kw) ... self.kw = d ... else: ... self.fn, self.args, self.kw = (args[1], args[2:], kw) ... def __call__(self, *args, **kw): ... if kw and self.kw: ... d = self.kw.copy() ... d.update(kw) ... else: ... d = kw or self.kw ... return self.fn(*(self.args + args), **d) ... def __get__(self, obj, type=None): ... if obj is None: ... return self ... return partial(self.fn, obj, *self.args, **self.kw) ... py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186BB0>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() (<__main__.C object at 0x01186650>, 'b', 'a') On the other hand, merging nested partials does reduce the number of function calls, so perhaps it's useful in and of itself... ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-25 22:45 Message: Logged In: YES user_id=1038590 If the __get__ method is added to make partial functions behave like instance methods, the documentation should probably mention that classmethod() and staticmethod() can then be used to alter the behaviour: Py> def f(*args): ... print args ... Py> class C: ... a = functional.partial(f) ... b = classmethod(functional.partial(f)) ... c = staticmethod(functional.partial(f)) ... Py> C().a Py> C().a() (<__main__.C instance at 0x009E6698>,) Py> C().b() (,) Py> C().c() () (This example used the simpler __get__ implementation I posted earlier) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-25 22:27 Message: Logged In: YES user_id=1038590 Steve's suggestion does sound good, but can't it simply be implemented with the PEP implementation and the following __get__ method?: def __get__(self, obj, type=None): if obj is None: return self return partial(self.func, obj, *self.args, **self.kwargs) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-25 22:17 Message: Logged In: YES user_id=1038590 Peter Harris already wrote docs in Patch 931007. Presumably they are still accurate, or perky would have said something. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-25 15:34 Message: Logged In: YES user_id=21627 In this form, the patch cannot be applied, since it lacks documentation changes. It might be that perky does not consider himself fluent enough in English to write the documentation - any other volunteers? I also think there is value to bediviere's point, even though the PEP currently specifies partial() differently. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-19 15:38 Message: Logged In: YES user_id=945502 It might be nice if partial objects were usable as instancemethods, like functions are. Note the following behavior with the current patch: >>> import functional >>> class C(object): ... pass ... >>> def func(self, arg): ... return arg ... >>> for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... >>> C().a() Traceback (most recent call last): File "", line 1, in ? TypeError: func() takes exactly 2 arguments (1 given) If functional.partial was instead defined like: class partial(object): def __init__(*args, **kwargs): self = args[0] try: self.func = args[1] except IndexError: raise TypeError('expected 2 or more arguments, got ' % len(args)) self.obj = () self.args = args[2:] self.kwargs = kwargs def __call__(self, *args, **kwargs): if kwargs and self.kwargs: d = self.kwargs.copy() d.update(kwargs) else: d = kwargs or self.kwargs return self.func(*(self.obj + self.args + args), **d) def __get__(self, obj, type=None): if obj is None: return self result = partial(self.func, *self.args, **self.kwargs) result.obj = (obj,) return result where an appropriate __get__ method is provided, then partial objects behave properly when set as attributes to a class: py> def test(): ... class C(object): ... pass ... def func(self, arg): ... return arg ... for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... c = C() ... return c.a(), c.b(), c.c() ... py> test() ('a', 'b', 'c') ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-10 19:11 Message: Logged In: YES user_id=1038590 I have tested this patch on Windows, and it passes its own test suite, without affecting any other tests. However, PCBuild\pythoncore.vcproj & PC\config.c require modification to allow Python to pick up the new module correctly. Patch #1006948 created with the needed changes (also removes unneeded ODBC references from pythoncore.vcproj as I am using the free MS toolkits to build here) My patch definitely needs to be checked by someone with a copy of Vis Studio 2003! ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-08-03 15:23 Message: Logged In: YES user_id=113328 OK, a real need beats my theoretical worries :-) Consider me convinced. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-05-17 23:05 Message: Logged In: YES user_id=139309 I would use partial in situations where speed can matter (imap, commonly used event handlers, etc.), so a fast C implementation would be nice to have. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 03:03 Message: Logged In: YES user_id=113328 Yes, that looks like a significant speed improvement :-) I was basing my assumptions on the comments made in the PEP. Sorry. But I still wonder if having the implementation in Python wouldn't be better from a maintenance point of view. (As well as all the arguments about usefulness as sample code, ability to backport, etc etc, that have come up on python-dev regarding moving other Python library modules into C...). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-04-26 21:05 Message: Logged In: YES user_id=55188 Python-version (function) ... 1.19 2.69 Python-version (class) ... 2.61 2.38 C-version ... 0.50 0.37 (former value is for 100000 instanciations and latter is for 100000 calls.) And, C version have a facility that changing attributes after the instantiation that is supported by class version only. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-26 14:30 Message: Logged In: YES user_id=113328 Why implement this in C? I can't imagine that the performance improvement will be that significant. A pure Python module in the standard library seems to me to be a far better idea. As the PEP says, "the case for a built-in coded in C is not very strong". And a Python module is good self-documentation. I prefer the function version suggested in the PEP (credited to Carl Banks) over the class-based one. You need to take a little care to avoid capturing argument names: def partial(*args, **kwds): def callit(*moreargs, **morekwds): kw = kwds.copy() kw.update(morekwds) return args[0](*(args[1:]+moreargs), **kw) return callit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 From noreply at sourceforge.net Mon Feb 28 17:53:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 17:53:28 2005 Subject: [Patches] [ python-Patches-900744 ] catch invalid chunk length in httplib read routine Message-ID: Patches item #900744, was opened at 2004-02-19 23:14 Message generated for change (Comment added) made by agwego You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=900744&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: catch invalid chunk length in httplib read routine Initial Comment: In HTTPResponse._read_chunked the chunk length is not checked to be a valid integer, and a ValueError will be raised in such a case. The attached patch catches ValueError (which should not normally happen, so this try:except: is reasonably fast), and raises IncompleteRead exception instead. I have no test case for this yet, but am trying to construct one :) ---------------------------------------------------------------------- Comment By: agwego (agwego) Date: 2005-02-28 16:53 Message: Logged In: YES user_id=1228982 I've run into this problem in conjunction with mod_python 3.1.4 (and although the problem is caused in mod_python) my python skills aren't up to the task. Which leaves me with fixing httplib. Although the above patch works when it comes to end of file situations, I think it would be better to return what has been consumed so far and leave it at that. A few lines down there's a comment about consuming trailers, this is the case that is tripping up httplib as far as I can tell. This is happening in Python 2.3.4. --- packages/Python-2.3.4/Lib/httplib.py Sun Nov 2 11:51:38 2003 +++ httplib.py Mon Feb 28 11:26:48 2005 @@ -423,7 +423,11 @@ i = line.find(';') if i >= 0: line = line[:i] # strip chunk-extensions - chunk_left = int(line, 16) + try: + chunk_left = int(line, 16) + except ValueError, msg: + self.close() + return value if chunk_left == 0: break if amt is None: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=900744&group_id=5470 From noreply at sourceforge.net Mon Feb 28 19:02:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 19:02:26 2005 Subject: [Patches] [ python-Patches-941881 ] PEP309 Partial implementation Message-ID: Patches item #941881, was opened at 2004-04-25 20:05 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) >Assigned to: Raymond Hettinger (rhettinger) Summary: PEP309 Partial implementation Initial Comment: This patch implements functional module which is introduced by PEP309. It has only 'partial' function as its member in this stage. Unittest code is copied and modified slightly from Patch #931010 by Peter Harris. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-28 19:02 Message: Logged In: YES user_id=21627 The patch looks good, so please apply. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-28 15:21 Message: Logged In: YES user_id=80475 Martin, if there are no objections, I'll go ahead an apply this one so we can move on. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-28 13:41 Message: Logged In: YES user_id=1038590 I agree with Raymond - put the basic left-binding partial in place, and we can look at options like partialmethod, rightpartial and so forth that give more control over the positional arguments later. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-28 06:25 Message: Logged In: YES user_id=80475 * Significantly beefed-up the test suite. * Brought in docs from another patch and heavily editted. * Brought in setup/build code from another patch and enhanced for MSC6.0. * Made attributes read-only and improved their names * Did NOT change dict copy/update logic. * Improved docstring wording * Applied the Py_VISIT macro * Added a NEWS announcement * Added lib.tex Suggest that if Nick wants to add __get__, that it occur separately after this patch is applied. It would be a nice improvement. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-28 00:05 Message: Logged In: YES user_id=21627 It turns out that the documentation is incorrect, wrt. this patch, as it mentions a non-existing class functional.Partial. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-27 21:43 Message: Logged In: YES user_id=80475 Exposing the structure members for dynamic alteration exceeds the PEP specification. While making the tool more flexible, it slows it down (requiring type checks for every call) and it encourages strange uses. The notion of giving partial objects a changable state is at odds with the basis for functional programming (i.e. statelessness). The traverse function should use the new Py_VISIT macro. The PyCallable_Check() is unnecessary as it duplicates the check already existing in PyObject_Call(). I am not certain whether the PyDict_Copy() is necessary. Calls to f(**d) already pass a copy of d. Likewise, calling f(a=1) will create a new dictionary. If so, that dictionary can be updated in- place with pto->kw rather than creating a new dictionary. None of these issues are critical. Feel free to go forward with the patch. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-02-27 21:43 Message: Logged In: YES user_id=113328 To build on Windows (at least with mingw gcc, I don't know about MSVC) you need to assign members of partial_type which are symbols in the Python DLL at runtime, not compile time. The following diff probably explains better: --- functionalmodule.c.orig 2005-02-27 20:41:41.000000000 +000 +++ functionalmodule.c 2005-02-26 21:41:14.000000000 +0000 @@ -197,7 +197,7 @@ 0, /* tp_hash */ (ternaryfunc)partial_call, /* tp_call */ 0, /* tp_str */ - PyObject_GenericGetAttr, /* tp_getattro */ + 0, /* tp_getattro */ 0, /* tp_setattro */ 0, /* tp_as_buffer */ Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC | @@ -220,7 +220,7 @@ 0, /* tp_init */ 0, /* tp_alloc */ partial_new, /* tp_new */ - PyObject_GC_Del, /* tp_free */ + 0, /* tp_free */ }; @@ -239,6 +239,8 @@ int i; PyObject *m; char *name; + partial_type.tp_getattro = PyObject_GenericGetAttr; + partial_type.tp_free = PyObject_GC_Del; PyTypeObject *typelist[] = { &partial_type, NULL ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 06:27 Message: Logged In: YES user_id=1038590 Moving the discussion to python-dev :) ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-26 04:58 Message: Logged In: YES user_id=945502 Oops -- wrong order of association. ... self.args = args[2:] + func.args ... d = func.kw.copy() ... d.update(kw) should have been ... self.args = func.args + args[2:] ... kw.update(func.kw) ... self.kw = kw hopefully these errors didn't confuse my intent too much. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-26 04:53 Message: Logged In: YES user_id=945502 Yes, that's much clearer. I don't remember why I couldn't get it to work this way before (I tried something quite similar to this), but I'm glad someone could figure out the simpler way to do it. ;-) One potential problem with my proposal -- it doesn't work for nested partials: py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186470>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() ('a', <__main__.C object at 0x01186370>, 'b') One possible solution would be to merge nested partials, but I'm not at all certain this solves all the problems: py> class partial(object): ... def __init__(*args, **kw): ... self = args[0] ... func = args[1] ... if isinstance(func, partial): ... self.fn = func.fn ... self.args = args[2:] + func.args ... d = func.kw.copy() ... d.update(kw) ... self.kw = d ... else: ... self.fn, self.args, self.kw = (args[1], args[2:], kw) ... def __call__(self, *args, **kw): ... if kw and self.kw: ... d = self.kw.copy() ... d.update(kw) ... else: ... d = kw or self.kw ... return self.fn(*(self.args + args), **d) ... def __get__(self, obj, type=None): ... if obj is None: ... return self ... return partial(self.fn, obj, *self.args, **self.kw) ... py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186BB0>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() (<__main__.C object at 0x01186650>, 'b', 'a') On the other hand, merging nested partials does reduce the number of function calls, so perhaps it's useful in and of itself... ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 04:45 Message: Logged In: YES user_id=1038590 If the __get__ method is added to make partial functions behave like instance methods, the documentation should probably mention that classmethod() and staticmethod() can then be used to alter the behaviour: Py> def f(*args): ... print args ... Py> class C: ... a = functional.partial(f) ... b = classmethod(functional.partial(f)) ... c = staticmethod(functional.partial(f)) ... Py> C().a Py> C().a() (<__main__.C instance at 0x009E6698>,) Py> C().b() (,) Py> C().c() () (This example used the simpler __get__ implementation I posted earlier) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 04:27 Message: Logged In: YES user_id=1038590 Steve's suggestion does sound good, but can't it simply be implemented with the PEP implementation and the following __get__ method?: def __get__(self, obj, type=None): if obj is None: return self return partial(self.func, obj, *self.args, **self.kwargs) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 04:17 Message: Logged In: YES user_id=1038590 Peter Harris already wrote docs in Patch 931007. Presumably they are still accurate, or perky would have said something. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-25 21:34 Message: Logged In: YES user_id=21627 In this form, the patch cannot be applied, since it lacks documentation changes. It might be that perky does not consider himself fluent enough in English to write the documentation - any other volunteers? I also think there is value to bediviere's point, even though the PEP currently specifies partial() differently. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-19 21:38 Message: Logged In: YES user_id=945502 It might be nice if partial objects were usable as instancemethods, like functions are. Note the following behavior with the current patch: >>> import functional >>> class C(object): ... pass ... >>> def func(self, arg): ... return arg ... >>> for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... >>> C().a() Traceback (most recent call last): File "", line 1, in ? TypeError: func() takes exactly 2 arguments (1 given) If functional.partial was instead defined like: class partial(object): def __init__(*args, **kwargs): self = args[0] try: self.func = args[1] except IndexError: raise TypeError('expected 2 or more arguments, got ' % len(args)) self.obj = () self.args = args[2:] self.kwargs = kwargs def __call__(self, *args, **kwargs): if kwargs and self.kwargs: d = self.kwargs.copy() d.update(kwargs) else: d = kwargs or self.kwargs return self.func(*(self.obj + self.args + args), **d) def __get__(self, obj, type=None): if obj is None: return self result = partial(self.func, *self.args, **self.kwargs) result.obj = (obj,) return result where an appropriate __get__ method is provided, then partial objects behave properly when set as attributes to a class: py> def test(): ... class C(object): ... pass ... def func(self, arg): ... return arg ... for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... c = C() ... return c.a(), c.b(), c.c() ... py> test() ('a', 'b', 'c') ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 02:11 Message: Logged In: YES user_id=1038590 I have tested this patch on Windows, and it passes its own test suite, without affecting any other tests. However, PCBuild\pythoncore.vcproj & PC\config.c require modification to allow Python to pick up the new module correctly. Patch #1006948 created with the needed changes (also removes unneeded ODBC references from pythoncore.vcproj as I am using the free MS toolkits to build here) My patch definitely needs to be checked by someone with a copy of Vis Studio 2003! ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-08-03 22:23 Message: Logged In: YES user_id=113328 OK, a real need beats my theoretical worries :-) Consider me convinced. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-05-18 06:05 Message: Logged In: YES user_id=139309 I would use partial in situations where speed can matter (imap, commonly used event handlers, etc.), so a fast C implementation would be nice to have. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 10:03 Message: Logged In: YES user_id=113328 Yes, that looks like a significant speed improvement :-) I was basing my assumptions on the comments made in the PEP. Sorry. But I still wonder if having the implementation in Python wouldn't be better from a maintenance point of view. (As well as all the arguments about usefulness as sample code, ability to backport, etc etc, that have come up on python-dev regarding moving other Python library modules into C...). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-04-27 04:05 Message: Logged In: YES user_id=55188 Python-version (function) ... 1.19 2.69 Python-version (class) ... 2.61 2.38 C-version ... 0.50 0.37 (former value is for 100000 instanciations and latter is for 100000 calls.) And, C version have a facility that changing attributes after the instantiation that is supported by class version only. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-26 21:30 Message: Logged In: YES user_id=113328 Why implement this in C? I can't imagine that the performance improvement will be that significant. A pure Python module in the standard library seems to me to be a far better idea. As the PEP says, "the case for a built-in coded in C is not very strong". And a Python module is good self-documentation. I prefer the function version suggested in the PEP (credited to Carl Banks) over the class-based one. You need to take a little care to avoid capturing argument names: def partial(*args, **kwds): def callit(*moreargs, **morekwds): kw = kwds.copy() kw.update(morekwds) return args[0](*(args[1:]+moreargs), **kw) return callit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 From noreply at sourceforge.net Mon Feb 28 19:11:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 19:11:27 2005 Subject: [Patches] [ python-Patches-1121611 ] sha and md5 modules should use OpenSSL when possible Message-ID: Patches item #1121611, was opened at 2005-02-12 17:33 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121611&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory P. Smith (greg) >Assigned to: Gregory P. Smith (greg) Summary: sha and md5 modules should use OpenSSL when possible Initial Comment: The md5 and sha (sha1) modules should use OpenSSL for the algorithms when it is available as its implementations are much faster than pythons own. Attached is an initial patch to use OpenSSL for the sha module. Its not ready for committing as is yet, but it is setup to be a generic base for all OpenSSL hashes with a little bit of work in the future. Tossing this out there for people to see how trivial it is and enjoy the speedups. diff is against HEAD but it should apply to 2.4 just fine. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2005-02-28 10:11 Message: Logged In: YES user_id=413 a much updated patch (hashlib-patch-004.patch). it incorporates some suggestions as well as including sf patch 935454's sha256/224 and sha512/384 implementations. still not complete but shows the direction its going in (i see a segfault part way thru the test suite after running the sha512 tests). as for the private modules being under another package, i see no reason to do that since there aren't very many (how does that work for binary modules anyways?). ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-18 11:21 Message: Logged In: YES user_id=764593 Should the private modules (such as _sha) be placed in a crypto package, instead of directly in the parent/everything library? ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-02-16 22:46 Message: Logged In: YES user_id=413 hashes-openssl-002.patch replaces the sha and md5 modules with a general hashes module that wraps all hashes that OpenSSL supports. note that OpenSSLs implementations are much faster than the previous python versions as it choses versions optimized for your particular hardware. Incase python is compiled without openssl the hashes wrapper falls back on the old python sha and md5 module implementations. side note: This may be sufficient for the Debian folks to work around their random odd licensing issue. just have debian python depend on openssl; use this and remove the old md5 module/code that wouldn't get used anyways. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121611&group_id=5470 From noreply at sourceforge.net Mon Feb 28 20:40:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 20:40:24 2005 Subject: [Patches] [ python-Patches-941881 ] PEP309 Partial implementation Message-ID: Patches item #941881, was opened at 2004-04-25 13:05 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 Category: Modules Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Raymond Hettinger (rhettinger) Summary: PEP309 Partial implementation Initial Comment: This patch implements functional module which is introduced by PEP309. It has only 'partial' function as its member in this stage. Unittest code is copied and modified slightly from Patch #931010 by Peter Harris. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-28 13:02 Message: Logged In: YES user_id=21627 The patch looks good, so please apply. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-28 09:21 Message: Logged In: YES user_id=80475 Martin, if there are no objections, I'll go ahead an apply this one so we can move on. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-28 07:41 Message: Logged In: YES user_id=1038590 I agree with Raymond - put the basic left-binding partial in place, and we can look at options like partialmethod, rightpartial and so forth that give more control over the positional arguments later. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-28 00:25 Message: Logged In: YES user_id=80475 * Significantly beefed-up the test suite. * Brought in docs from another patch and heavily editted. * Brought in setup/build code from another patch and enhanced for MSC6.0. * Made attributes read-only and improved their names * Did NOT change dict copy/update logic. * Improved docstring wording * Applied the Py_VISIT macro * Added a NEWS announcement * Added lib.tex Suggest that if Nick wants to add __get__, that it occur separately after this patch is applied. It would be a nice improvement. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-27 18:05 Message: Logged In: YES user_id=21627 It turns out that the documentation is incorrect, wrt. this patch, as it mentions a non-existing class functional.Partial. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-27 15:43 Message: Logged In: YES user_id=80475 Exposing the structure members for dynamic alteration exceeds the PEP specification. While making the tool more flexible, it slows it down (requiring type checks for every call) and it encourages strange uses. The notion of giving partial objects a changable state is at odds with the basis for functional programming (i.e. statelessness). The traverse function should use the new Py_VISIT macro. The PyCallable_Check() is unnecessary as it duplicates the check already existing in PyObject_Call(). I am not certain whether the PyDict_Copy() is necessary. Calls to f(**d) already pass a copy of d. Likewise, calling f(a=1) will create a new dictionary. If so, that dictionary can be updated in- place with pto->kw rather than creating a new dictionary. None of these issues are critical. Feel free to go forward with the patch. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-02-27 15:43 Message: Logged In: YES user_id=113328 To build on Windows (at least with mingw gcc, I don't know about MSVC) you need to assign members of partial_type which are symbols in the Python DLL at runtime, not compile time. The following diff probably explains better: --- functionalmodule.c.orig 2005-02-27 20:41:41.000000000 +000 +++ functionalmodule.c 2005-02-26 21:41:14.000000000 +0000 @@ -197,7 +197,7 @@ 0, /* tp_hash */ (ternaryfunc)partial_call, /* tp_call */ 0, /* tp_str */ - PyObject_GenericGetAttr, /* tp_getattro */ + 0, /* tp_getattro */ 0, /* tp_setattro */ 0, /* tp_as_buffer */ Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC | @@ -220,7 +220,7 @@ 0, /* tp_init */ 0, /* tp_alloc */ partial_new, /* tp_new */ - PyObject_GC_Del, /* tp_free */ + 0, /* tp_free */ }; @@ -239,6 +239,8 @@ int i; PyObject *m; char *name; + partial_type.tp_getattro = PyObject_GenericGetAttr; + partial_type.tp_free = PyObject_GC_Del; PyTypeObject *typelist[] = { &partial_type, NULL ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-26 00:27 Message: Logged In: YES user_id=1038590 Moving the discussion to python-dev :) ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-25 22:58 Message: Logged In: YES user_id=945502 Oops -- wrong order of association. ... self.args = args[2:] + func.args ... d = func.kw.copy() ... d.update(kw) should have been ... self.args = func.args + args[2:] ... kw.update(func.kw) ... self.kw = kw hopefully these errors didn't confuse my intent too much. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-25 22:53 Message: Logged In: YES user_id=945502 Yes, that's much clearer. I don't remember why I couldn't get it to work this way before (I tried something quite similar to this), but I'm glad someone could figure out the simpler way to do it. ;-) One potential problem with my proposal -- it doesn't work for nested partials: py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186470>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() ('a', <__main__.C object at 0x01186370>, 'b') One possible solution would be to merge nested partials, but I'm not at all certain this solves all the problems: py> class partial(object): ... def __init__(*args, **kw): ... self = args[0] ... func = args[1] ... if isinstance(func, partial): ... self.fn = func.fn ... self.args = args[2:] + func.args ... d = func.kw.copy() ... d.update(kw) ... self.kw = d ... else: ... self.fn, self.args, self.kw = (args[1], args[2:], kw) ... def __call__(self, *args, **kw): ... if kw and self.kw: ... d = self.kw.copy() ... d.update(kw) ... else: ... d = kw or self.kw ... return self.fn(*(self.args + args), **d) ... def __get__(self, obj, type=None): ... if obj is None: ... return self ... return partial(self.fn, obj, *self.args, **self.kw) ... py> class C(object): ... pass ... py> def func(self, arg1, arg2): ... return self, arg1, arg2 ... py> setattr(C, 'a', partial(func, 'a', 'b')) py> C().a() (<__main__.C object at 0x01186BB0>, 'a', 'b') py> setattr(C, 'a', partial(partial(func, 'a'), 'b')) py> C().a() (<__main__.C object at 0x01186650>, 'b', 'a') On the other hand, merging nested partials does reduce the number of function calls, so perhaps it's useful in and of itself... ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-25 22:45 Message: Logged In: YES user_id=1038590 If the __get__ method is added to make partial functions behave like instance methods, the documentation should probably mention that classmethod() and staticmethod() can then be used to alter the behaviour: Py> def f(*args): ... print args ... Py> class C: ... a = functional.partial(f) ... b = classmethod(functional.partial(f)) ... c = staticmethod(functional.partial(f)) ... Py> C().a Py> C().a() (<__main__.C instance at 0x009E6698>,) Py> C().b() (,) Py> C().c() () (This example used the simpler __get__ implementation I posted earlier) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-25 22:27 Message: Logged In: YES user_id=1038590 Steve's suggestion does sound good, but can't it simply be implemented with the PEP implementation and the following __get__ method?: def __get__(self, obj, type=None): if obj is None: return self return partial(self.func, obj, *self.args, **self.kwargs) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-25 22:17 Message: Logged In: YES user_id=1038590 Peter Harris already wrote docs in Patch 931007. Presumably they are still accurate, or perky would have said something. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-25 15:34 Message: Logged In: YES user_id=21627 In this form, the patch cannot be applied, since it lacks documentation changes. It might be that perky does not consider himself fluent enough in English to write the documentation - any other volunteers? I also think there is value to bediviere's point, even though the PEP currently specifies partial() differently. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-02-19 15:38 Message: Logged In: YES user_id=945502 It might be nice if partial objects were usable as instancemethods, like functions are. Note the following behavior with the current patch: >>> import functional >>> class C(object): ... pass ... >>> def func(self, arg): ... return arg ... >>> for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... >>> C().a() Traceback (most recent call last): File "", line 1, in ? TypeError: func() takes exactly 2 arguments (1 given) If functional.partial was instead defined like: class partial(object): def __init__(*args, **kwargs): self = args[0] try: self.func = args[1] except IndexError: raise TypeError('expected 2 or more arguments, got ' % len(args)) self.obj = () self.args = args[2:] self.kwargs = kwargs def __call__(self, *args, **kwargs): if kwargs and self.kwargs: d = self.kwargs.copy() d.update(kwargs) else: d = kwargs or self.kwargs return self.func(*(self.obj + self.args + args), **d) def __get__(self, obj, type=None): if obj is None: return self result = partial(self.func, *self.args, **self.kwargs) result.obj = (obj,) return result where an appropriate __get__ method is provided, then partial objects behave properly when set as attributes to a class: py> def test(): ... class C(object): ... pass ... def func(self, arg): ... return arg ... for item in ['a', 'b', 'c']: ... setattr(C, item, functional.partial(func, item)) ... c = C() ... return c.a(), c.b(), c.c() ... py> test() ('a', 'b', 'c') ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-10 19:11 Message: Logged In: YES user_id=1038590 I have tested this patch on Windows, and it passes its own test suite, without affecting any other tests. However, PCBuild\pythoncore.vcproj & PC\config.c require modification to allow Python to pick up the new module correctly. Patch #1006948 created with the needed changes (also removes unneeded ODBC references from pythoncore.vcproj as I am using the free MS toolkits to build here) My patch definitely needs to be checked by someone with a copy of Vis Studio 2003! ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-08-03 15:23 Message: Logged In: YES user_id=113328 OK, a real need beats my theoretical worries :-) Consider me convinced. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-05-17 23:05 Message: Logged In: YES user_id=139309 I would use partial in situations where speed can matter (imap, commonly used event handlers, etc.), so a fast C implementation would be nice to have. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 03:03 Message: Logged In: YES user_id=113328 Yes, that looks like a significant speed improvement :-) I was basing my assumptions on the comments made in the PEP. Sorry. But I still wonder if having the implementation in Python wouldn't be better from a maintenance point of view. (As well as all the arguments about usefulness as sample code, ability to backport, etc etc, that have come up on python-dev regarding moving other Python library modules into C...). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-04-26 21:05 Message: Logged In: YES user_id=55188 Python-version (function) ... 1.19 2.69 Python-version (class) ... 2.61 2.38 C-version ... 0.50 0.37 (former value is for 100000 instanciations and latter is for 100000 calls.) And, C version have a facility that changing attributes after the instantiation that is supported by class version only. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-26 14:30 Message: Logged In: YES user_id=113328 Why implement this in C? I can't imagine that the performance improvement will be that significant. A pure Python module in the standard library seems to me to be a far better idea. As the PEP says, "the case for a built-in coded in C is not very strong". And a Python module is good self-documentation. I prefer the function version suggested in the PEP (credited to Carl Banks) over the class-based one. You need to take a little care to avoid capturing argument names: def partial(*args, **kwds): def callit(*moreargs, **morekwds): kw = kwds.copy() kw.update(morekwds) return args[0](*(args[1:]+moreargs), **kw) return callit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470