From noreply at sourceforge.net Sun Oct 2 07:45:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 01 Oct 2005 22:45:26 -0700 Subject: [Patches] [ python-Patches-1031213 ] Patch for bug #780725 Message-ID: Patches item #1031213, was opened at 2004-09-20 06:37 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1031213&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: atsuo ishimoto (ishimoto) >Assigned to: Neal Norwitz (nnorwitz) Summary: Patch for bug #780725 Initial Comment: When SyntaxError occurs and the module contains source encodings definition, current implementation prints error line in UTF8. This patch reverts the line into original encoding for printing. This patch calls some memory-allocation APIs such as PyUnicode_DecodeUTF8. I'm not sure I can (or should) call PyErr_Clear() here if error happened. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-01 22:45 Message: Logged In: YES user_id=33168 I'm hoping that someone more familiar with unicode could take a look at this. The patch looks ok to me, but I don't know how to test that it works. I'm inclined to accept it, unless I hear otherwise. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1031213&group_id=5470 From noreply at sourceforge.net Sun Oct 2 20:08:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Oct 2005 11:08:59 -0700 Subject: [Patches] [ python-Patches-1031213 ] Patch for bug #780725 Message-ID: Patches item #1031213, was opened at 2004-09-20 15:37 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1031213&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Neal Norwitz (nnorwitz) Summary: Patch for bug #780725 Initial Comment: When SyntaxError occurs and the module contains source encodings definition, current implementation prints error line in UTF8. This patch reverts the line into original encoding for printing. This patch calls some memory-allocation APIs such as PyUnicode_DecodeUTF8. I'm not sure I can (or should) call PyErr_Clear() here if error happened. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-02 20:08 Message: Logged In: YES user_id=38388 Please use the "replace" error handler when recoding the source line to Unicode - this will reduce the probability of the conversion failing. If you do get an error, it's likely going to be an unknown encoding or less likely a memory problem. Please add some logic to deal with these errors as well - currently you don't call PyError_Clear() or take some other action which may lead to confusing error reports (e.g. error popping up randomly during program execution due to the set error). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 07:45 Message: Logged In: YES user_id=33168 I'm hoping that someone more familiar with unicode could take a look at this. The patch looks ok to me, but I don't know how to test that it works. I'm inclined to accept it, unless I hear otherwise. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1031213&group_id=5470 From noreply at sourceforge.net Sun Oct 2 22:27:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Oct 2005 13:27:22 -0700 Subject: [Patches] [ python-Patches-1201522 ] patch IDLE to allow running anonymous code in editor window Message-ID: Patches item #1201522, was opened at 2005-05-13 13:08 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1201522&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Jeff Shute (jshute) >Assigned to: Kurt B. Kaiser (kbk) Summary: patch IDLE to allow running anonymous code in editor window Initial Comment: This patch modifies IDLE so that when you can run code in an editor window that does not have a filename without first having to save the code. When you are editing an existing file, or have already saved the code once (giving it a filename), you are still required to save before you can run. This is useful when using IDLE for interactive hacking or calculating. Having to save and choose a filename is annoying when typing and running code that you have no intention of keeping, and tends to encourage editing big blocks of code in the shell when using an editor window would really be more convenient. I think the only reason that the save is required is because the debugger was getting confused when it did not have a backing file with the code. This patch fixes the debugger so it can handle unsaved anonymous code, and can highlight the correct source line in the edit window when the show source box is checked. The enhancement also works for the shell window, so the debugger can highlight the source line in the shell window (which may be something other than the last command, eg a function definition). The stack viewer and goto line command are also fixed to handle unsaved edit windows and the shell. It probably makes sense to apply this trivial patch also so you can get syntax highlighting in unsaved editor windows. http://sourceforge.net/tracker/index.php?func=detail&aid=1196895&group_id=5470&atid=305470 ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-10-02 16:27 Message: Logged In: YES user_id=149084 Having thought about this for awhile, I've concluded that the patch raises the risk of unintentionally losing code that one thought was being autosaved. It's simple enough to generate a throwaway filename, perhaps today's date, and clean the old ones out once in a while. Or reuse a file named scratch.py: pick it from the Recent Files menu, hit Select All followed by Backspace. The benefit/risk tradeoff just isn't good enough. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1201522&group_id=5470 From noreply at sourceforge.net Sun Oct 2 22:29:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Oct 2005 13:29:29 -0700 Subject: [Patches] [ python-Patches-1200038 ] CallTip Modifications Message-ID: Patches item #1200038, was opened at 2005-05-11 13:46 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200038&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: sowjanya (sowjanya) Assigned to: Nobody/Anonymous (nobody) >Summary: CallTip Modifications Initial Comment: These patches introduce modifications in CallTips, CallTipWindow and config-keys.def modules, 1-We create the global variable 'truncate ' in the CallTipWindow module .If truncate is True documenation string will be displayed till 75 characters ,and if False whole documentation string will be dispalyed. 2-In CallTips module , added if the object is callable then documenatation string describing the arguements of the object from call method is displayed with out truncating. 3-To allow the Up and Down arrow keys to be used to traverse the history of commands . In config-keys.def, history-next= history-previous= to history-next= history-previous= We are submitting the patches for your consideration to be included in to the next release of idlelib1.2a0. The patches were generated using the following comand, diff -c old new Thank you Sowjanya ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200038&group_id=5470 From noreply at sourceforge.net Sun Oct 2 23:56:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Oct 2005 14:56:27 -0700 Subject: [Patches] [ python-Patches-1309579 ] A wait4() implementation Message-ID: Patches item #1309579, was opened at 2005-09-30 08:32 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1309579&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: chads (cjschr) Assigned to: Nobody/Anonymous (nobody) Summary: A wait4() implementation Initial Comment: Implementation of a BSD-style wait4() function, which is similar to waitpid, but it also returns resource usage information about the child process. wait4(pid, options) -> (pid, status, rusage) Chad ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 14:56 Message: Logged In: YES user_id=33168 Comments from author received in mail: It is a duplicate of my original post, but it was diff'ed against the latest CVS tree. The usage example is for those who haven't had experience with wait4 before, hence the name. It's an FYI, nothing more. I'll also update the documentation accordingly. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-30 20:16 Message: Logged In: YES user_id=33168 Chad, I'm starting to look at this now, but it seems to be a duplicate of your original patch # 1000267. Can this be closed as a duplicate? I don't know if the attachments are the same. It would be easier to have all the changes in a single file. Since you are adding a new file, you will need to use -N option to cvs diff. Something like this: cvs diff -Nu ... (you can list the specific files that changed if necessary). >From what I looked at so far, there were a couple of things I didn't like. Though it looks like you addressed many (perhaps all) of the previous comments. I don't like the code in resourcemodule.h. I would prefer a public API in resourcemodule that posixmodule can call. If you think that no other modules outside python should call this, you can prefix the name with _, ie _PyResourceModule_...(). There are some un-prefixed names in resourcemodule.h. I think these may all go away if you move the code into the .c file. I would prefer to not have resourcemodule_h_author & resourcemodule_h_rcsid. The comment with your name and email is fine. I didn't look at the test or usage example. What should be done with the usage example? In the doc, could you remove the ", ?" for availability. We can leave it as Unix for now. If we find out definitive info about other platforms (Windows, Mac), we can add that later. Please add a \versionadded{2.5} at the end of the new doc (before the end). That's all my comments. This looks close to being ready. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1309579&group_id=5470 From noreply at sourceforge.net Sun Oct 2 23:57:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Oct 2005 14:57:30 -0700 Subject: [Patches] [ python-Patches-1000267 ] BSD-style wait4 implementation Message-ID: Patches item #1000267, was opened at 2004-07-29 11:52 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1000267&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: chads (cjschr) Assigned to: Nobody/Anonymous (nobody) Summary: BSD-style wait4 implementation Initial Comment: A BSD-style wait4 implementation. Using existing code from the posixmodule.c and resource.c files, I threw together a patch that implements the wait4 function. This function is similar to waitpid, but it also returns usage information about the child process. wait4(pid, options) -> (pid, status, rusage) It works for me on RedHat Linux 9 and FreeBSD 4.5 boxes using Python-2.3.4. The patch may need some fine tuning. Thanks Chad ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 14:57 Message: Logged In: YES user_id=33168 Received mail from author, this is out of date, newer patch is up-to-date. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-30 20:16 Message: Logged In: YES user_id=33168 Dup: 1309579. Not sure which is most up-to-date. Waiting for Chad to advise. ---------------------------------------------------------------------- Comment By: chads (cjschr) Date: 2005-08-01 15:50 Message: Logged In: YES user_id=1093928 Fix compilation error (gcc-2.95). Has anyone had a chance to look at this for inclusion? ---------------------------------------------------------------------- Comment By: chads (cjschr) Date: 2005-06-01 15:18 Message: Logged In: YES user_id=1093928 Per Martin's suggestions - thanks again. Documentation additions, configure test, import when called, single diff. LMK how this one fairs. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-24 14:15 Message: Logged In: YES user_id=21627 The code looks fine. The only problem I have with it that it seems to assume that any POSIX system implements wait4. However, I don't see it in Single Unix V3, so I think there should be some configure test to determine whether the function is present. Also, it would be nice if the resource module was only imported if wait4 was actually called. I can't see documentation changes; please provide a patch for Doc/lib/libos.tex as well. If you resubmit the patch, it would be easiest if the patch was a single file, eg. generated with "cvs diff -u". There is no need to include configure changes; configure.in would be sufficient. ---------------------------------------------------------------------- Comment By: chads (cjschr) Date: 2005-05-18 13:32 Message: Logged In: YES user_id=1093928 Finally took the time to implement os.wait4 based the comments from loewis. Added a resourcemodule.h header and modified resource.c and posixmodule.c appropriately. Take a gander and let me know what you think. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-22 09:23 Message: Logged In: YES user_id=21627 struct rusage is already defined in Modules/resourcemodule.c. It would be good if there was only a single definition of the type object. To achieve this, resourcemodule.c should expose a C API (e.g. PyObject *PyResource_FromResource(struct rusage*) ). This should be put into a CObject, which should be published through the module; then posixmodule should import resource when wait4 is called for the first time. Alternative, wait4 could be added to resourcemodule.c entirely. Yet another alternative, on top of this approach, posixmodule and/or os.py could provide their own definition of wait4 which delegates to resource.wait4 on first usage. ---------------------------------------------------------------------- Comment By: chads (cjschr) Date: 2004-08-13 12:00 Message: Logged In: YES user_id=1093928 Added a test suite and an example of using wait4. Feedback is welcome. Thanks. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-08-04 14:53 Message: Logged In: YES user_id=2772 You should also add code to the test suite to test wait4 when it is available. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1000267&group_id=5470 From noreply at sourceforge.net Mon Oct 3 02:39:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Oct 2005 17:39:09 -0700 Subject: [Patches] [ python-Patches-1227568 ] Patch for (Doc) bug #1219273 Message-ID: Patches item #1227568, was opened at 2005-06-25 15:49 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227568&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Peter van Kampen (pterk) >Assigned to: Neal Norwitz (nnorwitz) Summary: Patch for (Doc) bug #1219273 Initial Comment: Very limited extra info. Also: Lib/compiler.ast.py mentions that Expression is an 'artificial node class' so perhaps the omission is deliberate? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 17:39 Message: Logged In: YES user_id=33168 Thanks for the patch. Checked in as: * lib/asttable.tex 1.3 * Misc/ACKS 1.298 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227568&group_id=5470 From noreply at sourceforge.net Mon Oct 3 07:57:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Oct 2005 22:57:38 -0700 Subject: [Patches] [ python-Patches-1276356 ] Adding new regrtest resource 'urlfetch' Message-ID: Patches item #1276356, was opened at 2005-08-30 00:05 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1276356&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Hye-Shik Chang (perky) >Assigned to: Hye-Shik Chang (perky) Summary: Adding new regrtest resource 'urlfetch' Initial Comment: This is a fix for SF #1010952. test_normalization and test_codecmaps_* require too much effort to fetch the each test files. When this fix got applied, passing '-uurlfetch' to regrtest will enables on-demand downloads for the tests. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 22:57 Message: Logged In: YES user_id=33168 Perky, why don't you check this in? I don't see a particular problem with the code. If it breaks something, we oughta find out soon enough. :-) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-14 14:07 Message: Logged In: YES user_id=1188172 Applied the patch, works like a charm. I wonder though if you should give the user some feedback when he is downloading a file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1276356&group_id=5470 From noreply at sourceforge.net Mon Oct 3 16:17:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Oct 2005 07:17:12 -0700 Subject: [Patches] [ python-Patches-754022 ] Greatly enhanced webbrowser.py Message-ID: Patches item #754022, was opened at 2003-06-13 17:24 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Oleg Broytmann (phd) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Greatly enhanced webbrowser.py Initial Comment: The patch enhances webbrowser.py. First, all calls to os.system return result code, and the inverse of the code (it is ok/fail status) passed through all higher-level routines up to top-level call to open(url). This allows to check if a browser was really started. Second, the very open() modified so it is now trying to run all registered browsers in order until a browser returns 1. Third, the file can be used as a program: webbrowser.py url. Optional parameters -n allows to open the url in a new window. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-10-03 16:17 Message: Logged In: YES user_id=1188172 Committed the patch as Lib/webbrowser.py r1.38, Doc/lib/libwebbrowser.tex r1.11. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-09-23 16:09 Message: Logged In: YES user_id=4799 Done. New libwebbrowser.tex.patch is about to be uploaded. Thank you! ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-09-22 05:35 Message: Logged In: YES user_id=671362 Minor nit. 11.1.1 Browser Controller Objects from the description of open method:: > If new is true, a new browser window is opened if possible. Now "new" can be 0, 1 or 2. This part also needs an update. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-09-16 09:28 Message: Logged In: YES user_id=4799 Arguable (especially compared with smtpd.py), but I am not goint to argue. Please apply the patch and let us see what other people think and say. It seems there are enough users... ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-16 08:32 Message: Logged In: YES user_id=1188172 Granted, but you will concur that starting a webbrowser isn't something that the command line user normally wants to do via a Python script. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-09-15 23:52 Message: Logged In: YES user_id=4799 >From setup.py: scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle', 'Lib/smtpd.py'] See, Python installs 3 scripts into /usr/{local/}bin/ - pydoc, idle and smtpd.py. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 22:48 Message: Logged In: YES user_id=1188172 No other module that can be used standalone delivers such a script. There's also the question where to install it, etc. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-09-15 22:18 Message: Logged In: YES user_id=4799 In the main(): opts, args = getopt.getopt(sys.argv[1:], 'ntd') You can remove 'd' as you've dropeed debugging prints. Are you going to drop standalone webbrowser script? Is "python -m webbrowser" enough? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 21:49 Message: Logged In: YES user_id=1188172 Ah, thanks. I had already corrected #1, but didn't look closely enough for #2. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-09-15 19:26 Message: Logged In: YES user_id=671362 Let me point out two problems: o NameError if remote_background: cmd += ' &' => if self.remote_background: # add "self." cmd += ' &' o copy and paste mistake? \lineiii{'mozilla'}{\class{Mozilla('mozilla')}}{} \lineiii{'firefox'}{\class{Mozilla('mozilla')}}{} => \lineiii{'mozilla'}{\class{Mozilla('mozilla')}}{} \lineiii{'firefox'}{\class{Mozilla('firefox')}}{} ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 10:07 Message: Logged In: YES user_id=1188172 Adding new patch (webbrowser.diff), enhanced with other patches and bugfixes here on SF. Also updated the docs with changed/added notes. Please review, I'll apply this for 2.5. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 18:33 Message: Logged In: YES user_id=1188172 I have reviewed this one too, and I really recommend to apply it for 2.5. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-30 13:02 Message: Logged In: YES user_id=4799 Added Opera controller to the doc. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-30 13:01 Message: Logged In: YES user_id=4799 Added remote functionality for Opera on Unix. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-29 10:50 Message: Logged In: YES user_id=4799 Updated documention patch - added a section about webbrowser script and its command-line options and arguments. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-29 10:48 Message: Logged In: YES user_id=4799 Changed _isexecutable() on w32 to test for executable extensions (.exe, bat) . Tested on Linux with Mozilla/links/elinks; on w32 with Mozilla/Opera/Firefox. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-28 23:25 Message: Logged In: YES user_id=9057 I have revised: libwebbrowser.tex.patch and webbrowser.py.patch. They are Ok, I recommend to apply both. Outstanding work. However, I would withdraw the webbrowser wrapper script, since the same functionality can be accomplished with: python -m webbrowser http://www.python.org ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-28 16:21 Message: Logged In: YES user_id=4799 Patch for documentation. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-28 16:19 Message: Logged In: YES user_id=4799 Minor bugfix. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 14:30 Message: Logged In: YES user_id=4799 Do not report error if the browser doesn't support tabs - just open the URL in a new window. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 14:14 Message: Logged In: YES user_id=4799 I've reworked the patch once more. I moved some common functionality into the UnixBrowser class and added two new features - Elinks launcher class (elinks supports remote commands in a manner very similar to Mozilla) and new-tab functionality for browsers that support tabbed browsing (Mozilla and elinks); a user can now run "webbrowser -t URL" to open the URL a new tab. All classes in the module are now new-style classes (except for the Error class). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 22:18 Message: Logged In: YES user_id=4799 Uploading webbrowser wrapper script. Put it into Tools/scripts directory, and add to the end of setup.py. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 22:17 Message: Logged In: YES user_id=4799 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. :-( ) ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 22:14 Message: Logged In: YES user_id=4799 I've moved script code to main() function. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-23 20:25 Message: Logged In: YES user_id=9057 I have reviewed this patch in 2005-03-23 and recommend it to be applied ! Oleg have made the comments below to Python-dev, and those must be taken into consideration while applying this patch. http://python.org/sf/728278 Close with resolution "partially applied, partially rejected". http://python.org/sf/754022 Review and apply! ;) http://python.org/sf/1166780 Close with resolution "applied". (Though it was not applied in exactly that form...) http://python.org/sf/1077979 Close with resolution "applied long ago". http://python.org/sf/1144816 Close with resolution "duplicate of 1077979". ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 19:06 Message: Logged In: YES user_id=4799 I've consolidated patches 728278, 754022, 954628, 1166780 into this single patch. Some parts of those patches were applied, some rejected, many things changed. I also added elinks support - currently it is very similar to links. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-12-07 12:23 Message: Logged In: YES user_id=4799 Applied the patch from http://python.org/sf/1077979. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-20 08:11 Message: Logged In: YES user_id=80475 Too late for Py2.4. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-10-07 09:48 Message: Logged In: YES user_id=4799 And don't forget to make it executable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 From noreply at sourceforge.net Mon Oct 3 22:13:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Oct 2005 13:13:23 -0700 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 04: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 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. 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-10-03 16:13 Message: Logged In: YES user_id=149084 Checked in 03Feb05 patch as rev 1.5 Tweaked comments, docstrings, and names; checked in as rev 1.6 Incorporated Tal Einat's alignment suggestion; checked in as rev 1.7 It appears to me that the stopindent mechanism to terminate processing a region is now redundant. I can comment out the 'break' in get_context() [new name!] and everything still seems to work ok. Am I missing something? ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2005-08-18 11:28 Message: Logged In: YES user_id=1330769 This fixes the text alignment: (just replace te appropriate code in toggle_code_context_event with this) if not self.label: self.padding_frame = Tkinter.Frame(self.editwin.top, bg=self.bgcolor, border=2, relief="sunken", ) self.label = Tkinter.Label(self.padding_frame, text="\n" * (self.numlines - 1), anchor="w", justify="left", font=self.textfont, bg=self.bgcolor, fg=self.fgcolor, border=0, width=1, # Don't request more than we get ) self.label.pack(side="top", fill="x", expand=1, padx=4, pady=0) self.padding_frame.pack(side="top", fill="x", expand=0, padx=0, pady=0, after=self.editwin.status_bar) else: self.label.destroy() self.padding_frame.destroy() self.label = None Sorry it's not a diff... ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2005-02-03 19: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-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 18: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 21: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 17: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 18: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 16: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 16: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 Tue Oct 4 05:47:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Oct 2005 20:47:16 -0700 Subject: [Patches] [ python-Patches-1307806 ] PCbuild vcproj project files need a cleanup Message-ID: Patches item #1307806, was opened at 2005-09-29 03:08 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1307806&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Build >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: PCbuild vcproj project files need a cleanup Initial Comment: The Visual Studio .NET vcproj files were probably generated by importing the older Visual C++ 6.0 dsp files and saving them back into the new format. The convertor is not perfect. The bigest problem it has it's the handling of the configuration macro defines. Instead of defining the used macros once for each configuration, it defines them for each individual file. This causes file bloat and could cause problems when new files are added to the project since we could get builds with mixed defines due to the $(NoInherit) flag which makes the compiler ignore global defines. For example, the current pythoncore.vcproj file has 100 KB. A cleaned up version is less than 25 KB. NOW: CLEANED-UP: There are a couple of files which require custom options: ..\Modules\getbuildinfo.c - PreprocessorDefinitions="BUILD=67" ..\PC\import_nt.c - AdditionalIncludeDirectories="..\Python" ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-03 20:47 Message: Logged In: YES user_id=33168 Thanks. I'm moving this to patches. ---------------------------------------------------------------------- Comment By: Adal Chiriliuc (adalx) Date: 2005-10-03 14:32 Message: Logged In: YES user_id=1067739 Attached patch with cleaned up .vcproj files. VCCLCompilerTool: removed PrecompiledHeaderFile, AssemblerListingLocation, ObjectFile, ProgramDataBaseFileName entires. They are defined by default to the same values. VCMIDLTool: removed all entries. VCResourceCompilerTool: removed all entries for all but a couple of projects which actually have resource files. Removed FileConfiguration entries for all project files which don't need it. There's still stuff which could be cleaned up, I've only removed the biggest offenders. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-03 12:56 Message: Logged In: YES user_id=33168 Can you provide a patch (attach to this bug report if possible) for what the new file should look like? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1307806&group_id=5470 From noreply at sourceforge.net Tue Oct 4 17:12:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 04 Oct 2005 08:12:13 -0700 Subject: [Patches] [ python-Patches-1312980 ] httplib error handling and HTTP/0.9 fix Message-ID: Patches item #1312980, was opened at 2005-10-04 11:12 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=1312980&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Yusuke Shinyama (euske) Assigned to: Nobody/Anonymous (nobody) Summary: httplib error handling and HTTP/0.9 fix Initial Comment: HTTPResponse.begin did not initialize self.length if the protocol version is 0.9, which later causes an AttributeError. Also, error handling for "chunk_left = int(line, 16)" in HTTPResponse._read_chunked is missing, which might cause a ValueError. The patch fixes the above two problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1312980&group_id=5470 From noreply at sourceforge.net Wed Oct 5 13:03:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Oct 2005 04:03:33 -0700 Subject: [Patches] [ python-Patches-1183712 ] package_data chops off first char of default package Message-ID: Patches item #1183712, was opened at 2005-04-15 14:34 Message generated for change (Comment added) made by hcauwelier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1183712&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: package_data chops off first char of default package Initial Comment: If the package name is an empty string (ie the default package), all package_data files have the first character chopped off. Attached is a test package pytest.tar.gz where running python2.4 setup.py build_py produces this error: running build_py creating build creating build/lib copying __init__.py -> build/lib error: can't copy 'ATA': doesn't exist or not a regular file Also attached is a fix proposal, though I have tested this only against the test package. ---------------------------------------------------------------------- Comment By: Herv? Cauwelier (hcauwelier) Date: 2005-10-05 13:03 Message: Logged In: YES user_id=1216236 The patch worked well for me, thanks for it! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1183712&group_id=5470 From noreply at sourceforge.net Wed Oct 5 17:01:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Oct 2005 08:01:52 -0700 Subject: [Patches] [ python-Patches-1313939 ] Speedup PyUnicode_DecodeCharmap Message-ID: Patches item #1313939, was opened at 2005-10-05 17:01 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=1313939&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Speedup PyUnicode_DecodeCharmap Initial Comment: This patch speeds up PyUnicode_DecodeCharmap() as discussed in the thread: http://mail.python.org/pipermail/python-dev/2005-October/056958.html It makes it possible to pass a unicode string to cPyUnicode_DecodeCharmap() in addition to the dictionary which is still supported. The unicode character at position i in the string is used as the decoded value for byte i. Byte values greater that the length of the string and u"\ufffd" characters in the string are treated as "maps to undefined". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1313939&group_id=5470 From noreply at sourceforge.net Wed Oct 5 19:08:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Oct 2005 10:08:06 -0700 Subject: [Patches] [ python-Patches-1314067 ] os.makedirs - robust against partial path Message-ID: Patches item #1314067, was opened at 2005-10-05 13: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=1314067&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: os.makedirs - robust against partial path Initial Comment: os.py function makedirs is intended to create a directory, including any required parent directories. Unfortunately, at least on windows, it fails is some of those parent directories already exist. This patch says "if the directory I'm about to create is already an existing directory, then pretend I succeeded and continue with the next step." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1314067&group_id=5470 From info at ecorez.com Wed Oct 5 12:17:27 2005 From: info at ecorez.com (Eco Rez) Date: Wednesday, 5 Oct 2005 12:17:27 Subject: [Patches] 2 for 1 Fall Promotion Message-ID: <220d4db3-1be0-46b6-84a8-42e00c7c5745@IETF.ORG> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20051005/03c54505/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 235353 bytes Desc: not available Url : http://mail.python.org/pipermail/patches/attachments/20051005/03c54505/attachment-0001.jpe From noreply at sourceforge.net Wed Oct 5 19:50:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Oct 2005 10:50:43 -0700 Subject: [Patches] [ python-Patches-1313939 ] Speedup PyUnicode_DecodeCharmap Message-ID: Patches item #1313939, was opened at 2005-10-05 17:01 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1313939&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Speedup PyUnicode_DecodeCharmap Initial Comment: This patch speeds up PyUnicode_DecodeCharmap() as discussed in the thread: http://mail.python.org/pipermail/python-dev/2005-October/056958.html It makes it possible to pass a unicode string to cPyUnicode_DecodeCharmap() in addition to the dictionary which is still supported. The unicode character at position i in the string is used as the decoded value for byte i. Byte values greater that the length of the string and u"\ufffd" characters in the string are treated as "maps to undefined". ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-05 19:50 Message: Logged In: YES user_id=38388 The patch looks good, but I'd still like to see whether Hye-Shik's fastmap codec wouldn't be a better and more general solution since it seems to also provide good performance for encoding Unicode strings. That said, you should use a non-code point such as 0xFFFE for meaning "undefined mapping". The Unicode replacement character is not a good choice as this is a very valid character which often actually gets used to replace characters for which no Unicode code point is known. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1313939&group_id=5470 From noreply at sourceforge.net Wed Oct 5 20:36:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Oct 2005 11:36:15 -0700 Subject: [Patches] [ python-Patches-1313939 ] Speedup PyUnicode_DecodeCharmap Message-ID: Patches item #1313939, was opened at 2005-10-05 17:01 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1313939&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Speedup PyUnicode_DecodeCharmap Initial Comment: This patch speeds up PyUnicode_DecodeCharmap() as discussed in the thread: http://mail.python.org/pipermail/python-dev/2005-October/056958.html It makes it possible to pass a unicode string to cPyUnicode_DecodeCharmap() in addition to the dictionary which is still supported. The unicode character at position i in the string is used as the decoded value for byte i. Byte values greater that the length of the string and u"\ufffd" characters in the string are treated as "maps to undefined". ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-10-05 20:36 Message: Logged In: YES user_id=21627 For decoding, Walter's code is nearly identical to the fastmap decoder: both use a Py_UNICODE array to represent the map, and both use REPLACEMENT CHARACTER to denote a missing target code. I find the use of U+FFFD highly appropriate, and not at all debatable. None of the existing codecs maps any of its characters to U+FFFD, and I would consider it a bug if one did. REPLACEMENT CHARACTER should only be used if there is no approprate character, so no charmap should claim that the appropriate mapping for some by is that character. That you often use U+FFFD in output to denote unmappable characters is a different issue, indeed, Python's "replace" mode does so. It would continue to do so under this patch. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-05 19:50 Message: Logged In: YES user_id=38388 The patch looks good, but I'd still like to see whether Hye-Shik's fastmap codec wouldn't be a better and more general solution since it seems to also provide good performance for encoding Unicode strings. That said, you should use a non-code point such as 0xFFFE for meaning "undefined mapping". The Unicode replacement character is not a good choice as this is a very valid character which often actually gets used to replace characters for which no Unicode code point is known. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1313939&group_id=5470 From noreply at sourceforge.net Wed Oct 5 22:39:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Oct 2005 13:39:39 -0700 Subject: [Patches] [ python-Patches-1313939 ] Speedup PyUnicode_DecodeCharmap Message-ID: Patches item #1313939, was opened at 2005-10-05 17:01 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1313939&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Speedup PyUnicode_DecodeCharmap Initial Comment: This patch speeds up PyUnicode_DecodeCharmap() as discussed in the thread: http://mail.python.org/pipermail/python-dev/2005-October/056958.html It makes it possible to pass a unicode string to cPyUnicode_DecodeCharmap() in addition to the dictionary which is still supported. The unicode character at position i in the string is used as the decoded value for byte i. Byte values greater that the length of the string and u"\ufffd" characters in the string are treated as "maps to undefined". ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-05 22:39 Message: Logged In: YES user_id=38388 The whole point is finding a replacement code point for the None value in dictionaries. Since None is not a character, a code point should be chosen that is guaranteed to never be assigned. FFFE is such a code point, hence the choice. FFFD is an assigned code point. Note that a mapping to FFFE will always raise an exception and the codec user can then decide to use the replace error handler to have the codec use FFFD instead. It is also very reasonable for a codec to map some characters to FFFD to avoid invoking the exception handling in those cases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-05 20:36 Message: Logged In: YES user_id=21627 For decoding, Walter's code is nearly identical to the fastmap decoder: both use a Py_UNICODE array to represent the map, and both use REPLACEMENT CHARACTER to denote a missing target code. I find the use of U+FFFD highly appropriate, and not at all debatable. None of the existing codecs maps any of its characters to U+FFFD, and I would consider it a bug if one did. REPLACEMENT CHARACTER should only be used if there is no approprate character, so no charmap should claim that the appropriate mapping for some by is that character. That you often use U+FFFD in output to denote unmappable characters is a different issue, indeed, Python's "replace" mode does so. It would continue to do so under this patch. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-05 19:50 Message: Logged In: YES user_id=38388 The patch looks good, but I'd still like to see whether Hye-Shik's fastmap codec wouldn't be a better and more general solution since it seems to also provide good performance for encoding Unicode strings. That said, you should use a non-code point such as 0xFFFE for meaning "undefined mapping". The Unicode replacement character is not a good choice as this is a very valid character which often actually gets used to replace characters for which no Unicode code point is known. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1313939&group_id=5470 From noreply at sourceforge.net Thu Oct 6 04:18:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Oct 2005 19:18:56 -0700 Subject: [Patches] [ python-Patches-1314396 ] ensure lock is released if exception is raised Message-ID: Patches item #1314396, was opened at 2005-10-06 02: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=1314396&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eric Blossom (eblossom) Assigned to: Nobody/Anonymous (nobody) Summary: ensure lock is released if exception is raised Initial Comment: If an exception (typically KeyboardInterrupt) is raised in Thread.join, self.__block will be left locked, and any later attempt to join will block forever. The bug is easy to trigger if you provide a timeout to join. This patch ensures that the lock is released. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1314396&group_id=5470 From noreply at sourceforge.net Thu Oct 6 06:14:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Oct 2005 21:14:27 -0700 Subject: [Patches] [ python-Patches-1276356 ] Adding new regrtest resource 'urlfetch' Message-ID: Patches item #1276356, was opened at 2005-08-30 16:05 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1276356&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Hye-Shik Chang (perky) Summary: Adding new regrtest resource 'urlfetch' Initial Comment: This is a fix for SF #1010952. test_normalization and test_codecmaps_* require too much effort to fetch the each test files. When this fix got applied, passing '-uurlfetch' to regrtest will enables on-demand downloads for the tests. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2005-10-06 13:14 Message: Logged In: YES user_id=55188 I thought this needs to give notification when it's downloading files as birkenfeld suggested. I'll commit this fix after implementing that. Thank you for comments! :-) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-03 14:57 Message: Logged In: YES user_id=33168 Perky, why don't you check this in? I don't see a particular problem with the code. If it breaks something, we oughta find out soon enough. :-) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 06:07 Message: Logged In: YES user_id=1188172 Applied the patch, works like a charm. I wonder though if you should give the user some feedback when he is downloading a file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1276356&group_id=5470 From noreply at sourceforge.net Thu Oct 6 16:45:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Oct 2005 07:45:22 -0700 Subject: [Patches] [ python-Patches-1313939 ] Speedup PyUnicode_DecodeCharmap Message-ID: Patches item #1313939, was opened at 2005-10-05 17:01 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1313939&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Speedup PyUnicode_DecodeCharmap Initial Comment: This patch speeds up PyUnicode_DecodeCharmap() as discussed in the thread: http://mail.python.org/pipermail/python-dev/2005-October/056958.html It makes it possible to pass a unicode string to cPyUnicode_DecodeCharmap() in addition to the dictionary which is still supported. The unicode character at position i in the string is used as the decoded value for byte i. Byte values greater that the length of the string and u"\ufffd" characters in the string are treated as "maps to undefined". ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 16:45 Message: Logged In: YES user_id=89016 OK, I've updated the patch to include an update of the documentation and a few test and I've simplified codecs.make_maps a bit, since we'll always have a decoding string. 0xFFFD is still used as the undefined marker value. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-05 22:39 Message: Logged In: YES user_id=38388 The whole point is finding a replacement code point for the None value in dictionaries. Since None is not a character, a code point should be chosen that is guaranteed to never be assigned. FFFE is such a code point, hence the choice. FFFD is an assigned code point. Note that a mapping to FFFE will always raise an exception and the codec user can then decide to use the replace error handler to have the codec use FFFD instead. It is also very reasonable for a codec to map some characters to FFFD to avoid invoking the exception handling in those cases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-05 20:36 Message: Logged In: YES user_id=21627 For decoding, Walter's code is nearly identical to the fastmap decoder: both use a Py_UNICODE array to represent the map, and both use REPLACEMENT CHARACTER to denote a missing target code. I find the use of U+FFFD highly appropriate, and not at all debatable. None of the existing codecs maps any of its characters to U+FFFD, and I would consider it a bug if one did. REPLACEMENT CHARACTER should only be used if there is no approprate character, so no charmap should claim that the appropriate mapping for some by is that character. That you often use U+FFFD in output to denote unmappable characters is a different issue, indeed, Python's "replace" mode does so. It would continue to do so under this patch. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-05 19:50 Message: Logged In: YES user_id=38388 The patch looks good, but I'd still like to see whether Hye-Shik's fastmap codec wouldn't be a better and more general solution since it seems to also provide good performance for encoding Unicode strings. That said, you should use a non-code point such as 0xFFFE for meaning "undefined mapping". The Unicode replacement character is not a good choice as this is a very valid character which often actually gets used to replace characters for which no Unicode code point is known. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1313939&group_id=5470 From noreply at sourceforge.net Thu Oct 6 17:24:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Oct 2005 08:24:21 -0700 Subject: [Patches] [ python-Patches-1313939 ] Speedup PyUnicode_DecodeCharmap Message-ID: Patches item #1313939, was opened at 2005-10-05 17:01 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1313939&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Speedup PyUnicode_DecodeCharmap Initial Comment: This patch speeds up PyUnicode_DecodeCharmap() as discussed in the thread: http://mail.python.org/pipermail/python-dev/2005-October/056958.html It makes it possible to pass a unicode string to cPyUnicode_DecodeCharmap() in addition to the dictionary which is still supported. The unicode character at position i in the string is used as the decoded value for byte i. Byte values greater that the length of the string and u"\ufffd" characters in the string are treated as "maps to undefined". ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-06 17:24 Message: Logged In: YES user_id=38388 Thanks, Walter. However, you won't get my approval with the choice of FFFD as meaning "undefined mapping" - that code point is defined. Please choose a different code that is documented to never be defined by the Unicode standard. Also, please explain the new alias 'unicode_1_1_utf_7' : 'utf_7'. About the make_maps() function: the decoding maps should be generated by the gencodec.py script instead of doing this a import time. The dictionaries can then be removed from the codecs. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 16:45 Message: Logged In: YES user_id=89016 OK, I've updated the patch to include an update of the documentation and a few test and I've simplified codecs.make_maps a bit, since we'll always have a decoding string. 0xFFFD is still used as the undefined marker value. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-05 22:39 Message: Logged In: YES user_id=38388 The whole point is finding a replacement code point for the None value in dictionaries. Since None is not a character, a code point should be chosen that is guaranteed to never be assigned. FFFE is such a code point, hence the choice. FFFD is an assigned code point. Note that a mapping to FFFE will always raise an exception and the codec user can then decide to use the replace error handler to have the codec use FFFD instead. It is also very reasonable for a codec to map some characters to FFFD to avoid invoking the exception handling in those cases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-05 20:36 Message: Logged In: YES user_id=21627 For decoding, Walter's code is nearly identical to the fastmap decoder: both use a Py_UNICODE array to represent the map, and both use REPLACEMENT CHARACTER to denote a missing target code. I find the use of U+FFFD highly appropriate, and not at all debatable. None of the existing codecs maps any of its characters to U+FFFD, and I would consider it a bug if one did. REPLACEMENT CHARACTER should only be used if there is no approprate character, so no charmap should claim that the appropriate mapping for some by is that character. That you often use U+FFFD in output to denote unmappable characters is a different issue, indeed, Python's "replace" mode does so. It would continue to do so under this patch. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-05 19:50 Message: Logged In: YES user_id=38388 The patch looks good, but I'd still like to see whether Hye-Shik's fastmap codec wouldn't be a better and more general solution since it seems to also provide good performance for encoding Unicode strings. That said, you should use a non-code point such as 0xFFFE for meaning "undefined mapping". The Unicode replacement character is not a good choice as this is a very valid character which often actually gets used to replace characters for which no Unicode code point is known. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1313939&group_id=5470 From noreply at sourceforge.net Thu Oct 6 17:50:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Oct 2005 08:50:16 -0700 Subject: [Patches] [ python-Patches-1313939 ] Speedup PyUnicode_DecodeCharmap Message-ID: Patches item #1313939, was opened at 2005-10-05 17:01 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1313939&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Speedup PyUnicode_DecodeCharmap Initial Comment: This patch speeds up PyUnicode_DecodeCharmap() as discussed in the thread: http://mail.python.org/pipermail/python-dev/2005-October/056958.html It makes it possible to pass a unicode string to cPyUnicode_DecodeCharmap() in addition to the dictionary which is still supported. The unicode character at position i in the string is used as the decoded value for byte i. Byte values greater that the length of the string and u"\ufffd" characters in the string are treated as "maps to undefined". ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 17:50 Message: Logged In: YES user_id=89016 > Thanks, Walter. However, you won't get my approval with the > choice of FFFD as meaning "undefined mapping" - that code > point is defined. Please choose a different code that is > documented to never be defined by the Unicode standard. OK, I've updated the patch to use 0xfffe instead. Note that this only work as long as u"\fffe" is a legal Unicode literal. > Also, please explain the new alias 'unicode_1_1_utf_7' : > 'utf_7'. Oops, that was for bug #1245379. Removed > About the make_maps() function: the decoding maps should be > generated by the gencodec.py script instead of doing this a > import time. The dictionaries can then be removed from the > codecs. That's true. I'm still working on that. Do you have any tips on how to do that (what files do I have to download and where do I have to put it and how (and from where) do I have to call gencodec.py). Is this documented somewhere? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-06 17:24 Message: Logged In: YES user_id=38388 Thanks, Walter. However, you won't get my approval with the choice of FFFD as meaning "undefined mapping" - that code point is defined. Please choose a different code that is documented to never be defined by the Unicode standard. Also, please explain the new alias 'unicode_1_1_utf_7' : 'utf_7'. About the make_maps() function: the decoding maps should be generated by the gencodec.py script instead of doing this a import time. The dictionaries can then be removed from the codecs. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 16:45 Message: Logged In: YES user_id=89016 OK, I've updated the patch to include an update of the documentation and a few test and I've simplified codecs.make_maps a bit, since we'll always have a decoding string. 0xFFFD is still used as the undefined marker value. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-05 22:39 Message: Logged In: YES user_id=38388 The whole point is finding a replacement code point for the None value in dictionaries. Since None is not a character, a code point should be chosen that is guaranteed to never be assigned. FFFE is such a code point, hence the choice. FFFD is an assigned code point. Note that a mapping to FFFE will always raise an exception and the codec user can then decide to use the replace error handler to have the codec use FFFD instead. It is also very reasonable for a codec to map some characters to FFFD to avoid invoking the exception handling in those cases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-05 20:36 Message: Logged In: YES user_id=21627 For decoding, Walter's code is nearly identical to the fastmap decoder: both use a Py_UNICODE array to represent the map, and both use REPLACEMENT CHARACTER to denote a missing target code. I find the use of U+FFFD highly appropriate, and not at all debatable. None of the existing codecs maps any of its characters to U+FFFD, and I would consider it a bug if one did. REPLACEMENT CHARACTER should only be used if there is no approprate character, so no charmap should claim that the appropriate mapping for some by is that character. That you often use U+FFFD in output to denote unmappable characters is a different issue, indeed, Python's "replace" mode does so. It would continue to do so under this patch. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-05 19:50 Message: Logged In: YES user_id=38388 The patch looks good, but I'd still like to see whether Hye-Shik's fastmap codec wouldn't be a better and more general solution since it seems to also provide good performance for encoding Unicode strings. That said, you should use a non-code point such as 0xFFFE for meaning "undefined mapping". The Unicode replacement character is not a good choice as this is a very valid character which often actually gets used to replace characters for which no Unicode code point is known. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1313939&group_id=5470 From noreply at sourceforge.net Thu Oct 6 18:59:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Oct 2005 09:59:01 -0700 Subject: [Patches] [ python-Patches-1313939 ] Speedup PyUnicode_DecodeCharmap Message-ID: Patches item #1313939, was opened at 2005-10-05 17:01 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1313939&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Speedup PyUnicode_DecodeCharmap Initial Comment: This patch speeds up PyUnicode_DecodeCharmap() as discussed in the thread: http://mail.python.org/pipermail/python-dev/2005-October/056958.html It makes it possible to pass a unicode string to cPyUnicode_DecodeCharmap() in addition to the dictionary which is still supported. The unicode character at position i in the string is used as the decoded value for byte i. Byte values greater that the length of the string and u"\ufffd" characters in the string are treated as "maps to undefined". ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 18:59 Message: Logged In: YES user_id=89016 > I can regenerate the codecs using gencodec.py, no problem. I > can also change it to create the string mapping. That would be great. So should I check in everything else (i.e. unicodeobject.c and the doc and test changes)? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-06 18:02 Message: Logged In: YES user_id=38388 Thanks for the change. I can regenerate the codecs using gencodec.py, no problem. I can also change it to create the string mapping. For reference: the mapping files can be downloaded from ftp.unicode.org. The gencodec.py script then takes the mapping filename as argument and creates a codec .py file from it. Special care has to be taken in that some codecs contains hand-edited details. Note that it's likely that some codecs will have additions or removals - the files on the ftp.unicode.org are updated every now and then and usually contain more up-to-date mappings. For some codecs, you won't find mapping files on the Unicode site - these were then contributed by 3rd parties. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 17:50 Message: Logged In: YES user_id=89016 > Thanks, Walter. However, you won't get my approval with the > choice of FFFD as meaning "undefined mapping" - that code > point is defined. Please choose a different code that is > documented to never be defined by the Unicode standard. OK, I've updated the patch to use 0xfffe instead. Note that this only work as long as u"\fffe" is a legal Unicode literal. > Also, please explain the new alias 'unicode_1_1_utf_7' : > 'utf_7'. Oops, that was for bug #1245379. Removed > About the make_maps() function: the decoding maps should be > generated by the gencodec.py script instead of doing this a > import time. The dictionaries can then be removed from the > codecs. That's true. I'm still working on that. Do you have any tips on how to do that (what files do I have to download and where do I have to put it and how (and from where) do I have to call gencodec.py). Is this documented somewhere? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-06 17:24 Message: Logged In: YES user_id=38388 Thanks, Walter. However, you won't get my approval with the choice of FFFD as meaning "undefined mapping" - that code point is defined. Please choose a different code that is documented to never be defined by the Unicode standard. Also, please explain the new alias 'unicode_1_1_utf_7' : 'utf_7'. About the make_maps() function: the decoding maps should be generated by the gencodec.py script instead of doing this a import time. The dictionaries can then be removed from the codecs. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 16:45 Message: Logged In: YES user_id=89016 OK, I've updated the patch to include an update of the documentation and a few test and I've simplified codecs.make_maps a bit, since we'll always have a decoding string. 0xFFFD is still used as the undefined marker value. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-05 22:39 Message: Logged In: YES user_id=38388 The whole point is finding a replacement code point for the None value in dictionaries. Since None is not a character, a code point should be chosen that is guaranteed to never be assigned. FFFE is such a code point, hence the choice. FFFD is an assigned code point. Note that a mapping to FFFE will always raise an exception and the codec user can then decide to use the replace error handler to have the codec use FFFD instead. It is also very reasonable for a codec to map some characters to FFFD to avoid invoking the exception handling in those cases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-05 20:36 Message: Logged In: YES user_id=21627 For decoding, Walter's code is nearly identical to the fastmap decoder: both use a Py_UNICODE array to represent the map, and both use REPLACEMENT CHARACTER to denote a missing target code. I find the use of U+FFFD highly appropriate, and not at all debatable. None of the existing codecs maps any of its characters to U+FFFD, and I would consider it a bug if one did. REPLACEMENT CHARACTER should only be used if there is no approprate character, so no charmap should claim that the appropriate mapping for some by is that character. That you often use U+FFFD in output to denote unmappable characters is a different issue, indeed, Python's "replace" mode does so. It would continue to do so under this patch. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-05 19:50 Message: Logged In: YES user_id=38388 The patch looks good, but I'd still like to see whether Hye-Shik's fastmap codec wouldn't be a better and more general solution since it seems to also provide good performance for encoding Unicode strings. That said, you should use a non-code point such as 0xFFFE for meaning "undefined mapping". The Unicode replacement character is not a good choice as this is a very valid character which often actually gets used to replace characters for which no Unicode code point is known. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1313939&group_id=5470 From noreply at sourceforge.net Thu Oct 6 19:14:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Oct 2005 10:14:50 -0700 Subject: [Patches] [ python-Patches-1315161 ] ToolTip.py: fix main() function Message-ID: Patches item #1315161, was opened at 2005-10-06 19: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=1315161&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: sebastien blanchet (blanchet_38) Assigned to: Nobody/Anonymous (nobody) Summary: ToolTip.py: fix main() function Initial Comment: The main() function of ToolTip did not work: 1- root.mainloop() was commented, so the example code did not work 2- main() was invoked each time the module was imported because the test "if __name__ == "__main__":" was missing ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1315161&group_id=5470 From noreply at sourceforge.net Thu Oct 6 18:02:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Oct 2005 09:02:51 -0700 Subject: [Patches] [ python-Patches-1313939 ] Speedup PyUnicode_DecodeCharmap Message-ID: Patches item #1313939, was opened at 2005-10-05 17:01 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1313939&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Speedup PyUnicode_DecodeCharmap Initial Comment: This patch speeds up PyUnicode_DecodeCharmap() as discussed in the thread: http://mail.python.org/pipermail/python-dev/2005-October/056958.html It makes it possible to pass a unicode string to cPyUnicode_DecodeCharmap() in addition to the dictionary which is still supported. The unicode character at position i in the string is used as the decoded value for byte i. Byte values greater that the length of the string and u"\ufffd" characters in the string are treated as "maps to undefined". ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-06 18:02 Message: Logged In: YES user_id=38388 Thanks for the change. I can regenerate the codecs using gencodec.py, no problem. I can also change it to create the string mapping. For reference: the mapping files can be downloaded from ftp.unicode.org. The gencodec.py script then takes the mapping filename as argument and creates a codec .py file from it. Special care has to be taken in that some codecs contains hand-edited details. Note that it's likely that some codecs will have additions or removals - the files on the ftp.unicode.org are updated every now and then and usually contain more up-to-date mappings. For some codecs, you won't find mapping files on the Unicode site - these were then contributed by 3rd parties. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 17:50 Message: Logged In: YES user_id=89016 > Thanks, Walter. However, you won't get my approval with the > choice of FFFD as meaning "undefined mapping" - that code > point is defined. Please choose a different code that is > documented to never be defined by the Unicode standard. OK, I've updated the patch to use 0xfffe instead. Note that this only work as long as u"\fffe" is a legal Unicode literal. > Also, please explain the new alias 'unicode_1_1_utf_7' : > 'utf_7'. Oops, that was for bug #1245379. Removed > About the make_maps() function: the decoding maps should be > generated by the gencodec.py script instead of doing this a > import time. The dictionaries can then be removed from the > codecs. That's true. I'm still working on that. Do you have any tips on how to do that (what files do I have to download and where do I have to put it and how (and from where) do I have to call gencodec.py). Is this documented somewhere? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-06 17:24 Message: Logged In: YES user_id=38388 Thanks, Walter. However, you won't get my approval with the choice of FFFD as meaning "undefined mapping" - that code point is defined. Please choose a different code that is documented to never be defined by the Unicode standard. Also, please explain the new alias 'unicode_1_1_utf_7' : 'utf_7'. About the make_maps() function: the decoding maps should be generated by the gencodec.py script instead of doing this a import time. The dictionaries can then be removed from the codecs. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 16:45 Message: Logged In: YES user_id=89016 OK, I've updated the patch to include an update of the documentation and a few test and I've simplified codecs.make_maps a bit, since we'll always have a decoding string. 0xFFFD is still used as the undefined marker value. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-05 22:39 Message: Logged In: YES user_id=38388 The whole point is finding a replacement code point for the None value in dictionaries. Since None is not a character, a code point should be chosen that is guaranteed to never be assigned. FFFE is such a code point, hence the choice. FFFD is an assigned code point. Note that a mapping to FFFE will always raise an exception and the codec user can then decide to use the replace error handler to have the codec use FFFD instead. It is also very reasonable for a codec to map some characters to FFFD to avoid invoking the exception handling in those cases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-05 20:36 Message: Logged In: YES user_id=21627 For decoding, Walter's code is nearly identical to the fastmap decoder: both use a Py_UNICODE array to represent the map, and both use REPLACEMENT CHARACTER to denote a missing target code. I find the use of U+FFFD highly appropriate, and not at all debatable. None of the existing codecs maps any of its characters to U+FFFD, and I would consider it a bug if one did. REPLACEMENT CHARACTER should only be used if there is no approprate character, so no charmap should claim that the appropriate mapping for some by is that character. That you often use U+FFFD in output to denote unmappable characters is a different issue, indeed, Python's "replace" mode does so. It would continue to do so under this patch. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-05 19:50 Message: Logged In: YES user_id=38388 The patch looks good, but I'd still like to see whether Hye-Shik's fastmap codec wouldn't be a better and more general solution since it seems to also provide good performance for encoding Unicode strings. That said, you should use a non-code point such as 0xFFFE for meaning "undefined mapping". The Unicode replacement character is not a good choice as this is a very valid character which often actually gets used to replace characters for which no Unicode code point is known. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1313939&group_id=5470 From noreply at sourceforge.net Thu Oct 6 20:37:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Oct 2005 11:37:23 -0700 Subject: [Patches] [ python-Patches-1313939 ] Speedup PyUnicode_DecodeCharmap Message-ID: Patches item #1313939, was opened at 2005-10-05 17:01 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1313939&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Speedup PyUnicode_DecodeCharmap Initial Comment: This patch speeds up PyUnicode_DecodeCharmap() as discussed in the thread: http://mail.python.org/pipermail/python-dev/2005-October/056958.html It makes it possible to pass a unicode string to cPyUnicode_DecodeCharmap() in addition to the dictionary which is still supported. The unicode character at position i in the string is used as the decoded value for byte i. Byte values greater that the length of the string and u"\ufffd" characters in the string are treated as "maps to undefined". ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-06 20:37 Message: Logged In: YES user_id=38388 Yes, please. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 18:59 Message: Logged In: YES user_id=89016 > I can regenerate the codecs using gencodec.py, no problem. I > can also change it to create the string mapping. That would be great. So should I check in everything else (i.e. unicodeobject.c and the doc and test changes)? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-06 18:02 Message: Logged In: YES user_id=38388 Thanks for the change. I can regenerate the codecs using gencodec.py, no problem. I can also change it to create the string mapping. For reference: the mapping files can be downloaded from ftp.unicode.org. The gencodec.py script then takes the mapping filename as argument and creates a codec .py file from it. Special care has to be taken in that some codecs contains hand-edited details. Note that it's likely that some codecs will have additions or removals - the files on the ftp.unicode.org are updated every now and then and usually contain more up-to-date mappings. For some codecs, you won't find mapping files on the Unicode site - these were then contributed by 3rd parties. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 17:50 Message: Logged In: YES user_id=89016 > Thanks, Walter. However, you won't get my approval with the > choice of FFFD as meaning "undefined mapping" - that code > point is defined. Please choose a different code that is > documented to never be defined by the Unicode standard. OK, I've updated the patch to use 0xfffe instead. Note that this only work as long as u"\fffe" is a legal Unicode literal. > Also, please explain the new alias 'unicode_1_1_utf_7' : > 'utf_7'. Oops, that was for bug #1245379. Removed > About the make_maps() function: the decoding maps should be > generated by the gencodec.py script instead of doing this a > import time. The dictionaries can then be removed from the > codecs. That's true. I'm still working on that. Do you have any tips on how to do that (what files do I have to download and where do I have to put it and how (and from where) do I have to call gencodec.py). Is this documented somewhere? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-06 17:24 Message: Logged In: YES user_id=38388 Thanks, Walter. However, you won't get my approval with the choice of FFFD as meaning "undefined mapping" - that code point is defined. Please choose a different code that is documented to never be defined by the Unicode standard. Also, please explain the new alias 'unicode_1_1_utf_7' : 'utf_7'. About the make_maps() function: the decoding maps should be generated by the gencodec.py script instead of doing this a import time. The dictionaries can then be removed from the codecs. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 16:45 Message: Logged In: YES user_id=89016 OK, I've updated the patch to include an update of the documentation and a few test and I've simplified codecs.make_maps a bit, since we'll always have a decoding string. 0xFFFD is still used as the undefined marker value. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-05 22:39 Message: Logged In: YES user_id=38388 The whole point is finding a replacement code point for the None value in dictionaries. Since None is not a character, a code point should be chosen that is guaranteed to never be assigned. FFFE is such a code point, hence the choice. FFFD is an assigned code point. Note that a mapping to FFFE will always raise an exception and the codec user can then decide to use the replace error handler to have the codec use FFFD instead. It is also very reasonable for a codec to map some characters to FFFD to avoid invoking the exception handling in those cases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-05 20:36 Message: Logged In: YES user_id=21627 For decoding, Walter's code is nearly identical to the fastmap decoder: both use a Py_UNICODE array to represent the map, and both use REPLACEMENT CHARACTER to denote a missing target code. I find the use of U+FFFD highly appropriate, and not at all debatable. None of the existing codecs maps any of its characters to U+FFFD, and I would consider it a bug if one did. REPLACEMENT CHARACTER should only be used if there is no approprate character, so no charmap should claim that the appropriate mapping for some by is that character. That you often use U+FFFD in output to denote unmappable characters is a different issue, indeed, Python's "replace" mode does so. It would continue to do so under this patch. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-05 19:50 Message: Logged In: YES user_id=38388 The patch looks good, but I'd still like to see whether Hye-Shik's fastmap codec wouldn't be a better and more general solution since it seems to also provide good performance for encoding Unicode strings. That said, you should use a non-code point such as 0xFFFE for meaning "undefined mapping". The Unicode replacement character is not a good choice as this is a very valid character which often actually gets used to replace characters for which no Unicode code point is known. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1313939&group_id=5470 From noreply at sourceforge.net Thu Oct 6 22:32:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Oct 2005 13:32:52 -0700 Subject: [Patches] [ python-Patches-1313939 ] Speedup PyUnicode_DecodeCharmap Message-ID: Patches item #1313939, was opened at 2005-10-05 17:01 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1313939&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Speedup PyUnicode_DecodeCharmap Initial Comment: This patch speeds up PyUnicode_DecodeCharmap() as discussed in the thread: http://mail.python.org/pipermail/python-dev/2005-October/056958.html It makes it possible to pass a unicode string to cPyUnicode_DecodeCharmap() in addition to the dictionary which is still supported. The unicode character at position i in the string is used as the decoded value for byte i. Byte values greater that the length of the string and u"\ufffd" characters in the string are treated as "maps to undefined". ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 22:32 Message: Logged In: YES user_id=89016 Checked in as: Objects/unicodeobject.c 2.232 Lib/test/test_codecs.py 1.27 Doc/api/concrete.tex 1.68 Misc/NEWS 1.1387 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-06 20:37 Message: Logged In: YES user_id=38388 Yes, please. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 18:59 Message: Logged In: YES user_id=89016 > I can regenerate the codecs using gencodec.py, no problem. I > can also change it to create the string mapping. That would be great. So should I check in everything else (i.e. unicodeobject.c and the doc and test changes)? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-06 18:02 Message: Logged In: YES user_id=38388 Thanks for the change. I can regenerate the codecs using gencodec.py, no problem. I can also change it to create the string mapping. For reference: the mapping files can be downloaded from ftp.unicode.org. The gencodec.py script then takes the mapping filename as argument and creates a codec .py file from it. Special care has to be taken in that some codecs contains hand-edited details. Note that it's likely that some codecs will have additions or removals - the files on the ftp.unicode.org are updated every now and then and usually contain more up-to-date mappings. For some codecs, you won't find mapping files on the Unicode site - these were then contributed by 3rd parties. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 17:50 Message: Logged In: YES user_id=89016 > Thanks, Walter. However, you won't get my approval with the > choice of FFFD as meaning "undefined mapping" - that code > point is defined. Please choose a different code that is > documented to never be defined by the Unicode standard. OK, I've updated the patch to use 0xfffe instead. Note that this only work as long as u"\fffe" is a legal Unicode literal. > Also, please explain the new alias 'unicode_1_1_utf_7' : > 'utf_7'. Oops, that was for bug #1245379. Removed > About the make_maps() function: the decoding maps should be > generated by the gencodec.py script instead of doing this a > import time. The dictionaries can then be removed from the > codecs. That's true. I'm still working on that. Do you have any tips on how to do that (what files do I have to download and where do I have to put it and how (and from where) do I have to call gencodec.py). Is this documented somewhere? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-06 17:24 Message: Logged In: YES user_id=38388 Thanks, Walter. However, you won't get my approval with the choice of FFFD as meaning "undefined mapping" - that code point is defined. Please choose a different code that is documented to never be defined by the Unicode standard. Also, please explain the new alias 'unicode_1_1_utf_7' : 'utf_7'. About the make_maps() function: the decoding maps should be generated by the gencodec.py script instead of doing this a import time. The dictionaries can then be removed from the codecs. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 16:45 Message: Logged In: YES user_id=89016 OK, I've updated the patch to include an update of the documentation and a few test and I've simplified codecs.make_maps a bit, since we'll always have a decoding string. 0xFFFD is still used as the undefined marker value. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-05 22:39 Message: Logged In: YES user_id=38388 The whole point is finding a replacement code point for the None value in dictionaries. Since None is not a character, a code point should be chosen that is guaranteed to never be assigned. FFFE is such a code point, hence the choice. FFFD is an assigned code point. Note that a mapping to FFFE will always raise an exception and the codec user can then decide to use the replace error handler to have the codec use FFFD instead. It is also very reasonable for a codec to map some characters to FFFD to avoid invoking the exception handling in those cases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-05 20:36 Message: Logged In: YES user_id=21627 For decoding, Walter's code is nearly identical to the fastmap decoder: both use a Py_UNICODE array to represent the map, and both use REPLACEMENT CHARACTER to denote a missing target code. I find the use of U+FFFD highly appropriate, and not at all debatable. None of the existing codecs maps any of its characters to U+FFFD, and I would consider it a bug if one did. REPLACEMENT CHARACTER should only be used if there is no approprate character, so no charmap should claim that the appropriate mapping for some by is that character. That you often use U+FFFD in output to denote unmappable characters is a different issue, indeed, Python's "replace" mode does so. It would continue to do so under this patch. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-05 19:50 Message: Logged In: YES user_id=38388 The patch looks good, but I'd still like to see whether Hye-Shik's fastmap codec wouldn't be a better and more general solution since it seems to also provide good performance for encoding Unicode strings. That said, you should use a non-code point such as 0xFFFE for meaning "undefined mapping". The Unicode replacement character is not a good choice as this is a very valid character which often actually gets used to replace characters for which no Unicode code point is known. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1313939&group_id=5470 From noreply at sourceforge.net Fri Oct 7 04:20:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 6 Oct 2005 19:20:13 -0700 Subject: [Patches] [ python-Patches-1203393 ] Patch for [ 1163563 ] Sub threads execute in restricted mode Message-ID: <200510070220.j972KDWo032733@projects.sourceforge.net> Patches item #1203393, was opened at 05/17/05 01:39 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1203393&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: anothermax (yetanothermax) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for [ 1163563 ] Sub threads execute in restricted mode Initial Comment: The thread module delivered with versions of python greater than 2.3.4 is not compatible with the use of sub interpreters, this causes problems with the jep product and seems also to be a problem for mod_python. This has been raised as a bug "[ 1163563 ] Sub threads execute in restricted mode" (http://sourceforge.net/tracker/index.php? func=detail&aid=1163563&group_id=5470&atid=105470) please see this bug report for further details. The problem seems to be the with use of PyGIL_StateXXX functions in the module. This patch replaces these calls with those used in pre- 2.3.5 threadmodule.c. A file called threadtest.c is attached to the bug report which demonstrates the problem. I'm using Python version 2.4.1 on Windows XP SP1 ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 10/06/05 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1203393&group_id=5470 From noreply at sourceforge.net Sat Oct 8 02:10:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 07 Oct 2005 17:10:59 -0700 Subject: [Patches] [ python-Patches-1316653 ] Py_INCREF/Py_DECREF with magic constant demo Message-ID: Patches item #1316653, was opened at 2005-10-07 18: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=1316653&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Adam Olsen (rhamphoryncus) Assigned to: Nobody/Anonymous (nobody) Summary: Py_INCREF/Py_DECREF with magic constant demo Initial Comment: This is a simple "proof of concept" patch that shows making Py_INCREF/Py_DECREF be no-ops when ob_refcnt is set to a magic constant (to indicate only cyclic gc should be used here) is not a signifigant performance burden. Normal Py_INCREF/Py_DECREF rhamph at factor:~/src/Python-2.4.1$ ./python Lib/test/pystone.py 500000 Pystone(1.1) time for 500000 passes = 13.34 This machine benchmarks at 37481.3 pystones/second Modified Py_INCREF/Py_DECREF with magic constant rhamph at factor:~/src/Python-2.4.1-sandbox$ ./python Lib/test/pystone.py 500000 Pystone(1.1) time for 500000 passes = 13.38 This machine benchmarks at 37369.2 pystones/second Posting to python-dev will be done momentarily. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1316653&group_id=5470 From noreply at sourceforge.net Sun Oct 9 20:30:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Oct 2005 11:30:21 -0700 Subject: [Patches] [ python-Patches-906702 ] Syntax-related improvements to IDLE Message-ID: Patches item #906702, was opened at 2004-02-28 20:40 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=906702&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Kurt B. Kaiser (kbk) Summary: Syntax-related improvements to IDLE Initial Comment: Yes! It's finally here! The big bunch of syntax-related improvements to IDLE! Here are a few highlights: * Completion in Visual C++ style! * CallTip windows now disappear when you don't want them! * ParenMatch now works! And in a more general way: * The MultiCall class enables one event to trigger multiple actions, so that you extensions can do whatever they want without fighting who'll know when a key is being released (for example). * The HyperParser class gives extensions a better understanding of Python code, so that CallTips and ParenMatch can now be shown from anywhere in the code (not only after opening/closing parens), and CallTips and AutoCompletion is available for complex expressions, not just for expressions which look like identifier1.identifer2. IDLE with these changes was tested by about 15 people for a few months, and beside some minor inconviniences (for example, concerning when AutoComplete chooses to complete), no critical bugs were found. Here's a complete description of all the changes to files: * Used MultiCall In order to allow multiple actions to happen when one event happens (for example, when closing a bracket, show the opening bracket and close the calltip), I wrote a class called MultiCall, which, in this case, inherits from the Text widget, and overrides binding functions, so that all matching functions will be called when an event takes place. New file: MultiCall.py EditorWindow.py: diff 1, line 8: importing MultiCall diff 2, line 89: Use MultiCallCreator(Text) instead of Text diff 3, line 226: bind set_line_and_column using virtual events, so that it will be handled by MultiCall diff 4, line 333: Control+C, in Windows keys, means both copy and break. The three lines added solve the conflict. diff 5,6,7, line 524: When changing key configuration, first the current keys must be unbinded, then the new ones binded. configDialog.py: diffs 1,2,3: When changing key configuration, first the current keys must be unbinded, then the new ones binded. * Improved parsing abilities - HyperParser The new HyperParser class uses PyParse to find information about the bracketing structure of a Python code, and to find the expression which should be evaluated in CallTips and AutoComplete. New file: HyperParser.py EditorWindow.py: diff 8, 9, line 1072: Previously, the prompt was detected textually, by searching for ">>>". This is not generic, and I changed it to look for a text tagged by the "console" tag. PyParse.py: diff 1, line 16: 'if' and 'for' can't be considered block openers now, since list comprehension was introduced. diff 2-5, line 147: using the "prompt" tag instead of searching for ">>>". diff 6-15, line 357: Now, _study2 also saves information about the bracketing structure of the code. PyShell.py: diff 1, line 1049: use the "prompt" tag instead of searching for ">>>" * Added the AutoComplete extension: This extension opens a completion window after typing a dot or when requesting a completion using tab or control+space. It will evaluate code with function calls only when requested by control+space. New file: AutoComplete.py New file: AutoCompleteWindow.py config-extensions.def: diff 5: three new bindings - force-open-completions opens a completion win and is ready to evaluate functions. autocomplete tries to complete the current word, and if fails, opens a completion window (happens on tab). try-open-completions will open a completion window when no functions calls need to be done. run.py: diffs 1,2,3: Added functions in run.py for fetching the available completions, in a method copied from the method CallTips used when fetching the call tip. * Improved the CallTips extension: This extension is greatly improved, by using HyperParser: CallTips now work for multi-lined function calls, they can be opened from anywhere inside a function brackets, and can evaluate expressions which result in functions. CallTips.py: diff 1, line 6: The future plans are already here. diff 2, line 11: no need to import string diff 3, line 14: import HyperParser diff 4, line 20: Now there's a menu command to open a calltip. diff 5, line 39: cosmetical diff 6-11, line 44: Now there's no paren_open_event and paren_close_event, since you can open CallTips without typing parens. There's force_open_calltip_event, which opens a calltip and is ready to make function calls, and try_open_calltip_event, which will not agree to do such a thing. We also use HyperParser, instead of finding the function by ourselves. diff 12, line 153: It makes more sense to show the repr of default arguments in calltips, not the str of them. CallTipWindow.py: Now, the CallTipWindow is smart - it binds events to hide itself and to position itself. Hiding occurs when the cursor gets out of the parens. config-extensions.def: diffs 1,2, line 42: We have three new bindings: force-open-calltip opens a calltip and make function calls, if needed. try-open-calltip opens a calltip if it doesn't need to make function calls. refresh-calltip will close a calltip if not needed, and change it to another one if needed. It is binded both to parenright and 0, because if the shift was raised before the zero/parenright key, the event generated is KeyRelease-0. * Improved the ParenMatch extension: First, it now works, thanks to MultiCall. Also, it now can be invoked without closing a paren, and the surrounding parens will be highlighted. ParenMatch.py: All the code for event handling and finding the paren area was rewritten, using HyperParser, and relying on MultiCall. config-extensions.def: diff 3, line 50: enable it again diff 4,5: changed the binding so we now have flash-paren, which shows the surrounding parens, and paren-closed, which is instead of flash-open-paren. Patch and enjoy! Noam Raphael ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-10-09 14:30 Message: Logged In: YES user_id=149084 Add Noam Raphael's patch dated 10Jul05 ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2004-04-26 17:49 Message: Logged In: YES user_id=679426 I made a small usability bug, because I didn't parenthesize a boolean expression correctly. Line 298 should be changed to: and (self.mode==AutoComplete.COMPLETE_ATTRIBUTES or self.start): Happy Israel Independence Day! Noam Raphael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=906702&group_id=5470 From noreply at sourceforge.net Sun Oct 9 21:23:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Oct 2005 12:23:09 -0700 Subject: [Patches] [ python-Patches-1313939 ] Speedup PyUnicode_DecodeCharmap Message-ID: Patches item #1313939, was opened at 2005-10-05 17:01 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1313939&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) >Assigned to: M.-A. Lemburg (lemburg) Summary: Speedup PyUnicode_DecodeCharmap Initial Comment: This patch speeds up PyUnicode_DecodeCharmap() as discussed in the thread: http://mail.python.org/pipermail/python-dev/2005-October/056958.html It makes it possible to pass a unicode string to cPyUnicode_DecodeCharmap() in addition to the dictionary which is still supported. The unicode character at position i in the string is used as the decoded value for byte i. Byte values greater that the length of the string and u"\ufffd" characters in the string are treated as "maps to undefined". ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-10-09 21:23 Message: Logged In: YES user_id=89016 Assigning to MAL for the codec update ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 22:32 Message: Logged In: YES user_id=89016 Checked in as: Objects/unicodeobject.c 2.232 Lib/test/test_codecs.py 1.27 Doc/api/concrete.tex 1.68 Misc/NEWS 1.1387 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-06 20:37 Message: Logged In: YES user_id=38388 Yes, please. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 18:59 Message: Logged In: YES user_id=89016 > I can regenerate the codecs using gencodec.py, no problem. I > can also change it to create the string mapping. That would be great. So should I check in everything else (i.e. unicodeobject.c and the doc and test changes)? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-06 18:02 Message: Logged In: YES user_id=38388 Thanks for the change. I can regenerate the codecs using gencodec.py, no problem. I can also change it to create the string mapping. For reference: the mapping files can be downloaded from ftp.unicode.org. The gencodec.py script then takes the mapping filename as argument and creates a codec .py file from it. Special care has to be taken in that some codecs contains hand-edited details. Note that it's likely that some codecs will have additions or removals - the files on the ftp.unicode.org are updated every now and then and usually contain more up-to-date mappings. For some codecs, you won't find mapping files on the Unicode site - these were then contributed by 3rd parties. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 17:50 Message: Logged In: YES user_id=89016 > Thanks, Walter. However, you won't get my approval with the > choice of FFFD as meaning "undefined mapping" - that code > point is defined. Please choose a different code that is > documented to never be defined by the Unicode standard. OK, I've updated the patch to use 0xfffe instead. Note that this only work as long as u"\fffe" is a legal Unicode literal. > Also, please explain the new alias 'unicode_1_1_utf_7' : > 'utf_7'. Oops, that was for bug #1245379. Removed > About the make_maps() function: the decoding maps should be > generated by the gencodec.py script instead of doing this a > import time. The dictionaries can then be removed from the > codecs. That's true. I'm still working on that. Do you have any tips on how to do that (what files do I have to download and where do I have to put it and how (and from where) do I have to call gencodec.py). Is this documented somewhere? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-06 17:24 Message: Logged In: YES user_id=38388 Thanks, Walter. However, you won't get my approval with the choice of FFFD as meaning "undefined mapping" - that code point is defined. Please choose a different code that is documented to never be defined by the Unicode standard. Also, please explain the new alias 'unicode_1_1_utf_7' : 'utf_7'. About the make_maps() function: the decoding maps should be generated by the gencodec.py script instead of doing this a import time. The dictionaries can then be removed from the codecs. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 16:45 Message: Logged In: YES user_id=89016 OK, I've updated the patch to include an update of the documentation and a few test and I've simplified codecs.make_maps a bit, since we'll always have a decoding string. 0xFFFD is still used as the undefined marker value. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-05 22:39 Message: Logged In: YES user_id=38388 The whole point is finding a replacement code point for the None value in dictionaries. Since None is not a character, a code point should be chosen that is guaranteed to never be assigned. FFFE is such a code point, hence the choice. FFFD is an assigned code point. Note that a mapping to FFFE will always raise an exception and the codec user can then decide to use the replace error handler to have the codec use FFFD instead. It is also very reasonable for a codec to map some characters to FFFD to avoid invoking the exception handling in those cases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-05 20:36 Message: Logged In: YES user_id=21627 For decoding, Walter's code is nearly identical to the fastmap decoder: both use a Py_UNICODE array to represent the map, and both use REPLACEMENT CHARACTER to denote a missing target code. I find the use of U+FFFD highly appropriate, and not at all debatable. None of the existing codecs maps any of its characters to U+FFFD, and I would consider it a bug if one did. REPLACEMENT CHARACTER should only be used if there is no approprate character, so no charmap should claim that the appropriate mapping for some by is that character. That you often use U+FFFD in output to denote unmappable characters is a different issue, indeed, Python's "replace" mode does so. It would continue to do so under this patch. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-05 19:50 Message: Logged In: YES user_id=38388 The patch looks good, but I'd still like to see whether Hye-Shik's fastmap codec wouldn't be a better and more general solution since it seems to also provide good performance for encoding Unicode strings. That said, you should use a non-code point such as 0xFFFE for meaning "undefined mapping". The Unicode replacement character is not a good choice as this is a very valid character which often actually gets used to replace characters for which no Unicode code point is known. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1313939&group_id=5470 From noreply at sourceforge.net Sun Oct 9 21:43:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Oct 2005 12:43:35 -0700 Subject: [Patches] [ python-Patches-1245379 ] Encoding alias "unicode-1-1-utf-7" Message-ID: Patches item #1245379, was opened at 2005-07-26 18:37 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1245379&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Oren Tirosh (orenti) Assigned to: Nobody/Anonymous (nobody) Summary: Encoding alias "unicode-1-1-utf-7" Initial Comment: The utf7 encoding seems to be used quite a lot in Europe for emails (probably because it's more compact and readable than utf8+base64 or utf8+quopri). Some systems use the encoding name "unicode-1-1-utf-7" for 'utf7': http://www.google.com/search?q=unicode-1-1-utf-7 This patch adds this name as an alias for utf7. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-10-09 21:43 Message: Logged In: YES user_id=89016 Checked in as: Lib/encodings/aliases.py 1.29 Doc/lib/libcodecs.tex 1.37 Misc/NEWS 1.1390 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-09-01 19:33 Message: Logged In: YES user_id=89016 Here's another version of the patch. BTW, "UNICODE-1-1-UTF-7" is explicitely mentioned in RFC 1642 (http://www.faqs.org/rfcs/rfc1642.html) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-09 17:03 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. 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=1245379&group_id=5470 From noreply at sourceforge.net Mon Oct 10 00:57:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Oct 2005 15:57:58 -0700 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 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. 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-10-10 00:57 Message: Logged In: YES user_id=679426 It's an optimization: If we scroll up, we know that there can't be a new context line with a smaller indentation than that of the deleted context lines, so it lets us stop searching sooner. For example, take this class: class Babonag(object): # This is a big class, and a lot of methods are defined here... def ping(): print "ping" def pong(): pring "pong" Now say we scroll up: the first line was 'print "pong"', and it is now 'print "ping"'. If we use stopindent, we know that we can stop immediately after we have reached "def ping", because we know that there can't be a line with a smaller indentation than that. If we don't, we have to scan up to "class Babonag" to be certain that there aren't any extra context lines. (By the way, well done for the tweaked comments docstrings and names. They seem a lot cleaner.) Noam ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-10-03 22:13 Message: Logged In: YES user_id=149084 Checked in 03Feb05 patch as rev 1.5 Tweaked comments, docstrings, and names; checked in as rev 1.6 Incorporated Tal Einat's alignment suggestion; checked in as rev 1.7 It appears to me that the stopindent mechanism to terminate processing a region is now redundant. I can comment out the 'break' in get_context() [new name!] and everything still seems to work ok. Am I missing something? ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2005-08-18 18:28 Message: Logged In: YES user_id=1330769 This fixes the text alignment: (just replace te appropriate code in toggle_code_context_event with this) if not self.label: self.padding_frame = Tkinter.Frame(self.editwin.top, bg=self.bgcolor, border=2, relief="sunken", ) self.label = Tkinter.Label(self.padding_frame, text="\n" * (self.numlines - 1), anchor="w", justify="left", font=self.textfont, bg=self.bgcolor, fg=self.fgcolor, border=0, width=1, # Don't request more than we get ) self.label.pack(side="top", fill="x", expand=1, padx=4, pady=0) self.padding_frame.pack(side="top", fill="x", expand=0, padx=0, pady=0, after=self.editwin.status_bar) else: self.label.destroy() self.padding_frame.destroy() self.label = None Sorry it's not a diff... ---------------------------------------------------------------------- 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 Mon Oct 10 06:02:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Oct 2005 21:02:12 -0700 Subject: [Patches] [ python-Patches-906702 ] Syntax-related improvements to IDLE Message-ID: Patches item #906702, was opened at 2004-02-28 20:40 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=906702&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Kurt B. Kaiser (kbk) Summary: Syntax-related improvements to IDLE Initial Comment: Yes! It's finally here! The big bunch of syntax-related improvements to IDLE! Here are a few highlights: * Completion in Visual C++ style! * CallTip windows now disappear when you don't want them! * ParenMatch now works! And in a more general way: * The MultiCall class enables one event to trigger multiple actions, so that you extensions can do whatever they want without fighting who'll know when a key is being released (for example). * The HyperParser class gives extensions a better understanding of Python code, so that CallTips and ParenMatch can now be shown from anywhere in the code (not only after opening/closing parens), and CallTips and AutoCompletion is available for complex expressions, not just for expressions which look like identifier1.identifer2. IDLE with these changes was tested by about 15 people for a few months, and beside some minor inconviniences (for example, concerning when AutoComplete chooses to complete), no critical bugs were found. Here's a complete description of all the changes to files: * Used MultiCall In order to allow multiple actions to happen when one event happens (for example, when closing a bracket, show the opening bracket and close the calltip), I wrote a class called MultiCall, which, in this case, inherits from the Text widget, and overrides binding functions, so that all matching functions will be called when an event takes place. New file: MultiCall.py EditorWindow.py: diff 1, line 8: importing MultiCall diff 2, line 89: Use MultiCallCreator(Text) instead of Text diff 3, line 226: bind set_line_and_column using virtual events, so that it will be handled by MultiCall diff 4, line 333: Control+C, in Windows keys, means both copy and break. The three lines added solve the conflict. diff 5,6,7, line 524: When changing key configuration, first the current keys must be unbinded, then the new ones binded. configDialog.py: diffs 1,2,3: When changing key configuration, first the current keys must be unbinded, then the new ones binded. * Improved parsing abilities - HyperParser The new HyperParser class uses PyParse to find information about the bracketing structure of a Python code, and to find the expression which should be evaluated in CallTips and AutoComplete. New file: HyperParser.py EditorWindow.py: diff 8, 9, line 1072: Previously, the prompt was detected textually, by searching for ">>>". This is not generic, and I changed it to look for a text tagged by the "console" tag. PyParse.py: diff 1, line 16: 'if' and 'for' can't be considered block openers now, since list comprehension was introduced. diff 2-5, line 147: using the "prompt" tag instead of searching for ">>>". diff 6-15, line 357: Now, _study2 also saves information about the bracketing structure of the code. PyShell.py: diff 1, line 1049: use the "prompt" tag instead of searching for ">>>" * Added the AutoComplete extension: This extension opens a completion window after typing a dot or when requesting a completion using tab or control+space. It will evaluate code with function calls only when requested by control+space. New file: AutoComplete.py New file: AutoCompleteWindow.py config-extensions.def: diff 5: three new bindings - force-open-completions opens a completion win and is ready to evaluate functions. autocomplete tries to complete the current word, and if fails, opens a completion window (happens on tab). try-open-completions will open a completion window when no functions calls need to be done. run.py: diffs 1,2,3: Added functions in run.py for fetching the available completions, in a method copied from the method CallTips used when fetching the call tip. * Improved the CallTips extension: This extension is greatly improved, by using HyperParser: CallTips now work for multi-lined function calls, they can be opened from anywhere inside a function brackets, and can evaluate expressions which result in functions. CallTips.py: diff 1, line 6: The future plans are already here. diff 2, line 11: no need to import string diff 3, line 14: import HyperParser diff 4, line 20: Now there's a menu command to open a calltip. diff 5, line 39: cosmetical diff 6-11, line 44: Now there's no paren_open_event and paren_close_event, since you can open CallTips without typing parens. There's force_open_calltip_event, which opens a calltip and is ready to make function calls, and try_open_calltip_event, which will not agree to do such a thing. We also use HyperParser, instead of finding the function by ourselves. diff 12, line 153: It makes more sense to show the repr of default arguments in calltips, not the str of them. CallTipWindow.py: Now, the CallTipWindow is smart - it binds events to hide itself and to position itself. Hiding occurs when the cursor gets out of the parens. config-extensions.def: diffs 1,2, line 42: We have three new bindings: force-open-calltip opens a calltip and make function calls, if needed. try-open-calltip opens a calltip if it doesn't need to make function calls. refresh-calltip will close a calltip if not needed, and change it to another one if needed. It is binded both to parenright and 0, because if the shift was raised before the zero/parenright key, the event generated is KeyRelease-0. * Improved the ParenMatch extension: First, it now works, thanks to MultiCall. Also, it now can be invoked without closing a paren, and the surrounding parens will be highlighted. ParenMatch.py: All the code for event handling and finding the paren area was rewritten, using HyperParser, and relying on MultiCall. config-extensions.def: diff 3, line 50: enable it again diff 4,5: changed the binding so we now have flash-paren, which shows the surrounding parens, and paren-closed, which is instead of flash-open-paren. Patch and enjoy! Noam Raphael ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-10-10 00:02 Message: Logged In: YES user_id=149084 Checked in idlesyntax.10Jul05.diff on a branch: IDLE-syntax-branch. To switch to this branch: cvs up -r IDLE-syntax-branch To switch back to the IDLE trunk: cvs up -A Further changes to this line of development should be submitted as diffs against the branch. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-10-09 14:30 Message: Logged In: YES user_id=149084 Add Noam Raphael's patch dated 10Jul05 ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2004-04-26 17:49 Message: Logged In: YES user_id=679426 I made a small usability bug, because I didn't parenthesize a boolean expression correctly. Line 298 should be changed to: and (self.mode==AutoComplete.COMPLETE_ATTRIBUTES or self.start): Happy Israel Independence Day! Noam Raphael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=906702&group_id=5470 From kzl665544 at eyou.com Mon Oct 10 09:24:54 2005 From: kzl665544 at eyou.com (Paul) Date: Mon, 10 Oct 2005 15:24:54 +0800 Subject: [Patches] Marketing for you Message-ID: <20051010072452.CFEFB1E4004@bag.python.org> Dear patches at python.org: We specializing in E-mail Marketing. 1. Targeted list We may provide targeted email list. We will customize the list according to your requirements. 2. Sending out Targeted Marketing for you We may send your email message to your target clients! We will customize your email list and send your message for you. * We offer BP web Hosting & mail server. Regards! Paul Marketing Team kezunli321 at yeah.net To Bye: PaulNo at hotmail.com From noreply at sourceforge.net Tue Oct 11 19:25:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Oct 2005 10:25:11 -0700 Subject: [Patches] [ python-Patches-684944 ] extend readline functionality in pdb Message-ID: Patches item #684944, was opened at 2003-02-11 14:09 Message generated for change (Comment added) made by meonkeys You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684944&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Johannes Gijsbers (jlgijsbers) Summary: extend readline functionality in pdb Initial Comment: This patch allows readline completion of global and local variables while running code under pdb. Currently completion only works with the builtin pdb commands when in pdb. This patch uses the default pdb completer (in cmd.Cmd) to preserve the old completions, but adds completions in the current pdb execution frame. Patch is against current cvs. Let me know what you think. ---------------------------------------------------------------------- Comment By: Adam Monsen (meonkeys) Date: 2005-10-11 10:25 Message: Logged In: YES user_id=259388 jlgijsbers, do you mean that if a user typed (Pdb) help d only help topics that started with 'd' would autocomplete? And similarly for other pdb commands? ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 07:11 Message: Logged In: YES user_id=469548 I like the idea, but the implementation is currently too inclusive. It does completion the same for all commands, even for those where that doesn't make sense, such as enable, disable and quit. I'd accept a patch that used 'complete_*' functions for the individual commands where the completion makes sense. Let me know if you're still interested on working on this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=684944&group_id=5470 From noreply at sourceforge.net Wed Oct 12 01:58:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Oct 2005 16:58:42 -0700 Subject: [Patches] [ python-Patches-1309352 ] Make fcntl work properly on AMD64 Message-ID: Patches item #1309352, was opened at 2005-09-30 12:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1309352&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Brad Hards (bradh) Assigned to: Neal Norwitz (nnorwitz) Summary: Make fcntl work properly on AMD64 Initial Comment: The fcntl call doesn't work correctly on AMD-64, because of an unsigned int conversion problem. I found the problem using the dnotify.py code from buildbot.sf.net (attached). It (roughly) does: self.flags = reduce(lambda x, y: x | y, flags) | fcntl.DN_MULTISHOT self.fd = os.open(dirname, os.O_RDONLY) fcntl.fcntl(self.fd, fcntl.F_NOTIFY, self.flags) fcntl.DN_MULTISHOT is 0x80000000, which causes OverflowError: signed integer is greater than maximum There is a similar fix already committed for ioctl - see http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/fcntlmodule.c?r1=2.43&r2=2.44 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-10-12 01:58 Message: Logged In: YES user_id=21627 POSIX/Single Unix has this signature of fcntl: #include int fcntl(int fildes, int cmd, ...); The additional parameters depend on the cmd argument: - F_DUPFD, F_SETFD, F_SETFL, F_SETOWN: int - F_GETFD, F_GETFL, F_GETOWN, F_SETLKW: no argument - F_GETLK, F_SETLK: struct flock* Other values: implementation defined. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-01 05:33 Message: Logged In: YES user_id=33168 Thanks for your patch. I agree there's a problem, though I disagree with the fix. man fcntl says that the third argument is a long on my box (gentoo). Is that the same for you (3rd arg is long)? I don't think the first i (int arg) should be changed. ISTM only the second part of your patch (modifying the arg variable) is on the right track. I've attached my version of the patch, can you test that this works for you? It seems to work for dnotify, though I'm not sure what it should do. Finally, could you create a real unittest in Lib/test/test_fcntl.py? Let me know if you agree or disagree with my assessment. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1309352&group_id=5470 From noreply at sourceforge.net Wed Oct 12 06:45:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Oct 2005 21:45:17 -0700 Subject: [Patches] [ python-Patches-1309352 ] Make fcntl work properly on AMD64 Message-ID: Patches item #1309352, was opened at 2005-09-30 03:18 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1309352&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Brad Hards (bradh) Assigned to: Neal Norwitz (nnorwitz) Summary: Make fcntl work properly on AMD64 Initial Comment: The fcntl call doesn't work correctly on AMD-64, because of an unsigned int conversion problem. I found the problem using the dnotify.py code from buildbot.sf.net (attached). It (roughly) does: self.flags = reduce(lambda x, y: x | y, flags) | fcntl.DN_MULTISHOT self.fd = os.open(dirname, os.O_RDONLY) fcntl.fcntl(self.fd, fcntl.F_NOTIFY, self.flags) fcntl.DN_MULTISHOT is 0x80000000, which causes OverflowError: signed integer is greater than maximum There is a similar fix already committed for ioctl - see http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/fcntlmodule.c?r1=2.43&r2=2.44 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-11 21:45 Message: Logged In: YES user_id=33168 Hmmm, how should we handle "Other values: implementation defined"? That really concerns me. It seems that we can never do the right thing, because we can't really know what is right. I can use I (unsigned int) format for the third parameter which is a single char change from "i". This fixes the problem, but I'm not sure if it's best in the long run. Suggestions? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-11 16:58 Message: Logged In: YES user_id=21627 POSIX/Single Unix has this signature of fcntl: #include int fcntl(int fildes, int cmd, ...); The additional parameters depend on the cmd argument: - F_DUPFD, F_SETFD, F_SETFL, F_SETOWN: int - F_GETFD, F_GETFL, F_GETOWN, F_SETLKW: no argument - F_GETLK, F_SETLK: struct flock* Other values: implementation defined. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-30 20:33 Message: Logged In: YES user_id=33168 Thanks for your patch. I agree there's a problem, though I disagree with the fix. man fcntl says that the third argument is a long on my box (gentoo). Is that the same for you (3rd arg is long)? I don't think the first i (int arg) should be changed. ISTM only the second part of your patch (modifying the arg variable) is on the right track. I've attached my version of the patch, can you test that this works for you? It seems to work for dnotify, though I'm not sure what it should do. Finally, could you create a real unittest in Lib/test/test_fcntl.py? Let me know if you agree or disagree with my assessment. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1309352&group_id=5470 From noreply at sourceforge.net Wed Oct 12 06:48:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Oct 2005 21:48:43 -0700 Subject: [Patches] [ python-Patches-1316653 ] Py_INCREF/Py_DECREF with magic constant demo Message-ID: Patches item #1316653, was opened at 2005-10-07 17:10 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1316653&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Adam Olsen (rhamphoryncus) Assigned to: Nobody/Anonymous (nobody) Summary: Py_INCREF/Py_DECREF with magic constant demo Initial Comment: This is a simple "proof of concept" patch that shows making Py_INCREF/Py_DECREF be no-ops when ob_refcnt is set to a magic constant (to indicate only cyclic gc should be used here) is not a signifigant performance burden. Normal Py_INCREF/Py_DECREF rhamph at factor:~/src/Python-2.4.1$ ./python Lib/test/pystone.py 500000 Pystone(1.1) time for 500000 passes = 13.34 This machine benchmarks at 37481.3 pystones/second Modified Py_INCREF/Py_DECREF with magic constant rhamph at factor:~/src/Python-2.4.1-sandbox$ ./python Lib/test/pystone.py 500000 Pystone(1.1) time for 500000 passes = 13.38 This machine benchmarks at 37369.2 pystones/second Posting to python-dev will be done momentarily. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-11 21:48 Message: Logged In: YES user_id=33168 Adam IIRC you dropped this idea/went back to the drawing board? Is this patch still valid or should it be closed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1316653&group_id=5470 From noreply at sourceforge.net Wed Oct 12 07:21:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Oct 2005 22:21:05 -0700 Subject: [Patches] [ python-Patches-1316653 ] Py_INCREF/Py_DECREF with magic constant demo Message-ID: Patches item #1316653, was opened at 2005-10-07 18:10 Message generated for change (Comment added) made by rhamphoryncus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1316653&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Adam Olsen (rhamphoryncus) Assigned to: Nobody/Anonymous (nobody) Summary: Py_INCREF/Py_DECREF with magic constant demo Initial Comment: This is a simple "proof of concept" patch that shows making Py_INCREF/Py_DECREF be no-ops when ob_refcnt is set to a magic constant (to indicate only cyclic gc should be used here) is not a signifigant performance burden. Normal Py_INCREF/Py_DECREF rhamph at factor:~/src/Python-2.4.1$ ./python Lib/test/pystone.py 500000 Pystone(1.1) time for 500000 passes = 13.34 This machine benchmarks at 37481.3 pystones/second Modified Py_INCREF/Py_DECREF with magic constant rhamph at factor:~/src/Python-2.4.1-sandbox$ ./python Lib/test/pystone.py 500000 Pystone(1.1) time for 500000 passes = 13.38 This machine benchmarks at 37369.2 pystones/second Posting to python-dev will be done momentarily. ---------------------------------------------------------------------- >Comment By: Adam Olsen (rhamphoryncus) Date: 2005-10-11 23:21 Message: Logged In: YES user_id=12364 This was never intended as a usable patch, but rather as a demonstration. Since there doesn't seem to be any flag for that I suppose closing is the next best thing. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-11 22:48 Message: Logged In: YES user_id=33168 Adam IIRC you dropped this idea/went back to the drawing board? Is this patch still valid or should it be closed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1316653&group_id=5470 From noreply at sourceforge.net Wed Oct 12 10:29:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Oct 2005 01:29:02 -0700 Subject: [Patches] [ python-Patches-1309352 ] Make fcntl work properly on AMD64 Message-ID: Patches item #1309352, was opened at 2005-09-30 12:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1309352&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Brad Hards (bradh) Assigned to: Neal Norwitz (nnorwitz) Summary: Make fcntl work properly on AMD64 Initial Comment: The fcntl call doesn't work correctly on AMD-64, because of an unsigned int conversion problem. I found the problem using the dnotify.py code from buildbot.sf.net (attached). It (roughly) does: self.flags = reduce(lambda x, y: x | y, flags) | fcntl.DN_MULTISHOT self.fd = os.open(dirname, os.O_RDONLY) fcntl.fcntl(self.fd, fcntl.F_NOTIFY, self.flags) fcntl.DN_MULTISHOT is 0x80000000, which causes OverflowError: signed integer is greater than maximum There is a similar fix already committed for ioctl - see http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/fcntlmodule.c?r1=2.43&r2=2.44 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-10-12 10:29 Message: Logged In: YES user_id=21627 I think it will always be possible to produce crashes. If some operating system treats a parameter as a pointer, it doesn't matter whether we process ints or longs;it might always cause overwriting some random memory (if the system uses the pointer for output). The only solution would be to restrict the commands to the ones we understand, giving an exception for the rest. In the spirit of "consenting adults", this would be unpythonic. So if we want to give the user more control, we might do type-based reasoning: if the user passes an int, pass an C int (raising an exception if it is out of range). If the user passes a long, pass a C long if it fits, else a C long long, else raise an exception. I'm concerned about the POSIX vs. Linux story, though: POSIX claims that these are ints in many cases, yet Linux apparently uses long throughout. Doesn't this give an inconsistency in calling conventions on 64-bit platforms (with 64-bit longs), which would make Linux not POSIX-compliant? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-12 06:45 Message: Logged In: YES user_id=33168 Hmmm, how should we handle "Other values: implementation defined"? That really concerns me. It seems that we can never do the right thing, because we can't really know what is right. I can use I (unsigned int) format for the third parameter which is a single char change from "i". This fixes the problem, but I'm not sure if it's best in the long run. Suggestions? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-12 01:58 Message: Logged In: YES user_id=21627 POSIX/Single Unix has this signature of fcntl: #include int fcntl(int fildes, int cmd, ...); The additional parameters depend on the cmd argument: - F_DUPFD, F_SETFD, F_SETFL, F_SETOWN: int - F_GETFD, F_GETFL, F_GETOWN, F_SETLKW: no argument - F_GETLK, F_SETLK: struct flock* Other values: implementation defined. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-01 05:33 Message: Logged In: YES user_id=33168 Thanks for your patch. I agree there's a problem, though I disagree with the fix. man fcntl says that the third argument is a long on my box (gentoo). Is that the same for you (3rd arg is long)? I don't think the first i (int arg) should be changed. ISTM only the second part of your patch (modifying the arg variable) is on the right track. I've attached my version of the patch, can you test that this works for you? It seems to work for dnotify, though I'm not sure what it should do. Finally, could you create a real unittest in Lib/test/test_fcntl.py? Let me know if you agree or disagree with my assessment. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1309352&group_id=5470 From noreply at sourceforge.net Wed Oct 12 13:45:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Oct 2005 04:45:22 -0700 Subject: [Patches] [ python-Patches-1324762 ] Compiling and linking main() with C++ compiler Message-ID: Patches item #1324762, was opened at 2005-10-12 13:45 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=1324762&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Christoph Ludwig (cludwig) Assigned to: Nobody/Anonymous (nobody) Summary: Compiling and linking main() with C++ compiler Initial Comment: The attached patch proposes a resolution to the discussion started in regarding the compiler (C vs. C++) used to compile python's main() and to link the executable. The patch contains the following changes: 1) The configure option --with-cxx is renamed --with-cxx-main. This was done to avoid surprising the user by the changed meaning. Furthermore, it is now possible that CXX has a different value than provided by --with-cxx-main, so the old name would have been confusing. 2) The compiler used to translate python's main() function is stored in the configure / Makefile variable MAINCC. By default, MAINCC=$(CC). If --with-cxx-main is given (without an appended compiler name), then MAINCC=$(CXX). If --with-cxx-main= is on the configure command line, then MAINCC=. Additionally, configure sets CXX= unless CXX was already set on the configure command line. 3) The command used to link the python executable is (as before) stored in LINKCC. By default, LINKCC='$(PURIFY) $(MAINCC)', i.e. the linker front-end is the compiler used to translate main(). If necessary, LINKCC can be set on the configure command line in which case it won't be altered. 4) If CXX is not set by the user (on the command line or via --with-cxx-main), then configure tries several likely C++ compiler names. CXX is assigned the first name that refers to a callable program in the system. (CXX is set even if python is built with a C compiler only, so distutils can build C++ extensions.) 5) Modules/ccpython.cc is no longer used and can be removed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1324762&group_id=5470 From noreply at sourceforge.net Wed Oct 12 13:58:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Oct 2005 04:58:27 -0700 Subject: [Patches] [ python-Patches-1324770 ] Adding redblack tree to collections module Message-ID: Patches item #1324770, was opened at 2005-10-12 20: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=1324770&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Adding redblack tree to collections module Initial Comment: This patch drafts a new type "rbtree" implementing Redblack Tree for collections module. It's just a preliminary material for the future discussion and includes a least working code. Usage: [basic list-like tree operations] >>> from collections import rbtree >>> r = rbtree() >>> map(r.insert, [9, 3, 4, 100, 'dalki', 'subak', -51]) [None, None, None, None, None, None, None] >>> r.values() [-51, 3, 4, 9, 100, 'dalki', 'subak'] >>> r.remove(100) >>> r.values() [-51, 3, 4, 9, 'dalki', 'subak'] >>> r.insert('snisni') >>> r.values() [-51, 3, 4, 9, 'dalki', 'snisni', 'subak'] >>> 9 in r True >>> 8 in r False [labeled nodes operations] >>> r = rbtree() >>> r['dalki'] = 5; r['subak'] = 1; r['spam'] = 7 >>> r.values() [1, 5, 7] >>> r.keys() ['subak', 'dalki', 'spam'] >>> r['egg'] = 1 >>> r.items() [('egg', 1), ('dalki', 5), ('spam', 7)] >>> del r['spam'] >>> r.items() [('egg', 1), ('dalki', 5)] [mixed altogether] >>> r.insert(7) >>> r.insert(0) >>> r.items() [(None, 0), ('egg', 1), ('dalki', 5), (None, 7)] >>> r['dalki'] = 7 >>> r.items() [(None, 0), ('egg', 1), ('dalki', 7)] [heapq-like stuff] >>> r = rbtree() >>> map(r.insert, range(20)) [None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None] >>> r.nfirst(3) [0, 1, 2] >>> r.nfirst(10) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> r.nlast(5) [19, 18, 17, 16, 15] >>> r.popleft(5) [0, 1, 2, 3, 4] >>> r.values() [5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19] >>> r.popright(15) [19, 18, 17, 16] >>> r.values() [5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] >>> r['ham'] = 14 >>> r.poprightitems(14, True) [(None, 15), ('ham', 14)] [cmp, key and reverse are also supported] >>> r = rbtree(key=lambda x: x%10) >>> map(r.insert, range(30)) [None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None] >>> r.values() [20, 21, 22, 23, 24, 25, 26, 27, 28, 29] >>> r['yay'] = 78 >>> r.values() [20, 21, 22, 23, 24, 25, 26, 27, 78, 29] >>> r.items() [(None, 20), (None, 21), (None, 22), (None, 23), (None, 24), (None, 25), (None, 26), (None, 27), ('yay', 78), (None, 29)] >>> r.clear() >>> r.values() [] >>> r = rbtree(reverse=True) >>> map(r.insert, range(10)) [None, None, None, None, None, None, None, None, None, None] >>> r.values() [9, 8, 7, 6, 5, 4, 3, 2, 1, 0] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1324770&group_id=5470 From marketing at omtel.co.za Wed Oct 12 16:06:20 2005 From: marketing at omtel.co.za (Omtel) Date: Wed, 12 Oct 2005 16:06:20 +0200 Subject: [Patches] Your registration at OMTEL Message-ID: <45c6daf6868ba02ef3bd2df94cee1071@www.mailerdemon.co.za> Many thanks for your inquiry on OMTEL You want to reduce considerable your phone costs with OMTEL. You want to phone free of charge? You want to open a callshop? You want to represent our company in your country? You get all information about on our homepage http://www.omtel.de Register yourselve on our registration area and you will get all further information. We are available for further inquiries under marketing at omtel.co.za Yours sincerely Your OMTEL team This is a automatic generated e-mail. Should this e-mail not be wished by you or by a mistake reached you, please inform us. From noreply at sourceforge.net Thu Oct 13 08:38:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Oct 2005 23:38:48 -0700 Subject: [Patches] [ python-Patches-1031213 ] Patch for bug #780725 Message-ID: Patches item #1031213, was opened at 2004-09-20 22:37 Message generated for change (Comment added) made by ishimoto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1031213&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Neal Norwitz (nnorwitz) Summary: Patch for bug #780725 Initial Comment: When SyntaxError occurs and the module contains source encodings definition, current implementation prints error line in UTF8. This patch reverts the line into original encoding for printing. This patch calls some memory-allocation APIs such as PyUnicode_DecodeUTF8. I'm not sure I can (or should) call PyErr_Clear() here if error happened. ---------------------------------------------------------------------- >Comment By: atsuo ishimoto (ishimoto) Date: 2005-10-13 15:38 Message: Logged In: YES user_id=463672 Thanks for your comments. I'll post a revised patch and test case later. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-03 03:08 Message: Logged In: YES user_id=38388 Please use the "replace" error handler when recoding the source line to Unicode - this will reduce the probability of the conversion failing. If you do get an error, it's likely going to be an unknown encoding or less likely a memory problem. Please add some logic to deal with these errors as well - currently you don't call PyError_Clear() or take some other action which may lead to confusing error reports (e.g. error popping up randomly during program execution due to the set error). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 14:45 Message: Logged In: YES user_id=33168 I'm hoping that someone more familiar with unicode could take a look at this. The patch looks ok to me, but I don't know how to test that it works. I'm inclined to accept it, unless I hear otherwise. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1031213&group_id=5470 From noreply at sourceforge.net Thu Oct 13 13:54:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Oct 2005 04:54:22 -0700 Subject: [Patches] [ python-Patches-1006238 ] cross compile patch Message-ID: Patches item #1006238, was opened at 2004-08-09 22:05 Message generated for change (Comment added) made by robsa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Daniel Goertzen (goertzen) Assigned to: Nobody/Anonymous (nobody) Summary: cross compile patch Initial Comment: Here's a cross compile patch I prepared a while ago but never got around to submitting. I've been using it happily for months to cross compile python for embedded systems. Below is a descriptive excerpt from the patch. Also note that the patch modifies configure.in, but not configure. You will need to regenerate configure with something like autoconf configure.in >configure This patch is inpsired from work by Klaus Reimer at http://www.ailis.de/~k/docs/crosscompiling/python.php + Cross Compiling + --------------- + + Python can be cross compiled by supplying different --host and --build + parameters to configure. (Python is compiled on the "build" system + and executed on the "host" system, in case you forgot :). Python is + tricky to cross compile because it needs to execute parts of itself + during construction. To work around this, make's VPATH feature is + used to compile a native python in the subdirectory "buildpython". + When parts of python need to be executed during construction, the + "buildpython" versions are used. + + A consequence of using the VPATH feature is that you may not do a + cross compile build in the source directory. In other words, do this: + + mkdir mydir + cd mydir + ../Python/configure --host=powerpc-405-linux-gnu --build=i686-pc-linux-gnu + make + + Cross compiling works well under linux, mileage may vary for other + platforms. + + A few reminders on using configure to cross compile: + - Cross compile tools must be in the PATH. + - Cross compile tools must be prefixed with the host type + (ie powerpc-405-linux-gnu-cc, powerpc-405-linux-gnu-ranlib, ...) + - CC, CXX, AR, and RANLIB must be undefined when running configure and + make. Configure will detect them. + + If you need a cross compiler, check out Dan Kegel's crosstool: + http://www.kegel.com/crosstool + + ---------------------------------------------------------------------- Comment By: Robsa (robsa) Date: 2005-10-13 11:54 Message: Logged In: YES user_id=1277505 Just thought I'd let you know that this patch works against Python 2.4.2. I had Python running on my custom AT91RM9200 board (ARM920T core) in about 20 minutes. *snaps* for Daniel!! ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-04-13 17:36 Message: Logged In: YES user_id=843814 It still works for me, so I've had limited interest in working on it further. I think a "real" cross compile patch will involve significant refactoring of distutils and the main setup.py script. Should this start with a PEP? ---------------------------------------------------------------------- Comment By: Ned Ludd (solarx) Date: 2005-04-09 20:43 Message: Logged In: YES user_id=148412 Any progress with this on? python and perl are two of the last major things to overcome in the x-compile world. ---------------------------------------------------------------------- Comment By: Mike Frysinger (vapier) Date: 2004-10-26 16:00 Message: Logged In: YES user_id=114429 we've been using this with uClibc for a while now and it works great ... ive personally built (on amd64) & deployed (on x86/ppc/arm/mips/sh4) python ... would great if this finally made it into the official sources :) ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-10-21 01:08 Message: Logged In: YES user_id=2772 This patch applies cleanly to today's CVS head. If building in the source directory while cross compiling fails, please make configure complain about it. This patch makes the build process invoke make recursively, which is a big minus. I'd rather see pgen built with a HOSTCC and just assume python is available on $PATH for the setup.py step. There's no reason to build all the shared modules in buildpython, either, which would speed things up a fair bit. On to how it worked for me: Not cross-compiling, this produces no unexpected test failures in "make test". (redhat9) Cross compiling for i386-pc-bsdi2.1 everything goes fine until it tries to run buildpython and make shared modules, but shared modules don't work in the first place on bsdi2. I did not test the resulting Python binary. Cross compiling for i386-redhat-linux (libc6) some extensions fail to build, but this could be because my header files for the cross-development environment are not complete. Running "make test" tries to invoke the "buildpython/python" and doesn't work. Running it manually I get some skips due to modules that did not build, but everything that did build seems to pass. (OK, so I wrote this before the tests completed, but they're off to a good start) I currently cross-compile python 2.3 for win32 (mingw), and until recently cross-compiled it for bsdi2 and redhat6. However, I did not use configure or the included makefiles to do this (in order to integrate in a non-recursive build procedure that builds several packages), so this patch is unlikely to benefit me directly. I don't think this patch is ready to be applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 From noreply at sourceforge.net Thu Oct 13 21:07:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Oct 2005 12:07:43 -0700 Subject: [Patches] [ python-Patches-1326113 ] Letting "build_ext --libraries" take more than one lib Message-ID: Patches item #1326113, was opened at 2005-10-13 19:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1326113&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephen A. Langer (slanger) Assigned to: Nobody/Anonymous (nobody) Summary: Letting "build_ext --libraries" take more than one lib Initial Comment: It's impossible to specify more than one external library to link using build_ext --libraries. Bug 716634 says that the problem is fixed, but it isn't. Assuming that the desired format is --libraries="lib1 lib2 etc", then there's a simple one line fix which I've attached. The problem exists in python 2.3.5, 2.4.1, 2.4.2 and in cvs HEAD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1326113&group_id=5470 From noreply at sourceforge.net Fri Oct 14 17:55:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Oct 2005 08:55:22 -0700 Subject: [Patches] [ python-Patches-1324770 ] Adding redblack tree to collections module Message-ID: Patches item #1324770, was opened at 2005-10-12 20:58 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1324770&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Adding redblack tree to collections module Initial Comment: This patch drafts a new type "rbtree" implementing Redblack Tree for collections module. It's just a preliminary material for the future discussion and includes a least working code. Usage: [basic list-like tree operations] >>> from collections import rbtree >>> r = rbtree() >>> map(r.insert, [9, 3, 4, 100, 'dalki', 'subak', -51]) [None, None, None, None, None, None, None] >>> r.values() [-51, 3, 4, 9, 100, 'dalki', 'subak'] >>> r.remove(100) >>> r.values() [-51, 3, 4, 9, 'dalki', 'subak'] >>> r.insert('snisni') >>> r.values() [-51, 3, 4, 9, 'dalki', 'snisni', 'subak'] >>> 9 in r True >>> 8 in r False [labeled nodes operations] >>> r = rbtree() >>> r['dalki'] = 5; r['subak'] = 1; r['spam'] = 7 >>> r.values() [1, 5, 7] >>> r.keys() ['subak', 'dalki', 'spam'] >>> r['egg'] = 1 >>> r.items() [('egg', 1), ('dalki', 5), ('spam', 7)] >>> del r['spam'] >>> r.items() [('egg', 1), ('dalki', 5)] [mixed altogether] >>> r.insert(7) >>> r.insert(0) >>> r.items() [(None, 0), ('egg', 1), ('dalki', 5), (None, 7)] >>> r['dalki'] = 7 >>> r.items() [(None, 0), ('egg', 1), ('dalki', 7)] [heapq-like stuff] >>> r = rbtree() >>> map(r.insert, range(20)) [None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None] >>> r.nfirst(3) [0, 1, 2] >>> r.nfirst(10) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> r.nlast(5) [19, 18, 17, 16, 15] >>> r.popleft(5) [0, 1, 2, 3, 4] >>> r.values() [5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19] >>> r.popright(15) [19, 18, 17, 16] >>> r.values() [5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] >>> r['ham'] = 14 >>> r.poprightitems(14, True) [(None, 15), ('ham', 14)] [cmp, key and reverse are also supported] >>> r = rbtree(key=lambda x: x%10) >>> map(r.insert, range(30)) [None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None] >>> r.values() [20, 21, 22, 23, 24, 25, 26, 27, 28, 29] >>> r['yay'] = 78 >>> r.values() [20, 21, 22, 23, 24, 25, 26, 27, 78, 29] >>> r.items() [(None, 20), (None, 21), (None, 22), (None, 23), (None, 24), (None, 25), (None, 26), (None, 27), ('yay', 78), (None, 29)] >>> r.clear() >>> r.values() [] >>> r = rbtree(reverse=True) >>> map(r.insert, range(10)) [None, None, None, None, None, None, None, None, None, None] >>> r.values() [9, 8, 7, 6, 5, 4, 3, 2, 1, 0] ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2005-10-15 00:55 Message: Logged In: YES user_id=55188 Added a unittest and fixed a bug on initcollection() calling PyType_Ready(&rbtree_type). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1324770&group_id=5470 From noreply at sourceforge.net Sat Oct 15 11:22:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 15 Oct 2005 02:22:25 -0700 Subject: [Patches] [ python-Patches-1327377 ] VS NET 2003 Project Files contain per file compiler settings Message-ID: Patches item #1327377, was opened at 2005-10-15 11:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1327377&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Juan-Carlos Lopez-Garcia (babydoe) Assigned to: Nobody/Anonymous (nobody) Summary: VS NET 2003 Project Files contain per file compiler settings Initial Comment: A review of the vcproj files shows that not only the "global" compiler settings affect the compilation, but also most (not all) of the files to be compiled have their own overriding compiler settings. For example mathmodule.c (in pythoncore.vcproj): This per file definition makes it very time consuming to globally change compiler settings for an specific build (for example adding/removing a preprocessor definition, or changing the optimisation levels) Are this per file definitions really necessary (imho no, but i'm not one of the python developers), or are they just an artifact of importing the VS6 projects (this happened to me with all of my converted projects) ? If the per file configuration is not really necessary it can be safelly removed by deleting the elements contained in the tags ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1327377&group_id=5470 From noreply at sourceforge.net Sat Oct 15 12:24:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 15 Oct 2005 03:24:44 -0700 Subject: [Patches] [ python-Patches-1327377 ] VS NET 2003 Project Files contain per file compiler settings Message-ID: Patches item #1327377, was opened at 2005-10-15 11:22 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1327377&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Doe, Baby (babydoe) Assigned to: Nobody/Anonymous (nobody) Summary: VS NET 2003 Project Files contain per file compiler settings Initial Comment: A review of the vcproj files shows that not only the "global" compiler settings affect the compilation, but also most (not all) of the files to be compiled have their own overriding compiler settings. For example mathmodule.c (in pythoncore.vcproj): This per file definition makes it very time consuming to globally change compiler settings for an specific build (for example adding/removing a preprocessor definition, or changing the optimisation levels) Are this per file definitions really necessary (imho no, but i'm not one of the python developers), or are they just an artifact of importing the VS6 projects (this happened to me with all of my converted projects) ? If the per file configuration is not really necessary it can be safelly removed by deleting the elements contained in the tags ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-10-15 12:24 Message: Logged In: YES user_id=1188172 Are you willing to provide a patch? Else this must be moved to the "bugs" tracker. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1327377&group_id=5470 From noreply at sourceforge.net Sat Oct 15 12:52:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 15 Oct 2005 03:52:15 -0700 Subject: [Patches] [ python-Patches-1327377 ] VS NET 2003 Project Files contain per file compiler settings Message-ID: Patches item #1327377, was opened at 2005-10-15 11:22 Message generated for change (Comment added) made by babydoe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1327377&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Doe, Baby (babydoe) Assigned to: Nobody/Anonymous (nobody) Summary: VS NET 2003 Project Files contain per file compiler settings Initial Comment: A review of the vcproj files shows that not only the "global" compiler settings affect the compilation, but also most (not all) of the files to be compiled have their own overriding compiler settings. For example mathmodule.c (in pythoncore.vcproj): This per file definition makes it very time consuming to globally change compiler settings for an specific build (for example adding/removing a preprocessor definition, or changing the optimisation levels) Are this per file definitions really necessary (imho no, but i'm not one of the python developers), or are they just an artifact of importing the VS6 projects (this happened to me with all of my converted projects) ? If the per file configuration is not really necessary it can be safelly removed by deleting the elements contained in the tags ---------------------------------------------------------------------- >Comment By: Doe, Baby (babydoe) Date: 2005-10-15 12:52 Message: Logged In: YES user_id=458368 I have to make the changes anyway for my static build, so i can provide a patch ... Do you have any special instructions or should i just post a zip file with the "patched" vcproj files ? Should I use the files in the 2.4.2 Source distribution (this is my current base), or do you want me to use the anonymous CVS ? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-10-15 12:24 Message: Logged In: YES user_id=1188172 Are you willing to provide a patch? Else this must be moved to the "bugs" tracker. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1327377&group_id=5470 From noreply at sourceforge.net Sat Oct 15 15:35:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 15 Oct 2005 06:35:41 -0700 Subject: [Patches] [ python-Patches-1327377 ] VS NET 2003 Project Files contain per file compiler settings Message-ID: Patches item #1327377, was opened at 2005-10-15 11:22 Message generated for change (Comment added) made by babydoe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1327377&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Doe, Baby (babydoe) Assigned to: Nobody/Anonymous (nobody) Summary: VS NET 2003 Project Files contain per file compiler settings Initial Comment: A review of the vcproj files shows that not only the "global" compiler settings affect the compilation, but also most (not all) of the files to be compiled have their own overriding compiler settings. For example mathmodule.c (in pythoncore.vcproj): This per file definition makes it very time consuming to globally change compiler settings for an specific build (for example adding/removing a preprocessor definition, or changing the optimisation levels) Are this per file definitions really necessary (imho no, but i'm not one of the python developers), or are they just an artifact of importing the VS6 projects (this happened to me with all of my converted projects) ? If the per file configuration is not really necessary it can be safelly removed by deleting the elements contained in the tags ---------------------------------------------------------------------- >Comment By: Doe, Baby (babydoe) Date: 2005-10-15 15:35 Message: Logged In: YES user_id=458368 Just uploaded the modified vcproj files from the Python2.4.2 Sources, and an additional file containing the results of the build. I do not have _bsddb, _ssl, _tkinter, bz2 and zlib installed as source, thus those modules had to fail in my tests. ---------------------------------------------------------------------- Comment By: Doe, Baby (babydoe) Date: 2005-10-15 12:52 Message: Logged In: YES user_id=458368 I have to make the changes anyway for my static build, so i can provide a patch ... Do you have any special instructions or should i just post a zip file with the "patched" vcproj files ? Should I use the files in the 2.4.2 Source distribution (this is my current base), or do you want me to use the anonymous CVS ? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-10-15 12:24 Message: Logged In: YES user_id=1188172 Are you willing to provide a patch? Else this must be moved to the "bugs" tracker. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1327377&group_id=5470 From noreply at sourceforge.net Sat Oct 15 20:43:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 15 Oct 2005 11:43:43 -0700 Subject: [Patches] [ python-Patches-1327594 ] Static Windows Build fails to locate existing installation Message-ID: Patches item #1327594, was opened at 2005-10-15 20:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1327594&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Doe, Baby (babydoe) Assigned to: Nobody/Anonymous (nobody) Summary: Static Windows Build fails to locate existing installation Initial Comment: I have used the Python 2.4.2 source to create a static linkable version under windows (.lib). The executables using that library fail to find the registry path of an already existing Python 2.4 installation. I have traced this down to the PC/dl_nt.c file, where the variable PyWin_DLLVersionString is defined, but not initialized, execpt if the DllMain function is called. That function is only called by a process loading a DLL, this is not the case with an static linked library. I have used a preprocessor check against Py_NO_ENABLE_SHARED to create a modified version of dl_nt.c that will initialize the variable and remove the DLLMain function from the static version (and keep the original code when making a shared DLL) With this minimal modification "import site" works as usual even in an static linked version. For your convenience the modified file can be found in the attachement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1327594&group_id=5470 From noreply at sourceforge.net Sun Oct 16 09:42:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 16 Oct 2005 00:42:40 -0700 Subject: [Patches] [ python-Patches-1324770 ] Adding redblack tree to collections module Message-ID: Patches item #1324770, was opened at 2005-10-12 20:58 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1324770&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Adding redblack tree to collections module Initial Comment: This patch drafts a new type "rbtree" implementing Redblack Tree for collections module. It's just a preliminary material for the future discussion and includes a least working code. Usage: [basic list-like tree operations] >>> from collections import rbtree >>> r = rbtree() >>> map(r.insert, [9, 3, 4, 100, 'dalki', 'subak', -51]) [None, None, None, None, None, None, None] >>> r.values() [-51, 3, 4, 9, 100, 'dalki', 'subak'] >>> r.remove(100) >>> r.values() [-51, 3, 4, 9, 'dalki', 'subak'] >>> r.insert('snisni') >>> r.values() [-51, 3, 4, 9, 'dalki', 'snisni', 'subak'] >>> 9 in r True >>> 8 in r False [labeled nodes operations] >>> r = rbtree() >>> r['dalki'] = 5; r['subak'] = 1; r['spam'] = 7 >>> r.values() [1, 5, 7] >>> r.keys() ['subak', 'dalki', 'spam'] >>> r['egg'] = 1 >>> r.items() [('egg', 1), ('dalki', 5), ('spam', 7)] >>> del r['spam'] >>> r.items() [('egg', 1), ('dalki', 5)] [mixed altogether] >>> r.insert(7) >>> r.insert(0) >>> r.items() [(None, 0), ('egg', 1), ('dalki', 5), (None, 7)] >>> r['dalki'] = 7 >>> r.items() [(None, 0), ('egg', 1), ('dalki', 7)] [heapq-like stuff] >>> r = rbtree() >>> map(r.insert, range(20)) [None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None] >>> r.nfirst(3) [0, 1, 2] >>> r.nfirst(10) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> r.nlast(5) [19, 18, 17, 16, 15] >>> r.popleft(5) [0, 1, 2, 3, 4] >>> r.values() [5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19] >>> r.popright(15) [19, 18, 17, 16] >>> r.values() [5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] >>> r['ham'] = 14 >>> r.poprightitems(14, True) [(None, 15), ('ham', 14)] [cmp, key and reverse are also supported] >>> r = rbtree(key=lambda x: x%10) >>> map(r.insert, range(30)) [None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None] >>> r.values() [20, 21, 22, 23, 24, 25, 26, 27, 28, 29] >>> r['yay'] = 78 >>> r.values() [20, 21, 22, 23, 24, 25, 26, 27, 78, 29] >>> r.items() [(None, 20), (None, 21), (None, 22), (None, 23), (None, 24), (None, 25), (None, 26), (None, 27), ('yay', 78), (None, 29)] >>> r.clear() >>> r.values() [] >>> r = rbtree(reverse=True) >>> map(r.insert, range(10)) [None, None, None, None, None, None, None, None, None, None] >>> r.values() [9, 8, 7, 6, 5, 4, 3, 2, 1, 0] ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2005-10-16 16:42 Message: Logged In: YES user_id=55188 Added iterator and reverse iterator implementations and __copy__ method. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-10-15 00:55 Message: Logged In: YES user_id=55188 Added a unittest and fixed a bug on initcollection() calling PyType_Ready(&rbtree_type). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1324770&group_id=5470 From noreply at sourceforge.net Mon Oct 17 12:04:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Oct 2005 03:04:28 -0700 Subject: [Patches] [ python-Patches-1328526 ] Patch for (Doc) #1255218 Message-ID: Patches item #1328526, was opened at 2005-10-17 12: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=1328526&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter van Kampen (pterk) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for (Doc) #1255218 Initial Comment: Rewording in libmultifile.tex ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1328526&group_id=5470 From noreply at sourceforge.net Mon Oct 17 13:05:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Oct 2005 04:05:11 -0700 Subject: [Patches] [ python-Patches-1328566 ] Patch for (Doc) #1261659 Message-ID: Patches item #1328566, was opened at 2005-10-17 13:05 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=1328566&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter van Kampen (pterk) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for (Doc) #1261659 Initial Comment: Added ** function call example ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1328566&group_id=5470 From noreply at sourceforge.net Mon Oct 17 20:09:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Oct 2005 11:09:52 -0700 Subject: [Patches] [ python-Patches-1328851 ] pclose raises spurious exception on win32 Message-ID: Patches item #1328851, was opened at 2005-10-17 14:09 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=1328851&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: pclose raises spurious exception on win32 Initial Comment: When a program's exit status is -1, the Windows-specific _PyPclose() function will return -1, which is mistaken by its caller file_close() as a request to raise an exception, which then becomes IOError with errno set to zero. My proposed fix is to change result = exit_code; into result = exit_code & 0xffff; which should do the right thing at least on win32 (I don't care about win16). Patch attached. (I'd check this in but I can't test it.) To reproduce: (1) On XP, in the control panel, stop the "Server" service. (2) Run the following code: import os p = os.popen("net share -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20051017/fc79f7c0/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 184545 bytes Desc: not available Url : http://mail.python.org/pipermail/patches/attachments/20051017/fc79f7c0/attachment-0001.jpe From noreply at sourceforge.net Wed Oct 19 04:46:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Oct 2005 19:46:18 -0700 Subject: [Patches] [ python-Patches-1330538 ] datetime/xmlrpclib.DateTime comparison Message-ID: Patches item #1330538, was opened at 2005-10-18 21:46 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=1330538&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: datetime/xmlrpclib.DateTime comparison Initial Comment: Recent changes to xmlrpclib provided improved support for datetime objects. This patch improves that by adding support for comparison of xmlrpclib.DateTime objects with datetime.{datetime,date,time} objects. On the Mojam web server I run with an xmlrpclib module that is close to what Python 2.5 will have, though I use Python 2.3.4. The datetime support breaks the antispam BadContent support in MoinMoin's security policy because datetime objects and xmlrpclib.DateTime objects can't be compared. I believe this patch should solve that (though I haven't had time to test that yet). I've added new test cases to check support for comparing datetime.{datetime,date} objects with DateTime objects. I still need to add a test case to check support for comparing datetime.time objects. I believe something like this needs to go in 2.5 (maybe this should have been a bug report instead of patch). All Python test cases pass. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1330538&group_id=5470 From kitty at buddies.brastart.com Wed Oct 19 06:04:39 2005 From: kitty at buddies.brastart.com (kitty@buddies.brastart.com) Date: Wed, 19 Oct 2005 12:04:39 +0800 Subject: [Patches] Buddies ?J web site , ???h?i????~~~ Message-ID: <20051019120439.BE4CD1594013@qhbnotebook> Buddies ¬J web site , ¦n¦h³¥ª±ga ~~~ ­øÚ»¤U¯u«Y¥i±¤ ~~~ www.buddies.brastart.com °O±o ¯d¨¥ ©M §ë²¼ °Ú~~~ ¦pªG¤W­±­Ó link ­ø±o ´N¥Î www.buddies.t35.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20051019/6bc98282/attachment.htm From noreply at sourceforge.net Wed Oct 19 14:39:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 19 Oct 2005 05:39:03 -0700 Subject: [Patches] [ python-Patches-1331635 ] tarfile.py: fix for 1330039 Message-ID: Patches item #1331635, was opened at 2005-10-19 14: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=1331635&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py: fix for 1330039 Initial Comment: The attached patch fixes bug #1330039. The patch includes a testcase. A file is added to an archive as a hardlink if a file with the same inode number (and device number) was added before without futher checks. This leads to the undesired behaviour described in #1330039, i.e. if two throwaway temporary files are assigned the same inode number by the filesystem, the second one will be added as a hardlink to the first, which means that the content will be lost. The patched code checks if the file's st_nlink is greater 1. So only for files that actually have several links pointing to them hardlinks will be created, which is what GNU tar does. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1331635&group_id=5470 From noreply at sourceforge.net Thu Oct 20 06:56:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 19 Oct 2005 21:56:42 -0700 Subject: [Patches] [ python-Patches-1331635 ] tarfile.py: fix for 1330039 Message-ID: Patches item #1331635, was opened at 2005-10-19 05:39 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1331635&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Lars Gust?bel (gustaebel) >Assigned to: Neal Norwitz (nnorwitz) Summary: tarfile.py: fix for 1330039 Initial Comment: The attached patch fixes bug #1330039. The patch includes a testcase. A file is added to an archive as a hardlink if a file with the same inode number (and device number) was added before without futher checks. This leads to the undesired behaviour described in #1330039, i.e. if two throwaway temporary files are assigned the same inode number by the filesystem, the second one will be added as a hardlink to the first, which means that the content will be lost. The patched code checks if the file's st_nlink is greater 1. So only for files that actually have several links pointing to them hardlinks will be created, which is what GNU tar does. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-19 21:56 Message: Logged In: YES user_id=33168 Thanks Lars. Checked in as: * Lib/tarfile.py 1.34 and 1.21.2.6 * Lib/test/test_tarfile.py 1.20 and 1.16.2.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1331635&group_id=5470 From noreply at sourceforge.net Fri Oct 21 02:49:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Oct 2005 17:49:50 -0700 Subject: [Patches] [ python-Patches-1333679 ] Allow use of non-latin1 chars in interactive shell Message-ID: Patches item #1333679, was opened at 2005-10-21 02:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1333679&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: Allow use of non-latin1 chars in interactive shell Initial Comment: If I type a unicode string, such as u"שלום" in the interactive interpreter in the terminal, it does what I expect - return the unicode string (in this case, u'\u05e9\u05dc\u05d5\u05dd') However, if I type it in IDLE's interactive interpreter, I get something funny - I get a unicode string (u'\xd7\xa9\xd7\x9c\xd7\x95\xd7\x9d'), which is actually u"שלום".decode('utf8').encode('latin1'). This is caused by the PyShell.runsource method, which checks if the source string it gets is unicode, and if so, encodes it using the 'ascii' codec. If this check is removed, so that the unicode object itself gets compiled, everything works out fine. The bottom line: remove the if block starting with "if isinstance(source, types.UnicodeType)", at PyShell.py:589, and everything is fine. Have a good day, Noam ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1333679&group_id=5470 From noreply at sourceforge.net Sat Oct 22 18:44:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 22 Oct 2005 09:44:19 -0700 Subject: [Patches] [ python-Patches-1334979 ] Fix for int(string, base) wrong answers Message-ID: Patches item #1334979, was opened at 2005-10-22 10: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=1334979&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Adam Olsen (rhamphoryncus) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for int(string, base) wrong answers Initial Comment: Fix for Bug #1334662. Passes make test (other than skipped tests), as well as the errors listed in Bug #1334662. Although it does remove the division from the loop this does not seem to make a signifigant speedup. No clue why. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1334979&group_id=5470 From noreply at sourceforge.net Sat Oct 22 22:00:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 22 Oct 2005 13:00:26 -0700 Subject: [Patches] [ python-Patches-1334979 ] Fix for int(string, base) wrong answers Message-ID: Patches item #1334979, was opened at 2005-10-22 10:44 Message generated for change (Comment added) made by rhamphoryncus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1334979&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Adam Olsen (rhamphoryncus) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for int(string, base) wrong answers Initial Comment: Fix for Bug #1334662. Passes make test (other than skipped tests), as well as the errors listed in Bug #1334662. Although it does remove the division from the loop this does not seem to make a signifigant speedup. No clue why. ---------------------------------------------------------------------- >Comment By: Adam Olsen (rhamphoryncus) Date: 2005-10-22 14:00 Message: Logged In: YES user_id=12364 This one moves smallmax into a precomputed global table. $ python2.4 -m timeit 'int("999999999")' 1000000 loops, best of 3: 0.863 usec per loop $ python2.4 -m timeit 'int("9")' 1000000 loops, best of 3: 0.716 usec per loop $ ./python -m timeit 'int("999999999")' 1000000 loops, best of 3: 0.766 usec per loop $ ./python -m timeit 'int("9")' 1000000 loops, best of 3: 0.694 usec per loop So 0.863 -> 0.766 and 0.716 -> 0.694. 11% and 3%. I wouldn't bother if it weren't fixing a bug, but maybe the http://spoj.sphere.pl test will show a larger difference. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1334979&group_id=5470 From noreply at sourceforge.net Sat Oct 22 23:01:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 22 Oct 2005 14:01:51 -0700 Subject: [Patches] [ python-Patches-1330538 ] datetime/xmlrpclib.DateTime comparison Message-ID: Patches item #1330538, was opened at 2005-10-18 21:46 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1330538&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: datetime/xmlrpclib.DateTime comparison Initial Comment: Recent changes to xmlrpclib provided improved support for datetime objects. This patch improves that by adding support for comparison of xmlrpclib.DateTime objects with datetime.{datetime,date,time} objects. On the Mojam web server I run with an xmlrpclib module that is close to what Python 2.5 will have, though I use Python 2.3.4. The datetime support breaks the antispam BadContent support in MoinMoin's security policy because datetime objects and xmlrpclib.DateTime objects can't be compared. I believe this patch should solve that (though I haven't had time to test that yet). I've added new test cases to check support for comparing datetime.{datetime,date} objects with DateTime objects. I still need to add a test case to check support for comparing datetime.time objects. I believe something like this needs to go in 2.5 (maybe this should have been a bug report instead of patch). All Python test cases pass. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-10-22 16:01 Message: Logged In: YES user_id=44345 Based on inputs from python-dev I removed conversions of and comparisons with datetime.date and datetime.time objects. I also tweaked it to work with Python 2.2 through Python 2.5 (datetime support is unavailable in Python2.2). New patch is attached. I'd simply check this in except I've not done anything with rich comparisons before. Assigning to Fred since he's familiar with the code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1330538&group_id=5470 From noreply at sourceforge.net Sun Oct 23 00:33:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 22 Oct 2005 15:33:54 -0700 Subject: [Patches] [ python-Patches-1335054 ] Python 2.4.2 doesn't build with "--without-threads" Message-ID: Patches item #1335054, was opened at 2005-10-22 12:51 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1335054&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Build >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gunter Ohrner (interneci) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.2 doesn't build with "--without-threads" Initial Comment: Build fix is attached. (Not yet runtime tested.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1335054&group_id=5470 From noreply at sourceforge.net Mon Oct 24 00:33:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 23 Oct 2005 15:33:48 -0700 Subject: [Patches] [ python-Patches-1335812 ] Patch to implement PEP 351 Message-ID: Patches item #1335812, was opened at 2005-10-23 18: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=1335812&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to implement PEP 351 Initial Comment: PEP 351 proposes the freeze protocol. Here is a patch that implements the proposed builtin, as well as __freeze__() methods for lists and sets. Dictionaries are not yet implemented. Unit tests and documentation are also necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1335812&group_id=5470 From noreply at sourceforge.net Mon Oct 24 07:33:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 23 Oct 2005 22:33:11 -0700 Subject: [Patches] [ python-Patches-1335972 ] Fix for int(string, base) wrong answers (take 2) Message-ID: Patches item #1335972, was opened at 2005-10-24 00: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=1335972&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alan McIntyre (ESRG) (alanmcintyre) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for int(string, base) wrong answers (take 2) Initial Comment: This incorporates patch #1334979, adds test cases for all the cases listed in bug #1334662, and adds test cases for evaluation of 2**32+1. There seem to be some minor speed improvements (simplistic stats shown below). Some simple performance test scripts have been included in the attached file as well. A lookup table was added for the maximum number of digits that can never overflow on a 32-bit ulong for each base. Overflow is only checked when this limit is exceeded by 1, and once the input string is determined to be too long (2 over the limit), the evaluation is halted and an overflow indication is returned. This appears to help reduce the evaluation time for very long strings (no time is wasted trying to evaluate all of it into a 32-bit ulong). Evaluation of each character has also been replaced by a lookup table. I'm not certain of the amount of speed benefit obtained from this; I added it early on and haven't had time to go back and test. It may be that it's not worth the extra static table. Baseline Python from CVS: alan at tarantula:~/python/dist/src# ./python -m timeit 'int("9")' 100000 loops, best of 3: 4 usec per loop alan at tarantula:~/python/dist/src# ./python -m timeit 'int("999999999")' 100000 loops, best of 3: 5.49 usec per loop alan at tarantula:~/python/dist/src# ./python -m timeit 'int("999999999999")' 100000 loops, best of 3: 11.8 usec per loop alan at tarantula:~/python/dist/src# ./python -m timeit 'int("999999999999999")' 100000 loops, best of 3: 13.4 usec per loop alan at tarantula:~/python/dist/src# ./python -m timeit 'int("1"*600)' 1000 loops, best of 3: 997 usec per loop Modified: alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("9")' 100000 loops, best of 3: 3.63 usec per loop alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("999999999")' 100000 loops, best of 3: 3.93 usec per loop alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("999999999999")' 100000 loops, best of 3: 9.79 usec per loop alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("999999999999999")' 100000 loops, best of 3: 11 usec per loop alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("1"*600)' 1000 loops, best of 3: 905 usec per loop 10.2% faster for 1-digit int 39.7% faster for 9-digit int 20.5% faster for 12-digit int 21.8% faster for 15-digit int 10.2% faster for 600-digit int Test program that takes 750k ints from [0, 2**32) through stdin: Baseline: 8.114 sec (best of 5 consecutive runs) Modified: 6.774 sec (best of 5 consecutive runs) 19.8% faster NOTE: This patch causes new errors in test_array and test_compile, but it seems that these *should* be failing given the input string for long(), unless I'm missing something: ====================================================================== ERROR: test_repr (__main__.FloatTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_array.py", line 187, in test_repr self.assertEqual(a, eval(repr(a), {"array": array.array})) ValueError: invalid literal for long(): 10000000000.0 ====================================================================== ERROR: test_repr (__main__.DoubleTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_array.py", line 187, in test_repr self.assertEqual(a, eval(repr(a), {"array": array.array})) ValueError: invalid literal for long(): 10000000000.0 ---------------------------------------------------------------------- test test_compile crashed -- exceptions.ValueError: invalid literal for long(): 90000000000000. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1335972&group_id=5470 From noreply at sourceforge.net Mon Oct 24 07:41:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 23 Oct 2005 22:41:45 -0700 Subject: [Patches] [ python-Patches-1335972 ] Fix for int(string, base) wrong answers (take 2) Message-ID: Patches item #1335972, was opened at 2005-10-24 00:33 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1335972&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alan McIntyre (ESRG) (alanmcintyre) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for int(string, base) wrong answers (take 2) Initial Comment: This incorporates patch #1334979, adds test cases for all the cases listed in bug #1334662, and adds test cases for evaluation of 2**32+1. There seem to be some minor speed improvements (simplistic stats shown below). Some simple performance test scripts have been included in the attached file as well. A lookup table was added for the maximum number of digits that can never overflow on a 32-bit ulong for each base. Overflow is only checked when this limit is exceeded by 1, and once the input string is determined to be too long (2 over the limit), the evaluation is halted and an overflow indication is returned. This appears to help reduce the evaluation time for very long strings (no time is wasted trying to evaluate all of it into a 32-bit ulong). Evaluation of each character has also been replaced by a lookup table. I'm not certain of the amount of speed benefit obtained from this; I added it early on and haven't had time to go back and test. It may be that it's not worth the extra static table. Baseline Python from CVS: alan at tarantula:~/python/dist/src# ./python -m timeit 'int("9")' 100000 loops, best of 3: 4 usec per loop alan at tarantula:~/python/dist/src# ./python -m timeit 'int("999999999")' 100000 loops, best of 3: 5.49 usec per loop alan at tarantula:~/python/dist/src# ./python -m timeit 'int("999999999999")' 100000 loops, best of 3: 11.8 usec per loop alan at tarantula:~/python/dist/src# ./python -m timeit 'int("999999999999999")' 100000 loops, best of 3: 13.4 usec per loop alan at tarantula:~/python/dist/src# ./python -m timeit 'int("1"*600)' 1000 loops, best of 3: 997 usec per loop Modified: alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("9")' 100000 loops, best of 3: 3.63 usec per loop alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("999999999")' 100000 loops, best of 3: 3.93 usec per loop alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("999999999999")' 100000 loops, best of 3: 9.79 usec per loop alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("999999999999999")' 100000 loops, best of 3: 11 usec per loop alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("1"*600)' 1000 loops, best of 3: 905 usec per loop 10.2% faster for 1-digit int 39.7% faster for 9-digit int 20.5% faster for 12-digit int 21.8% faster for 15-digit int 10.2% faster for 600-digit int Test program that takes 750k ints from [0, 2**32) through stdin: Baseline: 8.114 sec (best of 5 consecutive runs) Modified: 6.774 sec (best of 5 consecutive runs) 19.8% faster NOTE: This patch causes new errors in test_array and test_compile, but it seems that these *should* be failing given the input string for long(), unless I'm missing something: ====================================================================== ERROR: test_repr (__main__.FloatTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_array.py", line 187, in test_repr self.assertEqual(a, eval(repr(a), {"array": array.array})) ValueError: invalid literal for long(): 10000000000.0 ====================================================================== ERROR: test_repr (__main__.DoubleTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_array.py", line 187, in test_repr self.assertEqual(a, eval(repr(a), {"array": array.array})) ValueError: invalid literal for long(): 10000000000.0 ---------------------------------------------------------------------- test test_compile crashed -- exceptions.ValueError: invalid literal for long(): 90000000000000. ---------------------------------------------------------------------- >Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-10-24 00:41 Message: Logged In: YES user_id=1115903 I forgot to add that these results were obtained on a PIIIm 833MHz running Linux 2.4.2, GCC 3.2.2, with the Python 2.5a0 CVS source from about 8pm EST Oct 23, 2005. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1335972&group_id=5470 From noreply at sourceforge.net Mon Oct 24 09:07:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Oct 2005 00:07:15 -0700 Subject: [Patches] [ python-Patches-1335972 ] Fix for int(string, base) wrong answers (take 2) Message-ID: Patches item #1335972, was opened at 2005-10-24 09:33 Message generated for change (Comment added) made by funny_falcon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1335972&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alan McIntyre (ESRG) (alanmcintyre) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for int(string, base) wrong answers (take 2) Initial Comment: This incorporates patch #1334979, adds test cases for all the cases listed in bug #1334662, and adds test cases for evaluation of 2**32+1. There seem to be some minor speed improvements (simplistic stats shown below). Some simple performance test scripts have been included in the attached file as well. A lookup table was added for the maximum number of digits that can never overflow on a 32-bit ulong for each base. Overflow is only checked when this limit is exceeded by 1, and once the input string is determined to be too long (2 over the limit), the evaluation is halted and an overflow indication is returned. This appears to help reduce the evaluation time for very long strings (no time is wasted trying to evaluate all of it into a 32-bit ulong). Evaluation of each character has also been replaced by a lookup table. I'm not certain of the amount of speed benefit obtained from this; I added it early on and haven't had time to go back and test. It may be that it's not worth the extra static table. Baseline Python from CVS: alan at tarantula:~/python/dist/src# ./python -m timeit 'int("9")' 100000 loops, best of 3: 4 usec per loop alan at tarantula:~/python/dist/src# ./python -m timeit 'int("999999999")' 100000 loops, best of 3: 5.49 usec per loop alan at tarantula:~/python/dist/src# ./python -m timeit 'int("999999999999")' 100000 loops, best of 3: 11.8 usec per loop alan at tarantula:~/python/dist/src# ./python -m timeit 'int("999999999999999")' 100000 loops, best of 3: 13.4 usec per loop alan at tarantula:~/python/dist/src# ./python -m timeit 'int("1"*600)' 1000 loops, best of 3: 997 usec per loop Modified: alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("9")' 100000 loops, best of 3: 3.63 usec per loop alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("999999999")' 100000 loops, best of 3: 3.93 usec per loop alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("999999999999")' 100000 loops, best of 3: 9.79 usec per loop alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("999999999999999")' 100000 loops, best of 3: 11 usec per loop alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("1"*600)' 1000 loops, best of 3: 905 usec per loop 10.2% faster for 1-digit int 39.7% faster for 9-digit int 20.5% faster for 12-digit int 21.8% faster for 15-digit int 10.2% faster for 600-digit int Test program that takes 750k ints from [0, 2**32) through stdin: Baseline: 8.114 sec (best of 5 consecutive runs) Modified: 6.774 sec (best of 5 consecutive runs) 19.8% faster NOTE: This patch causes new errors in test_array and test_compile, but it seems that these *should* be failing given the input string for long(), unless I'm missing something: ====================================================================== ERROR: test_repr (__main__.FloatTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_array.py", line 187, in test_repr self.assertEqual(a, eval(repr(a), {"array": array.array})) ValueError: invalid literal for long(): 10000000000.0 ====================================================================== ERROR: test_repr (__main__.DoubleTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_array.py", line 187, in test_repr self.assertEqual(a, eval(repr(a), {"array": array.array})) ValueError: invalid literal for long(): 10000000000.0 ---------------------------------------------------------------------- test test_compile crashed -- exceptions.ValueError: invalid literal for long(): 90000000000000. ---------------------------------------------------------------------- Comment By: funny_falcon (funny_falcon) Date: 2005-10-24 11:07 Message: Logged In: YES user_id=1290388 Instead of: overflowed: /* spool through remaining characters */ while ((c = Py_CHARMASK(*str)) != '\0') str ++; Shoold be while ((c = Py_CHARMASK(*str)) != '\0') { c = digitlookup[c]; if (c < 0 || c >= base) /* non-"digit" character */ break; str++; } And why not static int digitlookup[] = { 37, 37, 37 ...... }; and if (c >= base) break; ---------------------------------------------------------------------- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-10-24 09:41 Message: Logged In: YES user_id=1115903 I forgot to add that these results were obtained on a PIIIm 833MHz running Linux 2.4.2, GCC 3.2.2, with the Python 2.5a0 CVS source from about 8pm EST Oct 23, 2005. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1335972&group_id=5470 From noreply at sourceforge.net Mon Oct 24 17:26:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Oct 2005 08:26:19 -0700 Subject: [Patches] [ python-Patches-1335972 ] Fix for int(string, base) wrong answers (take 2) Message-ID: Patches item #1335972, was opened at 2005-10-24 00:33 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1335972&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alan McIntyre (ESRG) (alanmcintyre) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for int(string, base) wrong answers (take 2) Initial Comment: This incorporates patch #1334979, adds test cases for all the cases listed in bug #1334662, and adds test cases for evaluation of 2**32+1. There seem to be some minor speed improvements (simplistic stats shown below). Some simple performance test scripts have been included in the attached file as well. A lookup table was added for the maximum number of digits that can never overflow on a 32-bit ulong for each base. Overflow is only checked when this limit is exceeded by 1, and once the input string is determined to be too long (2 over the limit), the evaluation is halted and an overflow indication is returned. This appears to help reduce the evaluation time for very long strings (no time is wasted trying to evaluate all of it into a 32-bit ulong). Evaluation of each character has also been replaced by a lookup table. I'm not certain of the amount of speed benefit obtained from this; I added it early on and haven't had time to go back and test. It may be that it's not worth the extra static table. Baseline Python from CVS: alan at tarantula:~/python/dist/src# ./python -m timeit 'int("9")' 100000 loops, best of 3: 4 usec per loop alan at tarantula:~/python/dist/src# ./python -m timeit 'int("999999999")' 100000 loops, best of 3: 5.49 usec per loop alan at tarantula:~/python/dist/src# ./python -m timeit 'int("999999999999")' 100000 loops, best of 3: 11.8 usec per loop alan at tarantula:~/python/dist/src# ./python -m timeit 'int("999999999999999")' 100000 loops, best of 3: 13.4 usec per loop alan at tarantula:~/python/dist/src# ./python -m timeit 'int("1"*600)' 1000 loops, best of 3: 997 usec per loop Modified: alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("9")' 100000 loops, best of 3: 3.63 usec per loop alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("999999999")' 100000 loops, best of 3: 3.93 usec per loop alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("999999999999")' 100000 loops, best of 3: 9.79 usec per loop alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("999999999999999")' 100000 loops, best of 3: 11 usec per loop alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("1"*600)' 1000 loops, best of 3: 905 usec per loop 10.2% faster for 1-digit int 39.7% faster for 9-digit int 20.5% faster for 12-digit int 21.8% faster for 15-digit int 10.2% faster for 600-digit int Test program that takes 750k ints from [0, 2**32) through stdin: Baseline: 8.114 sec (best of 5 consecutive runs) Modified: 6.774 sec (best of 5 consecutive runs) 19.8% faster NOTE: This patch causes new errors in test_array and test_compile, but it seems that these *should* be failing given the input string for long(), unless I'm missing something: ====================================================================== ERROR: test_repr (__main__.FloatTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_array.py", line 187, in test_repr self.assertEqual(a, eval(repr(a), {"array": array.array})) ValueError: invalid literal for long(): 10000000000.0 ====================================================================== ERROR: test_repr (__main__.DoubleTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_array.py", line 187, in test_repr self.assertEqual(a, eval(repr(a), {"array": array.array})) ValueError: invalid literal for long(): 10000000000.0 ---------------------------------------------------------------------- test test_compile crashed -- exceptions.ValueError: invalid literal for long(): 90000000000000. ---------------------------------------------------------------------- >Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-10-24 10:26 Message: Logged In: YES user_id=1115903 Thanks, funny_falcon - that corrected the problem with the literals. I also included the change to the digit lookup table. The new patch is attached as python-mystrtoul4.tgz; it passes all tests now on my machine. ---------------------------------------------------------------------- Comment By: funny_falcon (funny_falcon) Date: 2005-10-24 02:07 Message: Logged In: YES user_id=1290388 Instead of: overflowed: /* spool through remaining characters */ while ((c = Py_CHARMASK(*str)) != '\0') str ++; Shoold be while ((c = Py_CHARMASK(*str)) != '\0') { c = digitlookup[c]; if (c < 0 || c >= base) /* non-"digit" character */ break; str++; } And why not static int digitlookup[] = { 37, 37, 37 ...... }; and if (c >= base) break; ---------------------------------------------------------------------- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-10-24 00:41 Message: Logged In: YES user_id=1115903 I forgot to add that these results were obtained on a PIIIm 833MHz running Linux 2.4.2, GCC 3.2.2, with the Python 2.5a0 CVS source from about 8pm EST Oct 23, 2005. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1335972&group_id=5470 From noreply at sourceforge.net Tue Oct 25 08:18:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Oct 2005 23:18:09 -0700 Subject: [Patches] [ python-Patches-1337051 ] remove 4 ints from PyFrameObject Message-ID: Patches item #1337051, was opened at 2005-10-24 23: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=1337051&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. 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 4 ints from PyFrameObject Initial Comment: Decreases the size of each frame object by 32 bytes. The 4 ints are already in the PyCodeObject. Well, 2 are in there directly (co_nlocals and co_stacksize). The other 2 are the tuple lengths of co_cellvars and co_freevars. I ran pybench before and after the patch. With the patch, the interpreter was .002 seconds slower, ie, noise. I get more variability than that with each recompile. Mostly the change is from using f->f_... to co->co_... ie, no difference in pointer derefs, just deref a different pointer. I don't see a good reason to duplicate the data. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1337051&group_id=5470 From noreply at sourceforge.net Tue Oct 25 18:49:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Oct 2005 09:49:06 -0700 Subject: [Patches] [ python-Patches-1337648 ] Elemental Security contribution - parsexml.py Message-ID: Patches item #1337648, was opened at 2005-10-25 12:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1337648&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: Elemental Security contribution - parsexml.py Initial Comment: This is a module I developed at Elemental for parsing and unparsing certain simple XML structures. It is licensed to the PSF using the contributor agreement. I expect that it will have to be transmogrified somewhat before it enters the standard library, and we'll need to find a good place for it in the xml package. It also needs docs. I will take care of all that in my spare time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1337648&group_id=5470 From noreply at sourceforge.net Tue Oct 25 19:52:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Oct 2005 10:52:18 -0700 Subject: [Patches] [ python-Patches-1337696 ] Elemental Security contribution - pgen2 package Message-ID: Patches item #1337696, was opened at 2005-10-25 13:52 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=1337696&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: Elemental Security contribution - pgen2 package Initial Comment: Here's the other Elemental contribution that I've promised for years. :-) This is a re-implementation of my old pgen parser generator. There's a sample showing how you define a simple grammar for Pythonic expressions. The code needs some work to make it usable; I plan to do this on my own time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1337696&group_id=5470 From noreply at sourceforge.net Tue Oct 25 20:57:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Oct 2005 11:57:08 -0700 Subject: [Patches] [ python-Patches-1337756 ] fileinput patch for bug #1336582 Message-ID: Patches item #1337756, was opened at 2005-10-25 18:57 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=1337756&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: A. Murat EREN (meren) Assigned to: Nobody/Anonymous (nobody) Summary: fileinput patch for bug #1336582 Initial Comment: Please see the bug report #1336582 (https://sourceforge.net/tracker/index.php?func=detail&aid=1336582&group_id=5470&atid=105470) Thanks in advance.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1337756&group_id=5470 From noreply at sourceforge.net Tue Oct 25 23:38:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Oct 2005 14:38:49 -0700 Subject: [Patches] [ python-Patches-1337876 ] Inconsistent use of buffer interface in string and unicode Message-ID: Patches item #1337876, was opened at 2005-10-25 22:38 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=1337876&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Phil Thompson (philthompson10) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent use of buffer interface in string and unicode Initial Comment: String and unicode objects allow objects that implement the buffer interface to be used in method arguments where a string is expected in most cases - but it's not completely consistent. Examples where the buffer interface is ignored include all the strip methods, the format methods, the just methods (for strings but not unicode) and the "in" operator (for strings but not unicode). The attached patch implements the missing bits. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1337876&group_id=5470 From noreply at sourceforge.net Wed Oct 26 12:21:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Oct 2005 03:21:59 -0700 Subject: [Patches] [ python-Patches-1338314 ] tarfile.py: fix for bug #1336623 Message-ID: Patches item #1338314, was opened at 2005-10-26 12:21 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=1338314&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py: fix for bug #1336623 Initial Comment: Old tar programs do not produce DIRTYPE members, they represent directories as REGTYPE members with a trailing slash. A workaround for these "buggy" archives is in tarfile.py since 2002, but got lost at some point in time. The attached patch revives this workaround and provides a regression test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1338314&group_id=5470 From noreply at sourceforge.net Thu Oct 27 07:29:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Oct 2005 22:29:02 -0700 Subject: [Patches] [ python-Patches-754022 ] Greatly enhanced webbrowser.py Message-ID: Patches item #754022, was opened at 2003-06-13 08:24 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Greatly enhanced webbrowser.py Initial Comment: The patch enhances webbrowser.py. First, all calls to os.system return result code, and the inverse of the code (it is ok/fail status) passed through all higher-level routines up to top-level call to open(url). This allows to check if a browser was really started. Second, the very open() modified so it is now trying to run all registered browsers in order until a browser returns 1. Third, the file can be used as a program: webbrowser.py url. Optional parameters -n allows to open the url in a new window. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-26 22:29 Message: Logged In: YES user_id=33168 There are a couple of bugs reported in 1338995 that appear to be associated with this patch. Could someone take a look and provide updates? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-10-03 07:17 Message: Logged In: YES user_id=1188172 Committed the patch as Lib/webbrowser.py r1.38, Doc/lib/libwebbrowser.tex r1.11. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-09-23 07:09 Message: Logged In: YES user_id=4799 Done. New libwebbrowser.tex.patch is about to be uploaded. Thank you! ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-09-21 20:35 Message: Logged In: YES user_id=671362 Minor nit. 11.1.1 Browser Controller Objects from the description of open method:: > If new is true, a new browser window is opened if possible. Now "new" can be 0, 1 or 2. This part also needs an update. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-09-16 00:28 Message: Logged In: YES user_id=4799 Arguable (especially compared with smtpd.py), but I am not goint to argue. Please apply the patch and let us see what other people think and say. It seems there are enough users... ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 23:32 Message: Logged In: YES user_id=1188172 Granted, but you will concur that starting a webbrowser isn't something that the command line user normally wants to do via a Python script. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-09-15 14:52 Message: Logged In: YES user_id=4799 >From setup.py: scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle', 'Lib/smtpd.py'] See, Python installs 3 scripts into /usr/{local/}bin/ - pydoc, idle and smtpd.py. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 13:48 Message: Logged In: YES user_id=1188172 No other module that can be used standalone delivers such a script. There's also the question where to install it, etc. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-09-15 13:18 Message: Logged In: YES user_id=4799 In the main(): opts, args = getopt.getopt(sys.argv[1:], 'ntd') You can remove 'd' as you've dropeed debugging prints. Are you going to drop standalone webbrowser script? Is "python -m webbrowser" enough? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 12:49 Message: Logged In: YES user_id=1188172 Ah, thanks. I had already corrected #1, but didn't look closely enough for #2. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-09-15 10:26 Message: Logged In: YES user_id=671362 Let me point out two problems: o NameError if remote_background: cmd += ' &' => if self.remote_background: # add "self." cmd += ' &' o copy and paste mistake? \lineiii{'mozilla'}{\class{Mozilla('mozilla')}}{} \lineiii{'firefox'}{\class{Mozilla('mozilla')}}{} => \lineiii{'mozilla'}{\class{Mozilla('mozilla')}}{} \lineiii{'firefox'}{\class{Mozilla('firefox')}}{} ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 01:07 Message: Logged In: YES user_id=1188172 Adding new patch (webbrowser.diff), enhanced with other patches and bugfixes here on SF. Also updated the docs with changed/added notes. Please review, I'll apply this for 2.5. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 09:33 Message: Logged In: YES user_id=1188172 I have reviewed this one too, and I really recommend to apply it for 2.5. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-30 03:02 Message: Logged In: YES user_id=4799 Added Opera controller to the doc. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-30 03:01 Message: Logged In: YES user_id=4799 Added remote functionality for Opera on Unix. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-29 00:50 Message: Logged In: YES user_id=4799 Updated documention patch - added a section about webbrowser script and its command-line options and arguments. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-29 00:48 Message: Logged In: YES user_id=4799 Changed _isexecutable() on w32 to test for executable extensions (.exe, bat) . Tested on Linux with Mozilla/links/elinks; on w32 with Mozilla/Opera/Firefox. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-28 13:25 Message: Logged In: YES user_id=9057 I have revised: libwebbrowser.tex.patch and webbrowser.py.patch. They are Ok, I recommend to apply both. Outstanding work. However, I would withdraw the webbrowser wrapper script, since the same functionality can be accomplished with: python -m webbrowser http://www.python.org ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-28 06:21 Message: Logged In: YES user_id=4799 Patch for documentation. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-28 06:19 Message: Logged In: YES user_id=4799 Minor bugfix. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 05:30 Message: Logged In: YES user_id=4799 Do not report error if the browser doesn't support tabs - just open the URL in a new window. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 05:14 Message: Logged In: YES user_id=4799 I've reworked the patch once more. I moved some common functionality into the UnixBrowser class and added two new features - Elinks launcher class (elinks supports remote commands in a manner very similar to Mozilla) and new-tab functionality for browsers that support tabbed browsing (Mozilla and elinks); a user can now run "webbrowser -t URL" to open the URL a new tab. All classes in the module are now new-style classes (except for the Error class). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 13:18 Message: Logged In: YES user_id=4799 Uploading webbrowser wrapper script. Put it into Tools/scripts directory, and add to the end of setup.py. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 13:17 Message: Logged In: YES user_id=4799 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. :-( ) ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 13:14 Message: Logged In: YES user_id=4799 I've moved script code to main() function. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-23 11:25 Message: Logged In: YES user_id=9057 I have reviewed this patch in 2005-03-23 and recommend it to be applied ! Oleg have made the comments below to Python-dev, and those must be taken into consideration while applying this patch. http://python.org/sf/728278 Close with resolution "partially applied, partially rejected". http://python.org/sf/754022 Review and apply! ;) http://python.org/sf/1166780 Close with resolution "applied". (Though it was not applied in exactly that form...) http://python.org/sf/1077979 Close with resolution "applied long ago". http://python.org/sf/1144816 Close with resolution "duplicate of 1077979". ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 10:06 Message: Logged In: YES user_id=4799 I've consolidated patches 728278, 754022, 954628, 1166780 into this single patch. Some parts of those patches were applied, some rejected, many things changed. I also added elinks support - currently it is very similar to links. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-12-07 03:23 Message: Logged In: YES user_id=4799 Applied the patch from http://python.org/sf/1077979. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-19 23:11 Message: Logged In: YES user_id=80475 Too late for Py2.4. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-10-07 00:48 Message: Logged In: YES user_id=4799 And don't forget to make it executable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 From noreply at sourceforge.net Thu Oct 27 17:37:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Oct 2005 08:37:36 -0700 Subject: [Patches] [ python-Patches-754022 ] Greatly enhanced webbrowser.py Message-ID: Patches item #754022, was opened at 2003-06-13 19:24 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Greatly enhanced webbrowser.py Initial Comment: The patch enhances webbrowser.py. First, all calls to os.system return result code, and the inverse of the code (it is ok/fail status) passed through all higher-level routines up to top-level call to open(url). This allows to check if a browser was really started. Second, the very open() modified so it is now trying to run all registered browsers in order until a browser returns 1. Third, the file can be used as a program: webbrowser.py url. Optional parameters -n allows to open the url in a new window. ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2005-10-27 19:37 Message: Logged In: YES user_id=4799 One of these two is a bug. But the orther is not. Thank you for spotting. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-27 09:29 Message: Logged In: YES user_id=33168 There are a couple of bugs reported in 1338995 that appear to be associated with this patch. Could someone take a look and provide updates? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-10-03 18:17 Message: Logged In: YES user_id=1188172 Committed the patch as Lib/webbrowser.py r1.38, Doc/lib/libwebbrowser.tex r1.11. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-09-23 18:09 Message: Logged In: YES user_id=4799 Done. New libwebbrowser.tex.patch is about to be uploaded. Thank you! ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-09-22 07:35 Message: Logged In: YES user_id=671362 Minor nit. 11.1.1 Browser Controller Objects from the description of open method:: > If new is true, a new browser window is opened if possible. Now "new" can be 0, 1 or 2. This part also needs an update. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-09-16 11:28 Message: Logged In: YES user_id=4799 Arguable (especially compared with smtpd.py), but I am not goint to argue. Please apply the patch and let us see what other people think and say. It seems there are enough users... ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-16 10:32 Message: Logged In: YES user_id=1188172 Granted, but you will concur that starting a webbrowser isn't something that the command line user normally wants to do via a Python script. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-09-16 01:52 Message: Logged In: YES user_id=4799 >From setup.py: scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle', 'Lib/smtpd.py'] See, Python installs 3 scripts into /usr/{local/}bin/ - pydoc, idle and smtpd.py. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-16 00:48 Message: Logged In: YES user_id=1188172 No other module that can be used standalone delivers such a script. There's also the question where to install it, etc. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-09-16 00:18 Message: Logged In: YES user_id=4799 In the main(): opts, args = getopt.getopt(sys.argv[1:], 'ntd') You can remove 'd' as you've dropeed debugging prints. Are you going to drop standalone webbrowser script? Is "python -m webbrowser" enough? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 23:49 Message: Logged In: YES user_id=1188172 Ah, thanks. I had already corrected #1, but didn't look closely enough for #2. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-09-15 21:26 Message: Logged In: YES user_id=671362 Let me point out two problems: o NameError if remote_background: cmd += ' &' => if self.remote_background: # add "self." cmd += ' &' o copy and paste mistake? \lineiii{'mozilla'}{\class{Mozilla('mozilla')}}{} \lineiii{'firefox'}{\class{Mozilla('mozilla')}}{} => \lineiii{'mozilla'}{\class{Mozilla('mozilla')}}{} \lineiii{'firefox'}{\class{Mozilla('firefox')}}{} ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 12:07 Message: Logged In: YES user_id=1188172 Adding new patch (webbrowser.diff), enhanced with other patches and bugfixes here on SF. Also updated the docs with changed/added notes. Please review, I'll apply this for 2.5. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 20:33 Message: Logged In: YES user_id=1188172 I have reviewed this one too, and I really recommend to apply it for 2.5. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-30 15:02 Message: Logged In: YES user_id=4799 Added Opera controller to the doc. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-30 15:01 Message: Logged In: YES user_id=4799 Added remote functionality for Opera on Unix. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-29 12:50 Message: Logged In: YES user_id=4799 Updated documention patch - added a section about webbrowser script and its command-line options and arguments. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-29 12:48 Message: Logged In: YES user_id=4799 Changed _isexecutable() on w32 to test for executable extensions (.exe, bat) . Tested on Linux with Mozilla/links/elinks; on w32 with Mozilla/Opera/Firefox. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-29 01:25 Message: Logged In: YES user_id=9057 I have revised: libwebbrowser.tex.patch and webbrowser.py.patch. They are Ok, I recommend to apply both. Outstanding work. However, I would withdraw the webbrowser wrapper script, since the same functionality can be accomplished with: python -m webbrowser http://www.python.org ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-28 18:21 Message: Logged In: YES user_id=4799 Patch for documentation. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-28 18:19 Message: Logged In: YES user_id=4799 Minor bugfix. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 16:30 Message: Logged In: YES user_id=4799 Do not report error if the browser doesn't support tabs - just open the URL in a new window. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 16:14 Message: Logged In: YES user_id=4799 I've reworked the patch once more. I moved some common functionality into the UnixBrowser class and added two new features - Elinks launcher class (elinks supports remote commands in a manner very similar to Mozilla) and new-tab functionality for browsers that support tabbed browsing (Mozilla and elinks); a user can now run "webbrowser -t URL" to open the URL a new tab. All classes in the module are now new-style classes (except for the Error class). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 00:18 Message: Logged In: YES user_id=4799 Uploading webbrowser wrapper script. Put it into Tools/scripts directory, and add to the end of setup.py. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 00:17 Message: Logged In: YES user_id=4799 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. :-( ) ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 00:14 Message: Logged In: YES user_id=4799 I've moved script code to main() function. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-23 22:25 Message: Logged In: YES user_id=9057 I have reviewed this patch in 2005-03-23 and recommend it to be applied ! Oleg have made the comments below to Python-dev, and those must be taken into consideration while applying this patch. http://python.org/sf/728278 Close with resolution "partially applied, partially rejected". http://python.org/sf/754022 Review and apply! ;) http://python.org/sf/1166780 Close with resolution "applied". (Though it was not applied in exactly that form...) http://python.org/sf/1077979 Close with resolution "applied long ago". http://python.org/sf/1144816 Close with resolution "duplicate of 1077979". ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 21:06 Message: Logged In: YES user_id=4799 I've consolidated patches 728278, 754022, 954628, 1166780 into this single patch. Some parts of those patches were applied, some rejected, many things changed. I also added elinks support - currently it is very similar to links. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-12-07 14:23 Message: Logged In: YES user_id=4799 Applied the patch from http://python.org/sf/1077979. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-20 10:11 Message: Logged In: YES user_id=80475 Too late for Py2.4. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-10-07 11:48 Message: Logged In: YES user_id=4799 And don't forget to make it executable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 From noreply at sourceforge.net Thu Oct 27 18:18:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Oct 2005 09:18:31 -0700 Subject: [Patches] [ python-Patches-1339673 ] cross compile and mingw support Message-ID: Patches item #1339673, was opened at 2005-10-27 18: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=1339673&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jan Nieuwenhuizen (janneke-sf) Assigned to: Nobody/Anonymous (nobody) Summary: cross compile and mingw support Initial Comment: The cross compile patch is similar to what I did for Guile and has still some bits from Daniel Goertzen's https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 The mingw patch is based on Matthias Kramm's https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1053879&group_id=5470 but adds autoconf tests and does have his C modifications. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339673&group_id=5470 From noreply at sourceforge.net Thu Oct 27 18:20:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Oct 2005 09:20:53 -0700 Subject: [Patches] [ python-Patches-1339673 ] cross compile and mingw support Message-ID: Patches item #1339673, was opened at 2005-10-27 18:18 Message generated for change (Comment added) made by janneke-sf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339673&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jan Nieuwenhuizen (janneke-sf) Assigned to: Nobody/Anonymous (nobody) Summary: cross compile and mingw support Initial Comment: The cross compile patch is similar to what I did for Guile and has still some bits from Daniel Goertzen's https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 The mingw patch is based on Matthias Kramm's https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1053879&group_id=5470 but adds autoconf tests and does have his C modifications. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ---------------------------------------------------------------------- >Comment By: Jan Nieuwenhuizen (janneke-sf) Date: 2005-10-27 18:20 Message: Logged In: YES user_id=1368960 .... and does NOT have his C modifications ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339673&group_id=5470 From noreply at sourceforge.net Thu Oct 27 20:23:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Oct 2005 11:23:55 -0700 Subject: [Patches] [ python-Patches-1339796 ] new function: os.path.relpath Message-ID: Patches item #1339796, was opened at 2005-10-27 20: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=1339796&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Richard Barran (rbarran) Assigned to: Nobody/Anonymous (nobody) Summary: new function: os.path.relpath Initial Comment: Hello, This patch adds a 'relpath' function to module os.path as per RFE #1309676 and also this thread: http://mail.python.org/pipermail/python-dev/2005-September/056709.html Here's a description of this function: "relpath(path, start=os.curdir) Return a relative filepath to 'path' either from the current directory or from a specified 'start' point." This patch includes Windows and *nix versions. It has been tested on Windows XP and OS/X 10.4. Note: there is no 'classic mac' version as I don't know that platform :-( Changed files are: lib/ntpath.py lib/test/test_ntpath.py lib/posixpath.py lib/test/test_posixpath.py I'll send a second patch for the documentation shortly. As this is my first submission please be gentle with me if there are any basic errors :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 From noreply at sourceforge.net Fri Oct 28 08:01:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Oct 2005 23:01:20 -0700 Subject: [Patches] [ python-Patches-1338314 ] tarfile.py: fix for bug #1336623 Message-ID: Patches item #1338314, was opened at 2005-10-26 03:21 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1338314&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py: fix for bug #1336623 Initial Comment: Old tar programs do not produce DIRTYPE members, they represent directories as REGTYPE members with a trailing slash. A workaround for these "buggy" archives is in tarfile.py since 2002, but got lost at some point in time. The attached patch revives this workaround and provides a regression test. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-27 23:01 Message: Logged In: YES user_id=33168 Thanks! Committed revision 41340. Committed revision 41341. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1338314&group_id=5470 From noreply at sourceforge.net Fri Oct 28 08:21:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Oct 2005 23:21:51 -0700 Subject: [Patches] [ python-Patches-1339796 ] new function: os.path.relpath Message-ID: Patches item #1339796, was opened at 2005-10-27 11:23 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Richard Barran (rbarran) Assigned to: Nobody/Anonymous (nobody) Summary: new function: os.path.relpath Initial Comment: Hello, This patch adds a 'relpath' function to module os.path as per RFE #1309676 and also this thread: http://mail.python.org/pipermail/python-dev/2005-September/056709.html Here's a description of this function: "relpath(path, start=os.curdir) Return a relative filepath to 'path' either from the current directory or from a specified 'start' point." This patch includes Windows and *nix versions. It has been tested on Windows XP and OS/X 10.4. Note: there is no 'classic mac' version as I don't know that platform :-( Changed files are: lib/ntpath.py lib/test/test_ntpath.py lib/posixpath.py lib/test/test_posixpath.py I'll send a second patch for the documentation shortly. As this is my first submission please be gentle with me if there are any basic errors :-) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-27 23:21 Message: Logged In: YES user_id=33168 Thanks for the patch, it's not in bad shape. Please attach the doc patch file here. It's easier to have a single patch than multiple. A couple of things about the patch. Some of these should be in PEP 8. * <> is deprecated in favor of != (didn't see this doc'd in PEP 8 though, maybe it's in another PEP) * don't add extra parentheses, e.g., (abspath(start)).split(sep) should be abspath(start).split(sep) * I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. * The for loop is a lot to swallow. It would be easier to read if you used a local variable for the min_len IMO. * I'd like to see a test case for: relpath("a", "a") * I'd like to see test cases in ntpath for paths with a drive letter * I'd like to see test cases for the exceptions raised in ntpath Another note that isn't a big deal. It's good that you made a single patch file. I think most other developers prefer the patch to start one level up. ie, don't start in Lib/, include it in the patch. I certainly prefer it this way so I don't have to cd much. It just makes development a little easier. You can attach new versions to this tracker item, but try to remember to add a description that says version # so no one reviews an older version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 From noreply at sourceforge.net Fri Oct 28 09:22:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Oct 2005 00:22:27 -0700 Subject: [Patches] [ python-Patches-1335054 ] Python 2.4.2 doesn't build with "--without-threads" Message-ID: Patches item #1335054, was opened at 2005-10-22 21:51 Message generated for change (Comment added) made by fperrad You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1335054&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gunter Ohrner (interneci) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.2 doesn't build with "--without-threads" Initial Comment: Build fix is attached. (Not yet runtime tested.) ---------------------------------------------------------------------- Comment By: Francois Perrad (fperrad) Date: 2005-10-28 09:22 Message: Logged In: YES user_id=1293818 Just an alternate patch : --- pystate.c.orig 2005-10-27 17:35:32.000000000 +0200 +++ pystate.c 2005-10-27 17:47:16.000000000 +0200 @@ -42,10 +42,14 @@ */ static PyInterpreterState *autoInterpreterState = NULL; static int autoTLSkey = 0; + +static void _PyGILState_NoteThreadState(PyThreadState* tstate); #else #define HEAD_INIT() /* Nothing */ #define HEAD_LOCK() /* Nothing */ #define HEAD_UNLOCK() /* Nothing */ + +#define _PyGILState_NoteThreadState(tstate) #endif static PyInterpreterState *interp_head = NULL; @@ -53,8 +57,6 @@ PyThreadState *_PyThreadState_Current = NULL; PyThreadFrameGetter _PyThreadState_GetFrame = NULL; -static void _PyGILState_NoteThreadState(PyThreadState* tstate); - PyInterpreterState * PyInterpreterState_New(void) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1335054&group_id=5470 From noreply at sourceforge.net Mon Oct 31 05:03:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Oct 2005 20:03:07 -0800 Subject: [Patches] [ python-Patches-1337876 ] Inconsistent use of buffer interface in string and unicode Message-ID: Patches item #1337876, was opened at 2005-10-25 14:38 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1337876&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Phil Thompson (philthompson10) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent use of buffer interface in string and unicode Initial Comment: String and unicode objects allow objects that implement the buffer interface to be used in method arguments where a string is expected in most cases - but it's not completely consistent. Examples where the buffer interface is ignored include all the strip methods, the format methods, the just methods (for strings but not unicode) and the "in" operator (for strings but not unicode). The attached patch implements the missing bits. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-30 20:03 Message: Logged In: YES user_id=33168 Are there any doc updates necessary? If so that should be included in the patch. Tests need to be added to verify objects that implement the buffer interface works for all affected code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1337876&group_id=5470 From noreply at sourceforge.net Mon Oct 31 13:54:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Oct 2005 04:54:02 -0800 Subject: [Patches] [ python-Patches-1339796 ] new function: os.path.relpath Message-ID: Patches item #1339796, was opened at 2005-10-27 20:23 Message generated for change (Comment added) made by rbarran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Richard Barran (rbarran) Assigned to: Nobody/Anonymous (nobody) Summary: new function: os.path.relpath Initial Comment: Hello, This patch adds a 'relpath' function to module os.path as per RFE #1309676 and also this thread: http://mail.python.org/pipermail/python-dev/2005-September/056709.html Here's a description of this function: "relpath(path, start=os.curdir) Return a relative filepath to 'path' either from the current directory or from a specified 'start' point." This patch includes Windows and *nix versions. It has been tested on Windows XP and OS/X 10.4. Note: there is no 'classic mac' version as I don't know that platform :-( Changed files are: lib/ntpath.py lib/test/test_ntpath.py lib/posixpath.py lib/test/test_posixpath.py I'll send a second patch for the documentation shortly. As this is my first submission please be gentle with me if there are any basic errors :-) ---------------------------------------------------------------------- >Comment By: Richard Barran (rbarran) Date: 2005-10-31 13:54 Message: Logged In: YES user_id=1207189 Hi, Thanks for all your comments; I'll amend my code & re-submit a patch. I've got a few questions for you: " I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. " By adding this check on the input I wanted to avoid this error message: >>> os.path.relpath('') Traceback (most recent call last): File "", line 1, in File "/usr/local/cvsrep/python/dist/src/Lib/posixpath.py", line 473, in relpath return os.path.join(*rel_list) TypeError: join() takes at least 1 argument (0 given) Which to me is obscure and forces you to dive into the stdlib code to understand the real cause of the problem. I'd noticed that the other functions in os.path don't seem to check input, but usually a sensible default value can be assumed (example, with abspath: if no argument is given it's sensible to use the current dir instead). So I'd like to keep the check on the input. However if you feel that it's not needed I'll remove it. " I'd like to see test cases for the exceptions raised in ntpath " When writing this I tried to maintain a consistent style with the other tests in the test_ntpath.py script which all use the "tester" function. As far as I can tell, this function doesn't allow testing of exceptions. I was tempted to use Unittest instead (as per the tests I wrote for posixpath.py) as it would allow testing of exceptions, but decided to try and maintain consistency. Do you think I should switch to using UnitTest instead? Regards, Richard ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-28 08:21 Message: Logged In: YES user_id=33168 Thanks for the patch, it's not in bad shape. Please attach the doc patch file here. It's easier to have a single patch than multiple. A couple of things about the patch. Some of these should be in PEP 8. * <> is deprecated in favor of != (didn't see this doc'd in PEP 8 though, maybe it's in another PEP) * don't add extra parentheses, e.g., (abspath(start)).split(sep) should be abspath(start).split(sep) * I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. * The for loop is a lot to swallow. It would be easier to read if you used a local variable for the min_len IMO. * I'd like to see a test case for: relpath("a", "a") * I'd like to see test cases in ntpath for paths with a drive letter * I'd like to see test cases for the exceptions raised in ntpath Another note that isn't a big deal. It's good that you made a single patch file. I think most other developers prefer the patch to start one level up. ie, don't start in Lib/, include it in the patch. I certainly prefer it this way so I don't have to cd much. It just makes development a little easier. You can attach new versions to this tracker item, but try to remember to add a description that says version # so no one reviews an older version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 From noreply at sourceforge.net Mon Oct 31 18:24:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Oct 2005 09:24:07 -0800 Subject: [Patches] [ python-Patches-1337876 ] Inconsistent use of buffer interface in string and unicode Message-ID: Patches item #1337876, was opened at 2005-10-25 22:38 Message generated for change (Comment added) made by philthompson10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1337876&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Phil Thompson (philthompson10) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent use of buffer interface in string and unicode Initial Comment: String and unicode objects allow objects that implement the buffer interface to be used in method arguments where a string is expected in most cases - but it's not completely consistent. Examples where the buffer interface is ignored include all the strip methods, the format methods, the just methods (for strings but not unicode) and the "in" operator (for strings but not unicode). The attached patch implements the missing bits. ---------------------------------------------------------------------- >Comment By: Phil Thompson (philthompson10) Date: 2005-10-31 17:24 Message: Logged In: YES user_id=1105728 I don't think any doc updates are necessary. Those methods that don't need fixing don't have any documentation that is specific to objects that implement the buffer interface. Likewise for tests. I couldn't find any existing tests for objects that implement the buffer interface - maybe because the core doesn't include any objects that can be tested. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-31 04:03 Message: Logged In: YES user_id=33168 Are there any doc updates necessary? If so that should be included in the patch. Tests need to be added to verify objects that implement the buffer interface works for all affected code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1337876&group_id=5470