From eurosemi at eurosemi.eu.com Wed Jun 1 11:40:02 2005 From: eurosemi at eurosemi.eu.com (eurosemi@eurosemi.eu.com) Date: Wed, 1 Jun 2005 05:40:02 -0400 (EDT) Subject: [Patches] Micro-electro-mechanical systems (MEMS) & MEMS Packaging Message-ID: <20050601094002.5BB2A553A62@sulux.angelbc.co.uk> European Semiconductor ---------------------- European Semiconductor Magazine is pleased to announce the publication of a major Guide on: Micro-electro-mechanical systems (MEMS) & MEMS Packaging ******************************************************** This represents an exciting opportunity to influence the European and American manufacturers through the combination of magazine, web, e-mail and event distribution. In Europe, activity in MEMS is feverish, with programmes both at the national and EU level. The sector is a rapidly growing multi-billion-dollar industry. The Cahners In-Stat Group forecasts a worldwide MEMS market of $11 billion by 2005. According to Yole Developpement and a Nexus Market survey, the total world MEMS market will certainly reach more than $5 billion in 2004 with a 25 per cent growth rate per year. Today, the driving markets for MEMS are the automotive, telecommunication and biomedical industries. Perhaps the most serious impediment to the development of commercial MEMS applications is their packaging. MEMS packaging know-how is viewed as a potential source of competitive advantage in the marketplace and treated as highly proprietary. The MEMS Guide will be: *********************** 1. Distributed with European Semiconductor Magazine (Circulation 10,000) 2. Distributed via 3 of our subscription E Mail Newsletter (36,000 circulation) 3. Distributed at Semicon West & other Semiconductor related events/conferences throughout 2005. 4. Available via our web site, reaching 40,000 unique visitors/month. Articles will include: ********************** - Business Opportunities for MEMS - Manufacturing issues Packaging/Materials - Markets Automobile, Telecommunications and Biomedical. The European Semiconductor MEMS Guide ************************************* MEMS has been a steadily growing area for the last few years and much of the manufacturing has come from the semiconductor industry. European Semiconductor has been working with the MEMS community from the very start and boasts one of the most dedicated databases for this emerging industry. The supplement will be distributed with the July issue of European Semiconductor Magazine. (10,000 circulation), with extra copies (2,500) being printed for distribution at exhibitions and conferences throughout 2005. The organisers of Semicon West will be distributing it in San Francisco. An electronic version of the full supplement will also be posted on the European Semiconductor website (which receives 40,000 unique visitors a month!). The supplement will also be promoted via three of our 12,000 strong subscription email newsletters. How can my company be involved in this European dedicated MEMS supplement? ************************************************************************** The package includes a total of a 3-page coverage. The choice is yours as to what you wish to submit in the form of editorial and whether you wish to run 1 page of editorial and 1 page of advertising, or alternatively 2 pages of editorial....... All for the exclusive price of 2,995 (British Pounds) This fixed cost includes the supplement being hosted on the European Semiconductor website, broadcast in our Eurosemi E Mail newsletter and combined with the 2,500 additional copies that will be distributed at various Trade Shows & Conferences that European Semiconductor has negotiated a presence at in 2005, including Semicon West. The cost represents a substantial saving on our normal advertising rates, and unbeatable value for your marketing spend. --------------------------------------------------------------------------------------------------- If you would like to reserve your copy of the free Guide or to enquire about advertising and promoting your product or company on the Guide please use the url below to submit your enquiry and a member of our team will get back to you. http://www.eurohs.eu.com/mems-newsletter/mems.htm#reserve --------------------------------------------------------------------------------------------------- To view the online version of this mail shot use the url below: http://www.eurohs.eu.com/mems-newsletter/mems.htm To unsubscribe from this database please email sukhi at angelbc.co.uk with the subject line - 'Eurosemi MEMS unsubscribe' From noreply at sourceforge.net Wed Jun 1 18:05:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 09:05:59 -0700 Subject: [Patches] [ python-Patches-1212837 ] Improved profiler Message-ID: Patches item #1212837, was opened at 2005-06-01 12: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=1212837&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: Open Resolution: None Priority: 5 Submitted By: Brett Rosen (bdrosen) Assigned to: Nobody/Anonymous (nobody) Summary: Improved profiler Initial Comment: I tried using both hotshot and the old python profiler and found them both to be inadequate. The old python profiler seems to give accurate results for timing, but is slow enough that it adds significant overhead to what it is measuing (approximately 10 times). Furthermore, it has no ability to give detailed stats about children. (how much of the cumulative time was taken up by each function called by a function) The hotshot profiler is much faster (profiling) adding only 30% overhead. However, it is extremely slow to load the results from the log file. It does not currently support detailed child stats, although I imagine that it could be made to do so using the information in the log file. The biggest problem with it, is that the time results seem to be highly inaccurate. (doesn't correspond to actual seconds, although they seem to be proportionally wrong) To address these shortcomings, I wrote a new profiling module. It adds about the same overhead (30%) as hotshot, but is much faster in retrieving results. It supports detailed child stats and gives accurate timing information in milliseconds. The accompanying .py module could use additional work though - because of the child stats, I was not able to reuse the stats module like hotshot does. I've included a simple test script that runs pystone for all 3 profilers (and without the profiler) to give a better idea of the differences. I've also included a dump of the output of the script running under Windows XP with python 2.4.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212837&group_id=5470 From noreply at sourceforge.net Wed Jun 1 18:25:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 09:25:21 -0700 Subject: [Patches] [ python-Patches-1144816 ] webbrowser.Netscape.open bug fix Message-ID: Patches item #1144816, was opened at 2005-02-20 15:58 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144816&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: Duplicate Priority: 5 Submitted By: Pernici Mario (pernici) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser.Netscape.open bug fix Initial Comment: My system: Python 2.4.1a0 (#2, Feb 9 2005, 12:50:04) [GCC 3.3.5 (Debian 1:3.3.5-8)] on linux2 In webbrowser.Netscape.open the command passed to the browser should not have blank spaces (see http://www.mozilla.org/unix/remote.html); due to the space in "openURL(%s, new-window)" mozilla-firefox opens my home page instead of the requested page. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 18:25 Message: Logged In: YES user_id=1188172 Closing as duplicate, as requested. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-20 02:20 Message: Logged In: YES user_id=9057 1144816 and 1077979 are the the same patch, as documented in a comment for 1144816 by Oleg Broytmann. The wrong behaviour was reported to Mozilla (unspecified version), Netscape 7.2 and Mozilla-firefox (unspecified version). I could not reproduce the problem neither with Mozilla 1.7.2 nor with Firefox 1.0.1. Nevertheless, applying the patch does not break current functionality and might fix bugs in older browsers. I recommend applying 1077979, and closing 1144816. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-19 21:22 Message: Logged In: YES user_id=4799 This is a dup of the bug http://python.org/sf/1077979 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144816&group_id=5470 From noreply at sourceforge.net Wed Jun 1 18:33:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 09:33:08 -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 (Comment added) 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: Open Resolution: None Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Fred L. Drake, Jr. (fdrake) 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-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 Wed Jun 1 19:01:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 10:01:37 -0700 Subject: [Patches] [ python-Patches-751943 ] cgitb: make more usable for 'binary-only' software Message-ID: Patches item #751943, was opened at 2003-06-10 16:31 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751943&group_id=5470 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: Closed >Resolution: Out of Date Priority: 5 Submitted By: Rob W.W. Hooft (hooft) Assigned to: Nobody/Anonymous (nobody) Summary: cgitb: make more usable for 'binary-only' software Initial Comment: I am abusing cgitb to show a traceback window for a GUI application in Qt. In such a case, the source code to the program is not always available. The stack trace is anyway useful to be submitted to the developers of the code. I attach a patch that should add some info to the HTML traceback made by cgitb in case the source file is not available. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 19:01 Message: Logged In: YES user_id=1188172 Closing, has been superseded by #1144549. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-02-23 19:32 Message: Logged In: YES user_id=1188172 see new patch #1144549 which applies on today's CVS HEAD. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-19 09:46 Message: Logged In: YES user_id=21627 Is that really generating a URL of "file://?"? It should not do that; instead, I think it should not generate a hyperlink for the file at all. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751943&group_id=5470 From noreply at sourceforge.net Wed Jun 1 19:04:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 10:04:29 -0700 Subject: [Patches] [ python-Patches-1166948 ] locale.getdefaultencoding: precedence of LANGUAGE / LANG Message-ID: Patches item #1166948, was opened at 2005-03-20 14:11 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166948&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: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: locale.getdefaultencoding: precedence of LANGUAGE / LANG Initial Comment: locale.getdefaultencoding checks first LANGUAGE, then the LC_* and LANG variables. Assume LANGUAGE is set to en:de, and LANG to en_US.utf-8, then getdefaultencoding returns the wrong encoding (ISO8859-1). AFAIK, LANGUAGE is specific to gettext (GNU extension), and IMO should not interfer with getting the correct encoding. This patch uses LANGUAGE as the choice with the lowest priority, so the other variables to determine the locale and encoding take precedence (LC_ALL, LC_CTYPE, LANG). There's another (minor) bug in the implementation: LANGUAGE is honoured even if the default locale is "C". ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 19:04 Message: Logged In: YES user_id=1188172 This file is one big patch for #1166938, #1166948 and #1166957. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166948&group_id=5470 From noreply at sourceforge.net Wed Jun 1 19:04:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 10:04:56 -0700 Subject: [Patches] [ python-Patches-1166957 ] locale: 'utf' is not a known encoding Message-ID: Patches item #1166957, was opened at 2005-03-20 14:32 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166957&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: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: locale: 'utf' is not a known encoding Initial Comment: checked with glibc-2.3.2 on a Debian/sarge system. The locale_alias and the encoding_alias tables map the encoding from utf-8, utf8 to utf, which is not a valid encoding, at least on this system. LANG=de_DE.utf-8 python -c 'import locale; locale.resetlocale()' Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 391, in resetlocale _setlocale(category, _build_localename(getdefaultlocale())) locale.Error: unsupported locale setting ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 19:04 Message: Logged In: YES user_id=1188172 This file is one big patch for #1166938, #1166948 and #1166957. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166957&group_id=5470 From noreply at sourceforge.net Wed Jun 1 20:18:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 11:18:37 -0700 Subject: [Patches] [ python-Patches-1212921 ] option to allow reload to affect existing instances Message-ID: Patches item #1212921, was opened at 2005-06-01 14: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=1212921&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: Brett Rosen (bdrosen) Assigned to: Nobody/Anonymous (nobody) Summary: option to allow reload to affect existing instances Initial Comment: One of the commonly asked questions (especially when developing GUI apps) is how do I reload a modified python file and have the existing instances automatically get the changed behavior. (this greatly speeds up the development cycle.) Unfortunately python doesn't support this without having to do the work yourself. To rectify this, I've implemented smart reloading as detailed below: Smart reloading is defined as applying modified code to your already instantiated objects on reload. Supporting smart reloading for python: Make sure that you execute python with the -r flag if you want smart reloading to work by default. The semantics of reload work as normal The normal model has been expanded by adding two special attributes to classes: 1 __pqname__ : This is used to give a hint as to our context if we are a nested class (top level classes don't need to use it) It specifies the parent hierarchy, excluding the module name. ie: class outer(object): class middle(object): __pqname__ = "outer" class inner(object): __pqname__ = "outer.middle" excluding this for inner classes can lead to confusion if you have multiple inner classes with the same name. 2 __reloadMode__ : This can have one of the 3 values - "overlay", "clear" and "disable" a) clear is the default if you are in reload mode (-r) and you don't specify anything. The behavior here is to clear the class dictionary before doing the reload of the class. b) overlay works like clear except that it doesn't clear the class dictionary first. c) disable gives you the classic python behavior and is the default if you are not in reload mode (no -r specified) When using this you almost never want to reuse class names in a module file. For example: class foo(object): ... class foo(object): ... would be bad. The second class foo replaces the first one, although with overlay it could be used as syntactic sugar for adding new methods to an existing class. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212921&group_id=5470 From noreply at sourceforge.net Wed Jun 1 20:21:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 11:21:54 -0700 Subject: [Patches] [ python-Patches-1212928 ] new patch for fixing skipitem() in getargs.c Message-ID: Patches item #1212928, was opened at 2005-06-01 20: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=1212928&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: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: new patch for fixing skipitem() in getargs.c Initial Comment: This patch subsumes #985713 and #853890. In Python/getargs.c, the function skipitem() has not been updated with new argument format codes, such as u, u#, w, w# etc. This is corrected with this patch. There are two possibilities: either all new codes are added to the switch statement (this is the file getargs-skipitem-diff), or the function is rewritten so that there is no need for a switch (because the pointer type for va_arg is irrelevant). That solution is in the file new_skipitem.c. Remaining issue: I don't know if the '(...)' formatting code should be handled here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212928&group_id=5470 From noreply at sourceforge.net Wed Jun 1 20:23:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 11:23:16 -0700 Subject: [Patches] [ python-Patches-1212928 ] new patch for fixing skipitem() in getargs.c Message-ID: Patches item #1212928, was opened at 2005-06-01 20:21 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212928&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: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: new patch for fixing skipitem() in getargs.c Initial Comment: This patch subsumes #985713 and #853890. In Python/getargs.c, the function skipitem() has not been updated with new argument format codes, such as u, u#, w, w# etc. This is corrected with this patch. There are two possibilities: either all new codes are added to the switch statement (this is the file getargs-skipitem-diff), or the function is rewritten so that there is no need for a switch (because the pointer type for va_arg is irrelevant). That solution is in the file new_skipitem.c. Remaining issue: I don't know if the '(...)' formatting code should be handled here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212928&group_id=5470 From noreply at sourceforge.net Wed Jun 1 20:24:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 11:24:29 -0700 Subject: [Patches] [ python-Patches-985713 ] bug skipping optional keyword arguments of type "w#" Message-ID: Patches item #985713, was opened at 2004-07-06 06:37 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=985713&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: Out of Date Priority: 5 Submitted By: Mark D. Roth (mdr0) Assigned to: Nobody/Anonymous (nobody) Summary: bug skipping optional keyword arguments of type "w#" Initial Comment: When using PyArg_ParseTupleAndKeywords(), if you use "w#" as an optional keyword argument, you cannot skip it and still specify an optional argument that follows it. For example, take the following function: static PyObject * dummy_func(PyObject *self, PyObject *args, PyObject *kwds) { char *string; char *buf = NULL; int bufsize = 0; unsigned short ushort = 5; static char *kwlist[] = { "string", "buffer", "ushort", NULL }; if (! PyArg_ParseTupleAndKeywords(args, kwds, "s|w#H", kwlist, &string, &buf, &bufsize, &ushort)) return NULL; printf("buf=%p, bufsize=%d, ushort=%hu\n", buf, bufsize, ushort); snprintf(buf, bufsize, "you said \%s\\n", hostname); return Py_BuildValue("s", hostname); } You can call this function successfully as follows: # don't specify buffer or ushort dummy_func("text") Or like this: # specify buffer buf = array.array('c', [' ' for x in range(0, 1023)]) dummy_func("text", buffer=buf) Or like this: # specify buffer and ushort buf = array.array('c', [' ' for x in range(0, 1023)]) dummy_func("text", buffer=buf, ushort=10) However, the following does NOT work: # specify ushort without first specifying buffer dummy_func("text", ushort=10) It fails with the following error: Traceback (most recent call last): File "", line 1, in ? TypeError: argument 2 impossible This is because the skipitem() function in Python/getargs.c does not know how to skip arguments for the "w#" format unit. I've attached a patch that fixes this. Note that skipitem() is also missing code for many other legal format units, in addition to "w" and "w#". In particular: u, u# (see patch #853890) es, es# et, et# I (capital i) k K D S U t# (tuple) It might be a good idea to refactor the code so that if/when new format units are added, the same code will handle them for both skipitem() and convertsimple(). ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 20:24 Message: Logged In: YES user_id=1188172 Closing; subsumed by #1212928. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-27 15:41 Message: Logged In: YES user_id=488897 I applied your patch and ran the Python test suite, finding no problems with this patch. I'll send a patch review to python-dev. ---------------------------------------------------------------------- Comment By: Mark D. Roth (mdr0) Date: 2004-07-06 06:42 Message: Logged In: YES user_id=994239 Whoops! You'll need to change "hostname" to "string" in that example function. I missed a few occurances of that variable when I renamed it to make the example more clear... *sheepish grin* ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=985713&group_id=5470 From noreply at sourceforge.net Wed Jun 1 20:24:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 11:24:47 -0700 Subject: [Patches] [ python-Patches-853890 ] Optional keyword unicode args not handled correctly Message-ID: Patches item #853890, was opened at 2003-12-04 09:05 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=853890&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: Out of Date Priority: 5 Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: Optional keyword unicode args not handled correctly Initial Comment: Added a case for 'u' in skipitem in getargs.c ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 20:24 Message: Logged In: YES user_id=1188172 Closing; subsumed by patch #1212928. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2005-03-29 00:04 Message: Logged In: YES user_id=771074 After taking another look at this, all the arguments it processes are pointers. Since they're not actually changed by this function, they can all be treated as void *, eliminating the case stmt altogether and effectively future-proofing the function. With as little code as is left, and since it's only called from one place, inlining it might be feasible. This leaves out validation of the format char, but I'd say it's up to whoever constructs the argument format to make sure it works correctly when you pass in a matching arg. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-03-27 09:20 Message: Logged In: YES user_id=488897 As mdr0 mentioned, skipitem misses code for several formats. This patch solves one, patch 985713 solves another one. Could you make a patch that solves all missing formats in skipitem? You can look at the convertsimple function to find all formats. ---------------------------------------------------------------------- Comment By: Mark D. Roth (mdr0) Date: 2004-07-06 06:39 Message: Logged In: YES user_id=994239 skipitem() is actually missing code for a number of other format units, in addition to "u" and "u#". See patch 985713 for more information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=853890&group_id=5470 From noreply at sourceforge.net Wed Jun 1 22:37:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 13:37:00 -0700 Subject: [Patches] [ python-Patches-1213031 ] note that os.chown can have -1 as an argument Message-ID: Patches item #1213031, was opened at 2005-06-01 22:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1213031&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: note that os.chown can have -1 as an argument Initial Comment: See bug #1200804. If you do not know the chown syscall, you can't know that a user/group id of -1 has the special meaning of "don't change". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1213031&group_id=5470 From noreply at sourceforge.net Wed Jun 1 23:50:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 14:50:13 -0700 Subject: [Patches] [ python-Patches-1194449 ] pydoc requires o.__nonzero__() == True Message-ID: Patches item #1194449, was opened at 2005-05-03 08:18 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1194449&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: Jay T Miller (jaytmiller) >Assigned to: Ka-Ping Yee (ping) Summary: pydoc requires o.__nonzero__() == True Initial Comment: On Tue, 2005-05-03 at 07:44, Nadav Horesh wrote: >>> import numarray as N > >>> a = N.array((2.3, 4.3)) > >>> N.__version__ > '1.3.1' > >>> help(a.stddev) > > Traceback (most recent call last): > File "", line 1, in -toplevel- > help(a.stddev) > File "/usr/local/lib/python2.4/site.py", line 328, in __call__ > return pydoc.help(*args, **kwds) > File "/usr/local/lib/python2.4/pydoc.py", line 1647, in __call__ > self.help(request) > File "/usr/local/lib/python2.4/pydoc.py", line 1691, in help > else: doc(request, 'Help on %s:') > File "/usr/local/lib/python2.4/pydoc.py", line 1475, in doc > pager(title % desc + '\n\n' + text.document(object, name)) > File "/usr/local/lib/python2.4/pydoc.py", line 297, in document > if inspect.isroutine(object): return self.docroutine(*args) > File "/usr/local/lib/python2.4/pydoc.py", line 1226, in docroutine > if object.im_self: > File "/usr/local/lib/python2.4/site-packages/numarray/generic.py", > line 537, in __nonzero__ > raise RuntimeError("An array doesn't make sense as a truth value. > Use any(a) or all(a).") > RuntimeError: An array doesn't make sense as a truth value. Use any(a) > or all(a). > >>> help(a.sum) > > In my opinion, this is a limitation (bug is maybe too strong) of pydoc, in that pydoc's docroutine method requires that an object be evaluable as a truth value and that the result be True. I think that's a common, but wrong, idiom. I believe it's widely recognized that array's don't make much sense as truth values because it leads to code like this: >>> a = array(5); b = array(8) >>> a & b array(0) >>> if a & b: ... print "foo!" foo! Numeric expressions like the above implicitly mean any(a & b) and appear to work but really contain subtle bugs. Hence, in numarray and Numeric3 (now or eventually), the exception: >>> if a & b: ... print "foo!" ... Traceback (most recent call last): ... RuntimeError: An array doesn't make sense as a truth value. Use any(a) or all(a). I think the pydoc docroutine() code should be changed to read: if object.im_self is not None: and that particular limitation will be removed. I submitted a patch. Regards, Todd ---------------------------------------------------------------------- Comment By: Jay T Miller (jaytmiller) Date: 2005-05-03 08:26 Message: Logged In: YES user_id=320512 The attached patch fixed my immediate problem but is untested against the Python test suites. I did not do a careful analysis for other uses of the "if o:" idiom but noted that there are many of which I'm fixing two. I only have anonymous access to Python CVS and it is unusable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1194449&group_id=5470 From noreply at sourceforge.net Thu Jun 2 00:18:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 15:18:21 -0700 Subject: [Patches] [ python-Patches-1000267 ] A BSD-style wait4 implementation Message-ID: Patches item #1000267, was opened at 2004-07-29 13:52 Message generated for change (Comment added) made by cjschr 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: Open Resolution: None Priority: 5 Submitted By: chads (cjschr) Assigned to: Nobody/Anonymous (nobody) Summary: A 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: chads (cjschr) Date: 2005-06-01 17: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 16: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 15: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 11: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 14: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 16: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 Thu Jun 2 07:17:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 22:17:39 -0700 Subject: [Patches] [ python-Patches-1184418 ] [ast] fix for 1183468: return/yield in class Message-ID: Patches item #1184418, was opened at 2005-04-16 22:01 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1184418&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: AST >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: logistix (logistix) Assigned to: Neil Schemenauer (nascheme) Summary: [ast] fix for 1183468: return/yield in class Initial Comment: I've got a patch that may or may not be acceptable. I've added a 'u_flags' field to the compiler_unit structure to track what sort of block we are in. This doesn't seem much different that it is in the current compiler, there is a boolean field called 'isfunction' that checks for this. There is a 'block_type' tracked by the symbol table entries, but I can't figure out how to harvest it. Fell free to accept or reject. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2005-06-02 05:17 Message: Logged In: YES user_id=35752 Using the block type from the symbol table seems like a better solution. I checked in a fix. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2005-04-23 19:12 Message: Logged In: YES user_id=699438 Sourceforge finally let me upload a real patch file. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2005-04-16 22:04 Message: Logged In: YES user_id=699438 Well, the patch attachment is failing due to a sf error with problems writing to an 'ArticleFile'. I'll try again later. Here it is in text for the curious: Index: python/newcompile.c ============================================= ====================== RCS file: /cvsroot/python/python/dist/src/Python/Attic/newcompile. c,v retrieving revision 1.1.2.107 diff -u -r1.1.2.107 newcompile.c --- python/newcompile.c 15 Apr 2005 01:49:23 -0000 1.1.2.107 +++ python/newcompile.c 16 Apr 2005 21:47:22 -0000 @@ -104,6 +104,13 @@ /* The following items change on entry and exit of code blocks. They must be saved and restored when returning to a block. */ + +#define UNIT_SCOPE_MODULE 1 +#define UNIT_SCOPE_CLASS 2 +#define UNIT_SCOPE_FUNCTION 4 +#define UNIT_SCOPE_LAMBDA 8 +#define UNIT_SCOPE_GENEXP 16 + struct compiler_unit { PySTEntryObject *u_ste; @@ -132,6 +139,8 @@ int u_lineno; /* the lineno for the current stmt */ bool u_lineno_set; /* boolean to indicate whether instr has been generated with current lineno */ + + unsigned int u_flags; /* only tracks type now */ }; struct compiler { @@ -159,7 +168,7 @@ int a_lineno_off; /* bytecode offset of last lineno */ }; -static int compiler_enter_scope(struct compiler *, identifier, void *, int); +static int compiler_enter_scope(struct compiler *, identifier, void *, int, unsigned int); static void compiler_free(struct compiler *); static basicblock *compiler_new_block(struct compiler *); static int compiler_next_instr(struct compiler *, basicblock *); @@ -568,7 +577,7 @@ static int compiler_enter_scope(struct compiler *c, identifier name, void *key, - int lineno) + int lineno, unsigned int flags) { struct compiler_unit *u; @@ -600,6 +609,8 @@ u->u_private = NULL; + u->u_flags = flags; + /* A little debugging output */ compiler_display_symbols(name, u->u_ste- >ste_symbols); @@ -1252,7 +1263,7 @@ if (!module) return NULL; } - if (!compiler_enter_scope(c, module, mod, 1)) + if (!compiler_enter_scope(c, module, mod, 1, UNIT_SCOPE_MODULE)) return NULL; switch (mod->kind) { case Module_kind: @@ -1396,7 +1407,7 @@ if (args->defaults) VISIT_SEQ(c, expr, args->defaults); if (!compiler_enter_scope(c, s- >v.FunctionDef.name, (void *)s, - s->lineno)) + s- >lineno,UNIT_SCOPE_FUNCTION)) return 0; st = asdl_seq_GET(s->v.FunctionDef.body, 0); @@ -1461,7 +1472,7 @@ VISIT_SEQ(c, expr, s- >v.ClassDef.bases); ADDOP_I(c, BUILD_TUPLE, n); if (!compiler_enter_scope(c, s->v.ClassDef.name, (void *)s, - s->lineno)) + s- >lineno,UNIT_SCOPE_CLASS)) return 0; c->u->u_private = s->v.ClassDef.name; Py_INCREF(c->u->u_private); @@ -1511,7 +1522,7 @@ if (args->defaults) VISIT_SEQ(c, expr, args->defaults); - if (!compiler_enter_scope(c, name, (void *)e, c->u- >u_lineno)) + if (!compiler_enter_scope(c, name, (void *)e, c->u- >u_lineno,UNIT_SCOPE_LAMBDA)) return 0; c->u->u_argcount = asdl_seq_LEN(args->args); VISIT(c, expr, e->v.Lambda.body); @@ -1992,7 +2003,7 @@ case ClassDef_kind: return compiler_class(c, s); case Return_kind: - if (c->c_nestlevel <= 1) + if (!(c->u->u_flags & UNIT_SCOPE_FUNCTION)) return compiler_error(c, "'return' outside function"); if (s->v.Return.value) { if (c->u->u_ste- >ste_generator) { @@ -2006,7 +2017,7 @@ ADDOP(c, RETURN_VALUE); break; case Yield_kind: - if (c->c_nestlevel <= 1) + if (!(c->u->u_flags & UNIT_SCOPE_FUNCTION)) return compiler_error(c, "'yield' outside function"); for (i = 0; i < c->u->u_nfblocks; i++) { if (c->u->u_fblock[i].fb_type == FINALLY_TRY) @@ -2650,7 +2661,7 @@ if (!name) return 0; - if (!compiler_enter_scope(c, name, (void *)e, c->u- >u_lineno)) + if (!compiler_enter_scope(c, name, (void *)e, c->u- >u_lineno,UNIT_SCOPE_GENEXP)) return 0; compiler_genexp_generator(c, e- >v.GeneratorExp.generators, 0, e- >v.GeneratorExp.elt); Index: lib/test/test_grammar.py ============================================= ====================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_grammar.py,v retrieving revision 1.40.8.3 diff -u -r1.40.8.3 test_grammar.py --- lib/test/test_grammar.py 7 Jan 2005 06:59:09 -0000 1.40.8.3 +++ lib/test/test_grammar.py 16 Apr 2005 21:51:39 -0000 @@ -413,6 +413,7 @@ def g2(): return 1 g1() x = g2() +check_syntax("class foo:return 1") print 'raise_stmt' # 'raise' test [',' test] try: raise RuntimeError, 'just testing' @@ -789,3 +790,7 @@ x = 10; t = False; g = ((i,j) for i in range(x) if t for j in range(x)) x = 5; t = True; verify([(i,j) for i in range(10) for j in range(5)] == list(g)) + +print 'yield_stmt' +check_syntax("class foo:yield 1") + ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1184418&group_id=5470 From noreply at sourceforge.net Thu Jun 2 07:35:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 22:35:26 -0700 Subject: [Patches] [ python-Patches-1194895 ] [AST] throw SyntaxError in "from x import y, " Message-ID: Patches item #1194895, was opened at 2005-05-04 01:23 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1194895&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: AST >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: logistix (logistix) >Assigned to: Neil Schemenauer (nascheme) Summary: [AST] throw SyntaxError in "from x import y," Initial Comment: This patch adds invalid trailing comma detection to the compiler. This is the root cause of one of the errors currently thrown in test compile. One down, one to go. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2005-06-02 05:35 Message: Logged In: YES user_id=35752 Checked in as Python/ast.c 1.1.2.63. Thanks for the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1194895&group_id=5470 From noreply at sourceforge.net Thu Jun 2 07:55:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 22:55:46 -0700 Subject: [Patches] [ python-Patches-1095541 ] fix for trivial flatten bug in astgen Message-ID: Patches item #1095541, was opened at 2005-01-04 08:15 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1095541&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.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: DSM (dsm001) >Assigned to: Neil Schemenauer (nascheme) Summary: fix for trivial flatten bug in astgen Initial Comment: The flatten in compiler.ast (from astgen) doesn't work for sublists, although the source shows it tries to: >>> compiler.ast.flatten([1,2,(3,4)]) [1, 2, 3, 4] >>> compiler.ast.flatten([1,2,[3,4]]) [1, 2, [3, 4]] The dangers of calling your lists 'list'.. (type is list check fails.) A brief glance suggests it gets called with tuples instead so I don't think the bug has any obvious consequences. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2005-06-02 05:55 Message: Logged In: YES user_id=35752 Checked in along with a little test. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-13 20:06 Message: Logged In: YES user_id=357491 Accidentally assigned this as an AST patch when it actuality it is for the compiler package. Fixed to be the proper group and assigned to Jeremy. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2005-02-12 03:00 Message: Logged In: YES user_id=51702 The patch works but it would be nice if there was a test in test_compiler.py that checks for correctness of the flattens too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1095541&group_id=5470 From noreply at sourceforge.net Thu Jun 2 15:13:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 06:13:23 -0700 Subject: [Patches] [ python-Patches-1212117 ] Add st_flags support to (l)stat function Message-ID: Patches item #1212117, was opened at 2005-06-01 01:39 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212117&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.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Diego Petten? (dgp85) >Assigned to: Hye-Shik Chang (perky) Summary: Add st_flags support to (l)stat function Initial Comment: The attached patch applied over Python 2.3.5 sources adds support for st_flags attribute of struct stat, which is used for example on FreeBSD for file's special flags. The same patch applies (with a bit of fuzzyness) over 2.4. The check is similar to the st_blocks and st_rdev in configure.in, and works in the same way. HTH, Diego Petten? ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2005-06-02 22:13 Message: Logged In: YES user_id=55188 Committed as: configure 1.472 configure.in 1.485 pyconfig.h.in 1.107 Misc/NEWS 1.1295 Modules/posixmodule.c 2.336 Doc/lib/libos.tex 1.155 You specified "Group" as Python 2.3, but it can't go Python 2.3 nor 2.4 because it's not a bug fix. :) Thank you! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212117&group_id=5470 From noreply at sourceforge.net Thu Jun 2 19:15:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 10:15:53 -0700 Subject: [Patches] [ python-Patches-1200134 ] buffer overflow in _cursesmodule.c Message-ID: Patches item #1200134, was opened at 2005-05-11 16:15 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200134&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: Open Resolution: None Priority: 5 Submitted By: Jan Michael H?lsbergen (avu) >Assigned to: A.M. Kuchling (akuchling) Summary: buffer overflow in _cursesmodule.c Initial Comment: In PyCursesWindow_GetStr(), a buffer with a fixed size of 1024 byte is used for reading the input from the user. This leads to a buffer overflow. If the user does not provide a limit to win.getstr(), wgetstr() is used, enforcing no limit at all, if the user provides a limit, it can be greater than 1024, leading to the same problem. My Patch replaces the buffer with a dynamicly allocated one, if the user does not provide a limit the maximum still is 1024. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200134&group_id=5470 From noreply at sourceforge.net Thu Jun 2 19:16:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 10:16:49 -0700 Subject: [Patches] [ python-Patches-1186781 ] Typo in Curses-Function doc Message-ID: Patches item #1186781, was opened at 2005-04-20 12:13 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1186781&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: Closed >Resolution: Fixed Priority: 5 Submitted By: grzankam (grzankam) >Assigned to: A.M. Kuchling (akuchling) Summary: Typo in Curses-Function doc Initial Comment: The description of the filter() method on says "This may be used for enabling cgaracter-at-a-time line editing without touching the rest of the screen." cgaracter should likely be character ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-02 13:16 Message: Logged In: YES user_id=11375 Fixed; thanks! ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-04-29 02:10 Message: Logged In: YES user_id=488897 Note that curses-functions.html is generated from Doc/lib/libcurses.tex, so the patch should be against this file instead of the HTML page. Otherwise, you're right of course. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1186781&group_id=5470 From noreply at sourceforge.net Thu Jun 2 19:17:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 10:17:41 -0700 Subject: [Patches] [ python-Patches-1005895 ] curses for win32 Message-ID: Patches item #1005895, was opened at 2004-08-09 07:05 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005895&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Alexandr Zamaraev (shura_zam) >Assigned to: A.M. Kuchling (akuchling) Summary: curses for win32 Initial Comment: I have paths for compile _curses module. I use compiler - mingw32 v3.3.1 curses library - Public Domain Curses (PDCurses 2.6) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005895&group_id=5470 From noreply at sourceforge.net Thu Jun 2 19:18:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 10:18:35 -0700 Subject: [Patches] [ python-Patches-721464 ] Remote debugging with pdb.py Message-ID: Patches item #721464, was opened at 2003-04-14 19:02 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=721464&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: Laurent Pelecq (lpelecq) Assigned to: Nobody/Anonymous (nobody) Summary: Remote debugging with pdb.py Initial Comment: With this patch, instances of pdb.Pdb can read and write from arbitrary file objects. It is based on similar changes that have been made to cmd.py. It basically consists of replacing print statement with calls to self.stdout.write. So it is possible for example to control the debugger from another terminal to debug curses-based applications or CGI scripts. I can provide a basic client/server debugger. This patch has been tested on Mandrake Linux 9.1 with the current CVS version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-22 13:15 Message: Logged In: YES user_id=80475 I think this is a good idea. It is past the the time for being added to 2.3. Unassigning, but will come back to it for 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=721464&group_id=5470 From noreply at sourceforge.net Thu Jun 2 19:20:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 10:20:19 -0700 Subject: [Patches] [ python-Patches-1196980 ] trivial bug in error message text Message-ID: Patches item #1196980, was opened at 2005-05-06 21:08 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196980&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: Jeff Shute (jshute) >Assigned to: Kurt B. Kaiser (kbk) Summary: trivial bug in error message text Initial Comment: This is a trivial patch to fix an error message in IDLE that refers to the Untabify menu choice as being in the Edit submenu when it is actually in the Format submenu. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196980&group_id=5470 From noreply at sourceforge.net Fri Jun 3 00:00:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 15:00:54 -0700 Subject: [Patches] [ python-Patches-1213831 ] Trivial typo in unicodedata._getcode Message-ID: Patches item #1213831, was opened at 2005-06-02 22:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1213831&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: Darek Suchojad (dsuch) Assigned to: Nobody/Anonymous (nobody) Summary: Trivial typo in unicodedata._getcode Initial Comment: Hi, I think there's a typo in unicodedata module's _getcode function. Line 823 (today's CVS build) should be if (L != -1 && V != -1 && T != -1 && pos-name == namelen) { not if (V != -1 && V != -1 && T != -1 && pos-name == namelen) { as in attached patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1213831&group_id=5470 From kyley_norman at bigpond.com Fri Jun 3 00:33:03 2005 From: kyley_norman at bigpond.com (Kyley Norman) Date: Fri, 3 Jun 2005 08:33:03 +1000 Subject: [Patches] Buy Phentermine, Viagra & More With NO PRESCRIPTION! Message-ID: <001001c567c3$0ac39280$128228cb@forman0pia7bna> Hi, Can you get phentermine to australia without having it stopped ?? Thanks K -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20050603/d56bb63e/attachment.html From noreply at sourceforge.net Fri Jun 3 02:14:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 17:14:39 -0700 Subject: [Patches] [ python-Patches-1174614 ] site enhancements Message-ID: Patches item #1174614, was opened at 2005-04-01 00:24 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1174614&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: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: site enhancements Initial Comment: The current site.py has three major deficiencies: (1) All site dirs must exist on the filesystem: Since PEP 302 (New Import Hooks) was adopted, this is not necessarily true. sys.meta_path and sys.path_hooks can have valid uses for non- existent paths. Even the standard zipimport hook supports in-zip- file paths (i.e. foo.zip/bar). (2) The directories added to sys.path by .pth files are not scanned for further .pth files. If they were, you could make life much easier on developers and users of multi-user systems. For example, it would be possible for an administrator to drop in a .pth file into the system-wide site-packages to allow users to have their own local site-packages folder. Currently, you could try this, but it wouldn't work because many packages such as PIL, Numeric, and PyObjC take advantage of .pth files during their installation. (3) To support the above use case, .pth files should be allowed to use os.path.expanduser(), so you can toss a tilde in front and do the right thing. Currently, the only way to support (2) is to use an ugly "import" pth hook. Attached is a patch to CVS HEAD that: (1) Removes the os.path.exists() / os.path.isdir() restrictions (2) Changes the .pth reader to use addsitedir() (top down) rather than sys.path.append() (3) makepath() uses os.path.expanduser() after the os.path.join(). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-02 20:14 Message: Logged In: YES user_id=6380 Hm. Looking for .pth files only in site-packages was intentional; it will slow down startup considerably if you have to do an os.listdir() of every directory on sys.path (even worse if some are on NFS!). I'd recommend against that part. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-04-07 04:33 Message: Logged In: YES user_id=92689 Patch looks good, the new functionality is great to have, recommend apply. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1174614&group_id=5470 From noreply at sourceforge.net Fri Jun 3 02:21:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 17:21:56 -0700 Subject: [Patches] [ python-Patches-1174614 ] site enhancements Message-ID: Patches item #1174614, was opened at 2005-04-01 00:24 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1174614&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: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: site enhancements Initial Comment: The current site.py has three major deficiencies: (1) All site dirs must exist on the filesystem: Since PEP 302 (New Import Hooks) was adopted, this is not necessarily true. sys.meta_path and sys.path_hooks can have valid uses for non- existent paths. Even the standard zipimport hook supports in-zip- file paths (i.e. foo.zip/bar). (2) The directories added to sys.path by .pth files are not scanned for further .pth files. If they were, you could make life much easier on developers and users of multi-user systems. For example, it would be possible for an administrator to drop in a .pth file into the system-wide site-packages to allow users to have their own local site-packages folder. Currently, you could try this, but it wouldn't work because many packages such as PIL, Numeric, and PyObjC take advantage of .pth files during their installation. (3) To support the above use case, .pth files should be allowed to use os.path.expanduser(), so you can toss a tilde in front and do the right thing. Currently, the only way to support (2) is to use an ugly "import" pth hook. Attached is a patch to CVS HEAD that: (1) Removes the os.path.exists() / os.path.isdir() restrictions (2) Changes the .pth reader to use addsitedir() (top down) rather than sys.path.append() (3) makepath() uses os.path.expanduser() after the os.path.join(). ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2005-06-02 20:21 Message: Logged In: YES user_id=139309 If you read closer, it only scans directories added by .pth files, not all directories on sys.path. This is to facilitate better encapsulation, so an admin user can create a .pth file that says "~/lib/python2.4/site- packages" and any user that starts Python will have their own site- packages dir, where .pth files work, without resorting to PYTHONPATH. This way you can use distutils to install packages into your homedir, and they will actually work as expected. PYTHONPATH is utterly disastrous if you regularly deal with several different Python interpreters. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-02 20:14 Message: Logged In: YES user_id=6380 Hm. Looking for .pth files only in site-packages was intentional; it will slow down startup considerably if you have to do an os.listdir() of every directory on sys.path (even worse if some are on NFS!). I'd recommend against that part. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-04-07 04:33 Message: Logged In: YES user_id=92689 Patch looks good, the new functionality is great to have, recommend apply. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1174614&group_id=5470 From noreply at sourceforge.net Fri Jun 3 02:28:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 17:28:45 -0700 Subject: [Patches] [ python-Patches-1174614 ] site enhancements Message-ID: Patches item #1174614, was opened at 2005-04-01 00:24 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1174614&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: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: site enhancements Initial Comment: The current site.py has three major deficiencies: (1) All site dirs must exist on the filesystem: Since PEP 302 (New Import Hooks) was adopted, this is not necessarily true. sys.meta_path and sys.path_hooks can have valid uses for non- existent paths. Even the standard zipimport hook supports in-zip- file paths (i.e. foo.zip/bar). (2) The directories added to sys.path by .pth files are not scanned for further .pth files. If they were, you could make life much easier on developers and users of multi-user systems. For example, it would be possible for an administrator to drop in a .pth file into the system-wide site-packages to allow users to have their own local site-packages folder. Currently, you could try this, but it wouldn't work because many packages such as PIL, Numeric, and PyObjC take advantage of .pth files during their installation. (3) To support the above use case, .pth files should be allowed to use os.path.expanduser(), so you can toss a tilde in front and do the right thing. Currently, the only way to support (2) is to use an ugly "import" pth hook. Attached is a patch to CVS HEAD that: (1) Removes the os.path.exists() / os.path.isdir() restrictions (2) Changes the .pth reader to use addsitedir() (top down) rather than sys.path.append() (3) makepath() uses os.path.expanduser() after the os.path.join(). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-02 20:28 Message: Logged In: YES user_id=6380 It still looks like a potentially considerable slowdown (since every directory added by a .pth file is scanned recursively), and I'm doubting the usefulness. Why should a site admin have the power to make Python search in an arbitrary place in my home directory? That could cause surprises too! When you are regularly switching between multiple Python interpreters, wouldn't it make more sense to have a few aliases (or shell scripts, .bat files, etc.) that set PYTHONPATH without exporting it? Methinks that many people have dealt with this issue *without* feeling the need to patch site.py. (BTW I'm okay with the other changes, from your description.) ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-06-02 20:21 Message: Logged In: YES user_id=139309 If you read closer, it only scans directories added by .pth files, not all directories on sys.path. This is to facilitate better encapsulation, so an admin user can create a .pth file that says "~/lib/python2.4/site- packages" and any user that starts Python will have their own site- packages dir, where .pth files work, without resorting to PYTHONPATH. This way you can use distutils to install packages into your homedir, and they will actually work as expected. PYTHONPATH is utterly disastrous if you regularly deal with several different Python interpreters. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-02 20:14 Message: Logged In: YES user_id=6380 Hm. Looking for .pth files only in site-packages was intentional; it will slow down startup considerably if you have to do an os.listdir() of every directory on sys.path (even worse if some are on NFS!). I'd recommend against that part. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-04-07 04:33 Message: Logged In: YES user_id=92689 Patch looks good, the new functionality is great to have, recommend apply. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1174614&group_id=5470 From noreply at sourceforge.net Fri Jun 3 02:36:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 17:36:02 -0700 Subject: [Patches] [ python-Patches-1213831 ] Trivial typo in unicodedata._getcode Message-ID: Patches item #1213831, was opened at 2005-06-02 17:00 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1213831&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: Darek Suchojad (dsuch) >Assigned to: Martin v. L?wis (loewis) Summary: Trivial typo in unicodedata._getcode Initial Comment: Hi, I think there's a typo in unicodedata module's _getcode function. Line 823 (today's CVS build) should be if (L != -1 && V != -1 && T != -1 && pos-name == namelen) { not if (V != -1 && V != -1 && T != -1 && pos-name == namelen) { as in attached patch. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-02 19:36 Message: Logged In: YES user_id=80475 Martin, I believe this is your code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1213831&group_id=5470 From noreply at sourceforge.net Fri Jun 3 02:41:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 17:41:18 -0700 Subject: [Patches] [ python-Patches-1174614 ] site enhancements Message-ID: Patches item #1174614, was opened at 2005-04-01 00:24 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1174614&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: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: site enhancements Initial Comment: The current site.py has three major deficiencies: (1) All site dirs must exist on the filesystem: Since PEP 302 (New Import Hooks) was adopted, this is not necessarily true. sys.meta_path and sys.path_hooks can have valid uses for non- existent paths. Even the standard zipimport hook supports in-zip- file paths (i.e. foo.zip/bar). (2) The directories added to sys.path by .pth files are not scanned for further .pth files. If they were, you could make life much easier on developers and users of multi-user systems. For example, it would be possible for an administrator to drop in a .pth file into the system-wide site-packages to allow users to have their own local site-packages folder. Currently, you could try this, but it wouldn't work because many packages such as PIL, Numeric, and PyObjC take advantage of .pth files during their installation. (3) To support the above use case, .pth files should be allowed to use os.path.expanduser(), so you can toss a tilde in front and do the right thing. Currently, the only way to support (2) is to use an ugly "import" pth hook. Attached is a patch to CVS HEAD that: (1) Removes the os.path.exists() / os.path.isdir() restrictions (2) Changes the .pth reader to use addsitedir() (top down) rather than sys.path.append() (3) makepath() uses os.path.expanduser() after the os.path.join(). ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2005-06-02 20:41 Message: Logged In: YES user_id=139309 Well in practice, .pth files aren't used a lot (most people will see maybe wxPython, PIL, and Numeric), so those three os.listdir() probably aren't going to be significant. If users are creating pth files themselves (which they probably should be doing, during development), then they'd likely take advantage of the new features. As far as power for site admins goes.. why should they have power to install Python at all? Lots of things an admin could do can cause surprises. PYTHONPATH is only useful when dealing with the command prompt directly, which is probably not the case for users of Mac OS X and Windows. It shouldn't have to be, anyway. Mac OS X doesn't even ship with a GUI interface to edit login environment variables, and the normal rc scripts aren't run in the context of LaunchServices. Also, consider the situation where a user of some shared web server is writing CGI scripts that depend on Numeric installed in their home directory. They'd need to know to add the following to the top of *EVERY* cgi script: import site import os site.addsitedir(os.path.expanduser("~/lib/python" + sys.version[:3] + "/ site-packages")) If the admin had configured a directory to put things by installing a .pth file that pointed there, they simply would have to tell users what flags to pass to distutils. For Mac OS X, there is a workaround, in that ~/Library/Python/2.X/site- packages is a second site dir, but this doesn't need to be a workaround and should be available elsewhere. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-02 20:28 Message: Logged In: YES user_id=6380 It still looks like a potentially considerable slowdown (since every directory added by a .pth file is scanned recursively), and I'm doubting the usefulness. Why should a site admin have the power to make Python search in an arbitrary place in my home directory? That could cause surprises too! When you are regularly switching between multiple Python interpreters, wouldn't it make more sense to have a few aliases (or shell scripts, .bat files, etc.) that set PYTHONPATH without exporting it? Methinks that many people have dealt with this issue *without* feeling the need to patch site.py. (BTW I'm okay with the other changes, from your description.) ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-06-02 20:21 Message: Logged In: YES user_id=139309 If you read closer, it only scans directories added by .pth files, not all directories on sys.path. This is to facilitate better encapsulation, so an admin user can create a .pth file that says "~/lib/python2.4/site- packages" and any user that starts Python will have their own site- packages dir, where .pth files work, without resorting to PYTHONPATH. This way you can use distutils to install packages into your homedir, and they will actually work as expected. PYTHONPATH is utterly disastrous if you regularly deal with several different Python interpreters. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-02 20:14 Message: Logged In: YES user_id=6380 Hm. Looking for .pth files only in site-packages was intentional; it will slow down startup considerably if you have to do an os.listdir() of every directory on sys.path (even worse if some are on NFS!). I'd recommend against that part. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-04-07 04:33 Message: Logged In: YES user_id=92689 Patch looks good, the new functionality is great to have, recommend apply. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1174614&group_id=5470 From noreply at sourceforge.net Fri Jun 3 02:43:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 17:43:21 -0700 Subject: [Patches] [ python-Patches-1174614 ] site enhancements Message-ID: Patches item #1174614, was opened at 2005-04-01 00:24 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1174614&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: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: site enhancements Initial Comment: The current site.py has three major deficiencies: (1) All site dirs must exist on the filesystem: Since PEP 302 (New Import Hooks) was adopted, this is not necessarily true. sys.meta_path and sys.path_hooks can have valid uses for non- existent paths. Even the standard zipimport hook supports in-zip- file paths (i.e. foo.zip/bar). (2) The directories added to sys.path by .pth files are not scanned for further .pth files. If they were, you could make life much easier on developers and users of multi-user systems. For example, it would be possible for an administrator to drop in a .pth file into the system-wide site-packages to allow users to have their own local site-packages folder. Currently, you could try this, but it wouldn't work because many packages such as PIL, Numeric, and PyObjC take advantage of .pth files during their installation. (3) To support the above use case, .pth files should be allowed to use os.path.expanduser(), so you can toss a tilde in front and do the right thing. Currently, the only way to support (2) is to use an ugly "import" pth hook. Attached is a patch to CVS HEAD that: (1) Removes the os.path.exists() / os.path.isdir() restrictions (2) Changes the .pth reader to use addsitedir() (top down) rather than sys.path.append() (3) makepath() uses os.path.expanduser() after the os.path.join(). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-02 20:43 Message: Logged In: YES user_id=6380 Sorry, I'm still -1, but I don't have the time to discuss it further. All your examples seem to be Mac OS X based; perhaps you can come up with a Mac OS X specific solution? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-06-02 20:41 Message: Logged In: YES user_id=139309 Well in practice, .pth files aren't used a lot (most people will see maybe wxPython, PIL, and Numeric), so those three os.listdir() probably aren't going to be significant. If users are creating pth files themselves (which they probably should be doing, during development), then they'd likely take advantage of the new features. As far as power for site admins goes.. why should they have power to install Python at all? Lots of things an admin could do can cause surprises. PYTHONPATH is only useful when dealing with the command prompt directly, which is probably not the case for users of Mac OS X and Windows. It shouldn't have to be, anyway. Mac OS X doesn't even ship with a GUI interface to edit login environment variables, and the normal rc scripts aren't run in the context of LaunchServices. Also, consider the situation where a user of some shared web server is writing CGI scripts that depend on Numeric installed in their home directory. They'd need to know to add the following to the top of *EVERY* cgi script: import site import os site.addsitedir(os.path.expanduser("~/lib/python" + sys.version[:3] + "/ site-packages")) If the admin had configured a directory to put things by installing a .pth file that pointed there, they simply would have to tell users what flags to pass to distutils. For Mac OS X, there is a workaround, in that ~/Library/Python/2.X/site- packages is a second site dir, but this doesn't need to be a workaround and should be available elsewhere. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-02 20:28 Message: Logged In: YES user_id=6380 It still looks like a potentially considerable slowdown (since every directory added by a .pth file is scanned recursively), and I'm doubting the usefulness. Why should a site admin have the power to make Python search in an arbitrary place in my home directory? That could cause surprises too! When you are regularly switching between multiple Python interpreters, wouldn't it make more sense to have a few aliases (or shell scripts, .bat files, etc.) that set PYTHONPATH without exporting it? Methinks that many people have dealt with this issue *without* feeling the need to patch site.py. (BTW I'm okay with the other changes, from your description.) ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-06-02 20:21 Message: Logged In: YES user_id=139309 If you read closer, it only scans directories added by .pth files, not all directories on sys.path. This is to facilitate better encapsulation, so an admin user can create a .pth file that says "~/lib/python2.4/site- packages" and any user that starts Python will have their own site- packages dir, where .pth files work, without resorting to PYTHONPATH. This way you can use distutils to install packages into your homedir, and they will actually work as expected. PYTHONPATH is utterly disastrous if you regularly deal with several different Python interpreters. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-02 20:14 Message: Logged In: YES user_id=6380 Hm. Looking for .pth files only in site-packages was intentional; it will slow down startup considerably if you have to do an os.listdir() of every directory on sys.path (even worse if some are on NFS!). I'd recommend against that part. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-04-07 04:33 Message: Logged In: YES user_id=92689 Patch looks good, the new functionality is great to have, recommend apply. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1174614&group_id=5470 From noreply at sourceforge.net Fri Jun 3 02:44:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 17:44:43 -0700 Subject: [Patches] [ python-Patches-1174614 ] site enhancements Message-ID: Patches item #1174614, was opened at 2005-04-01 00:24 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1174614&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: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: site enhancements Initial Comment: The current site.py has three major deficiencies: (1) All site dirs must exist on the filesystem: Since PEP 302 (New Import Hooks) was adopted, this is not necessarily true. sys.meta_path and sys.path_hooks can have valid uses for non- existent paths. Even the standard zipimport hook supports in-zip- file paths (i.e. foo.zip/bar). (2) The directories added to sys.path by .pth files are not scanned for further .pth files. If they were, you could make life much easier on developers and users of multi-user systems. For example, it would be possible for an administrator to drop in a .pth file into the system-wide site-packages to allow users to have their own local site-packages folder. Currently, you could try this, but it wouldn't work because many packages such as PIL, Numeric, and PyObjC take advantage of .pth files during their installation. (3) To support the above use case, .pth files should be allowed to use os.path.expanduser(), so you can toss a tilde in front and do the right thing. Currently, the only way to support (2) is to use an ugly "import" pth hook. Attached is a patch to CVS HEAD that: (1) Removes the os.path.exists() / os.path.isdir() restrictions (2) Changes the .pth reader to use addsitedir() (top down) rather than sys.path.append() (3) makepath() uses os.path.expanduser() after the os.path.join(). ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2005-06-02 20:44 Message: Logged In: YES user_id=139309 Did you read my whole comment? I did come up with an example that is not Mac OS X based: CGIs on a web server. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-02 20:43 Message: Logged In: YES user_id=6380 Sorry, I'm still -1, but I don't have the time to discuss it further. All your examples seem to be Mac OS X based; perhaps you can come up with a Mac OS X specific solution? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-06-02 20:41 Message: Logged In: YES user_id=139309 Well in practice, .pth files aren't used a lot (most people will see maybe wxPython, PIL, and Numeric), so those three os.listdir() probably aren't going to be significant. If users are creating pth files themselves (which they probably should be doing, during development), then they'd likely take advantage of the new features. As far as power for site admins goes.. why should they have power to install Python at all? Lots of things an admin could do can cause surprises. PYTHONPATH is only useful when dealing with the command prompt directly, which is probably not the case for users of Mac OS X and Windows. It shouldn't have to be, anyway. Mac OS X doesn't even ship with a GUI interface to edit login environment variables, and the normal rc scripts aren't run in the context of LaunchServices. Also, consider the situation where a user of some shared web server is writing CGI scripts that depend on Numeric installed in their home directory. They'd need to know to add the following to the top of *EVERY* cgi script: import site import os site.addsitedir(os.path.expanduser("~/lib/python" + sys.version[:3] + "/ site-packages")) If the admin had configured a directory to put things by installing a .pth file that pointed there, they simply would have to tell users what flags to pass to distutils. For Mac OS X, there is a workaround, in that ~/Library/Python/2.X/site- packages is a second site dir, but this doesn't need to be a workaround and should be available elsewhere. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-02 20:28 Message: Logged In: YES user_id=6380 It still looks like a potentially considerable slowdown (since every directory added by a .pth file is scanned recursively), and I'm doubting the usefulness. Why should a site admin have the power to make Python search in an arbitrary place in my home directory? That could cause surprises too! When you are regularly switching between multiple Python interpreters, wouldn't it make more sense to have a few aliases (or shell scripts, .bat files, etc.) that set PYTHONPATH without exporting it? Methinks that many people have dealt with this issue *without* feeling the need to patch site.py. (BTW I'm okay with the other changes, from your description.) ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-06-02 20:21 Message: Logged In: YES user_id=139309 If you read closer, it only scans directories added by .pth files, not all directories on sys.path. This is to facilitate better encapsulation, so an admin user can create a .pth file that says "~/lib/python2.4/site- packages" and any user that starts Python will have their own site- packages dir, where .pth files work, without resorting to PYTHONPATH. This way you can use distutils to install packages into your homedir, and they will actually work as expected. PYTHONPATH is utterly disastrous if you regularly deal with several different Python interpreters. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-02 20:14 Message: Logged In: YES user_id=6380 Hm. Looking for .pth files only in site-packages was intentional; it will slow down startup considerably if you have to do an os.listdir() of every directory on sys.path (even worse if some are on NFS!). I'd recommend against that part. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-04-07 04:33 Message: Logged In: YES user_id=92689 Patch looks good, the new functionality is great to have, recommend apply. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1174614&group_id=5470 From noreply at sourceforge.net Fri Jun 3 02:49:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 17:49:19 -0700 Subject: [Patches] [ python-Patches-1174614 ] site enhancements Message-ID: Patches item #1174614, was opened at 2005-04-01 00:24 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1174614&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: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: site enhancements Initial Comment: The current site.py has three major deficiencies: (1) All site dirs must exist on the filesystem: Since PEP 302 (New Import Hooks) was adopted, this is not necessarily true. sys.meta_path and sys.path_hooks can have valid uses for non- existent paths. Even the standard zipimport hook supports in-zip- file paths (i.e. foo.zip/bar). (2) The directories added to sys.path by .pth files are not scanned for further .pth files. If they were, you could make life much easier on developers and users of multi-user systems. For example, it would be possible for an administrator to drop in a .pth file into the system-wide site-packages to allow users to have their own local site-packages folder. Currently, you could try this, but it wouldn't work because many packages such as PIL, Numeric, and PyObjC take advantage of .pth files during their installation. (3) To support the above use case, .pth files should be allowed to use os.path.expanduser(), so you can toss a tilde in front and do the right thing. Currently, the only way to support (2) is to use an ugly "import" pth hook. Attached is a patch to CVS HEAD that: (1) Removes the os.path.exists() / os.path.isdir() restrictions (2) Changes the .pth reader to use addsitedir() (top down) rather than sys.path.append() (3) makepath() uses os.path.expanduser() after the os.path.join(). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-02 20:49 Message: Logged In: YES user_id=6380 Do such shared web servers really exist? It sounds like an invitation to being hacked to me. Given that this is a last resort (it would make more sense to petition the ISP to install Numeric) I don't see that patching sys.path at the top of the cgi script is so bad. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-06-02 20:44 Message: Logged In: YES user_id=139309 Did you read my whole comment? I did come up with an example that is not Mac OS X based: CGIs on a web server. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-02 20:43 Message: Logged In: YES user_id=6380 Sorry, I'm still -1, but I don't have the time to discuss it further. All your examples seem to be Mac OS X based; perhaps you can come up with a Mac OS X specific solution? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-06-02 20:41 Message: Logged In: YES user_id=139309 Well in practice, .pth files aren't used a lot (most people will see maybe wxPython, PIL, and Numeric), so those three os.listdir() probably aren't going to be significant. If users are creating pth files themselves (which they probably should be doing, during development), then they'd likely take advantage of the new features. As far as power for site admins goes.. why should they have power to install Python at all? Lots of things an admin could do can cause surprises. PYTHONPATH is only useful when dealing with the command prompt directly, which is probably not the case for users of Mac OS X and Windows. It shouldn't have to be, anyway. Mac OS X doesn't even ship with a GUI interface to edit login environment variables, and the normal rc scripts aren't run in the context of LaunchServices. Also, consider the situation where a user of some shared web server is writing CGI scripts that depend on Numeric installed in their home directory. They'd need to know to add the following to the top of *EVERY* cgi script: import site import os site.addsitedir(os.path.expanduser("~/lib/python" + sys.version[:3] + "/ site-packages")) If the admin had configured a directory to put things by installing a .pth file that pointed there, they simply would have to tell users what flags to pass to distutils. For Mac OS X, there is a workaround, in that ~/Library/Python/2.X/site- packages is a second site dir, but this doesn't need to be a workaround and should be available elsewhere. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-02 20:28 Message: Logged In: YES user_id=6380 It still looks like a potentially considerable slowdown (since every directory added by a .pth file is scanned recursively), and I'm doubting the usefulness. Why should a site admin have the power to make Python search in an arbitrary place in my home directory? That could cause surprises too! When you are regularly switching between multiple Python interpreters, wouldn't it make more sense to have a few aliases (or shell scripts, .bat files, etc.) that set PYTHONPATH without exporting it? Methinks that many people have dealt with this issue *without* feeling the need to patch site.py. (BTW I'm okay with the other changes, from your description.) ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-06-02 20:21 Message: Logged In: YES user_id=139309 If you read closer, it only scans directories added by .pth files, not all directories on sys.path. This is to facilitate better encapsulation, so an admin user can create a .pth file that says "~/lib/python2.4/site- packages" and any user that starts Python will have their own site- packages dir, where .pth files work, without resorting to PYTHONPATH. This way you can use distutils to install packages into your homedir, and they will actually work as expected. PYTHONPATH is utterly disastrous if you regularly deal with several different Python interpreters. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-02 20:14 Message: Logged In: YES user_id=6380 Hm. Looking for .pth files only in site-packages was intentional; it will slow down startup considerably if you have to do an os.listdir() of every directory on sys.path (even worse if some are on NFS!). I'd recommend against that part. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-04-07 04:33 Message: Logged In: YES user_id=92689 Patch looks good, the new functionality is great to have, recommend apply. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1174614&group_id=5470 From noreply at sourceforge.net Fri Jun 3 02:52:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 17:52:28 -0700 Subject: [Patches] [ python-Patches-1174614 ] site enhancements Message-ID: Patches item #1174614, was opened at 2005-04-01 00:24 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1174614&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: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: site enhancements Initial Comment: The current site.py has three major deficiencies: (1) All site dirs must exist on the filesystem: Since PEP 302 (New Import Hooks) was adopted, this is not necessarily true. sys.meta_path and sys.path_hooks can have valid uses for non- existent paths. Even the standard zipimport hook supports in-zip- file paths (i.e. foo.zip/bar). (2) The directories added to sys.path by .pth files are not scanned for further .pth files. If they were, you could make life much easier on developers and users of multi-user systems. For example, it would be possible for an administrator to drop in a .pth file into the system-wide site-packages to allow users to have their own local site-packages folder. Currently, you could try this, but it wouldn't work because many packages such as PIL, Numeric, and PyObjC take advantage of .pth files during their installation. (3) To support the above use case, .pth files should be allowed to use os.path.expanduser(), so you can toss a tilde in front and do the right thing. Currently, the only way to support (2) is to use an ugly "import" pth hook. Attached is a patch to CVS HEAD that: (1) Removes the os.path.exists() / os.path.isdir() restrictions (2) Changes the .pth reader to use addsitedir() (top down) rather than sys.path.append() (3) makepath() uses os.path.expanduser() after the os.path.join(). ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2005-06-02 20:52 Message: Logged In: YES user_id=139309 And if the listdir performance is the only killer, the "recursive site" protocol could be changed slightly -- it could depend on the existence of some file (e.g. "python-site"), so the os.listdir() turns into a false os.path.exists() in the general case (where it is not intended to be added as another site directory). Alternatively, some token in the .pth file could say "this points to another site dir". Currently that (undocumented) token actually exists, but it looks like this: import site; site.addsitedir("....") ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-02 20:49 Message: Logged In: YES user_id=6380 Do such shared web servers really exist? It sounds like an invitation to being hacked to me. Given that this is a last resort (it would make more sense to petition the ISP to install Numeric) I don't see that patching sys.path at the top of the cgi script is so bad. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-06-02 20:44 Message: Logged In: YES user_id=139309 Did you read my whole comment? I did come up with an example that is not Mac OS X based: CGIs on a web server. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-02 20:43 Message: Logged In: YES user_id=6380 Sorry, I'm still -1, but I don't have the time to discuss it further. All your examples seem to be Mac OS X based; perhaps you can come up with a Mac OS X specific solution? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-06-02 20:41 Message: Logged In: YES user_id=139309 Well in practice, .pth files aren't used a lot (most people will see maybe wxPython, PIL, and Numeric), so those three os.listdir() probably aren't going to be significant. If users are creating pth files themselves (which they probably should be doing, during development), then they'd likely take advantage of the new features. As far as power for site admins goes.. why should they have power to install Python at all? Lots of things an admin could do can cause surprises. PYTHONPATH is only useful when dealing with the command prompt directly, which is probably not the case for users of Mac OS X and Windows. It shouldn't have to be, anyway. Mac OS X doesn't even ship with a GUI interface to edit login environment variables, and the normal rc scripts aren't run in the context of LaunchServices. Also, consider the situation where a user of some shared web server is writing CGI scripts that depend on Numeric installed in their home directory. They'd need to know to add the following to the top of *EVERY* cgi script: import site import os site.addsitedir(os.path.expanduser("~/lib/python" + sys.version[:3] + "/ site-packages")) If the admin had configured a directory to put things by installing a .pth file that pointed there, they simply would have to tell users what flags to pass to distutils. For Mac OS X, there is a workaround, in that ~/Library/Python/2.X/site- packages is a second site dir, but this doesn't need to be a workaround and should be available elsewhere. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-02 20:28 Message: Logged In: YES user_id=6380 It still looks like a potentially considerable slowdown (since every directory added by a .pth file is scanned recursively), and I'm doubting the usefulness. Why should a site admin have the power to make Python search in an arbitrary place in my home directory? That could cause surprises too! When you are regularly switching between multiple Python interpreters, wouldn't it make more sense to have a few aliases (or shell scripts, .bat files, etc.) that set PYTHONPATH without exporting it? Methinks that many people have dealt with this issue *without* feeling the need to patch site.py. (BTW I'm okay with the other changes, from your description.) ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-06-02 20:21 Message: Logged In: YES user_id=139309 If you read closer, it only scans directories added by .pth files, not all directories on sys.path. This is to facilitate better encapsulation, so an admin user can create a .pth file that says "~/lib/python2.4/site- packages" and any user that starts Python will have their own site- packages dir, where .pth files work, without resorting to PYTHONPATH. This way you can use distutils to install packages into your homedir, and they will actually work as expected. PYTHONPATH is utterly disastrous if you regularly deal with several different Python interpreters. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-02 20:14 Message: Logged In: YES user_id=6380 Hm. Looking for .pth files only in site-packages was intentional; it will slow down startup considerably if you have to do an os.listdir() of every directory on sys.path (even worse if some are on NFS!). I'd recommend against that part. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-04-07 04:33 Message: Logged In: YES user_id=92689 Patch looks good, the new functionality is great to have, recommend apply. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1174614&group_id=5470 From noreply at sourceforge.net Fri Jun 3 02:57:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 17:57:00 -0700 Subject: [Patches] [ python-Patches-1174614 ] site enhancements Message-ID: Patches item #1174614, was opened at 2005-04-01 00:24 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1174614&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: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: site enhancements Initial Comment: The current site.py has three major deficiencies: (1) All site dirs must exist on the filesystem: Since PEP 302 (New Import Hooks) was adopted, this is not necessarily true. sys.meta_path and sys.path_hooks can have valid uses for non- existent paths. Even the standard zipimport hook supports in-zip- file paths (i.e. foo.zip/bar). (2) The directories added to sys.path by .pth files are not scanned for further .pth files. If they were, you could make life much easier on developers and users of multi-user systems. For example, it would be possible for an administrator to drop in a .pth file into the system-wide site-packages to allow users to have their own local site-packages folder. Currently, you could try this, but it wouldn't work because many packages such as PIL, Numeric, and PyObjC take advantage of .pth files during their installation. (3) To support the above use case, .pth files should be allowed to use os.path.expanduser(), so you can toss a tilde in front and do the right thing. Currently, the only way to support (2) is to use an ugly "import" pth hook. Attached is a patch to CVS HEAD that: (1) Removes the os.path.exists() / os.path.isdir() restrictions (2) Changes the .pth reader to use addsitedir() (top down) rather than sys.path.append() (3) makepath() uses os.path.expanduser() after the os.path.join(). ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2005-06-02 20:57 Message: Logged In: YES user_id=139309 Such shared web servers do exist, and are actually quite common for low-cost hosting (i.e. pythonmac.org is sitting on one of these right now - dreamhost.com). However, they setuid first so that they are not a security hole waiting to happen. This is done with Apache using the suEXEC module . Petitioning the ISP to go through the trouble of auditing and installing some package for all users doesn't do you much good if you're trying to get something up and running that day. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-06-02 20:52 Message: Logged In: YES user_id=139309 And if the listdir performance is the only killer, the "recursive site" protocol could be changed slightly -- it could depend on the existence of some file (e.g. "python-site"), so the os.listdir() turns into a false os.path.exists() in the general case (where it is not intended to be added as another site directory). Alternatively, some token in the .pth file could say "this points to another site dir". Currently that (undocumented) token actually exists, but it looks like this: import site; site.addsitedir("....") ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-02 20:49 Message: Logged In: YES user_id=6380 Do such shared web servers really exist? It sounds like an invitation to being hacked to me. Given that this is a last resort (it would make more sense to petition the ISP to install Numeric) I don't see that patching sys.path at the top of the cgi script is so bad. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-06-02 20:44 Message: Logged In: YES user_id=139309 Did you read my whole comment? I did come up with an example that is not Mac OS X based: CGIs on a web server. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-02 20:43 Message: Logged In: YES user_id=6380 Sorry, I'm still -1, but I don't have the time to discuss it further. All your examples seem to be Mac OS X based; perhaps you can come up with a Mac OS X specific solution? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-06-02 20:41 Message: Logged In: YES user_id=139309 Well in practice, .pth files aren't used a lot (most people will see maybe wxPython, PIL, and Numeric), so those three os.listdir() probably aren't going to be significant. If users are creating pth files themselves (which they probably should be doing, during development), then they'd likely take advantage of the new features. As far as power for site admins goes.. why should they have power to install Python at all? Lots of things an admin could do can cause surprises. PYTHONPATH is only useful when dealing with the command prompt directly, which is probably not the case for users of Mac OS X and Windows. It shouldn't have to be, anyway. Mac OS X doesn't even ship with a GUI interface to edit login environment variables, and the normal rc scripts aren't run in the context of LaunchServices. Also, consider the situation where a user of some shared web server is writing CGI scripts that depend on Numeric installed in their home directory. They'd need to know to add the following to the top of *EVERY* cgi script: import site import os site.addsitedir(os.path.expanduser("~/lib/python" + sys.version[:3] + "/ site-packages")) If the admin had configured a directory to put things by installing a .pth file that pointed there, they simply would have to tell users what flags to pass to distutils. For Mac OS X, there is a workaround, in that ~/Library/Python/2.X/site- packages is a second site dir, but this doesn't need to be a workaround and should be available elsewhere. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-02 20:28 Message: Logged In: YES user_id=6380 It still looks like a potentially considerable slowdown (since every directory added by a .pth file is scanned recursively), and I'm doubting the usefulness. Why should a site admin have the power to make Python search in an arbitrary place in my home directory? That could cause surprises too! When you are regularly switching between multiple Python interpreters, wouldn't it make more sense to have a few aliases (or shell scripts, .bat files, etc.) that set PYTHONPATH without exporting it? Methinks that many people have dealt with this issue *without* feeling the need to patch site.py. (BTW I'm okay with the other changes, from your description.) ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-06-02 20:21 Message: Logged In: YES user_id=139309 If you read closer, it only scans directories added by .pth files, not all directories on sys.path. This is to facilitate better encapsulation, so an admin user can create a .pth file that says "~/lib/python2.4/site- packages" and any user that starts Python will have their own site- packages dir, where .pth files work, without resorting to PYTHONPATH. This way you can use distutils to install packages into your homedir, and they will actually work as expected. PYTHONPATH is utterly disastrous if you regularly deal with several different Python interpreters. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-02 20:14 Message: Logged In: YES user_id=6380 Hm. Looking for .pth files only in site-packages was intentional; it will slow down startup considerably if you have to do an os.listdir() of every directory on sys.path (even worse if some are on NFS!). I'd recommend against that part. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-04-07 04:33 Message: Logged In: YES user_id=92689 Patch looks good, the new functionality is great to have, recommend apply. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1174614&group_id=5470 From noreply at sourceforge.net Fri Jun 3 15:49:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 06:49:58 -0700 Subject: [Patches] [ python-Patches-1209527 ] Optimization for textwrap Message-ID: Patches item #1209527, was opened at 2005-05-26 18:09 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1209527&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: Connelly (connelly) Assigned to: Greg Ward (gward) Summary: Optimization for textwrap Initial Comment: This patch speeds up the textwrap module, so that it takes O(n) time to process n chunks rather than the O(n^2) time that textwrap previously took. This makes textwrap much faster for large texts (for example, the patched version runs textwrap.fill('foo' * 100000) 80 times faster than the unpatched version). ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-06-03 08:49 Message: Logged In: YES user_id=2772 I didn't benchmark the speed increase, but I verified that on my system 'test_textwrap.py' still completes successfully. I also looked at the patch and found the change to be straightforward. However, I wonder if the speed increase would be nearly as great if collections.deque was used instead of the reversed list. Unfortunately, the textwrap module seems to intend portability with older versions of Python, which would not work if the collections module is used. ---------------------------------------------------------------------- Comment By: Connelly (connelly) Date: 2005-05-27 11:37 Message: Logged In: YES user_id=1039782 I assign the Copyright for this patch to the Python Software Foundation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1209527&group_id=5470 From noreply at sourceforge.net Fri Jun 3 16:53:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 07:53:30 -0700 Subject: [Patches] [ python-Patches-1180995 ] binary formats for marshalling floats Message-ID: Patches item #1180995, was opened at 2005-04-11 20:50 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1180995&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: Closed >Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Michael Hudson (mwh) Summary: binary formats for marshalling floats Initial Comment: This patch makes marshal.c use a binary format for floats when version > 1 using _PyFloat_Pack8, _PyFloat_Unpack8 (as suggested on python-dev). It doesn't actually update the default version yet, so you have to be explicit about it: >>> marshal.dumps(1.0, 2) 'g\x00\x00\x00\x00\x00\x00\xf0?' This almost certainly falls in the realm of platform-depedent accident -- what does frexp do with special values? -- but on my system: >>> inf = 1e308*1e308 >>> inf inf >>> marshal.dumps(inf, 2) Traceback (most recent call last): File "", line 1, in ? ValueError: unmarshallable object ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-06-03 15:53 Message: Logged In: YES user_id=6656 Checked this in as: Include/marshal.h revision: 2.15 Python/marshal.c revision: 1.83 Python/import.c revision: 2.242 Lib/test/test_marshal.py revision: 1.9 Misc/NEWS revision: 1.1297 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-14 08:53 Message: Logged In: YES user_id=6656 New patch. Main difference is updating MAGIC. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-12 18:24 Message: Logged In: YES user_id=6656 New patch. This attacks error handling in unmarshalling code objects to be more likely to reflect the real reason unmarshalling fails, and updates the default marshal version to 2. Combined with my float packing changes this gives us a much more coherent float marshalling/unmarshalling story. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-04-11 21:10 Message: Logged In: YES user_id=31435 Yes, C89 says nothing about what frexp() does in the presence of infinities, NaNs or signed zeroes. That's why whether pickling/unpickling (proto >= 1), or struct packing/unpacking (std mode), such things appears to work-- or how it fails --have always been platform-dependent accidents, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1180995&group_id=5470 From noreply at sourceforge.net Fri Jun 3 16:56:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 07:56:31 -0700 Subject: [Patches] [ python-Patches-1197218 ] test_locale fix on modern linux Message-ID: Patches item #1197218, was opened at 2005-05-07 13:58 Message generated for change (Settings changed) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1197218&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: Accepted Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) >Assigned to: Anthony Baxter (anthonybaxter) Summary: test_locale fix on modern linux Initial Comment: At least on this Linux (Ubuntu Hoary), test_locale fails because en_US is not a valid locale. en_US.UTF-8 is, tho. This patch makes the test_locale try each of en_US.UTF-8, en_US.US-ASCII, and en_US in turn, failing only if none of them work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1197218&group_id=5470 From noreply at sourceforge.net Fri Jun 3 17:49:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 08:49:39 -0700 Subject: [Patches] [ python-Patches-1177779 ] explicit sign variable for longs Message-ID: Patches item #1177779, was opened at 2005-04-06 14:47 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1177779&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: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: explicit sign variable for longs Initial Comment: This patch removes longobject.c abuse of ob_size to store the sign in favour of an explicit sign member, as mentioned on python-dev. The only other file that needed modifying is marshal.c (but the marshal format isn't changed). It doesn't touch all the various code that handles ob_size generically. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-06-03 16:49 Message: Logged In: YES user_id=6656 New patch, which updates marshal.c appropriately. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-04-14 10:34 Message: Logged In: YES user_id=4771 Tim, I don't really have the motivation nor knowledge of the long implementation, so I can't review this patch any better than you did already. Unassigned from me. My general feeling is that mwh+tim+tests is quite safe already :-) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-04-11 10:38 Message: Logged In: YES user_id=4771 Sorry, I tested the memory overhead of adding an "int" field long_sign, and forgot that the digits were "short". (mwh, your patch #2 forgot to rename "sign" in marshal.c) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-11 00:44 Message: Logged In: YES user_id=6656 Good, I didn't really understand Armin's point either :) Here's a new version of the patch that pays a bit more attention to the comments (I changed my mind over a few details while writing it, I'm not entirely surprised that clarity suffered) and renames the sign member to long_sign -- but it turns out that you could find all references by searching for "->sign"... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-04-11 00:28 Message: Logged In: YES user_id=31435 Armin, I don't understand your use case. Can you be more explicit? Best I can guess, you're using Python longs on a 32-bit box to store positive integers with bit 2**31 set. But there's no change in memory burden for those (rounds up to 24 bytes either way), so that can't be what you mean. Maybe you're using Python longs to store _all_ integers, no matter how small they are? But in that case you weren't serious about memory use to begin with. Michael, I got confused at the start of the patch. When you changed the comment SUM(for i=0 through abs(ob_size)-1) ob_digit[i] * 2**(SHIFT*i) to sign * SUM(for i=0 through ob_size) ob_digit[i] * 2**(SHIFT*i) you dropped the "-1" as well as the "abs()". That wasn't intended, was it? Was also confused by why you dropped the "zero is represented by ob_size == 0." comment. It would be very helpful to rename the new member, e.g., as "long_sign". Then it's easy to find references in the code with an editor search. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-04-08 15:20 Message: Logged In: YES user_id=4771 Unlike Tim I have a use case for lots of small longs in memory: to store unsigned machine integers. It's exactly the case where it would be nice that the extra field didn't cross the malloc 8-byte boundary. Of course, it's exactly NOT what is happening here on 32-bit machines, and this patch makes program relying on this kind of longs suddenly consume 8 extra bytes per long. Damn. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-06 14:51 Message: Logged In: YES user_id=6656 Oh, and I meant to say, it passes make test but more testing is certainly welcome -- some mistakes show up in pretty obscure ways... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1177779&group_id=5470 From noreply at sourceforge.net Fri Jun 3 20:11:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 11:11:09 -0700 Subject: [Patches] [ python-Patches-1203094 ] httplib mentions getreply instead of getresponse Message-ID: Patches item #1203094, was opened at 2005-05-16 22:03 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1203094&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: Robert Brewer (aminusfu) >Assigned to: Raymond Hettinger (rhettinger) Summary: httplib mentions getreply instead of getresponse Initial Comment: See Bug 1202475. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 20:11 Message: Logged In: YES user_id=1188172 Okay to check in? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1203094&group_id=5470 From noreply at sourceforge.net Fri Jun 3 20:12:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 11:12:41 -0700 Subject: [Patches] [ python-Patches-1180012 ] no html file for modulefinder Message-ID: Patches item #1180012, was opened at 2005-04-10 04:18 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1180012&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) >Assigned to: Raymond Hettinger (rhettinger) Summary: no html file for modulefinder Initial Comment: libmodulefinder.tex exists from 2.4 branch but html file is not created and modulefinder is not listed in Global Module Index. http://www.python.org/doc/2.4.1/modindex.html The fix is trivial. Just add \input{modulefinder} to Doc/lib/lib.tex. My only concern is where modulefinder should reside. Since its main purpose is to parse source codes, "Python Language Services" seems best. But it also seems reasonable to put it in "Python Runtime Services" along with imp or zipimport modules that also do import-related jobs. If this is intentional(the doc is just a draft and not completed yet), feel free to mark this invalid or whatever. Status of bug #914375 is still open. [modulefinder is not documented] http://www.python.org/sf/914375 ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 20:12 Message: Logged In: YES user_id=1188172 Okay to check in? ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-04-10 06:28 Message: Logged In: YES user_id=671362 My fault. \input{modulefinder} should be :: \input{libmodulefinder} ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1180012&group_id=5470 From noreply at sourceforge.net Fri Jun 3 20:25:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 11:25:59 -0700 Subject: [Patches] [ python-Patches-1197218 ] test_locale fix on modern linux Message-ID: Patches item #1197218, was opened at 2005-05-07 22:58 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1197218&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: Closed Resolution: Accepted Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Anthony Baxter (anthonybaxter) Summary: test_locale fix on modern linux Initial Comment: At least on this Linux (Ubuntu Hoary), test_locale fails because en_US is not a valid locale. en_US.UTF-8 is, tho. This patch makes the test_locale try each of en_US.UTF-8, en_US.US-ASCII, and en_US in turn, failing only if none of them work. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2005-06-04 04:25 Message: Logged In: YES user_id=29957 checked in on trunk and branch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1197218&group_id=5470 From noreply at sourceforge.net Sat Jun 4 09:33:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 00:33:00 -0700 Subject: [Patches] [ python-Patches-1173245 ] unicodedata docstrings Message-ID: Patches item #1173245, was opened at 2005-03-30 21:16 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1173245&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: Closed Resolution: Accepted Priority: 5 Submitted By: Jeremy Yallop (yallop) Assigned to: Nobody/Anonymous (nobody) Summary: unicodedata docstrings Initial Comment: Docstrings for unicodedata, extracted from the tex documentation. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2005-06-04 16:33 Message: Logged In: YES user_id=55188 URL is corrected in CVS. Thank you! Doc/lib/libunicodedata.tex 1.9 Modules/unicodedata.c 2.34 ---------------------------------------------------------------------- Comment By: Darek Suchojad (dsuch) Date: 2005-04-30 06:36 Message: Logged In: YES user_id=954779 I think the module's docstring is wrong (and so is the tex documentation, and this page too http://docs.python.org/lib/module-unicodedata.html). The URL for UnicodeData File Format 3.2.0 is http://www.unicode.org/Public/3.2-Update/UnicodeData-3.2.0.html now. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-04-05 01:32 Message: Logged In: YES user_id=55188 Committed in Modules/unicodedata.c 2.33. Thank you for the patch! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1173245&group_id=5470 From noreply at sourceforge.net Sat Jun 4 19:20:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 10:20:16 -0700 Subject: [Patches] [ python-Patches-1214879 ] Support non-file source/dest in marshal Message-ID: Patches item #1214879, was opened at 2005-06-04 12:20 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=1214879&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: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Support non-file source/dest in marshal Initial Comment: I own bug #780354. The problem is that socket.makefile() no longer returns a true file. This breaks code that had assumed it did. The marshal module is one such instance. In the above bug's corresponce Martin stated: Instead, I think the C modules that expect file objects need to be fixed. Later on Martin stated that he thought it would be fine to simply document the limitation for the marshal module. I ignored that and fixed it in the attached patch. It includes modified docs and an updated test suite. It's obviously somewhat slower than the current version when reading/writing true files. That's to be expected. I wanted to get it right first. I imagine something can be done to speed things up in the common case (run PyFile_Check() and make calls to stdio functions if it is a true file). Even if this patch is rejected, the modified test_marshal.py should probably be kept (with suitable deletions), as it refactors the individual tests into helper functions, thus avoiding a lot of code duplication and potential future cut-n-paste errors. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214879&group_id=5470 From noreply at sourceforge.net Sat Jun 4 19:45:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 10:45:10 -0700 Subject: [Patches] [ python-Patches-1214889 ] file.encoding support for file.write and file.writelines Message-ID: Patches item #1214889, was opened at 2005-06-04 19: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=1214889&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: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: file.encoding support for file.write and file.writelines Initial Comment: Here is a patch that allows Unicode strings written to a file being automatically encoded. It enables Python code to set file.encoding and obeys this encoding when writing Unicode strings with write() or writelines(). It is my first core hackery, so forgive me one leaked ref or the other. I hope I got the error handling right; it is kind of confusing... (btw: Bug #967986 will be fixed with this) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&group_id=5470 From noreply at sourceforge.net Sun Jun 5 04:16:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 19:16:57 -0700 Subject: [Patches] [ python-Patches-1207985 ] An URL for UnicodeData File Format 3.2 has changed. Message-ID: Patches item #1207985, was opened at 2005-05-25 02:12 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1207985&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: Closed Resolution: None Priority: 7 Submitted By: Darek Suchojad (dsuch) Assigned to: Martin v. L?wis (loewis) Summary: An URL for UnicodeData File Format 3.2 has changed. Initial Comment: Hello, both Modules/unicodedata.c and Doc/lib/libunicodedata.tex mention an old URL for UnicodeData File Format 3.2.0. Attached is a patch to make them correct. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2005-06-05 11:16 Message: Logged In: YES user_id=55188 Closing because the problem is corrected in CVS. (SF #1173245) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1207985&group_id=5470 From noreply at sourceforge.net Sun Jun 5 04:26:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 19:26:28 -0700 Subject: [Patches] [ python-Patches-1214889 ] file.encoding support for file.write and file.writelines Message-ID: Patches item #1214889, was opened at 2005-06-05 02:45 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&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: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: file.encoding support for file.write and file.writelines Initial Comment: Here is a patch that allows Unicode strings written to a file being automatically encoded. It enables Python code to set file.encoding and obeys this encoding when writing Unicode strings with write() or writelines(). It is my first core hackery, so forgive me one leaked ref or the other. I hope I got the error handling right; it is kind of confusing... (btw: Bug #967986 will be fixed with this) ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2005-06-05 11:26 Message: Logged In: YES user_id=55188 The idea looks good to me. I attached a revised patch fixed code style, C99-style local variable declaration and added a regrtest. I think some documentation update will be needed also. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&group_id=5470 From noreply at sourceforge.net Sun Jun 5 09:56:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Jun 2005 00:56:21 -0700 Subject: [Patches] [ python-Patches-1214889 ] file.encoding support for file.write and file.writelines Message-ID: Patches item #1214889, was opened at 2005-06-04 19:45 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&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: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: file.encoding support for file.write and file.writelines Initial Comment: Here is a patch that allows Unicode strings written to a file being automatically encoded. It enables Python code to set file.encoding and obeys this encoding when writing Unicode strings with write() or writelines(). It is my first core hackery, so forgive me one leaked ref or the other. I hope I got the error handling right; it is kind of confusing... (btw: Bug #967986 will be fixed with this) ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 09:56 Message: Logged In: YES user_id=1188172 Third revision; adds new documentation and allows Python code to set the encoding to Py_None. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-06-05 04:26 Message: Logged In: YES user_id=55188 The idea looks good to me. I attached a revised patch fixed code style, C99-style local variable declaration and added a regrtest. I think some documentation update will be needed also. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&group_id=5470 From noreply at sourceforge.net Sun Jun 5 12:27:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Jun 2005 03:27:15 -0700 Subject: [Patches] [ python-Patches-1213031 ] note that os.chown can have -1 as an argument Message-ID: Patches item #1213031, was opened at 2005-06-01 22:37 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1213031&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) >Assigned to: Raymond Hettinger (rhettinger) Summary: note that os.chown can have -1 as an argument Initial Comment: See bug #1200804. If you do not know the chown syscall, you can't know that a user/group id of -1 has the special meaning of "don't change". ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 12:27 Message: Logged In: YES user_id=1188172 Okay to check in? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1213031&group_id=5470 From noreply at sourceforge.net Sun Jun 5 14:09:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Jun 2005 05:09:31 -0700 Subject: [Patches] [ python-Patches-1214889 ] file.encoding support for file.write and file.writelines Message-ID: Patches item #1214889, was opened at 2005-06-05 02:45 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&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: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: file.encoding support for file.write and file.writelines Initial Comment: Here is a patch that allows Unicode strings written to a file being automatically encoded. It enables Python code to set file.encoding and obeys this encoding when writing Unicode strings with write() or writelines(). It is my first core hackery, so forgive me one leaked ref or the other. I hope I got the error handling right; it is kind of confusing... (btw: Bug #967986 will be fixed with this) ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-06-05 21:09 Message: Logged In: YES user_id=671362 Reinhold, libstdtypes.tex needs two fixes. \versionadded{2.3} +\versionchanged[The encoding attribute is now writable and is used +for encoding Unicode strings given to \method{write()} and +\method{writelines()}.]{ ~~~ First, versionchanged tag does not have a trailing brace and it resuls in compile error. Second(really trivial), versionchanged macro automatically appends a period at the end of the sentence(see the link [*]), so you don't need to put it by hand. Then the above line would become: +\method{writelines()}]{2.5} [*]: http://docs.python.org/doc/inline-markup.html ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 16:56 Message: Logged In: YES user_id=1188172 Third revision; adds new documentation and allows Python code to set the encoding to Py_None. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-06-05 11:26 Message: Logged In: YES user_id=55188 The idea looks good to me. I attached a revised patch fixed code style, C99-style local variable declaration and added a regrtest. I think some documentation update will be needed also. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&group_id=5470 From noreply at sourceforge.net Sun Jun 5 14:17:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Jun 2005 05:17:03 -0700 Subject: [Patches] [ python-Patches-1214889 ] file.encoding support for file.write and file.writelines Message-ID: Patches item #1214889, was opened at 2005-06-04 19:45 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&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: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: file.encoding support for file.write and file.writelines Initial Comment: Here is a patch that allows Unicode strings written to a file being automatically encoded. It enables Python code to set file.encoding and obeys this encoding when writing Unicode strings with write() or writelines(). It is my first core hackery, so forgive me one leaked ref or the other. I hope I got the error handling right; it is kind of confusing... (btw: Bug #967986 will be fixed with this) ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 14:17 Message: Logged In: YES user_id=1188172 Thanks! Corrected in patch #4. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-06-05 14:09 Message: Logged In: YES user_id=671362 Reinhold, libstdtypes.tex needs two fixes. \versionadded{2.3} +\versionchanged[The encoding attribute is now writable and is used +for encoding Unicode strings given to \method{write()} and +\method{writelines()}.]{ ~~~ First, versionchanged tag does not have a trailing brace and it resuls in compile error. Second(really trivial), versionchanged macro automatically appends a period at the end of the sentence(see the link [*]), so you don't need to put it by hand. Then the above line would become: +\method{writelines()}]{2.5} [*]: http://docs.python.org/doc/inline-markup.html ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 09:56 Message: Logged In: YES user_id=1188172 Third revision; adds new documentation and allows Python code to set the encoding to Py_None. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-06-05 04:26 Message: Logged In: YES user_id=55188 The idea looks good to me. I attached a revised patch fixed code style, C99-style local variable declaration and added a regrtest. I think some documentation update will be needed also. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&group_id=5470 From noreply at sourceforge.net Sun Jun 5 16:52:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Jun 2005 07:52:08 -0700 Subject: [Patches] [ python-Patches-1215184 ] two fileinput enhancements (fileno, openhook) Message-ID: Patches item #1215184, was opened at 2005-06-05 16: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=1215184&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: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: two fileinput enhancements (fileno, openhook) Initial Comment: These two patches enhance the fileinput module. The fileno patch adds a "fileno()" method that returns the current file number. The openhook patch adds a possibility to specify an opening hook, that is, instead of calling open(), the hook is called. This is useful, for example, for transparently decompressing gzip files, as wished in RFE #563141. Docs and tests will be added if this is welcomed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1215184&group_id=5470 From noreply at sourceforge.net Sun Jun 5 17:20:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Jun 2005 08:20:19 -0700 Subject: [Patches] [ python-Patches-1214889 ] file.encoding support for file.write and file.writelines Message-ID: Patches item #1214889, was opened at 2005-06-05 02:45 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&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: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: file.encoding support for file.write and file.writelines Initial Comment: Here is a patch that allows Unicode strings written to a file being automatically encoded. It enables Python code to set file.encoding and obeys this encoding when writing Unicode strings with write() or writelines(). It is my first core hackery, so forgive me one leaked ref or the other. I hope I got the error handling right; it is kind of confusing... (btw: Bug #967986 will be fixed with this) ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2005-06-06 00:20 Message: Logged In: YES user_id=55188 Yet another thing to fix: You can't put local namespace declarations after non-declaration statements. Because Python uses C89 as a C source code standard, you should all declarations in the top of functions only. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 21:17 Message: Logged In: YES user_id=1188172 Thanks! Corrected in patch #4. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-06-05 21:09 Message: Logged In: YES user_id=671362 Reinhold, libstdtypes.tex needs two fixes. \versionadded{2.3} +\versionchanged[The encoding attribute is now writable and is used +for encoding Unicode strings given to \method{write()} and +\method{writelines()}.]{ ~~~ First, versionchanged tag does not have a trailing brace and it resuls in compile error. Second(really trivial), versionchanged macro automatically appends a period at the end of the sentence(see the link [*]), so you don't need to put it by hand. Then the above line would become: +\method{writelines()}]{2.5} [*]: http://docs.python.org/doc/inline-markup.html ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 16:56 Message: Logged In: YES user_id=1188172 Third revision; adds new documentation and allows Python code to set the encoding to Py_None. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-06-05 11:26 Message: Logged In: YES user_id=55188 The idea looks good to me. I attached a revised patch fixed code style, C99-style local variable declaration and added a regrtest. I think some documentation update will be needed also. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&group_id=5470 From noreply at sourceforge.net Sun Jun 5 18:31:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Jun 2005 09:31:59 -0700 Subject: [Patches] [ python-Patches-1214889 ] file.encoding support for file.write and file.writelines Message-ID: Patches item #1214889, was opened at 2005-06-04 19:45 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&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: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: file.encoding support for file.write and file.writelines Initial Comment: Here is a patch that allows Unicode strings written to a file being automatically encoded. It enables Python code to set file.encoding and obeys this encoding when writing Unicode strings with write() or writelines(). It is my first core hackery, so forgive me one leaked ref or the other. I hope I got the error handling right; it is kind of confusing... (btw: Bug #967986 will be fixed with this) ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 18:31 Message: Logged In: YES user_id=1188172 Okay, put on #5. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-06-05 17:20 Message: Logged In: YES user_id=55188 Yet another thing to fix: You can't put local namespace declarations after non-declaration statements. Because Python uses C89 as a C source code standard, you should all declarations in the top of functions only. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 14:17 Message: Logged In: YES user_id=1188172 Thanks! Corrected in patch #4. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-06-05 14:09 Message: Logged In: YES user_id=671362 Reinhold, libstdtypes.tex needs two fixes. \versionadded{2.3} +\versionchanged[The encoding attribute is now writable and is used +for encoding Unicode strings given to \method{write()} and +\method{writelines()}.]{ ~~~ First, versionchanged tag does not have a trailing brace and it resuls in compile error. Second(really trivial), versionchanged macro automatically appends a period at the end of the sentence(see the link [*]), so you don't need to put it by hand. Then the above line would become: +\method{writelines()}]{2.5} [*]: http://docs.python.org/doc/inline-markup.html ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 09:56 Message: Logged In: YES user_id=1188172 Third revision; adds new documentation and allows Python code to set the encoding to Py_None. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-06-05 04:26 Message: Logged In: YES user_id=55188 The idea looks good to me. I attached a revised patch fixed code style, C99-style local variable declaration and added a regrtest. I think some documentation update will be needed also. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&group_id=5470 From noreply at sourceforge.net Wed Jun 8 11:41:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Jun 2005 02:41:50 -0700 Subject: [Patches] [ python-Patches-1216942 ] Suggested Additional Material for urllib2 docs Message-ID: Patches item #1216942, was opened at 2005-06-08 09:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1216942&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: Mike Foord (mjfoord) Assigned to: Nobody/Anonymous (nobody) Summary: Suggested Additional Material for urllib2 docs Initial Comment: This is some suggested additional material for the urllib2 docs. Particularly the part about error codes and the reason/code attributes of error objects is *missing* from the manual and needed. Also the example showing basic Authentication using password manager/handler/opener may help avoid some confusion. Alternatively you can link to my online tutorials at http://www.voidspace.org.uk/python/articles.shtml#http :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1216942&group_id=5470 From noreply at sourceforge.net Wed Jun 8 23:16:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Jun 2005 14:16:14 -0700 Subject: [Patches] [ python-Patches-1217246 ] proposed patch for tls wrapped ssl support added to smtplib Message-ID: Patches item #1217246, was opened at 2005-06-08 16:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1217246&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: Open Resolution: None Priority: 5 Submitted By: Pete G (pgreenwell) Assigned to: Nobody/Anonymous (nobody) Summary: proposed patch for tls wrapped ssl support added to smtplib Initial Comment: The current smtplib.py can only do TLS over a standard port but it does not have support for an ssl wrapped session which is usually offered on port 465. I just added a few lines to allow a true ssl socket to be created instead of a standard one. I also added a one line function to set this option on. We have many customers that use clients that can only do this type of TLS connection. Postfix and Sendmail and most others allow for this too, and I wanted to be able to write up some nagios monitoring scripts using python. This allowed me to do it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1217246&group_id=5470 From noreply at sourceforge.net Thu Jun 9 00:53:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Jun 2005 15:53:59 -0700 Subject: [Patches] [ python-Patches-1171487 ] Patch for [ 1170331 ] Error in base64.b32decode Message-ID: Patches item #1171487, was opened at 2005-03-27 14:46 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1171487&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: 6 Submitted By: logistix (logistix) >Assigned to: A.M. Kuchling (akuchling) Summary: Patch for [ 1170331 ] Error in base64.b32decode Initial Comment: base64.b32decode didn't decode some things properly. Seems to have only impacted characters with a value < 32. Attached is a fix and a new test. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-08 18:53 Message: Logged In: YES user_id=11375 Applied; thanks! I also added a test case that would have caught the bug. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2005-03-27 16:43 Message: Logged In: YES user_id=699438 Updated patch to reflect another fix. I originally thought the bug was related to cleanup of a partial quanta. It will trigger on any quanta where the initial hex value is < 0x10. When this happens part of the hex code disappears in the initial conversion and is mistakenly swallowed. The hex function that was originally used doesn't zero-pad, but the way the bit shifting works, it doesn't need to when encoding normal alpha-numeric characters, so it seemed to work correctly. This will only cause problems if you are using a character value of < 0x10 in the 0th, 4th, 8th, 12th, etc positions in the encoded string. Otherwise it'll work properly. Using "%010x" ensures that you'll get the appropriate zero-padding if necessary. Example of more broken code not covered in the original bug: >>> base64.b32decode(base64.b32encode('\x00aaa')) 'aaa' Updated patch fixes this case as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1171487&group_id=5470 From noreply at sourceforge.net Thu Jun 9 16:23:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Jun 2005 07:23:05 -0700 Subject: [Patches] [ python-Patches-1074381 ] #1074261 gzip dies on gz files with many appended headers Message-ID: Patches item #1074381, was opened at 2004-11-27 18:26 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1074381&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: Mark Eichin (eichin) >Assigned to: A.M. Kuchling (akuchling) Summary: #1074261 gzip dies on gz files with many appended headers Initial Comment: I came up with a patch after submitting the bug (which appears in 2.4rc1, as well as back as far as 2.1); there wasn't an obvious way to move it to this queue, so I'm [possibly redundantly] submitting the patch directly here; description and details in the bug tracker: http://sourceforge.net/tracker/index.php? func=detail&aid=1074261&group_id=5470&atid=105470 ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-09 10:23 Message: Logged In: YES user_id=11375 Applied; thanks for the fix! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1074381&group_id=5470 From noreply at sourceforge.net Thu Jun 9 17:27:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Jun 2005 08:27:11 -0700 Subject: [Patches] [ python-Patches-1002763 ] asynchat does not accept 'long' terminator Message-ID: Patches item #1002763, was opened at 2004-08-03 13:35 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1002763&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: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jey Kottalam (jeyk) Assigned to: A.M. Kuchling (akuchling) Summary: asynchat does not accept 'long' terminator Initial Comment: I was browsing the asynchat source code and noticed that the asynchat module accepts ints but not longs for the set_terminator function. I'm attaching a patch that allows it to accept longs as well. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-09 11:27 Message: Logged In: YES user_id=11375 Applied to CVS head; thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1002763&group_id=5470 From noreply at sourceforge.net Thu Jun 9 19:56:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Jun 2005 10:56:26 -0700 Subject: [Patches] [ python-Patches-1200134 ] buffer overflow in _cursesmodule.c Message-ID: Patches item #1200134, was opened at 2005-05-11 16:15 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200134&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: Fixed Priority: 5 Submitted By: Jan Michael H?lsbergen (avu) Assigned to: A.M. Kuchling (akuchling) Summary: buffer overflow in _cursesmodule.c Initial Comment: In PyCursesWindow_GetStr(), a buffer with a fixed size of 1024 byte is used for reading the input from the user. This leads to a buffer overflow. If the user does not provide a limit to win.getstr(), wgetstr() is used, enforcing no limit at all, if the user provides a limit, it can be greater than 1024, leading to the same problem. My Patch replaces the buffer with a dynamicly allocated one, if the user does not provide a limit the maximum still is 1024. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-09 13:56 Message: Logged In: YES user_id=11375 Fixed on both CVS HEAD and 2.4-maint branches. Thanks for reporting this and for providing a fix. I simply constrained the results to fit within the 1024-byte buffer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200134&group_id=5470 From noreply at sourceforge.net Fri Jun 10 17:03:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Jun 2005 08:03:21 -0700 Subject: [Patches] [ python-Patches-1161914 ] python-config Message-ID: Patches item #1161914, was opened at 2005-03-12 19:44 Message generated for change (Comment added) made by mdehoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1161914&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: Andre Jonsson (tatsujin) Assigned to: Nobody/Anonymous (nobody) Summary: python-config Initial Comment: I'm not sure this is the correct place to do this, but I found the need for a python-config (similar to sdl-config, etc.) when building an C++ application that embeds python. It accepts two arguments --cflags and --static-libs: # ./python-config --cflags --static-libs -I/usr/include/python2.4 /usr/lib/python2.4/config/libpython2.4.a I guess it could be expanded to do more, but it was all I needed. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-06-11 00:03 Message: Logged In: YES user_id=488897 Three comments: 1) When running this script, I got the following error on Unix and Cygwin: $ python-config.php --cflags --static-libs -I/usr/local/include/python2.4 Traceback (most recent call last): File "", line 1, in ? AttributeError: 'module' object has no attribute 'lib' 2) Since we are Pythoneers, why write this script as a shell-script instead of a Python script? (sh may not even be available on Windows). 3) Isn't it easier / more reliable to get this information via distutils? See section 5.6 of "Extending and Embedding the Python Interpreter". ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-15 04:14 Message: Logged In: YES user_id=21627 It appears that the *-config programs (e.g. gtk-config, ...) share command line options; this seems to be part of the "pkg-config" system. I think we need to understand what precisely the standard for these utilities is, and conform to it. ---------------------------------------------------------------------- Comment By: Andre Jonsson (tatsujin) Date: 2005-03-14 17:43 Message: Logged In: YES user_id=195710 Ok. I'll make an attempt. What do you mean by "what specific options are expected from a *-config program" ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-14 07:47 Message: Logged In: YES user_id=21627 This is the right place if you want this to be included in the standard Python distribution. If you just want to share it with others, the Python cookbook is a better place: http://aspn.activestate.com/ASPN/Python/Cookbook/ In the current form, this is not acceptable, as it is incomplete (e.g. there is no integration into the Python build process, and we need to know what specific options are expected from a *-config program, and implement them). Are you willing to complete this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1161914&group_id=5470 From noreply at sourceforge.net Fri Jun 10 18:02:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Jun 2005 09:02:35 -0700 Subject: [Patches] [ python-Patches-1196895 ] in IDLE, assume new text files are python source by default Message-ID: Patches item #1196895, was opened at 2005-05-07 06:25 Message generated for change (Comment added) made by mdehoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196895&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: Jeff Shute (jshute) Assigned to: Nobody/Anonymous (nobody) Summary: in IDLE, assume new text files are python source by default Initial Comment: This changes IDLE so that when you use File->New Window, it assumes that the file will be python source by default, so syntax highlighting will be enabled. Currently, when you make a new window, it assumes that it is not python source by default, so you do not get syntax highlighting until you save the file with extension .py. I believe this was the original intent of the code, based on the test for a missing filename, but it got broken at some point when the code was modified to accept a path instead of a missing filename. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-06-11 01:02 Message: Logged In: YES user_id=488897 I've tested this patch on Windows. Without the patch, as soon as the file is saved as something.py, syntax highlighting is turned on. Before saving, no syntax highlighting is used. With the patch, the file is assumed to contain Python code, and syntax highlighting is turned on immediately. Unfortunately, if the user is creating a generic text file (so not containing Python code), syntax highlighting is turned on even if the user saves the file as something.txt. For a correct patch, syntax highlighting should be turned off again if the user decides to save the file as a *.txt. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-05-07 07:21 Message: Logged In: YES user_id=31435 I haven't looked at the patch, but +1 on the idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196895&group_id=5470 From noreply at sourceforge.net Fri Jun 10 18:15:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Jun 2005 09:15:01 -0700 Subject: [Patches] [ python-Patches-1196917 ] change recall in IDLE shell to not overwrite current command Message-ID: Patches item #1196917, was opened at 2005-05-07 06:55 Message generated for change (Comment added) made by mdehoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196917&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: Jeff Shute (jshute) Assigned to: Nobody/Anonymous (nobody) Summary: change recall in IDLE shell to not overwrite current command Initial Comment: Currently, when you move the cursor over any previous command/output and press enter, IDLE replaces the command you are currently typing with that text. I find this behaviour very annoying because I often end up doing it by accident when I switch from another window back to IDLE, and it cannot be undone, so I lose whatever command I was building up. This patch changes the behaviour so that instead of replacing your current text with the text under the cursor, the text under the cursor is inserted at the current location, using the auto-indenter to make sure it is put in the correct place. The operation also becomes undoable. This allows sequences like the following: >>> comp1() 5.436436 >>> comp2() 3.655546 >>> print 5.436436 + 3.655546 9.091982 where I have generated the third command like this: print [up, up, up, enter] + [up, enter][enter] or like this: >>> for a in set1: for b in set2: print a,b ... >>> for c in set3: for a in set1: for b in set2: print a,b I generate the second command by typing the first line, and then cursoring up to the previous command and pressing enter. The old loop is inserted properly indented into the new loop. (This does not work with copy and paste.) I can then continue to edit the combined command or press enter to run it. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-06-11 01:15 Message: Logged In: YES user_id=488897 FWIW, I've tried this patch on Windows. I agree that it makes IDLE easier to use. I'll write to python-dev in support of this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196917&group_id=5470 From noreply at sourceforge.net Fri Jun 10 19:09:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Jun 2005 10:09:52 -0700 Subject: [Patches] [ python-Patches-1187396 ] Add const specifier to PySpam_System prototype Message-ID: Patches item #1187396, was opened at 2005-04-21 16:15 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1187396&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: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 1 Submitted By: Luis Bruno (lbruno) Assigned to: Nobody/Anonymous (nobody) Summary: Add const specifier to PySpam_System prototype Initial Comment: Section 1.12 of Extending & Embedding needs a const specifier for correct compilation (tested on Fedora Core 3, py2.3). Closes #1184380, submitted by bamoore at users.sf.net ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-10 19:09 Message: Logged In: YES user_id=1188172 Fixed in r1.33 of Doc/ext/extending.tex. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-04-29 08:07 Message: Logged In: YES user_id=488897 Patch looks fine to me. I'll write a patch review to the python-dev mailing list in support of this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1187396&group_id=5470 From noreply at sourceforge.net Fri Jun 10 19:15:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Jun 2005 10:15:48 -0700 Subject: [Patches] [ python-Patches-1171150 ] Newline in error output of py_compile.compile Message-ID: Patches item #1171150, was opened at 2005-03-26 21:57 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1171150&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: Closed >Resolution: Accepted Priority: 3 Submitted By: paul cannon (paulcannon) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Newline in error output of py_compile.compile Initial Comment: The py_compile.compile() function, when doraise=False and a compilation error is encountered, simply prints the message to sys.stderr and returns. However, it neglects to add a newline. Furthermore, judging by the definition of PyCompileError earlier in the file and the fact that the message will always come from an instance of PyCompileError, the message will never include a newline. Some shells issue a carraige return before the command prompt, so that would hide the output from py_compile.compile if it were the last message to the console. Checking all occurences of "py_compile" in the python source indicates they all either use compile() with doraise=True or expect normal newline-terminated output on error. This patch appends the newline. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-10 19:15 Message: Logged In: YES user_id=1188172 Thanks! Checked in as py_compile.py rev 1.27. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1171150&group_id=5470 From noreply at sourceforge.net Fri Jun 10 19:29:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Jun 2005 10:29:27 -0700 Subject: [Patches] [ python-Patches-756021 ] Allow socket.inet_aton(" 255.255.255.255" ) on Windo Message-ID: Patches item #756021, was opened at 2003-06-17 18:30 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756021&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Ben Gertzfield (che_fox) >Assigned to: Raymond Hettinger (rhettinger) >Summary: Allow socket.inet_aton("255.255.255.255") on Windo Initial Comment: Currently there's an XXX comment in socketmodule.c for the Windows implementation (actually, for any platform that doesn't have inet_aton) of socket.inet_aton: /* XXX Problem here: inet_aton('255.255.255.255') raises an exception while it should be a valid address. */ This patch (against Python CVS) fixes this problem by special-casing "255.255.255.255" as input when inet_addr returns -1 (usually an error). We just strcmp() the input string with "255.255.255.255" if inet_addr returned -1; if it matches, we allow PyString_FromStringAndSize() to do its thing on -1. Also, I noticed that the unit tests for module.inet_aton and friends were skipped if the platform didn't have inet_pton; this is an obvious error, and so I've split out the tests for inet_pton and inet_ntop's IPv4 functionality from inet_aton and inet_ntoa, as well as adding an explicit test for the now-handled "255.255.255.255" case. Finally, I haven't gotten CVS python to build on Windows under Visual Studio.NET (I get 'invalid project errors' when it tries to convert the VS6 project files -- and I don't have VS6) although I've tested this patch and the new tests on Debian Linux. This patch really should be applied to the 2.2 maintenance branch as well as 2.3, since "255.255.255.255" is a legal IP address and is not documented to raise an exception in the Python docs (even though it does currently on Windows). ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-10 19:29 Message: Logged In: YES user_id=1188172 Attached new patch which special-cases 255.255.255.255 as proposed by Irmen. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-16 16:34 Message: Logged In: YES user_id=129426 Looks good but I have one suggestion: isn't it better to test for "255.255.255.255" before calling inet_addr and then return '\xff\xff\xff\xff' directly, rather than relying on INADDR_NONE being 0xffffffff ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756021&group_id=5470 From noreply at sourceforge.net Fri Jun 10 20:59:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Jun 2005 11:59:03 -0700 Subject: [Patches] [ python-Patches-1218421 ] byteorder issue in PyMac_GetOSType Message-ID: Patches item #1218421, was opened at 2005-06-10 20:59 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=1218421&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: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: byteorder issue in PyMac_GetOSType Initial Comment: The attached patch fixes an issue with byte order in PyMac_GetOSType (and its reverse). These functions convert from an OSType to a string (and back) by interpreting an OSType as a 4-byte string. This is not correct if you're not on a big-endian system, such as some of the future Apple systems. The attached patch is for python 2.4.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1218421&group_id=5470 From noreply at sourceforge.net Fri Jun 10 22:46:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Jun 2005 13:46:48 -0700 Subject: [Patches] [ python-Patches-1049855 ] PyOS_InputHook inconsistency on Windows Message-ID: Patches item #1049855, was opened at 2004-10-19 18:03 Message generated for change (Comment added) made by mdehoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1049855&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: Michiel de Hoon (mdehoon) Assigned to: Nobody/Anonymous (nobody) Summary: PyOS_InputHook inconsistency on Windows Initial Comment: PyOS_InputHook is a pointer to a function to be called periodically when Python is idle. It is used, for example, to get messages delivered to graphics windows. If I compile Python from source (which uses Modules/readline.c), PyOS_InputHook is called ten times per second. However, with the Windows-version of Python, PyOS_InputHook is called only once for each command typed by the user. It seems that the problem resides in Parser/myreadline.c (which I presume is used for the Windows-version of Python): if (PyOS_InputHook != NULL) (void)(PyOS_InputHook)(); ... p = fgets(buf, len, fp); Python idles at "fgets", but PyOS_InputHook is not being called while Python is idle. The attached patch solves this problem by using the "select" function, basically in the same way as what is in Module/readline.c. I don't know how to compile Python for Windows, so I wasn't able to test this patch. ---------------------------------------------------------------------- >Comment By: Michiel de Hoon (mdehoon) Date: 2005-06-11 05:46 Message: Logged In: YES user_id=488897 Thomas Heller sent me this comment: > The PyOS_StdioReadline function calls my_fgets with a file > pointer argument. The my_fgets function in the patch assumes > that STD_INPUT_HANDLE is the handle to use - is this > assumption always correct? He is right, this assumption is not necessarily correct. I have made a new patch (labeled 20050610) to solve this issue. This latest version has been tested on Cygwin, but not yet on Windows -- I need to dig up a compiler for Windows first. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-05-13 12:57 Message: Logged In: YES user_id=488897 I have rewritten the patch to include Windows support. I compiled Python on Windows with VC98, and on Linux and Mac OS X and found no problems with it. The new patch is attached. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-05-02 12:40 Message: Logged In: YES user_id=149084 Yeah, that's why I didn't want to check it in, I can't build on Windows ithe VC 5. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-05-02 11:52 Message: Logged In: YES user_id=488897 Thanks for looking at this patch. Today I found out that it is possible to compile Python 2.4.1 with the older Microsoft Visual Studio 6.0, which I happen to have in my office. It turned out that the patch does not work correctly on Windows, due to the fact that the "select" function doesn't work with stdin on Windows. I will fix the patch so it'll work on Windows too. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-05-01 03:21 Message: Logged In: YES user_id=149084 The revised patch looks ok to me. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-03-26 22:33 Message: Logged In: YES user_id=488897 I have now tested this patch. After fixing one error (I had forgotton to declare one variable), the patch works correctly. I have uploaded a fixed patch. Note that this bug occurs not only on Windows, but on any Python compiled without readline. (which allowed me to test this patch by compiling Python without readline support). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1049855&group_id=5470 From noreply at sourceforge.net Sat Jun 11 05:57:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Jun 2005 20:57:54 -0700 Subject: [Patches] [ python-Patches-1196895 ] in IDLE, assume new text files are python source by default Message-ID: Patches item #1196895, was opened at 2005-05-06 17:25 Message generated for change (Comment added) made by jshute You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196895&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: Jeff Shute (jshute) Assigned to: Nobody/Anonymous (nobody) Summary: in IDLE, assume new text files are python source by default Initial Comment: This changes IDLE so that when you use File->New Window, it assumes that the file will be python source by default, so syntax highlighting will be enabled. Currently, when you make a new window, it assumes that it is not python source by default, so you do not get syntax highlighting until you save the file with extension .py. I believe this was the original intent of the code, based on the test for a missing filename, but it got broken at some point when the code was modified to accept a path instead of a missing filename. ---------------------------------------------------------------------- >Comment By: Jeff Shute (jshute) Date: 2005-06-10 23:57 Message: Logged In: YES user_id=39615 I noticed that behaviour before, but didn't fix it because I considered it at the time to be an unrelated bug. (The same thing happens when you have a file saved as .py, and then save it as .txt - the coloring is turned off for new text, but the old text is not uncolored.) It is also trivial to fix this problem. Here is another patch that does so. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-06-10 12:02 Message: Logged In: YES user_id=488897 I've tested this patch on Windows. Without the patch, as soon as the file is saved as something.py, syntax highlighting is turned on. Before saving, no syntax highlighting is used. With the patch, the file is assumed to contain Python code, and syntax highlighting is turned on immediately. Unfortunately, if the user is creating a generic text file (so not containing Python code), syntax highlighting is turned on even if the user saves the file as something.txt. For a correct patch, syntax highlighting should be turned off again if the user decides to save the file as a *.txt. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-05-06 18:21 Message: Logged In: YES user_id=31435 I haven't looked at the patch, but +1 on the idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196895&group_id=5470 From noreply at sourceforge.net Sat Jun 11 15:15:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Jun 2005 06:15:57 -0700 Subject: [Patches] [ python-Patches-1161914 ] python-config Message-ID: Patches item #1161914, was opened at 2005-03-12 11:44 Message generated for change (Comment added) made by tatsujin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1161914&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: Andre Jonsson (tatsujin) Assigned to: Nobody/Anonymous (nobody) Summary: python-config Initial Comment: I'm not sure this is the correct place to do this, but I found the need for a python-config (similar to sdl-config, etc.) when building an C++ application that embeds python. It accepts two arguments --cflags and --static-libs: # ./python-config --cflags --static-libs -I/usr/include/python2.4 /usr/lib/python2.4/config/libpython2.4.a I guess it could be expanded to do more, but it was all I needed. ---------------------------------------------------------------------- >Comment By: Andre Jonsson (tatsujin) Date: 2005-06-11 15:15 Message: Logged In: YES user_id=195710 1. php? Anyway, I see that the 'lib' attribute actually isn't an official one. Bad call from my part. 2. Yes, I'm ashamed to have commited such atrocities. :-) 3. Ah, I see. Didn't know about that one. That said, as loewis stated previously this script should probably follow the pkg-config standard anyhow. I haven't gotten around to do anything further in this matter, unfortunately. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-06-10 17:03 Message: Logged In: YES user_id=488897 Three comments: 1) When running this script, I got the following error on Unix and Cygwin: $ python-config.php --cflags --static-libs -I/usr/local/include/python2.4 Traceback (most recent call last): File "", line 1, in ? AttributeError: 'module' object has no attribute 'lib' 2) Since we are Pythoneers, why write this script as a shell-script instead of a Python script? (sh may not even be available on Windows). 3) Isn't it easier / more reliable to get this information via distutils? See section 5.6 of "Extending and Embedding the Python Interpreter". ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-14 20:14 Message: Logged In: YES user_id=21627 It appears that the *-config programs (e.g. gtk-config, ...) share command line options; this seems to be part of the "pkg-config" system. I think we need to understand what precisely the standard for these utilities is, and conform to it. ---------------------------------------------------------------------- Comment By: Andre Jonsson (tatsujin) Date: 2005-03-14 09:43 Message: Logged In: YES user_id=195710 Ok. I'll make an attempt. What do you mean by "what specific options are expected from a *-config program" ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-13 23:47 Message: Logged In: YES user_id=21627 This is the right place if you want this to be included in the standard Python distribution. If you just want to share it with others, the Python cookbook is a better place: http://aspn.activestate.com/ASPN/Python/Cookbook/ In the current form, this is not acceptable, as it is incomplete (e.g. there is no integration into the Python build process, and we need to know what specific options are expected from a *-config program, and implement them). Are you willing to complete this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1161914&group_id=5470 From noreply at sourceforge.net Sun Jun 12 05:21:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Jun 2005 20:21:34 -0700 Subject: [Patches] [ python-Patches-1121611 ] sha and md5 modules should use OpenSSL when possible Message-ID: Patches item #1121611, was opened at 2005-02-12 17:33 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121611&group_id=5470 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: Gregory P. Smith (greg) Assigned to: Gregory P. Smith (greg) Summary: sha and md5 modules should use OpenSSL when possible Initial Comment: The md5 and sha (sha1) modules should use OpenSSL for the algorithms when it is available as its implementations are much faster than pythons own. Attached is an initial patch to use OpenSSL for the sha module. Its not ready for committing as is yet, but it is setup to be a generic base for all OpenSSL hashes with a little bit of work in the future. Tossing this out there for people to see how trivial it is and enjoy the speedups. diff is against HEAD but it should apply to 2.4 just fine. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2005-06-11 20:21 Message: Logged In: YES user_id=413 Ok, this patch is ready. documentation has been added. I'll bring it up on python-dev for discussion/approval with a link to the htmlified documentation. The speedups are great for any application hashing a lot of data when OpenSSL is used. It also adds a sha224, sha256, sha384 and sha512 support. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-03-12 17:13 Message: Logged In: YES user_id=413 I linked a _hashlib.so library statically against openssl and reran the speed test. no change. that means its not shared library overhead causing the higher startup time but just an artifact of the OpenSSL EVP interface. Next up, analyze what size things common heavy sha1 using applications regularly hash (BitTorrent and such). ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-03-10 00:09 Message: Logged In: YES user_id=413 The 007 patch improves the speed of the constructor. There is still a potential speed issue with the constructor/destructor to work on: greg at spiff src $ ./python Lib/test/test_hashlib_speed.py _sha testing speed of old _sha legacy interface 0.06 seconds [20000 creations] 0.24 seconds [20000 "" digests] 0.15 seconds 20 x 106201 bytes [huge data] 0.15 seconds 200 x 10620 bytes [large data] 0.17 seconds 2000 x 1062 bytes [medium data] 0.35 seconds 20020 x 106 bytes [small data] 1.37 seconds 106200 x 20 bytes [digest_size data] 2.75 seconds 212400 x 10 bytes [tiny data] greg at spiff src $ ./python Lib/test/test_hashlib_speed.py sha1 testing speed of hashlib.sha1 0.22 seconds [20000 creations] 0.57 seconds [20000 "" digests] 0.09 seconds 20 x 106201 bytes [huge data] 0.09 seconds 200 x 10620 bytes [large data] 0.15 seconds 2000 x 1062 bytes [medium data] 0.71 seconds 20020 x 106 bytes [small data] 3.39 seconds 106200 x 20 bytes [digest_size data] 6.70 seconds 212400 x 10 bytes [tiny data] I suspect the cause is either or both of the shared openssl library call overhead or the openssl EVP abstraction interface. The speed results are very similar to the above regardless of which digest is used (the above was a celeron 333mhz running linux). ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-03-03 13:15 Message: Logged In: YES user_id=413 hashlib-006.patch adds fast constructors and a speed test. documentation is the next step. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-03-01 01:14 Message: Logged In: YES user_id=413 hashlib-005.patch now passes its test suite and no problems appear in valgrind. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-02-28 10:11 Message: Logged In: YES user_id=413 a much updated patch (hashlib-patch-004.patch). it incorporates some suggestions as well as including sf patch 935454's sha256/224 and sha512/384 implementations. still not complete but shows the direction its going in (i see a segfault part way thru the test suite after running the sha512 tests). as for the private modules being under another package, i see no reason to do that since there aren't very many (how does that work for binary modules anyways?). ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-18 11:21 Message: Logged In: YES user_id=764593 Should the private modules (such as _sha) be placed in a crypto package, instead of directly in the parent/everything library? ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-02-16 22:46 Message: Logged In: YES user_id=413 hashes-openssl-002.patch replaces the sha and md5 modules with a general hashes module that wraps all hashes that OpenSSL supports. note that OpenSSLs implementations are much faster than the previous python versions as it choses versions optimized for your particular hardware. Incase python is compiled without openssl the hashes wrapper falls back on the old python sha and md5 module implementations. side note: This may be sufficient for the Debian folks to work around their random odd licensing issue. just have debian python depend on openssl; use this and remove the old md5 module/code that wouldn't get used anyways. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121611&group_id=5470 From noreply at sourceforge.net Sun Jun 12 06:38:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Jun 2005 21:38:13 -0700 Subject: [Patches] [ python-Patches-1196895 ] in IDLE, assume new text files are python source by default Message-ID: Patches item #1196895, was opened at 2005-05-06 16:25 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196895&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: Accepted Priority: 5 Submitted By: Jeff Shute (jshute) >Assigned to: Kurt B. Kaiser (kbk) Summary: in IDLE, assume new text files are python source by default Initial Comment: This changes IDLE so that when you use File->New Window, it assumes that the file will be python source by default, so syntax highlighting will be enabled. Currently, when you make a new window, it assumes that it is not python source by default, so you do not get syntax highlighting until you save the file with extension .py. I believe this was the original intent of the code, based on the test for a missing filename, but it got broken at some point when the code was modified to accept a path instead of a missing filename. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-06-11 23:38 Message: Logged In: YES user_id=149084 ColorDelegator 1.15 EditorWindow.py 1.68 Closes Python Bugs 775012 and 800432, partial fix IDLEfork 763524. Thanks for the patches! ---------------------------------------------------------------------- Comment By: Jeff Shute (jshute) Date: 2005-06-10 22:57 Message: Logged In: YES user_id=39615 I noticed that behaviour before, but didn't fix it because I considered it at the time to be an unrelated bug. (The same thing happens when you have a file saved as .py, and then save it as .txt - the coloring is turned off for new text, but the old text is not uncolored.) It is also trivial to fix this problem. Here is another patch that does so. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-06-10 11:02 Message: Logged In: YES user_id=488897 I've tested this patch on Windows. Without the patch, as soon as the file is saved as something.py, syntax highlighting is turned on. Before saving, no syntax highlighting is used. With the patch, the file is assumed to contain Python code, and syntax highlighting is turned on immediately. Unfortunately, if the user is creating a generic text file (so not containing Python code), syntax highlighting is turned on even if the user saves the file as something.txt. For a correct patch, syntax highlighting should be turned off again if the user decides to save the file as a *.txt. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-05-06 17:21 Message: Logged In: YES user_id=31435 I haven't looked at the patch, but +1 on the idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196895&group_id=5470 From noreply at sourceforge.net Sun Jun 12 07:20:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Jun 2005 22:20:24 -0700 Subject: [Patches] [ python-Patches-1196980 ] trivial bug in error message text Message-ID: Patches item #1196980, was opened at 2005-05-06 20:08 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196980&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: Accepted Priority: 5 Submitted By: Jeff Shute (jshute) Assigned to: Kurt B. Kaiser (kbk) Summary: trivial bug in error message text Initial Comment: This is a trivial patch to fix an error message in IDLE that refers to the Untabify menu choice as being in the Edit submenu when it is actually in the Format submenu. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-06-12 00:20 Message: Logged In: YES user_id=149084 ScriptBinding 1.30 Thanks for the patch! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196980&group_id=5470 From noreply at sourceforge.net Sun Jun 12 14:18:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Jun 2005 05:18:05 -0700 Subject: [Patches] [ python-Patches-1121611 ] sha and md5 modules should use OpenSSL when possible Message-ID: Patches item #1121611, was opened at 2005-02-13 01:33 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121611&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: Gregory P. Smith (greg) Assigned to: Gregory P. Smith (greg) Summary: sha and md5 modules should use OpenSSL when possible Initial Comment: The md5 and sha (sha1) modules should use OpenSSL for the algorithms when it is available as its implementations are much faster than pythons own. Attached is an initial patch to use OpenSSL for the sha module. Its not ready for committing as is yet, but it is setup to be a generic base for all OpenSSL hashes with a little bit of work in the future. Tossing this out there for people to see how trivial it is and enjoy the speedups. diff is against HEAD but it should apply to 2.4 just fine. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-06-12 12:18 Message: Logged In: YES user_id=4771 On a side note, maybe it makes sense for a new module like this one to promote and use the modern (>=2.2) ways of defining C types. What I have in mind is using tp_methods instead of Py_FindMethod, and generally not reverting to strcmp(). In this case, the constants like 'digest_size' would be best stored as class attributes instead, if possible. Indeed, allowing expressions like "hashlib.md5.digest_size" conveys the idea that the result doesn't depend on a particular instance, unlike "hashlib.md5().digest_size". (Of course class attributes are also readable from the instance, as usual.) I can give it a try if you don't want to invest more time in this patch than you already did (for which we are grateful to you :-) ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-06-12 03:21 Message: Logged In: YES user_id=413 Ok, this patch is ready. documentation has been added. I'll bring it up on python-dev for discussion/approval with a link to the htmlified documentation. The speedups are great for any application hashing a lot of data when OpenSSL is used. It also adds a sha224, sha256, sha384 and sha512 support. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-03-13 01:13 Message: Logged In: YES user_id=413 I linked a _hashlib.so library statically against openssl and reran the speed test. no change. that means its not shared library overhead causing the higher startup time but just an artifact of the OpenSSL EVP interface. Next up, analyze what size things common heavy sha1 using applications regularly hash (BitTorrent and such). ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-03-10 08:09 Message: Logged In: YES user_id=413 The 007 patch improves the speed of the constructor. There is still a potential speed issue with the constructor/destructor to work on: greg at spiff src $ ./python Lib/test/test_hashlib_speed.py _sha testing speed of old _sha legacy interface 0.06 seconds [20000 creations] 0.24 seconds [20000 "" digests] 0.15 seconds 20 x 106201 bytes [huge data] 0.15 seconds 200 x 10620 bytes [large data] 0.17 seconds 2000 x 1062 bytes [medium data] 0.35 seconds 20020 x 106 bytes [small data] 1.37 seconds 106200 x 20 bytes [digest_size data] 2.75 seconds 212400 x 10 bytes [tiny data] greg at spiff src $ ./python Lib/test/test_hashlib_speed.py sha1 testing speed of hashlib.sha1 0.22 seconds [20000 creations] 0.57 seconds [20000 "" digests] 0.09 seconds 20 x 106201 bytes [huge data] 0.09 seconds 200 x 10620 bytes [large data] 0.15 seconds 2000 x 1062 bytes [medium data] 0.71 seconds 20020 x 106 bytes [small data] 3.39 seconds 106200 x 20 bytes [digest_size data] 6.70 seconds 212400 x 10 bytes [tiny data] I suspect the cause is either or both of the shared openssl library call overhead or the openssl EVP abstraction interface. The speed results are very similar to the above regardless of which digest is used (the above was a celeron 333mhz running linux). ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-03-03 21:15 Message: Logged In: YES user_id=413 hashlib-006.patch adds fast constructors and a speed test. documentation is the next step. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-03-01 09:14 Message: Logged In: YES user_id=413 hashlib-005.patch now passes its test suite and no problems appear in valgrind. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-02-28 18:11 Message: Logged In: YES user_id=413 a much updated patch (hashlib-patch-004.patch). it incorporates some suggestions as well as including sf patch 935454's sha256/224 and sha512/384 implementations. still not complete but shows the direction its going in (i see a segfault part way thru the test suite after running the sha512 tests). as for the private modules being under another package, i see no reason to do that since there aren't very many (how does that work for binary modules anyways?). ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-18 19:21 Message: Logged In: YES user_id=764593 Should the private modules (such as _sha) be placed in a crypto package, instead of directly in the parent/everything library? ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-02-17 06:46 Message: Logged In: YES user_id=413 hashes-openssl-002.patch replaces the sha and md5 modules with a general hashes module that wraps all hashes that OpenSSL supports. note that OpenSSLs implementations are much faster than the previous python versions as it choses versions optimized for your particular hardware. Incase python is compiled without openssl the hashes wrapper falls back on the old python sha and md5 module implementations. side note: This may be sufficient for the Debian folks to work around their random odd licensing issue. just have debian python depend on openssl; use this and remove the old md5 module/code that wouldn't get used anyways. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121611&group_id=5470 From postmaster at mx1.moonlighting.co.za Sun Jun 12 19:08:38 2005 From: postmaster at mx1.moonlighting.co.za (postmaster@mx1.moonlighting.co.za) Date: Sun, 12 Jun 2005 19:08:38 +0200 Subject: [Patches] Inflex scan report [061219084762] Message-ID: <200506121708.j5CH8etu004802@mx1.moonlighting.co.za> This email has been sent to you from an email content scanning filter located on the server [python.org]. If you have any queries relating to this email, please direct them to postmaster. Report Details ----------------------------------------------- Administrator Email Reply Address: postmaster Email sent to: brian at blender.co.za Inflex ID: 061219084762 Report Details ----------------------------------------------- AntiVirus Results... Scanning /usr/local/inflex/tmp/inf_061219084762/unpacked/* Scanning file /usr/local/inflex/tmp/inf_061219084762/unpacked/_headers_ Scanning file /usr/local/inflex/tmp/inf_061219084762/unpacked/text.zip /usr/local/inflex/tmp/inf_061219084762/unpacked/text.zip Found the Generic Malware.a!zip trojan !!! Scanning file /usr/local/inflex/tmp/inf_061219084762/unpacked/textfile0 Scanning file /usr/local/inflex/tmp/inf_061219084762/unpacked/textfile1 Scanning file /usr/local/inflex/tmp/inf_061219084762/unpacked/textfile2 Summary report on /usr/local/inflex/tmp/inf_061219084762/unpacked/* File(s) Total files: ........... 5 Clean: ................. 4 Possibly Infected: ..... 1 File NAME/TYPE Scan Results 061219084762 from:patches at python.org to: brian at blender.co.zaType scanning off. Name scanning off. Text scanning off. END OF MESSAGE. End. . From noreply at sourceforge.net Sun Jun 12 22:35:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Jun 2005 13:35:52 -0700 Subject: [Patches] [ python-Patches-1121611 ] sha and md5 modules should use OpenSSL when possible Message-ID: Patches item #1121611, was opened at 2005-02-12 20:33 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121611&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: Gregory P. Smith (greg) Assigned to: Gregory P. Smith (greg) Summary: sha and md5 modules should use OpenSSL when possible Initial Comment: The md5 and sha (sha1) modules should use OpenSSL for the algorithms when it is available as its implementations are much faster than pythons own. Attached is an initial patch to use OpenSSL for the sha module. Its not ready for committing as is yet, but it is setup to be a generic base for all OpenSSL hashes with a little bit of work in the future. Tossing this out there for people to see how trivial it is and enjoy the speedups. diff is against HEAD but it should apply to 2.4 just fine. ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-06-12 16:35 Message: Logged In: YES user_id=593130 Re Doc page: As a somewhat naive (relative to the subject) reader, the title and first sentence implied that 'secure hash' and 'message digest' are two separate things, whereas, judging from the .digest() blurb, they both seem to be16-byte hashes. So I would prefer this equivalence and the actual meaning were made clear at the top. Something like "This module implements a common interface to several secure hash or message digest algorithms that produce 16-byte hashes." If, as I presume, xx.hexdigest() == binascii.hexlify(xx.digest()), then I would say so and reference binsacii for the interconversion functions one would need if one had the two versions to compare or needed to convert after the extraction. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-06-12 08:18 Message: Logged In: YES user_id=4771 On a side note, maybe it makes sense for a new module like this one to promote and use the modern (>=2.2) ways of defining C types. What I have in mind is using tp_methods instead of Py_FindMethod, and generally not reverting to strcmp(). In this case, the constants like 'digest_size' would be best stored as class attributes instead, if possible. Indeed, allowing expressions like "hashlib.md5.digest_size" conveys the idea that the result doesn't depend on a particular instance, unlike "hashlib.md5().digest_size". (Of course class attributes are also readable from the instance, as usual.) I can give it a try if you don't want to invest more time in this patch than you already did (for which we are grateful to you :-) ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-06-11 23:21 Message: Logged In: YES user_id=413 Ok, this patch is ready. documentation has been added. I'll bring it up on python-dev for discussion/approval with a link to the htmlified documentation. The speedups are great for any application hashing a lot of data when OpenSSL is used. It also adds a sha224, sha256, sha384 and sha512 support. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-03-12 20:13 Message: Logged In: YES user_id=413 I linked a _hashlib.so library statically against openssl and reran the speed test. no change. that means its not shared library overhead causing the higher startup time but just an artifact of the OpenSSL EVP interface. Next up, analyze what size things common heavy sha1 using applications regularly hash (BitTorrent and such). ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-03-10 03:09 Message: Logged In: YES user_id=413 The 007 patch improves the speed of the constructor. There is still a potential speed issue with the constructor/destructor to work on: greg at spiff src $ ./python Lib/test/test_hashlib_speed.py _sha testing speed of old _sha legacy interface 0.06 seconds [20000 creations] 0.24 seconds [20000 "" digests] 0.15 seconds 20 x 106201 bytes [huge data] 0.15 seconds 200 x 10620 bytes [large data] 0.17 seconds 2000 x 1062 bytes [medium data] 0.35 seconds 20020 x 106 bytes [small data] 1.37 seconds 106200 x 20 bytes [digest_size data] 2.75 seconds 212400 x 10 bytes [tiny data] greg at spiff src $ ./python Lib/test/test_hashlib_speed.py sha1 testing speed of hashlib.sha1 0.22 seconds [20000 creations] 0.57 seconds [20000 "" digests] 0.09 seconds 20 x 106201 bytes [huge data] 0.09 seconds 200 x 10620 bytes [large data] 0.15 seconds 2000 x 1062 bytes [medium data] 0.71 seconds 20020 x 106 bytes [small data] 3.39 seconds 106200 x 20 bytes [digest_size data] 6.70 seconds 212400 x 10 bytes [tiny data] I suspect the cause is either or both of the shared openssl library call overhead or the openssl EVP abstraction interface. The speed results are very similar to the above regardless of which digest is used (the above was a celeron 333mhz running linux). ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-03-03 16:15 Message: Logged In: YES user_id=413 hashlib-006.patch adds fast constructors and a speed test. documentation is the next step. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-03-01 04:14 Message: Logged In: YES user_id=413 hashlib-005.patch now passes its test suite and no problems appear in valgrind. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-02-28 13:11 Message: Logged In: YES user_id=413 a much updated patch (hashlib-patch-004.patch). it incorporates some suggestions as well as including sf patch 935454's sha256/224 and sha512/384 implementations. still not complete but shows the direction its going in (i see a segfault part way thru the test suite after running the sha512 tests). as for the private modules being under another package, i see no reason to do that since there aren't very many (how does that work for binary modules anyways?). ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-18 14:21 Message: Logged In: YES user_id=764593 Should the private modules (such as _sha) be placed in a crypto package, instead of directly in the parent/everything library? ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-02-17 01:46 Message: Logged In: YES user_id=413 hashes-openssl-002.patch replaces the sha and md5 modules with a general hashes module that wraps all hashes that OpenSSL supports. note that OpenSSLs implementations are much faster than the previous python versions as it choses versions optimized for your particular hardware. Incase python is compiled without openssl the hashes wrapper falls back on the old python sha and md5 module implementations. side note: This may be sufficient for the Debian folks to work around their random odd licensing issue. just have debian python depend on openssl; use this and remove the old md5 module/code that wouldn't get used anyways. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121611&group_id=5470 From noreply at sourceforge.net Tue Jun 14 11:11:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Jun 2005 02:11:53 -0700 Subject: [Patches] [ python-Patches-1220212 ] os.kill on windows Message-ID: Patches item #1220212, was opened at 2005-06-14 12:11 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=1220212&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: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: os.kill on windows Initial Comment: This patch enables os.kill on windows. This way there will be an "out of the box" way to kill process on windows. Basically kill calls TerminateProcess and the "signal" paramer will be the process return code. Don't have CVS access today so I'm sending the whole files in a zip (sorry). Also some config wizard need to change the winsows configuration and set HAVE_KILL. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220212&group_id=5470 From noreply at sourceforge.net Tue Jun 14 12:04:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Jun 2005 03:04:30 -0700 Subject: [Patches] [ python-Patches-1220242 ] _csv.c leaks when dialect creation fails Message-ID: Patches item #1220242, was opened at 2005-06-14 11: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=1220242&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: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Skip Montanaro (montanaro) Summary: _csv.c leaks when dialect creation fails Initial Comment: test_csv currently leaks 48 refs per run, and they all seem to be fixed by this simple patch. (The problem is that when you create a Dialect instance, but then validation fails for some reason, you need to decref the partially created instance before returning NULL). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220242&group_id=5470 From noreply at sourceforge.net Wed Jun 15 03:27:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Jun 2005 18:27:43 -0700 Subject: [Patches] [ python-Patches-1220874 ] update the binhex module for Mach-O Message-ID: Patches item #1220874, was opened at 2005-06-14 21:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220874&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: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: update the binhex module for Mach-O Initial Comment: The binhex module only understands resource forks if os.name == 'mac', which is only true for CFM builds of Python. We haven't maintained those in years, so this has been broken for quite some time. This patch is a partial fix that allows it to de-binhex the resource fork on Mach-O, but it still doesn't do the type/creator stuff. I'm currently only using it to create one of those pesky "Icon\r" files, so this is all I fixed and tested. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220874&group_id=5470 From noreply at sourceforge.net Wed Jun 15 03:29:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Jun 2005 18:29:30 -0700 Subject: [Patches] [ python-Patches-1220874 ] update the binhex module for Mach-O Message-ID: Patches item #1220874, was opened at 2005-06-14 21:27 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220874&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: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: update the binhex module for Mach-O Initial Comment: The binhex module only understands resource forks if os.name == 'mac', which is only true for CFM builds of Python. We haven't maintained those in years, so this has been broken for quite some time. This patch is a partial fix that allows it to de-binhex the resource fork on Mach-O, but it still doesn't do the type/creator stuff. I'm currently only using it to create one of those pesky "Icon\r" files, so this is all I fixed and tested. ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2005-06-14 21:29 Message: Logged In: YES user_id=139309 this is also a backport candidate ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220874&group_id=5470 From noreply at sourceforge.net Wed Jun 15 03:34:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Jun 2005 18:34:20 -0700 Subject: [Patches] [ python-Patches-1220242 ] _csv.c leaks when dialect creation fails Message-ID: Patches item #1220242, was opened at 2005-06-14 05:04 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220242&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: Fixed Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Skip Montanaro (montanaro) Summary: _csv.c leaks when dialect creation fails Initial Comment: test_csv currently leaks 48 refs per run, and they all seem to be fixed by this simple patch. (The problem is that when you create a Dialect instance, but then validation fails for some reason, you need to decref the partially created instance before returning NULL). ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-06-14 20:34 Message: Logged In: YES user_id=44345 Thanks. Applied as _csv.c 1.37. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220242&group_id=5470 From noreply at sourceforge.net Wed Jun 15 20:49:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Jun 2005 11:49:41 -0700 Subject: [Patches] [ python-Patches-1005892 ] test_curses bugs Message-ID: Patches item #1005892, was opened at 2004-08-09 06:57 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005892&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: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Alexandr Zamaraev (shura_zam) Assigned to: A.M. Kuchling (akuchling) Summary: test_curses bugs Initial Comment: I find 2 bugs in test_curses.py 1) in line 110 setscrreg(10,15) - cursor mast place in line10-15 2) in line 181 pair_content(curses.COLOR_PAIRS) - argument pair_content mast by less COLOR_PAIRS constant ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-15 14:49 Message: Logged In: YES user_id=11375 Patch applied to both HEAD and 2.4-maint branches; thanks for reporting this! In fact, fixing the pair_content() test turned up another bug; the C extension was getting the error check on pair_content() backwards. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005892&group_id=5470 From noreply at sourceforge.net Wed Jun 15 21:20:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Jun 2005 12:20:27 -0700 Subject: [Patches] [ python-Patches-1005895 ] curses for win32 Message-ID: Patches item #1005895, was opened at 2004-08-09 07:05 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005895&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Alexandr Zamaraev (shura_zam) >Assigned to: Jason Tishler (jlt63) Summary: curses for win32 Initial Comment: I have paths for compile _curses module. I use compiler - mingw32 v3.3.1 curses library - Public Domain Curses (PDCurses 2.6) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-15 15:20 Message: Logged In: YES user_id=11375 In the cursesmodule patch, the first argument to intrflush is changed from NULL to stdscr. Why? According to the ncurses man page, the window argument is ignored. use_env() is apparently a no-op for PDcurses; why not just remove the Python-visible use_env function completely? In the setting of _C_API_VERSION, what does the string "PDCurses M" mean? (In particular, what does the 'M' stand for?) Except for the above questions, the patches to test_curses.py and _cursesmodule.c look OK. I have no access to a Windows machine and no way to test them or the new .mak file, so I'm reassigning this bug to Jason Tishler, who does a lot of Cygwin work. Jason, please feel free to ask me any questions you might have about curses, the _cursesmodule.c file, or whatever. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005895&group_id=5470 From noreply at sourceforge.net Wed Jun 15 22:48:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Jun 2005 13:48:44 -0700 Subject: [Patches] [ python-Patches-1220212 ] os.kill on windows Message-ID: Patches item #1220212, was opened at 2005-06-14 11:11 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220212&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: 9 Submitted By: Miki Tebeka (tebeka) >Assigned to: Martin v. L?wis (loewis) Summary: os.kill on windows Initial Comment: This patch enables os.kill on windows. This way there will be an "out of the box" way to kill process on windows. Basically kill calls TerminateProcess and the "signal" paramer will be the process return code. Don't have CVS access today so I'm sending the whole files in a zip (sorry). Also some config wizard need to change the winsows configuration and set HAVE_KILL. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220212&group_id=5470 From noreply at sourceforge.net Thu Jun 16 01:15:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Jun 2005 16:15:19 -0700 Subject: [Patches] [ python-Patches-1221598 ] ftplib storbinary callback Message-ID: Patches item #1221598, was opened at 2005-06-15 16:15 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=1221598&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: Open Resolution: None Priority: 5 Submitted By: Phil Schwartz (phil_schwartz) Assigned to: Nobody/Anonymous (nobody) Summary: ftplib storbinary callback Initial Comment: The ftplib.FTP class currently allows the ability to provide a callback function for the retrbinary & retrlines methods to invoke. However, the corresponding storbinary and storlines methods do not. My ReleaseForge application currently uses the ftplib to send files (rather than retrieve) and it's helpful to know the percentage of the file that has been sent. For my app I subclassed ftplib.FTP and reimplemented storbinary to optionally accept a callback function as a parameter. However, I think this would be a useful method to include in the standard python distribution. I've attached a modified version of ftplib.py which adds this functionality. Unlike the retrX methods, the storX methods only invoke the callback function if it's not None so that it will not interfere with existing code. For completeness, the retrX methods invoke print_line if a callback function is not provided and doing so for the storX functions may be undesired. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1221598&group_id=5470 From noreply at sourceforge.net Thu Jun 16 01:26:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Jun 2005 16:26:00 -0700 Subject: [Patches] [ python-Patches-1221598 ] ftplib storbinary/storlines callback function Message-ID: Patches item #1221598, was opened at 2005-06-15 16:15 Message generated for change (Settings changed) made by phil_schwartz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1221598&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: Open Resolution: None Priority: 5 Submitted By: Phil Schwartz (phil_schwartz) Assigned to: Nobody/Anonymous (nobody) >Summary: ftplib storbinary/storlines callback function Initial Comment: The ftplib.FTP class currently allows the ability to provide a callback function for the retrbinary & retrlines methods to invoke. However, the corresponding storbinary and storlines methods do not. My ReleaseForge application currently uses the ftplib to send files (rather than retrieve) and it's helpful to know the percentage of the file that has been sent. For my app I subclassed ftplib.FTP and reimplemented storbinary to optionally accept a callback function as a parameter. However, I think this would be a useful method to include in the standard python distribution. I've attached a modified version of ftplib.py which adds this functionality. Unlike the retrX methods, the storX methods only invoke the callback function if it's not None so that it will not interfere with existing code. For completeness, the retrX methods invoke print_line if a callback function is not provided and doing so for the storX functions may be undesired. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1221598&group_id=5470 From noreply at sourceforge.net Thu Jun 16 06:45:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Jun 2005 21:45:28 -0700 Subject: [Patches] [ python-Patches-1005895 ] curses for win32 Message-ID: Patches item #1005895, was opened at 2004-08-09 18:05 Message generated for change (Comment added) made by shura_zam You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005895&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Alexandr Zamaraev (shura_zam) Assigned to: Jason Tishler (jlt63) Summary: curses for win32 Initial Comment: I have paths for compile _curses module. I use compiler - mingw32 v3.3.1 curses library - Public Domain Curses (PDCurses 2.6) ---------------------------------------------------------------------- >Comment By: Alexandr Zamaraev (shura_zam) Date: 2005-06-16 11:45 Message: Logged In: YES user_id=980085 >In the cursesmodule patch, the first argument to intrflush >is changed from NULL to stdscr. Why? In PDCurses intrflush return ERR if first arg is NULL. >In the setting of _C_API_VERSION, what does the string >"PDCurses M" mean? (In particular, what does the 'M' stand for?) _C_API_VERSION setting to numeric constant PDC_BUILD currentli 2601. Bat _C_API_NAME setting to name of C curses library. I modyfy source of PDCurses and add suffix "M". Currently all my changes applay in head branch, and suffix "M" not nidded. ;-) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-16 02:20 Message: Logged In: YES user_id=11375 In the cursesmodule patch, the first argument to intrflush is changed from NULL to stdscr. Why? According to the ncurses man page, the window argument is ignored. use_env() is apparently a no-op for PDcurses; why not just remove the Python-visible use_env function completely? In the setting of _C_API_VERSION, what does the string "PDCurses M" mean? (In particular, what does the 'M' stand for?) Except for the above questions, the patches to test_curses.py and _cursesmodule.c look OK. I have no access to a Windows machine and no way to test them or the new .mak file, so I'm reassigning this bug to Jason Tishler, who does a lot of Cygwin work. Jason, please feel free to ask me any questions you might have about curses, the _cursesmodule.c file, or whatever. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005895&group_id=5470 From noreply at sourceforge.net Thu Jun 16 15:48:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Jun 2005 06:48:32 -0700 Subject: [Patches] [ python-Patches-1005895 ] curses for win32 Message-ID: Patches item #1005895, was opened at 2004-08-09 03:05 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005895&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Alexandr Zamaraev (shura_zam) Assigned to: Jason Tishler (jlt63) Summary: curses for win32 Initial Comment: I have paths for compile _curses module. I use compiler - mingw32 v3.3.1 curses library - Public Domain Curses (PDCurses 2.6) ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2005-06-16 05:48 Message: Logged In: YES user_id=86216 > I have no access to a Windows machine and no way > to test them or the new .mak file, so I'm > reassigning this bug to Jason Tishler, who does a > lot of Cygwin work. Jason, please feel free to > ask me any questions you might have about curses, > the _cursesmodule.c file, or whatever. Andrew, Sorry, but I'm confused. What exactly are you asking me to do? Make sure Alexandr's patch doesn't break the Cygwin build? Other builds? Works? Thanks, Jason ---------------------------------------------------------------------- Comment By: Alexandr Zamaraev (shura_zam) Date: 2005-06-15 20:45 Message: Logged In: YES user_id=980085 >In the cursesmodule patch, the first argument to intrflush >is changed from NULL to stdscr. Why? In PDCurses intrflush return ERR if first arg is NULL. >In the setting of _C_API_VERSION, what does the string >"PDCurses M" mean? (In particular, what does the 'M' stand for?) _C_API_VERSION setting to numeric constant PDC_BUILD currentli 2601. Bat _C_API_NAME setting to name of C curses library. I modyfy source of PDCurses and add suffix "M". Currently all my changes applay in head branch, and suffix "M" not nidded. ;-) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-15 11:20 Message: Logged In: YES user_id=11375 In the cursesmodule patch, the first argument to intrflush is changed from NULL to stdscr. Why? According to the ncurses man page, the window argument is ignored. use_env() is apparently a no-op for PDcurses; why not just remove the Python-visible use_env function completely? In the setting of _C_API_VERSION, what does the string "PDCurses M" mean? (In particular, what does the 'M' stand for?) Except for the above questions, the patches to test_curses.py and _cursesmodule.c look OK. I have no access to a Windows machine and no way to test them or the new .mak file, so I'm reassigning this bug to Jason Tishler, who does a lot of Cygwin work. Jason, please feel free to ask me any questions you might have about curses, the _cursesmodule.c file, or whatever. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005895&group_id=5470 From noreply at sourceforge.net Thu Jun 16 16:02:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Jun 2005 07:02:09 -0700 Subject: [Patches] [ python-Patches-1005895 ] curses for win32 Message-ID: Patches item #1005895, was opened at 2004-08-09 07:05 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005895&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Alexandr Zamaraev (shura_zam) Assigned to: Jason Tishler (jlt63) Summary: curses for win32 Initial Comment: I have paths for compile _curses module. I use compiler - mingw32 v3.3.1 curses library - Public Domain Curses (PDCurses 2.6) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-16 10:02 Message: Logged In: YES user_id=11375 As maintainer of the curses module, applying the patch is OK with me, but I'm not going to apply it because I don't use Cygwin, the affected platform. I leave it up to you to apply the patch, or reject it, or demand changes; I'm happy if you decide to apply it, but don't really care. (Note that the patch to test_curses.py won't apply cleanly; it includes some other fixes from Alexandr that I've already applied. If you decide to accept the patch, I can help straighten out test_curses.py.) ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2005-06-16 09:48 Message: Logged In: YES user_id=86216 > I have no access to a Windows machine and no way > to test them or the new .mak file, so I'm > reassigning this bug to Jason Tishler, who does a > lot of Cygwin work. Jason, please feel free to > ask me any questions you might have about curses, > the _cursesmodule.c file, or whatever. Andrew, Sorry, but I'm confused. What exactly are you asking me to do? Make sure Alexandr's patch doesn't break the Cygwin build? Other builds? Works? Thanks, Jason ---------------------------------------------------------------------- Comment By: Alexandr Zamaraev (shura_zam) Date: 2005-06-16 00:45 Message: Logged In: YES user_id=980085 >In the cursesmodule patch, the first argument to intrflush >is changed from NULL to stdscr. Why? In PDCurses intrflush return ERR if first arg is NULL. >In the setting of _C_API_VERSION, what does the string >"PDCurses M" mean? (In particular, what does the 'M' stand for?) _C_API_VERSION setting to numeric constant PDC_BUILD currentli 2601. Bat _C_API_NAME setting to name of C curses library. I modyfy source of PDCurses and add suffix "M". Currently all my changes applay in head branch, and suffix "M" not nidded. ;-) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-15 15:20 Message: Logged In: YES user_id=11375 In the cursesmodule patch, the first argument to intrflush is changed from NULL to stdscr. Why? According to the ncurses man page, the window argument is ignored. use_env() is apparently a no-op for PDcurses; why not just remove the Python-visible use_env function completely? In the setting of _C_API_VERSION, what does the string "PDCurses M" mean? (In particular, what does the 'M' stand for?) Except for the above questions, the patches to test_curses.py and _cursesmodule.c look OK. I have no access to a Windows machine and no way to test them or the new .mak file, so I'm reassigning this bug to Jason Tishler, who does a lot of Cygwin work. Jason, please feel free to ask me any questions you might have about curses, the _cursesmodule.c file, or whatever. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005895&group_id=5470 From noreply at sourceforge.net Thu Jun 16 17:28:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Jun 2005 08:28:29 -0700 Subject: [Patches] [ python-Patches-1005895 ] curses for win32 Message-ID: Patches item #1005895, was opened at 2004-08-09 03:05 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005895&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Alexandr Zamaraev (shura_zam) Assigned to: Jason Tishler (jlt63) Summary: curses for win32 Initial Comment: I have paths for compile _curses module. I use compiler - mingw32 v3.3.1 curses library - Public Domain Curses (PDCurses 2.6) ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2005-06-16 07:28 Message: Logged In: YES user_id=86216 If the patch affects Cygwin, then it's not obvious: $ fgrep -i cygwin _cursesmodule.c.patch mingw32.mak test_curses.py.patch $ However, it seems to affect the native Windows build: $ grep -i 'platform.*win' _cursesmodule.c.patch mingw32.mak test_curses.py.patch test_curses.py.patch:+ if sys.platform == 'win32': Please point out actually where the patch affects Cygwin. Thanks. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-16 06:02 Message: Logged In: YES user_id=11375 As maintainer of the curses module, applying the patch is OK with me, but I'm not going to apply it because I don't use Cygwin, the affected platform. I leave it up to you to apply the patch, or reject it, or demand changes; I'm happy if you decide to apply it, but don't really care. (Note that the patch to test_curses.py won't apply cleanly; it includes some other fixes from Alexandr that I've already applied. If you decide to accept the patch, I can help straighten out test_curses.py.) ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2005-06-16 05:48 Message: Logged In: YES user_id=86216 > I have no access to a Windows machine and no way > to test them or the new .mak file, so I'm > reassigning this bug to Jason Tishler, who does a > lot of Cygwin work. Jason, please feel free to > ask me any questions you might have about curses, > the _cursesmodule.c file, or whatever. Andrew, Sorry, but I'm confused. What exactly are you asking me to do? Make sure Alexandr's patch doesn't break the Cygwin build? Other builds? Works? Thanks, Jason ---------------------------------------------------------------------- Comment By: Alexandr Zamaraev (shura_zam) Date: 2005-06-15 20:45 Message: Logged In: YES user_id=980085 >In the cursesmodule patch, the first argument to intrflush >is changed from NULL to stdscr. Why? In PDCurses intrflush return ERR if first arg is NULL. >In the setting of _C_API_VERSION, what does the string >"PDCurses M" mean? (In particular, what does the 'M' stand for?) _C_API_VERSION setting to numeric constant PDC_BUILD currentli 2601. Bat _C_API_NAME setting to name of C curses library. I modyfy source of PDCurses and add suffix "M". Currently all my changes applay in head branch, and suffix "M" not nidded. ;-) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-15 11:20 Message: Logged In: YES user_id=11375 In the cursesmodule patch, the first argument to intrflush is changed from NULL to stdscr. Why? According to the ncurses man page, the window argument is ignored. use_env() is apparently a no-op for PDcurses; why not just remove the Python-visible use_env function completely? In the setting of _C_API_VERSION, what does the string "PDCurses M" mean? (In particular, what does the 'M' stand for?) Except for the above questions, the patches to test_curses.py and _cursesmodule.c look OK. I have no access to a Windows machine and no way to test them or the new .mak file, so I'm reassigning this bug to Jason Tishler, who does a lot of Cygwin work. Jason, please feel free to ask me any questions you might have about curses, the _cursesmodule.c file, or whatever. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005895&group_id=5470 From noreply at sourceforge.net Thu Jun 16 17:34:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Jun 2005 08:34:26 -0700 Subject: [Patches] [ python-Patches-1005895 ] curses for win32 Message-ID: Patches item #1005895, was opened at 2004-08-09 07:05 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005895&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Alexandr Zamaraev (shura_zam) Assigned to: Jason Tishler (jlt63) Summary: curses for win32 Initial Comment: I have paths for compile _curses module. I use compiler - mingw32 v3.3.1 curses library - Public Domain Curses (PDCurses 2.6) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-16 11:34 Message: Logged In: YES user_id=11375 Ah; I looked at the initial description which says 'mingw32' was used, and thought that was the Cygwin compiler. Sorry! If this patch applies to the standard windows build, just unassign it; some Windows person will have to look at it. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2005-06-16 11:28 Message: Logged In: YES user_id=86216 If the patch affects Cygwin, then it's not obvious: $ fgrep -i cygwin _cursesmodule.c.patch mingw32.mak test_curses.py.patch $ However, it seems to affect the native Windows build: $ grep -i 'platform.*win' _cursesmodule.c.patch mingw32.mak test_curses.py.patch test_curses.py.patch:+ if sys.platform == 'win32': Please point out actually where the patch affects Cygwin. Thanks. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-16 10:02 Message: Logged In: YES user_id=11375 As maintainer of the curses module, applying the patch is OK with me, but I'm not going to apply it because I don't use Cygwin, the affected platform. I leave it up to you to apply the patch, or reject it, or demand changes; I'm happy if you decide to apply it, but don't really care. (Note that the patch to test_curses.py won't apply cleanly; it includes some other fixes from Alexandr that I've already applied. If you decide to accept the patch, I can help straighten out test_curses.py.) ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2005-06-16 09:48 Message: Logged In: YES user_id=86216 > I have no access to a Windows machine and no way > to test them or the new .mak file, so I'm > reassigning this bug to Jason Tishler, who does a > lot of Cygwin work. Jason, please feel free to > ask me any questions you might have about curses, > the _cursesmodule.c file, or whatever. Andrew, Sorry, but I'm confused. What exactly are you asking me to do? Make sure Alexandr's patch doesn't break the Cygwin build? Other builds? Works? Thanks, Jason ---------------------------------------------------------------------- Comment By: Alexandr Zamaraev (shura_zam) Date: 2005-06-16 00:45 Message: Logged In: YES user_id=980085 >In the cursesmodule patch, the first argument to intrflush >is changed from NULL to stdscr. Why? In PDCurses intrflush return ERR if first arg is NULL. >In the setting of _C_API_VERSION, what does the string >"PDCurses M" mean? (In particular, what does the 'M' stand for?) _C_API_VERSION setting to numeric constant PDC_BUILD currentli 2601. Bat _C_API_NAME setting to name of C curses library. I modyfy source of PDCurses and add suffix "M". Currently all my changes applay in head branch, and suffix "M" not nidded. ;-) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-15 15:20 Message: Logged In: YES user_id=11375 In the cursesmodule patch, the first argument to intrflush is changed from NULL to stdscr. Why? According to the ncurses man page, the window argument is ignored. use_env() is apparently a no-op for PDcurses; why not just remove the Python-visible use_env function completely? In the setting of _C_API_VERSION, what does the string "PDCurses M" mean? (In particular, what does the 'M' stand for?) Except for the above questions, the patches to test_curses.py and _cursesmodule.c look OK. I have no access to a Windows machine and no way to test them or the new .mak file, so I'm reassigning this bug to Jason Tishler, who does a lot of Cygwin work. Jason, please feel free to ask me any questions you might have about curses, the _cursesmodule.c file, or whatever. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005895&group_id=5470 From noreply at sourceforge.net Thu Jun 16 19:24:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Jun 2005 10:24:53 -0700 Subject: [Patches] [ python-Patches-1005895 ] curses for win32 Message-ID: Patches item #1005895, was opened at 2004-08-09 03:05 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005895&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Alexandr Zamaraev (shura_zam) >Assigned to: Nobody/Anonymous (nobody) Summary: curses for win32 Initial Comment: I have paths for compile _curses module. I use compiler - mingw32 v3.3.1 curses library - Public Domain Curses (PDCurses 2.6) ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2005-06-16 09:24 Message: Logged In: YES user_id=86216 AFAICT, this patch applies to the standard Windows build. So, I'm unassigning it as suggested by Andrew. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-16 07:34 Message: Logged In: YES user_id=11375 Ah; I looked at the initial description which says 'mingw32' was used, and thought that was the Cygwin compiler. Sorry! If this patch applies to the standard windows build, just unassign it; some Windows person will have to look at it. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2005-06-16 07:28 Message: Logged In: YES user_id=86216 If the patch affects Cygwin, then it's not obvious: $ fgrep -i cygwin _cursesmodule.c.patch mingw32.mak test_curses.py.patch $ However, it seems to affect the native Windows build: $ grep -i 'platform.*win' _cursesmodule.c.patch mingw32.mak test_curses.py.patch test_curses.py.patch:+ if sys.platform == 'win32': Please point out actually where the patch affects Cygwin. Thanks. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-16 06:02 Message: Logged In: YES user_id=11375 As maintainer of the curses module, applying the patch is OK with me, but I'm not going to apply it because I don't use Cygwin, the affected platform. I leave it up to you to apply the patch, or reject it, or demand changes; I'm happy if you decide to apply it, but don't really care. (Note that the patch to test_curses.py won't apply cleanly; it includes some other fixes from Alexandr that I've already applied. If you decide to accept the patch, I can help straighten out test_curses.py.) ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2005-06-16 05:48 Message: Logged In: YES user_id=86216 > I have no access to a Windows machine and no way > to test them or the new .mak file, so I'm > reassigning this bug to Jason Tishler, who does a > lot of Cygwin work. Jason, please feel free to > ask me any questions you might have about curses, > the _cursesmodule.c file, or whatever. Andrew, Sorry, but I'm confused. What exactly are you asking me to do? Make sure Alexandr's patch doesn't break the Cygwin build? Other builds? Works? Thanks, Jason ---------------------------------------------------------------------- Comment By: Alexandr Zamaraev (shura_zam) Date: 2005-06-15 20:45 Message: Logged In: YES user_id=980085 >In the cursesmodule patch, the first argument to intrflush >is changed from NULL to stdscr. Why? In PDCurses intrflush return ERR if first arg is NULL. >In the setting of _C_API_VERSION, what does the string >"PDCurses M" mean? (In particular, what does the 'M' stand for?) _C_API_VERSION setting to numeric constant PDC_BUILD currentli 2601. Bat _C_API_NAME setting to name of C curses library. I modyfy source of PDCurses and add suffix "M". Currently all my changes applay in head branch, and suffix "M" not nidded. ;-) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-15 11:20 Message: Logged In: YES user_id=11375 In the cursesmodule patch, the first argument to intrflush is changed from NULL to stdscr. Why? According to the ncurses man page, the window argument is ignored. use_env() is apparently a no-op for PDcurses; why not just remove the Python-visible use_env function completely? In the setting of _C_API_VERSION, what does the string "PDCurses M" mean? (In particular, what does the 'M' stand for?) Except for the above questions, the patches to test_curses.py and _cursesmodule.c look OK. I have no access to a Windows machine and no way to test them or the new .mak file, so I'm reassigning this bug to Jason Tishler, who does a lot of Cygwin work. Jason, please feel free to ask me any questions you might have about curses, the _cursesmodule.c file, or whatever. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005895&group_id=5470 From noreply at sourceforge.net Thu Jun 16 19:41:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Jun 2005 10:41:17 -0700 Subject: [Patches] [ python-Patches-1209781 ] Build Python2.4.1 on AIX5 using xlc v6 Message-ID: Patches item #1209781, was opened at 2005-05-27 11:53 Message generated for change (Comment added) made by npkg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1209781&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: Gangadhar NPK (npkg) Assigned to: Nobody/Anonymous (nobody) Summary: Build Python2.4.1 on AIX5 using xlc v6 Initial Comment: Using IBM's Visualage compiler to build Python on AIX, requires small changes to the code, to let it compile cleanly. OS version: AIX 5.2 xlc version: 6 The changes are: 1 AIX defines hz as a preprocessor symbol and it creates a conflict during preprocessing in the _codecs_cn.c. This symbol has been selectively undefined for AIX only 2.Trailing commas in an enum 3. Multiple defines of the _THREAD_SAFE symbol in python/thread.c. This has been selectively undefined. ---------------------------------------------------------------------- >Comment By: Gangadhar NPK (npkg) Date: 2005-06-16 17:41 Message: Logged In: YES user_id=587037 Sorry for not responding, was a little busy. I will check the last one - could be because of the patch levels too. Will check and post it here. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-30 08:25 Message: Logged In: YES user_id=21627 These patches look fine except for the last chunk. I very much doubt that xlc cannot handle multiple defines; ISO C mandates that a redefine is allowed as long as the replacement lists of the macros are identical (6.10.3p2). So if xlc complains, it is likely that it has a different definition than the one it reports a conflict is. Also, it is unclear what precisely the conflict is: AFAICT, Python never defines _THREAD_SAFE itself. So the conflict must be between two AIX header files. Can you please investigate this aspect further? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1209781&group_id=5470 From noreply at sourceforge.net Thu Jun 16 20:08:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Jun 2005 11:08:34 -0700 Subject: [Patches] [ python-Patches-1182394 ] HMAC hexdigest and general review Message-ID: Patches item #1182394, was opened at 2005-04-13 13:08 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1182394&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: Shane Holloway (shane_holloway) Assigned to: Nobody/Anonymous (nobody) Summary: HMAC hexdigest and general review Initial Comment: This patch is primarily aimed at speeding up the HMAC.hexdigest method. The current implementation is:: return "".join([hex(ord(x))[2:].zfill(2) for x in tuple(self.digest())]) Which is correct, but a little too clever. Especially when other tools are available. The attached patch adds HMAC._current that returns the hash object combined from self.inner and self.outter to be used by HMAC.digest and HMAC.hexdigest. This results in an 11 fold speed improvement for md5 and sha digestmod's while also making the code a little easier. Other review points for the HMAC module include removing "_secret_backdoor_key" in favor of using "None" as the sentinel. In this case, it makes sense to use None because it is an invalid key, avoids a global lookup in py2.4 and beyond, and is just as readable. I also moved blocksize to a class level constant. This allows implementations to create different blocksize hashes by inheriting and changing this value. This also involved a change to copy() to use self.__class__(None) instead of directly calling HMAC(None). The final comment is that it would be nice to have a C-level implementation of _strxor in binascii for this module and possibly other uses. However, I don't really know a significantly faster way of implementing this method in python. Thanks, -Shane Holloway ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-16 14:08 Message: Logged In: YES user_id=11375 The HMAC._current() change and adding self.blocksize both look reasonable. I don't see the point of the _secret_backdoor_key change, though; accidentally using None or calling HMAC() will get an object that fails to work, and the speedup seems too small to compensate for this. Do you have a use case that requires making lots of HMAC.copy() calls? If the backdoor_key gets taken out, I don't think we need to keep the name around for backward compatibility; no callers of the module should have been using it. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-04-26 12:32 Message: Logged In: YES user_id=341410 Obviously "always have a length of 4" should have been "always have a length of zero modulo 4". ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-04-26 03:10 Message: Logged In: YES user_id=341410 I think the patch looks good. Though perhaps leaving a... _secret_backdoor_key = None ... for backwards compatibility is a good idea. The fastest method I've found (in pure Python) for xoring strings is to use an array.array, with the largest typecode that is a divisor of your sequence (cooking your strings to always have a length of 4 and to use signed 4 byte longs seems to work well on PII/PIII based systems). Alternatively, writing it in C and compiling it with the new GCC 4 will offer automatic vectorization, and save allocating Python integers. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-14 03:54 Message: Logged In: YES user_id=6656 Attempting to add the ^ for strings is a non-starter. No opinion on the rest of the patch. ---------------------------------------------------------------------- Comment By: Shane Holloway (shane_holloway) Date: 2005-04-13 17:21 Message: Logged In: YES user_id=283742 I would prefer to keep str's interface lean. I think binascii would be a nice home for strxor though. ---------------------------------------------------------------------- Comment By: Antti Louko (alouko) Date: 2005-04-13 14:01 Message: Logged In: YES user_id=116402 This seems good. I would also need strxor. Should we add it to the string type? ^ operator is not currently defined for strings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1182394&group_id=5470 From noreply at sourceforge.net Thu Jun 16 20:19:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Jun 2005 11:19:48 -0700 Subject: [Patches] [ python-Patches-1180012 ] no html file for modulefinder Message-ID: Patches item #1180012, was opened at 2005-04-09 22:18 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1180012&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: no html file for modulefinder Initial Comment: libmodulefinder.tex exists from 2.4 branch but html file is not created and modulefinder is not listed in Global Module Index. http://www.python.org/doc/2.4.1/modindex.html The fix is trivial. Just add \input{modulefinder} to Doc/lib/lib.tex. My only concern is where modulefinder should reside. Since its main purpose is to parse source codes, "Python Language Services" seems best. But it also seems reasonable to put it in "Python Runtime Services" along with imp or zipimport modules that also do import-related jobs. If this is intentional(the doc is just a draft and not completed yet), feel free to mark this invalid or whatever. Status of bug #914375 is still open. [modulefinder is not documented] http://www.python.org/sf/914375 ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-16 14:19 Message: Logged In: YES user_id=11375 Bad documentation is better than nothing, so it should be linked in. "Runtime Services" seems like the right section to me; Fred can always change it if he disagrees. Please check in the change, on both the HEAD and 2.4-maint branches. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 14:12 Message: Logged In: YES user_id=1188172 Okay to check in? ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-04-10 00:28 Message: Logged In: YES user_id=671362 My fault. \input{modulefinder} should be :: \input{libmodulefinder} ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1180012&group_id=5470 From noreply at sourceforge.net Thu Jun 16 20:24:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Jun 2005 11:24:15 -0700 Subject: [Patches] [ python-Patches-1173998 ] Python crashes in pyexpat.c if malformed XML is parsed Message-ID: Patches item #1173998, was opened at 2005-03-31 05:59 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1173998&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.3 Status: Open Resolution: Works For Me Priority: 7 Submitted By: pdecat (pdecat) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Python crashes in pyexpat.c if malformed XML is parsed Initial Comment: If a malformed XML file (containing non unicode characters) is parsed with pyexpat, python crashes. Most details on request. ---------------------------------------------------------------------- Comment By: pdecat (pdecat) Date: 2005-03-31 08:00 Message: Logged In: YES user_id=1210681 STRING_CONV_FUNC returns NULL if the string is contains non-ascii and non-unicode characters. ---------------------------------------------------------------------- Comment By: pdecat (pdecat) Date: 2005-03-31 07:18 Message: Logged In: YES user_id=1210681 Maybe security related, as it can lead to denial of service: it crashes a Zope server using the ParsedXML product simply by uploading a malformed XML file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1173998&group_id=5470 From noreply at sourceforge.net Thu Jun 16 20:24:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Jun 2005 11:24:33 -0700 Subject: [Patches] [ python-Patches-1173998 ] Python crashes in pyexpat.c if malformed XML is parsed Message-ID: Patches item #1173998, was opened at 2005-03-31 05:59 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1173998&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.3 Status: Open Resolution: Works For Me Priority: 7 Submitted By: pdecat (pdecat) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Python crashes in pyexpat.c if malformed XML is parsed Initial Comment: If a malformed XML file (containing non unicode characters) is parsed with pyexpat, python crashes. Most details on request. ---------------------------------------------------------------------- Comment By: pdecat (pdecat) Date: 2005-03-31 08:00 Message: Logged In: YES user_id=1210681 STRING_CONV_FUNC returns NULL if the string is contains non-ascii and non-unicode characters. ---------------------------------------------------------------------- Comment By: pdecat (pdecat) Date: 2005-03-31 07:18 Message: Logged In: YES user_id=1210681 Maybe security related, as it can lead to denial of service: it crashes a Zope server using the ParsedXML product simply by uploading a malformed XML file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1173998&group_id=5470 From noreply at sourceforge.net Fri Jun 17 03:26:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Jun 2005 18:26:33 -0700 Subject: [Patches] [ python-Patches-677103 ] PYTHONBYTECODEBASE patch (PEP 304) Message-ID: Patches item #677103, was opened at 2003-01-29 16:49 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677103&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: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: PYTHONBYTECODEBASE patch (PEP 304) Initial Comment: This is just a placeholder patch related to PEP 304. Feel free to comment on it. It's far from complete at this point. The first patch is just to see if we can do all the proper detection at startup. These checks have to be performed before any .py files are imported, otherwise you'd have some .pyc files dumped out before the machinery is ready to go. The first patch contains mods to sysmodule.c with next to no concern for platform independence. There is a small shell script and a few expected output files which are used to test setting of various values. These should probably be wrapped into regular PyUnit tests which popen() the interpreter with different settings, but this seemed quicker as a start. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-06-16 20:26 Message: Logged In: YES user_id=44345 Update patch for current CVS (2.5a0)... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-11-14 17:12 Message: Logged In: YES user_id=44345 *sigh* - let's try again... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-11-14 16:48 Message: Logged In: YES user_id=44345 Patch updated for current CVS (~ 2.4b2). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-31 11:37 Message: Logged In: YES user_id=44345 Another patch. This one fixes the problems of the one I withdrew yesterday. There are still problems: * A half dozen regression tests fail for various reasons which I haven't completely investigated. * Nothing has been done for Windows. Someone will have to step up to the plate for this. I can't build on Windows. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-30 16:51 Message: Logged In: YES user_id=44345 While not technically broken, the patch I just posted is a bit bent. Withdrawing for a little fixup... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-30 16:33 Message: Logged In: YES user_id=44345 Here's an updated context diff. It seems to do the right thing on my Mac OS X system. It won't currently do anything on Windows ( need help there). No more test cases, but if PYTHONBYTECODEBASE points to a valid directory, the .pyc files seem to get put in all the right places. To get the behavior, you'll have to configure --with-bytecodebase. Feedback, please... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-29 16:52 Message: Logged In: YES user_id=44345 second upload try - what the hell is with SF? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677103&group_id=5470 From noreply at sourceforge.net Fri Jun 17 14:29:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Jun 2005 05:29:06 -0700 Subject: [Patches] [ python-Patches-1222585 ] C++ compilation support for distutils Message-ID: Patches item #1222585, was opened at 2005-06-17 15:29 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=1222585&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: Antti Honkela (ahonkela) Assigned to: Nobody/Anonymous (nobody) Summary: C++ compilation support for distutils Initial Comment: Add more proper C++ compilation support to distutils by propagating information on used language to compiler as well as linker. The information is used by unixccompiler, cygwinccompiler and emxccompiler to call a C++ compiler instead of a C compiler. Options for the call are formed by as a union of options to both C and C++ compilers. The old version worked by accident on some platforms where you can compile C++ programs by calling the C compiler (e.g. gcc), but not on others (e.g. Tru64 Unix, probably also others not using gcc). The more compilcated handling of options than with linker is necessary to properly support manual overrides such as "CXX=g++ -foo". The attached patch is against CVS HEAD, but applies with minimal changes at least to Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1222585&group_id=5470 From noreply at sourceforge.net Sat Jun 18 22:07:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Jun 2005 13:07:54 -0700 Subject: [Patches] [ python-Patches-1180012 ] no html file for modulefinder Message-ID: Patches item #1180012, was opened at 2005-04-10 04:18 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1180012&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: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: no html file for modulefinder Initial Comment: libmodulefinder.tex exists from 2.4 branch but html file is not created and modulefinder is not listed in Global Module Index. http://www.python.org/doc/2.4.1/modindex.html The fix is trivial. Just add \input{modulefinder} to Doc/lib/lib.tex. My only concern is where modulefinder should reside. Since its main purpose is to parse source codes, "Python Language Services" seems best. But it also seems reasonable to put it in "Python Runtime Services" along with imp or zipimport modules that also do import-related jobs. If this is intentional(the doc is just a draft and not completed yet), feel free to mark this invalid or whatever. Status of bug #914375 is still open. [modulefinder is not documented] http://www.python.org/sf/914375 ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-18 22:07 Message: Logged In: YES user_id=1188172 Okay, checked in as Doc/lib/lib.tex rev1.231.2.2, rev1.239. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-16 20:19 Message: Logged In: YES user_id=11375 Bad documentation is better than nothing, so it should be linked in. "Runtime Services" seems like the right section to me; Fred can always change it if he disagrees. Please check in the change, on both the HEAD and 2.4-maint branches. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 20:12 Message: Logged In: YES user_id=1188172 Okay to check in? ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-04-10 06:28 Message: Logged In: YES user_id=671362 My fault. \input{modulefinder} should be :: \input{libmodulefinder} ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1180012&group_id=5470 From noreply at sourceforge.net Sat Jun 18 22:59:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Jun 2005 13:59:21 -0700 Subject: [Patches] [ python-Patches-1200018 ] Restore GC support to set objects Message-ID: Patches item #1200018, was opened at 2005-05-11 12:16 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200018&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: Accepted Priority: 7 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Raymond Hettinger (rhettinger) Summary: Restore GC support to set objects Initial Comment: Contrary to what the log message for setobject.c 1.26 implies, built-in sets can indeed participate in cycles, so they must support GC. This patch restores GC support to built-in sets for Python 2.4. It should be ported to Python 2.5. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-18 15:59 Message: Logged In: YES user_id=80475 Okay, fixed. Kept the PyDict_Clear since that is what is done in dictobject.c. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-05-11 17:41 Message: Logged In: YES user_id=12800 Even without the __del__() method, notice how the second gc.collect() prints 0. With the patch it prints 4. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-05-11 17:20 Message: Logged In: YES user_id=764593 Clarification: cycle.py *as posted* does not demonstrate the problem, but if you uncomment the __del__ method in class foo, you will get uncollectable garbage. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-05-11 14:59 Message: Logged In: YES user_id=12800 cycle.py demonstrates the need for this patch ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-05-11 14:58 Message: Logged In: YES user_id=12800 Actually, use set-patch2.txt because I don't believe you need to clear so->data in set_tp_clear(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200018&group_id=5470 From noreply at sourceforge.net Sun Jun 19 01:08:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Jun 2005 16:08:41 -0700 Subject: [Patches] [ python-Patches-1223381 ] PEP 342/343 Generator enhancements Message-ID: Patches item #1223381, was opened at 2005-06-18 23: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=1223381&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: Phillip J. Eby (pje) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 342/343 Generator enhancements Initial Comment: The attached patch implements code and test changes for: * yield expressions * bare yield (short for yield None) * yield in try/finally * generator.send(value) (send value into generator; substituted for PEP 342's next(arg)) * generator.throw(typ[,val[,tb]]) (raise error in generator) * generator.close() (per PEP 343) * GeneratorExit built-in exception type * generator.__del__ (well, the C equivalent) * All necessary mods to the compiler, parser module, and Python 'compiler' package to support these changes. It was necessary to change a small part of the eval loop (well, the initialization, not the loop) and the gc module's has_finalizer() logic in order to support a C equivalent to __del__. Specialists in these areas should probably scrutinize this patch! There is one additional implementation detail that was not contemplated in either PEP. in order to prevent used-up generators from retaining unnecessary references to their frame's contents, I set the generator's gi_frame member to None whenever the generator finishes normally or with an error. Thus, an exhausted generator cannot be part of a cycle, and it releases its frame object sooner than in previous Python versions. For generators used only in a direct "for" loop, this makes no difference, but for generators used with the iterator protocol (i.e. "gen.next()") from Python, this avoids stranding the generator's frame in a traceback cycle. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1223381&group_id=5470 From noreply at sourceforge.net Sun Jun 19 09:37:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Jun 2005 00:37:33 -0700 Subject: [Patches] [ python-Patches-1223381 ] PEP 342/343 Generator enhancements Message-ID: Patches item #1223381, was opened at 2005-06-19 01:08 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1223381&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: Phillip J. Eby (pje) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 342/343 Generator enhancements Initial Comment: The attached patch implements code and test changes for: * yield expressions * bare yield (short for yield None) * yield in try/finally * generator.send(value) (send value into generator; substituted for PEP 342's next(arg)) * generator.throw(typ[,val[,tb]]) (raise error in generator) * generator.close() (per PEP 343) * GeneratorExit built-in exception type * generator.__del__ (well, the C equivalent) * All necessary mods to the compiler, parser module, and Python 'compiler' package to support these changes. It was necessary to change a small part of the eval loop (well, the initialization, not the loop) and the gc module's has_finalizer() logic in order to support a C equivalent to __del__. Specialists in these areas should probably scrutinize this patch! There is one additional implementation detail that was not contemplated in either PEP. in order to prevent used-up generators from retaining unnecessary references to their frame's contents, I set the generator's gi_frame member to None whenever the generator finishes normally or with an error. Thus, an exhausted generator cannot be part of a cycle, and it releases its frame object sooner than in previous Python versions. For generators used only in a direct "for" loop, this makes no difference, but for generators used with the iterator protocol (i.e. "gen.next()") from Python, this avoids stranding the generator's frame in a traceback cycle. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-19 09:37 Message: Logged In: YES user_id=1188172 Minor nit: on line 642, 'yield_stmt' should be changed to 'yield_expr'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1223381&group_id=5470 From noreply at sourceforge.net Sun Jun 19 20:57:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Jun 2005 11:57:00 -0700 Subject: [Patches] [ python-Patches-1196917 ] change recall in IDLE shell to not overwrite current command Message-ID: Patches item #1196917, was opened at 2005-05-06 16:55 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196917&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: Accepted Priority: 5 Submitted By: Jeff Shute (jshute) >Assigned to: Kurt B. Kaiser (kbk) Summary: change recall in IDLE shell to not overwrite current command Initial Comment: Currently, when you move the cursor over any previous command/output and press enter, IDLE replaces the command you are currently typing with that text. I find this behaviour very annoying because I often end up doing it by accident when I switch from another window back to IDLE, and it cannot be undone, so I lose whatever command I was building up. This patch changes the behaviour so that instead of replacing your current text with the text under the cursor, the text under the cursor is inserted at the current location, using the auto-indenter to make sure it is put in the correct place. The operation also becomes undoable. This allows sequences like the following: >>> comp1() 5.436436 >>> comp2() 3.655546 >>> print 5.436436 + 3.655546 9.091982 where I have generated the third command like this: print [up, up, up, enter] + [up, enter][enter] or like this: >>> for a in set1: for b in set2: print a,b ... >>> for c in set3: for a in set1: for b in set2: print a,b I generate the second command by typing the first line, and then cursoring up to the previous command and pressing enter. The old loop is inserted properly indented into the new loop. (This does not work with copy and paste.) I can then continue to edit the combined command or press enter to run it. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-06-19 13:57 Message: Logged In: YES user_id=149084 PyShell.py Rev 1.97 Thanks for the patch! ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-06-10 11:15 Message: Logged In: YES user_id=488897 FWIW, I've tried this patch on Windows. I agree that it makes IDLE easier to use. I'll write to python-dev in support of this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196917&group_id=5470 From noreply at sourceforge.net Sun Jun 19 21:24:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Jun 2005 12:24:51 -0700 Subject: [Patches] [ python-Patches-1049855 ] PyOS_InputHook inconsistency on Windows Message-ID: Patches item #1049855, was opened at 2004-10-19 04:03 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1049855&group_id=5470 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: Michiel de Hoon (mdehoon) Assigned to: Nobody/Anonymous (nobody) Summary: PyOS_InputHook inconsistency on Windows Initial Comment: PyOS_InputHook is a pointer to a function to be called periodically when Python is idle. It is used, for example, to get messages delivered to graphics windows. If I compile Python from source (which uses Modules/readline.c), PyOS_InputHook is called ten times per second. However, with the Windows-version of Python, PyOS_InputHook is called only once for each command typed by the user. It seems that the problem resides in Parser/myreadline.c (which I presume is used for the Windows-version of Python): if (PyOS_InputHook != NULL) (void)(PyOS_InputHook)(); ... p = fgets(buf, len, fp); Python idles at "fgets", but PyOS_InputHook is not being called while Python is idle. The attached patch solves this problem by using the "select" function, basically in the same way as what is in Module/readline.c. I don't know how to compile Python for Windows, so I wasn't able to test this patch. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-06-10 15:46 Message: Logged In: YES user_id=488897 Thomas Heller sent me this comment: > The PyOS_StdioReadline function calls my_fgets with a file > pointer argument. The my_fgets function in the patch assumes > that STD_INPUT_HANDLE is the handle to use - is this > assumption always correct? He is right, this assumption is not necessarily correct. I have made a new patch (labeled 20050610) to solve this issue. This latest version has been tested on Cygwin, but not yet on Windows -- I need to dig up a compiler for Windows first. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-05-12 22:57 Message: Logged In: YES user_id=488897 I have rewritten the patch to include Windows support. I compiled Python on Windows with VC98, and on Linux and Mac OS X and found no problems with it. The new patch is attached. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-05-01 22:40 Message: Logged In: YES user_id=149084 Yeah, that's why I didn't want to check it in, I can't build on Windows ithe VC 5. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-05-01 21:52 Message: Logged In: YES user_id=488897 Thanks for looking at this patch. Today I found out that it is possible to compile Python 2.4.1 with the older Microsoft Visual Studio 6.0, which I happen to have in my office. It turned out that the patch does not work correctly on Windows, due to the fact that the "select" function doesn't work with stdin on Windows. I will fix the patch so it'll work on Windows too. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-04-30 13:21 Message: Logged In: YES user_id=149084 The revised patch looks ok to me. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-03-26 08:33 Message: Logged In: YES user_id=488897 I have now tested this patch. After fixing one error (I had forgotton to declare one variable), the patch works correctly. I have uploaded a fixed patch. Note that this bug occurs not only on Windows, but on any Python compiled without readline. (which allowed me to test this patch by compiling Python without readline support). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1049855&group_id=5470 From noreply at sourceforge.net Wed Jun 22 01:34:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Jun 2005 16:34:34 -0700 Subject: [Patches] [ python-Patches-1225212 ] HP-UX ia64 64-bit Python executable Message-ID: Patches item #1225212, was opened at 2005-06-21 16:34 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=1225212&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: Peter Kropf (peterk) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX ia64 64-bit Python executable Initial Comment: In working on getting a 64-bit Python to build and pass the test suites on a Itanium 2 system running HP-UX 11, there were two major issues that needed to be resolved: - on ia64 HP-UX, unistd.h does not define _POSIX_THREADS and therefore Python/thread.c was not including thread_pthreads.h even though enough of the posix threading API is available to support threads in Python. - isnan() was not being called to check floating point numbers and math.sqrt(-1) would not throw a ValueError. The attached patch make the following changes: - modifies Python/thread.c to check for __hpux and _SC_THREADS and if they're defined, then define _POSIX_THREADS. - modifies Include/pyport.h to check for __hpux and __ia64 in the macro that defines _Py_SET_EDOM_FOR_NAN. - modifies Readme to include details on how to build a 64-bit version of Python on a HP-UX based Itanium 2 system. The patch file was created by running: cvs diff -c | tee ~/hpux_ia64_port.patch from python/dist/src on a current CVS tree. The current Readme also states that there is optimization problems when building Python on an ia64 based HP-UX system using HP's C compiler. I have not found this to be a problem. Should this note be removed or marked as out of date? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1225212&group_id=5470 From noreply at sourceforge.net Wed Jun 22 12:45:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Jun 2005 03:45:50 -0700 Subject: [Patches] [ python-Patches-1220874 ] update the binhex module for Mach-O Message-ID: Patches item #1220874, was opened at 2005-06-15 03:27 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220874&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: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: update the binhex module for Mach-O Initial Comment: The binhex module only understands resource forks if os.name == 'mac', which is only true for CFM builds of Python. We haven't maintained those in years, so this has been broken for quite some time. This patch is a partial fix that allows it to de-binhex the resource fork on Mach-O, but it still doesn't do the type/creator stuff. I'm currently only using it to create one of those pesky "Icon\r" files, so this is all I fixed and tested. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2005-06-22 12:45 Message: Logged In: YES user_id=580910 You forgot to add the patch. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-06-15 03:29 Message: Logged In: YES user_id=139309 this is also a backport candidate ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220874&group_id=5470 From noreply at sourceforge.net Wed Jun 22 13:03:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Jun 2005 04:03:18 -0700 Subject: [Patches] [ python-Patches-869555 ] Building on Mac OS X 10.1 Message-ID: Patches item #869555, was opened at 2004-01-02 21:36 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=869555&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: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: Building on Mac OS X 10.1 Initial Comment: This patch contains two changes to allow building on MacOS X 10.1 1) A change to macosmodule.c that only enables the code using 'CGMainDisplayID' on MacOS X 10.2 and later, the function is not available on 10.1 2) Some conditional code in Mac/OSX/Makefile that chooses pbxbuild or xcodebuild depending on which one is on the system (prefering xcodebuild). I have barely tested these changes, they seem to work well enough on 10.1. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2005-06-22 13:03 Message: Logged In: YES user_id=580910 I don't think this is relevant anymore, anyone who still runs OSX 10.1 should upgrade to a newer version :-). ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-06-02 23:27 Message: Logged In: YES user_id=580910 No, I erased my 10.1 partition to be able to test on 10.2. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2004-06-02 23:17 Message: Logged In: YES user_id=45365 Ronald, I applied the Makefile portion of the patch. The macosmodule.c part I had already solved (but it was still sitting on my disk only) in a different way. Do you still have easy access to 10.1? If so: could you check that the 2.3 branch (and the 2.4 trunk) now builds on 10.1? If not: let me know and I'll try. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=869555&group_id=5470 From noreply at sourceforge.net Wed Jun 22 13:50:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Jun 2005 04:50:15 -0700 Subject: [Patches] [ python-Patches-1225466 ] fileinput openfile patch, bz2fileinput Message-ID: Patches item #1225466, was opened at 2005-06-22 11:50 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=1225466&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: Stephan Boettcher (sib4) Assigned to: Nobody/Anonymous (nobody) Summary: fileinput openfile patch, bz2fileinput Initial Comment: Please consider the enclosed patch to fileinput.py, which implements an openfile method of FileInput. Included is a use case bz2fileinput.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1225466&group_id=5470 From noreply at sourceforge.net Wed Jun 22 16:47:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Jun 2005 07:47:28 -0700 Subject: [Patches] [ python-Patches-1116722 ] Solaris 10 fails to compile complexobject.c [FIX incl.] Message-ID: Patches item #1116722, was opened at 2005-02-05 18:02 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&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: Case Van Horsen (casevh) Assigned to: Martin v. L?wis (loewis) Summary: Solaris 10 fails to compile complexobject.c [FIX incl.] Initial Comment: This is a duplicate of 970334. The fix I used was to make the following change in pyport.h: Change #define Py_HUGE_VAL HUGE_VAL to #define PY_HUGE_VAL DBL_MAX. DBL_MAX is found in float.h Versions used: Python 2.4 gcc 3.4.3 Solaris 10 x86 GA release. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2005-06-23 00:47 Message: Logged In: YES user_id=29957 I haven't had time to try installing Solaris 10 on anything yet - does setting _XOPEN_SOURCE in this way break anything else? (does make testall complete ok?) If you could confirm it doesn't break anything else, I'll make the change for 2.5 and 2.4.2... ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-03-19 17:06 Message: Logged In: YES user_id=1212585 I found a reference in the 2.4a3 release notes that this problem was fixed for Solaris 8 and 9 with Patch #1006629. That patch set _XOPEN_SOURCE to 500. Using 2.4.1c2 source, I patched line 1521 from SunOS/5.8|SunOS/5.9) to SunOS/5.8|SunOS/5.9|SunOS/5.10) I successfully completed a make; make test with a generic Solaris 10 x86 install. I verified that it failed without the patch. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-03-05 09:28 Message: Logged In: YES user_id=1212585 Below is the official response from Sun. It doesn't look like Sun sees it as a problem. Document Audience: SPECTRUM Document ID: 6173815 Title: bug 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Update Date: Tue Oct 05 06:44:47 MDT 2004 Bug ID: 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Category: c++ Subcategory: compiler State: 11-Closed Description: * * This is a problem I ran into trying to compile Python 2.3.4 on a Solaris * 10 beta 63 (x86) system. I worked with Martin v. Lowis * to isolate the problem as it affects Python, but our * conclusion is that this is really a GCC/Solaris problem. * * -- Chris Wicklein * * ---------------------------------------- * * $ uname -a * SunOS solaris1 5.10 s10_63 i86pc i386 i86pc * * $ gcc -v * Reading specs from /opt/gcc/lib/gcc/i386-pc- solaris2.10/3.4.2/specs * Configured with: ../gcc-3.4.2/configure --with- as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls -- prefix=/opt/gcc * Thread model: posix * gcc version 3.4.2 * * $ gcc -o foo foo.c * * $ gcc -D_STDC_C99 -o foo foo.c * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ gcc -D_STDC_C99 -o foo foo.c --save-temps * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ grep __builtin_huge_val foo.i * if (x == __builtin_huge_val) { * * ---------------------------------------- * The problem for GCC is having HUGE_VAL expanded to __builtin_huge_val * (pointer to a function returning a double) rather than to * __builtin_huge_val() (call to a function returning a double.) * * Is this an error in the header file /usr/include/iso/math_c99.h * or something that was done intentionally to support the * Sun ONE compiler? (Is this something for Sun to fix, or should * this be addressed on the GCC end?) */ #include int main (int argc, char **argv) { double x = 3.14; if (x == HUGE_VAL) { x = 2.7; } return 0; } Customer comments: It is my understanding that HUGE_VAL is a standard C feature, and the function __builtin_huge_val() is a GCC- specific extension for implementing this standard C feature. If this is correct, then by referencing __builtin_huge_val in /usr/include/iso/math_c99.h, Solaris 10 is providing GCC- specific header support. (As an aside, it's remotely possible that my copy of math_c99.h was locally modified as part of installing GCC from a third-party package, but I doubt this happened.) Assuming then that Solaris 10 is providing support for a GCC- specific built-in function (__builtin_huge_val) in math_c99.h, then that support should be corrected (by adding the missing parens.) Otherwise, it will be necessary for GCC to work- around this header problem. Here then is the crux of the matter: assuming that math_c99.h contains this reference to __builtin_huge_val without the required parens, was this done to support GCC, or is this also used by the Sun Pro compiler? If this is present only for GCC, then the missing parens should be added by Sun, or I would like to know that Sun sees this as not-a-bug, in which case GCC will have to work around this itself. At any rate, I am not requesting support for GCC, but rather trying to understand 1) why math_c99.h references __builtin_huge_val as it does in Solaris 10, and 2) if this is something Sun views as a problem on the Solaris side to be fixed. > HI Chris, > > We do not support gcc A third-party C compiler; not supported. > ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-03-05 09:26 Message: Logged In: YES user_id=1212585 Below is the official response from Sun. It doesn't look like Sun sees it as a problem. Document Audience: SPECTRUM Document ID: 6173815 Title: bug 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Update Date: Tue Oct 05 06:44:47 MDT 2004 Bug ID: 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Category: c++ Subcategory: compiler State: 11-Closed Description: * * This is a problem I ran into trying to compile Python 2.3.4 on a Solaris * 10 beta 63 (x86) system. I worked with Martin v. Lowis * to isolate the problem as it affects Python, but our * conclusion is that this is really a GCC/Solaris problem. * * -- Chris Wicklein * * ---------------------------------------- * * $ uname -a * SunOS solaris1 5.10 s10_63 i86pc i386 i86pc * * $ gcc -v * Reading specs from /opt/gcc/lib/gcc/i386-pc- solaris2.10/3.4.2/specs * Configured with: ../gcc-3.4.2/configure --with- as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls -- prefix=/opt/gcc * Thread model: posix * gcc version 3.4.2 * * $ gcc -o foo foo.c * * $ gcc -D_STDC_C99 -o foo foo.c * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ gcc -D_STDC_C99 -o foo foo.c --save-temps * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ grep __builtin_huge_val foo.i * if (x == __builtin_huge_val) { * * ---------------------------------------- * The problem for GCC is having HUGE_VAL expanded to __builtin_huge_val * (pointer to a function returning a double) rather than to * __builtin_huge_val() (call to a function returning a double.) * * Is this an error in the header file /usr/include/iso/math_c99.h * or something that was done intentionally to support the * Sun ONE compiler? (Is this something for Sun to fix, or should * this be addressed on the GCC end?) */ #include int main (int argc, char **argv) { double x = 3.14; if (x == HUGE_VAL) { x = 2.7; } return 0; } Customer comments: It is my understanding that HUGE_VAL is a standard C feature, and the function __builtin_huge_val() is a GCC- specific extension for implementing this standard C feature. If this is correct, then by referencing __builtin_huge_val in /usr/include/iso/math_c99.h, Solaris 10 is providing GCC- specific header support. (As an aside, it's remotely possible that my copy of math_c99.h was locally modified as part of installing GCC from a third-party package, but I doubt this happened.) Assuming then that Solaris 10 is providing support for a GCC- specific built-in function (__builtin_huge_val) in math_c99.h, then that support should be corrected (by adding the missing parens.) Otherwise, it will be necessary for GCC to work- around this header problem. Here then is the crux of the matter: assuming that math_c99.h contains this reference to __builtin_huge_val without the required parens, was this done to support GCC, or is this also used by the Sun Pro compiler? If this is present only for GCC, then the missing parens should be added by Sun, or I would like to know that Sun sees this as not-a-bug, in which case GCC will have to work around this itself. At any rate, I am not requesting support for GCC, but rather trying to understand 1) why math_c99.h references __builtin_huge_val as it does in Solaris 10, and 2) if this is something Sun views as a problem on the Solaris side to be fixed. > HI Chris, > > We do not support gcc A third-party C compiler; not supported. > ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-05 06:04 Message: Logged In: YES user_id=21627 Turns out casevh's report is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-05 01:18 Message: Logged In: YES user_id=21627 I have now reported this bug to gcc as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20317 ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 17:33 Message: Logged In: YES user_id=1212585 Oops. I made a typo in one of my tests. It does include in /include/iso/math_c99.h when you type it correctly. I will work with Sun / gcc to determine a resolution. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 17:03 Message: Logged In: YES user_id=1212585 I poked around in the preprocessor outputs and it appears gcc doesn't its specific directory for math_c99.h. It only appears to look in /usr/include/iso. I changed the definition of HUGE_VAL in /usr/include/iso/math_c99.h to read: #define HUGE_VAL __builtin_huge_val() The hv2.c compiled completely and so did Python 2.4. I'll open a bug report with GCC and also with Sun since I used the version of GCC that was distributed by Sun. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 16:16 Message: Logged In: YES user_id=1212585 I ran mkheaders to rebuild the gcc headers but that made no difference. The following program (hv.c) compiled correctly: #define _XOPEN_SOURCE 500 #include int main() { double f=HUGE_VAL; } The following program (hv2.c) did not compile. #define _XOPEN_SOURCE 1000 #include int main() { double f=HUGE_VAL; } Output is: $ gcc --save-temps hv.c $ gcc --save-temp hv2.c hv2.c: In function `main': hv2.c:5: error: incompatible types in initialization $ I have attached hv.i and hv2.i. I have also attached complexobject.i I'm not a C programmer so please let me know what else I can do to help. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 03:50 Message: Logged In: YES user_id=1212585 I tried steps 1 through 4 and it fails, with and with the (). I'm not sure how to do step 5. I will try the short program snippet later and report back. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-10 15:44 Message: Logged In: YES user_id=31435 Doubt this will help: googling suggests that -Xc has to be passed to Sun's native C compiler to get HUGE_VAL defined correctly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-10 14:23 Message: Logged In: YES user_id=21627 I have the Solaris 10 iso/math_c99.h in front of me, but no gcc, so it is somewhat difficult to get through the ifdefery. It appears that we should have _XOPEN_SOURCE - 0 >= 600, so we should be using #define HUGE_VAL __builtin_huge_val The problem apparently is that in Sun CC, __builtin_huge_val appears to be a constant, whereas in gcc, it probably is a function, so the definition should read #define HUGE_VAL __builtin_huge_val() So there is a bug in the gcc port of Solaris here - fixincludes should adjust the definition of HUGE_VAL when installing its adjusted copy of math_c99.h. I'm willing to accept patches to work around this gcc bug, but only if the bug gets reported to gcc first. So, please, 1. find out the gcc installation directory on your system, using gcc --print-search-dirs 2a. check whether /include/iso/math_c99.h exists 2b. if it does not exist, copy if from /usr/include/iso/math_c99.h 3. edit /include/iso/math_c99.h to add the parentheses after builtin_huge_val 4. check whether this fixes the problem 5a. if not, provide the preprocessor output for complexobject.i, using --save-temps 5b. if it does, make a bug report to gcc, indicating that the program #include int main() { double f=HUGE_VAL; } fails on Solaris 10. For that report - check whether it actually fails without the update math_c99, and succeeds with it (you might have to #define _XOPEN_SOURCE to make it fail) - include the preprocessor output for this sample program, using the original math_c99 - indicate that a solution is to add parentheses 6. Come up with a patch that checks for Solaris 10 and all gcc versions showing the problem (i.e. 3.4.x, with x<=3, perhaps also 3.y, y<=3), and defines Py_HUGE_VAL correctly for this system. 7. Report the gcc bug number and the patch in this report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-10 12:43 Message: Logged In: YES user_id=31435 The C standard requires that "The macro HUGE_VAL expands to a positive double constant expression, not necessarily representable as a float". Python requires that too. #define'ing to worm around a broken compilation environment isn't acceptable to me; finding a switch to make this environment conform to the standard would be OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 From eurosemi at eurosemi.eu.com Wed Jun 22 14:56:55 2005 From: eurosemi at eurosemi.eu.com (eurosemi@eurosemi.eu.com) Date: Wed, 22 Jun 2005 13:56:55 +0100 (BST) Subject: [Patches] Eurosemi E-News Message-ID: <20050622125655.24955D678C@silux.angelbc.co.uk> charset="iso-8859-1" Content-Transfer-Encoding:8bit +---------------------------------------------------------+ | EUROSEMI NEWSLETTER - PLAIN TEXT VERSION | | if you would like to see this in HTML goto: | | http://www.eurosemi.eu.com | +---------------------------------------------------------+ | 22nd June 2005 +---------------------------------------------------------+ | Contents | | ~~~~~~~~~ | | - SECAP ends with working 300mm line | - CEA Leti announces low power transistors for 45nm and beyond | - SEMI report looks at Chinese manufacturing trends | - Price Erosion Spurs NOR Flash Revenue Decline in 2005 +---------------------------------------------------------+ +---------------------------------------------------------+ SECAP ends with working 300mm line The Semiconductor Equipment Consortium for Advanced Packaging (SECAP) has announced that they will disband now that the consortium has successfully established 300 mm Wafer Level Packaging as a functional technology and full-volume production on the first installed wafer-bumping line is underway. To view the whole story goto:http://www.eurosemi.eu.com/cgi-bin/viewnew22.pl?id=6414 +---------------------------------------------------------+ CEA Leti announces low power transistors for 45nm and beyond Just one year after the inauguration of the Nanotec 300 research platform for the 45 and 32 nanometer microelectronics nodes, CEA Leti announced the successful completion of its first High K metal gate transistors on 300mm wafers. To view the whole story goto:http://www.eurosemi.eu.com/cgi-bin/viewnew22.pl?id=6415 +---------------------------------------------------------+ SEMI report looks at Chinese manufacturing trends SEMI has released a report that shows the Chinese semiconductor market is increasing faster than the rest of the world with 300mm wafers already being tested well before predictions based on external restrictions placed upon the country's technological growth. To view the whole story goto:http://www.eurosemi.eu.com/cgi-bin/viewnew22.pl?id=6416 +---------------------------------------------------------+ Price Erosion Spurs NOR Flash Revenue Decline in 2005 Cutthroat competition is spurring continued price erosion for NOR-type flash memory, resulting in a significant decline in market revenue this year, according to iSuppli Corp. To view the whole story goto:http://www.eurosemi.eu.com/cgi-bin/viewnew22.pl?id=6417 +--------------------------------------------------------+ | To Unsubscribe Goto | +-------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20050622/fd1878aa/attachment-0001.htm From noreply at sourceforge.net Wed Jun 22 18:00:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Jun 2005 09:00:54 -0700 Subject: [Patches] [ python-Patches-869555 ] Building on Mac OS X 10.1 Message-ID: Patches item #869555, was opened at 2004-01-02 20:36 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=869555&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: Macintosh Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: Building on Mac OS X 10.1 Initial Comment: This patch contains two changes to allow building on MacOS X 10.1 1) A change to macosmodule.c that only enables the code using 'CGMainDisplayID' on MacOS X 10.2 and later, the function is not available on 10.1 2) Some conditional code in Mac/OSX/Makefile that chooses pbxbuild or xcodebuild depending on which one is on the system (prefering xcodebuild). I have barely tested these changes, they seem to work well enough on 10.1. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-06-22 17:00 Message: Logged In: YES user_id=6656 Closing, then. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2005-06-22 12:03 Message: Logged In: YES user_id=580910 I don't think this is relevant anymore, anyone who still runs OSX 10.1 should upgrade to a newer version :-). ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-06-02 22:27 Message: Logged In: YES user_id=580910 No, I erased my 10.1 partition to be able to test on 10.2. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2004-06-02 22:17 Message: Logged In: YES user_id=45365 Ronald, I applied the Makefile portion of the patch. The macosmodule.c part I had already solved (but it was still sitting on my disk only) in a different way. Do you still have easy access to 10.1? If so: could you check that the 2.3 branch (and the 2.4 trunk) now builds on 10.1? If not: let me know and I'll try. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=869555&group_id=5470 From noreply at sourceforge.net Wed Jun 22 21:48:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Jun 2005 12:48:01 -0700 Subject: [Patches] [ python-Patches-1225769 ] Proposal to implement comment rows in csv module Message-ID: Patches item #1225769, was opened at 2005-06-22 19:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1225769&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: Iain Haslam (iain_haslam) Assigned to: Nobody/Anonymous (nobody) Summary: Proposal to implement comment rows in csv module Initial Comment: Sometimes csv files contain comment rows, for temporarily commenting out data or occasionally for documentation. The current csv module has no built-in ability to skip rows; in order to skip all lines beginning with '#', the programmer writes something like: csv_reader = csv.reader(fp) for row in csv_reader: if row[0][0] != '#': #assuming no blank lines print row I propose adding a "commentchar" parameter to the csv parser, so that the above code could be written (more elegantly, in my opinion): csv_reader = csv.reader(fp, commentchar='#') for row in csv_reader: print row This requires only relatively minor changes to the module, and by defaulting to using no comment character, existing code will behave as before. If you are interested, the patch (diffs against current cvs) required for the second example to run are attached. Note that that implementation adds SKIPPED_RECORD as a pseudonym for START_RECORD, because setting status to START_RECORD after skipping a record would cause a blank record to be returned. Altering that behaviour would cause more changes and the patch would be harder to review. I've also held back on updating tests and documentation to reflect this change, pending any support for it. It shoud be irrelevant, but this has been developed on Debian testing against the cvs head of Python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1225769&group_id=5470 From noreply at sourceforge.net Wed Jun 22 22:09:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Jun 2005 13:09:24 -0700 Subject: [Patches] [ python-Patches-1225769 ] Proposal to implement comment rows in csv module Message-ID: Patches item #1225769, was opened at 2005-06-22 14:48 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1225769&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: Iain Haslam (iain_haslam) >Assigned to: Skip Montanaro (montanaro) Summary: Proposal to implement comment rows in csv module Initial Comment: Sometimes csv files contain comment rows, for temporarily commenting out data or occasionally for documentation. The current csv module has no built-in ability to skip rows; in order to skip all lines beginning with '#', the programmer writes something like: csv_reader = csv.reader(fp) for row in csv_reader: if row[0][0] != '#': #assuming no blank lines print row I propose adding a "commentchar" parameter to the csv parser, so that the above code could be written (more elegantly, in my opinion): csv_reader = csv.reader(fp, commentchar='#') for row in csv_reader: print row This requires only relatively minor changes to the module, and by defaulting to using no comment character, existing code will behave as before. If you are interested, the patch (diffs against current cvs) required for the second example to run are attached. Note that that implementation adds SKIPPED_RECORD as a pseudonym for START_RECORD, because setting status to START_RECORD after skipping a record would cause a blank record to be returned. Altering that behaviour would cause more changes and the patch would be harder to review. I've also held back on updating tests and documentation to reflect this change, pending any support for it. It shoud be irrelevant, but this has been developed on Debian testing against the cvs head of Python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1225769&group_id=5470 From noreply at sourceforge.net Wed Jun 22 22:59:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Jun 2005 13:59:25 -0700 Subject: [Patches] [ python-Patches-1223381 ] PEP 342/343 Generator enhancements Message-ID: Patches item #1223381, was opened at 2005-06-19 00:08 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1223381&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: Phillip J. Eby (pje) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 342/343 Generator enhancements Initial Comment: The attached patch implements code and test changes for: * yield expressions * bare yield (short for yield None) * yield in try/finally * generator.send(value) (send value into generator; substituted for PEP 342's next(arg)) * generator.throw(typ[,val[,tb]]) (raise error in generator) * generator.close() (per PEP 343) * GeneratorExit built-in exception type * generator.__del__ (well, the C equivalent) * All necessary mods to the compiler, parser module, and Python 'compiler' package to support these changes. It was necessary to change a small part of the eval loop (well, the initialization, not the loop) and the gc module's has_finalizer() logic in order to support a C equivalent to __del__. Specialists in these areas should probably scrutinize this patch! There is one additional implementation detail that was not contemplated in either PEP. in order to prevent used-up generators from retaining unnecessary references to their frame's contents, I set the generator's gi_frame member to None whenever the generator finishes normally or with an error. Thus, an exhausted generator cannot be part of a cycle, and it releases its frame object sooner than in previous Python versions. For generators used only in a direct "for" loop, this makes no difference, but for generators used with the iterator protocol (i.e. "gen.next()") from Python, this avoids stranding the generator's frame in a traceback cycle. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-06-22 21:59 Message: Logged In: YES user_id=6656 Argh, I'd hoped you'd done with, too :) Have you done any work on that yet? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-19 08:37 Message: Logged In: YES user_id=1188172 Minor nit: on line 642, 'yield_stmt' should be changed to 'yield_expr'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1223381&group_id=5470 From noreply at sourceforge.net Wed Jun 22 23:11:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Jun 2005 14:11:03 -0700 Subject: [Patches] [ python-Patches-1220874 ] update the binhex module for Mach-O Message-ID: Patches item #1220874, was opened at 2005-06-14 21:27 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220874&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: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: update the binhex module for Mach-O Initial Comment: The binhex module only understands resource forks if os.name == 'mac', which is only true for CFM builds of Python. We haven't maintained those in years, so this has been broken for quite some time. This patch is a partial fix that allows it to de-binhex the resource fork on Mach-O, but it still doesn't do the type/creator stuff. I'm currently only using it to create one of those pesky "Icon\r" files, so this is all I fixed and tested. ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2005-06-22 17:11 Message: Logged In: YES user_id=139309 I definitely added it, but I forgot to click the stupid box. I hate sourceforge. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2005-06-22 06:45 Message: Logged In: YES user_id=580910 You forgot to add the patch. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-06-14 21:29 Message: Logged In: YES user_id=139309 this is also a backport candidate ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220874&group_id=5470 From noreply at sourceforge.net Thu Jun 23 06:54:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Jun 2005 21:54:38 -0700 Subject: [Patches] [ python-Patches-1116722 ] Solaris 10 fails to compile complexobject.c [FIX incl.] Message-ID: Patches item #1116722, was opened at 2005-02-05 18:02 Message generated for change (Comment added) made by slashlib You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&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: Case Van Horsen (casevh) Assigned to: Martin v. L?wis (loewis) Summary: Solaris 10 fails to compile complexobject.c [FIX incl.] Initial Comment: This is a duplicate of 970334. The fix I used was to make the following change in pyport.h: Change #define Py_HUGE_VAL HUGE_VAL to #define PY_HUGE_VAL DBL_MAX. DBL_MAX is found in float.h Versions used: Python 2.4 gcc 3.4.3 Solaris 10 x86 GA release. ---------------------------------------------------------------------- Comment By: Bill Clarke (slashlib) Date: 2005-06-23 14:54 Message: Logged In: YES user_id=421902 i hit this bug too. this has been fixed in gcc (will be in gcc 3.4.5 and 4.0.1). to workaround with (say) an installed gcc 3.4.4 build current gcc 3.4 cvs and copy the fixed iso/math_c99.h file from the build to the installed gcc fixed includes directory. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-06-23 00:47 Message: Logged In: YES user_id=29957 I haven't had time to try installing Solaris 10 on anything yet - does setting _XOPEN_SOURCE in this way break anything else? (does make testall complete ok?) If you could confirm it doesn't break anything else, I'll make the change for 2.5 and 2.4.2... ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-03-19 17:06 Message: Logged In: YES user_id=1212585 I found a reference in the 2.4a3 release notes that this problem was fixed for Solaris 8 and 9 with Patch #1006629. That patch set _XOPEN_SOURCE to 500. Using 2.4.1c2 source, I patched line 1521 from SunOS/5.8|SunOS/5.9) to SunOS/5.8|SunOS/5.9|SunOS/5.10) I successfully completed a make; make test with a generic Solaris 10 x86 install. I verified that it failed without the patch. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-03-05 09:28 Message: Logged In: YES user_id=1212585 Below is the official response from Sun. It doesn't look like Sun sees it as a problem. Document Audience: SPECTRUM Document ID: 6173815 Title: bug 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Update Date: Tue Oct 05 06:44:47 MDT 2004 Bug ID: 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Category: c++ Subcategory: compiler State: 11-Closed Description: * * This is a problem I ran into trying to compile Python 2.3.4 on a Solaris * 10 beta 63 (x86) system. I worked with Martin v. Lowis * to isolate the problem as it affects Python, but our * conclusion is that this is really a GCC/Solaris problem. * * -- Chris Wicklein * * ---------------------------------------- * * $ uname -a * SunOS solaris1 5.10 s10_63 i86pc i386 i86pc * * $ gcc -v * Reading specs from /opt/gcc/lib/gcc/i386-pc- solaris2.10/3.4.2/specs * Configured with: ../gcc-3.4.2/configure --with- as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls -- prefix=/opt/gcc * Thread model: posix * gcc version 3.4.2 * * $ gcc -o foo foo.c * * $ gcc -D_STDC_C99 -o foo foo.c * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ gcc -D_STDC_C99 -o foo foo.c --save-temps * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ grep __builtin_huge_val foo.i * if (x == __builtin_huge_val) { * * ---------------------------------------- * The problem for GCC is having HUGE_VAL expanded to __builtin_huge_val * (pointer to a function returning a double) rather than to * __builtin_huge_val() (call to a function returning a double.) * * Is this an error in the header file /usr/include/iso/math_c99.h * or something that was done intentionally to support the * Sun ONE compiler? (Is this something for Sun to fix, or should * this be addressed on the GCC end?) */ #include int main (int argc, char **argv) { double x = 3.14; if (x == HUGE_VAL) { x = 2.7; } return 0; } Customer comments: It is my understanding that HUGE_VAL is a standard C feature, and the function __builtin_huge_val() is a GCC- specific extension for implementing this standard C feature. If this is correct, then by referencing __builtin_huge_val in /usr/include/iso/math_c99.h, Solaris 10 is providing GCC- specific header support. (As an aside, it's remotely possible that my copy of math_c99.h was locally modified as part of installing GCC from a third-party package, but I doubt this happened.) Assuming then that Solaris 10 is providing support for a GCC- specific built-in function (__builtin_huge_val) in math_c99.h, then that support should be corrected (by adding the missing parens.) Otherwise, it will be necessary for GCC to work- around this header problem. Here then is the crux of the matter: assuming that math_c99.h contains this reference to __builtin_huge_val without the required parens, was this done to support GCC, or is this also used by the Sun Pro compiler? If this is present only for GCC, then the missing parens should be added by Sun, or I would like to know that Sun sees this as not-a-bug, in which case GCC will have to work around this itself. At any rate, I am not requesting support for GCC, but rather trying to understand 1) why math_c99.h references __builtin_huge_val as it does in Solaris 10, and 2) if this is something Sun views as a problem on the Solaris side to be fixed. > HI Chris, > > We do not support gcc A third-party C compiler; not supported. > ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-03-05 09:26 Message: Logged In: YES user_id=1212585 Below is the official response from Sun. It doesn't look like Sun sees it as a problem. Document Audience: SPECTRUM Document ID: 6173815 Title: bug 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Update Date: Tue Oct 05 06:44:47 MDT 2004 Bug ID: 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Category: c++ Subcategory: compiler State: 11-Closed Description: * * This is a problem I ran into trying to compile Python 2.3.4 on a Solaris * 10 beta 63 (x86) system. I worked with Martin v. Lowis * to isolate the problem as it affects Python, but our * conclusion is that this is really a GCC/Solaris problem. * * -- Chris Wicklein * * ---------------------------------------- * * $ uname -a * SunOS solaris1 5.10 s10_63 i86pc i386 i86pc * * $ gcc -v * Reading specs from /opt/gcc/lib/gcc/i386-pc- solaris2.10/3.4.2/specs * Configured with: ../gcc-3.4.2/configure --with- as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls -- prefix=/opt/gcc * Thread model: posix * gcc version 3.4.2 * * $ gcc -o foo foo.c * * $ gcc -D_STDC_C99 -o foo foo.c * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ gcc -D_STDC_C99 -o foo foo.c --save-temps * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ grep __builtin_huge_val foo.i * if (x == __builtin_huge_val) { * * ---------------------------------------- * The problem for GCC is having HUGE_VAL expanded to __builtin_huge_val * (pointer to a function returning a double) rather than to * __builtin_huge_val() (call to a function returning a double.) * * Is this an error in the header file /usr/include/iso/math_c99.h * or something that was done intentionally to support the * Sun ONE compiler? (Is this something for Sun to fix, or should * this be addressed on the GCC end?) */ #include int main (int argc, char **argv) { double x = 3.14; if (x == HUGE_VAL) { x = 2.7; } return 0; } Customer comments: It is my understanding that HUGE_VAL is a standard C feature, and the function __builtin_huge_val() is a GCC- specific extension for implementing this standard C feature. If this is correct, then by referencing __builtin_huge_val in /usr/include/iso/math_c99.h, Solaris 10 is providing GCC- specific header support. (As an aside, it's remotely possible that my copy of math_c99.h was locally modified as part of installing GCC from a third-party package, but I doubt this happened.) Assuming then that Solaris 10 is providing support for a GCC- specific built-in function (__builtin_huge_val) in math_c99.h, then that support should be corrected (by adding the missing parens.) Otherwise, it will be necessary for GCC to work- around this header problem. Here then is the crux of the matter: assuming that math_c99.h contains this reference to __builtin_huge_val without the required parens, was this done to support GCC, or is this also used by the Sun Pro compiler? If this is present only for GCC, then the missing parens should be added by Sun, or I would like to know that Sun sees this as not-a-bug, in which case GCC will have to work around this itself. At any rate, I am not requesting support for GCC, but rather trying to understand 1) why math_c99.h references __builtin_huge_val as it does in Solaris 10, and 2) if this is something Sun views as a problem on the Solaris side to be fixed. > HI Chris, > > We do not support gcc A third-party C compiler; not supported. > ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-05 06:04 Message: Logged In: YES user_id=21627 Turns out casevh's report is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-05 01:18 Message: Logged In: YES user_id=21627 I have now reported this bug to gcc as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20317 ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 17:33 Message: Logged In: YES user_id=1212585 Oops. I made a typo in one of my tests. It does include in /include/iso/math_c99.h when you type it correctly. I will work with Sun / gcc to determine a resolution. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 17:03 Message: Logged In: YES user_id=1212585 I poked around in the preprocessor outputs and it appears gcc doesn't its specific directory for math_c99.h. It only appears to look in /usr/include/iso. I changed the definition of HUGE_VAL in /usr/include/iso/math_c99.h to read: #define HUGE_VAL __builtin_huge_val() The hv2.c compiled completely and so did Python 2.4. I'll open a bug report with GCC and also with Sun since I used the version of GCC that was distributed by Sun. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 16:16 Message: Logged In: YES user_id=1212585 I ran mkheaders to rebuild the gcc headers but that made no difference. The following program (hv.c) compiled correctly: #define _XOPEN_SOURCE 500 #include int main() { double f=HUGE_VAL; } The following program (hv2.c) did not compile. #define _XOPEN_SOURCE 1000 #include int main() { double f=HUGE_VAL; } Output is: $ gcc --save-temps hv.c $ gcc --save-temp hv2.c hv2.c: In function `main': hv2.c:5: error: incompatible types in initialization $ I have attached hv.i and hv2.i. I have also attached complexobject.i I'm not a C programmer so please let me know what else I can do to help. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 03:50 Message: Logged In: YES user_id=1212585 I tried steps 1 through 4 and it fails, with and with the (). I'm not sure how to do step 5. I will try the short program snippet later and report back. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-10 15:44 Message: Logged In: YES user_id=31435 Doubt this will help: googling suggests that -Xc has to be passed to Sun's native C compiler to get HUGE_VAL defined correctly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-10 14:23 Message: Logged In: YES user_id=21627 I have the Solaris 10 iso/math_c99.h in front of me, but no gcc, so it is somewhat difficult to get through the ifdefery. It appears that we should have _XOPEN_SOURCE - 0 >= 600, so we should be using #define HUGE_VAL __builtin_huge_val The problem apparently is that in Sun CC, __builtin_huge_val appears to be a constant, whereas in gcc, it probably is a function, so the definition should read #define HUGE_VAL __builtin_huge_val() So there is a bug in the gcc port of Solaris here - fixincludes should adjust the definition of HUGE_VAL when installing its adjusted copy of math_c99.h. I'm willing to accept patches to work around this gcc bug, but only if the bug gets reported to gcc first. So, please, 1. find out the gcc installation directory on your system, using gcc --print-search-dirs 2a. check whether /include/iso/math_c99.h exists 2b. if it does not exist, copy if from /usr/include/iso/math_c99.h 3. edit /include/iso/math_c99.h to add the parentheses after builtin_huge_val 4. check whether this fixes the problem 5a. if not, provide the preprocessor output for complexobject.i, using --save-temps 5b. if it does, make a bug report to gcc, indicating that the program #include int main() { double f=HUGE_VAL; } fails on Solaris 10. For that report - check whether it actually fails without the update math_c99, and succeeds with it (you might have to #define _XOPEN_SOURCE to make it fail) - include the preprocessor output for this sample program, using the original math_c99 - indicate that a solution is to add parentheses 6. Come up with a patch that checks for Solaris 10 and all gcc versions showing the problem (i.e. 3.4.x, with x<=3, perhaps also 3.y, y<=3), and defines Py_HUGE_VAL correctly for this system. 7. Report the gcc bug number and the patch in this report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-10 12:43 Message: Logged In: YES user_id=31435 The C standard requires that "The macro HUGE_VAL expands to a positive double constant expression, not necessarily representable as a float". Python requires that too. #define'ing to worm around a broken compilation environment isn't acceptable to me; finding a switch to make this environment conform to the standard would be OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 From noreply at sourceforge.net Thu Jun 23 07:35:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Jun 2005 22:35:33 -0700 Subject: [Patches] [ python-Patches-1116722 ] Solaris 10 fails to compile complexobject.c [FIX incl.] Message-ID: Patches item #1116722, was opened at 2005-02-04 23:02 Message generated for change (Comment added) made by casevh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 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: Case Van Horsen (casevh) Assigned to: Martin v. L?wis (loewis) Summary: Solaris 10 fails to compile complexobject.c [FIX incl.] Initial Comment: This is a duplicate of 970334. The fix I used was to make the following change in pyport.h: Change #define Py_HUGE_VAL HUGE_VAL to #define PY_HUGE_VAL DBL_MAX. DBL_MAX is found in float.h Versions used: Python 2.4 gcc 3.4.3 Solaris 10 x86 GA release. ---------------------------------------------------------------------- >Comment By: Case Van Horsen (casevh) Date: 2005-06-22 22:35 Message: Logged In: YES user_id=1212585 "make testall" fails with an error in _curses: missing typeahead(). I don't know it that is normal or not. I will try some additional tests this weekend, including using the new iso/math_c99.h file. A more subtle issue is that some of the the Solaris Express releases identified themselves as 5.10.1 and the latest Solaris Express (and I believe OpenSolaris) identify themselves as 5.11 and will probably use 5.11.x in the future. I will try to upgrade to the latest Solaris Express release this weekend and report how that behaves. ---------------------------------------------------------------------- Comment By: Bill Clarke (slashlib) Date: 2005-06-22 21:54 Message: Logged In: YES user_id=421902 i hit this bug too. this has been fixed in gcc (will be in gcc 3.4.5 and 4.0.1). to workaround with (say) an installed gcc 3.4.4 build current gcc 3.4 cvs and copy the fixed iso/math_c99.h file from the build to the installed gcc fixed includes directory. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-06-22 07:47 Message: Logged In: YES user_id=29957 I haven't had time to try installing Solaris 10 on anything yet - does setting _XOPEN_SOURCE in this way break anything else? (does make testall complete ok?) If you could confirm it doesn't break anything else, I'll make the change for 2.5 and 2.4.2... ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-03-18 22:06 Message: Logged In: YES user_id=1212585 I found a reference in the 2.4a3 release notes that this problem was fixed for Solaris 8 and 9 with Patch #1006629. That patch set _XOPEN_SOURCE to 500. Using 2.4.1c2 source, I patched line 1521 from SunOS/5.8|SunOS/5.9) to SunOS/5.8|SunOS/5.9|SunOS/5.10) I successfully completed a make; make test with a generic Solaris 10 x86 install. I verified that it failed without the patch. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-03-04 14:28 Message: Logged In: YES user_id=1212585 Below is the official response from Sun. It doesn't look like Sun sees it as a problem. Document Audience: SPECTRUM Document ID: 6173815 Title: bug 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Update Date: Tue Oct 05 06:44:47 MDT 2004 Bug ID: 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Category: c++ Subcategory: compiler State: 11-Closed Description: * * This is a problem I ran into trying to compile Python 2.3.4 on a Solaris * 10 beta 63 (x86) system. I worked with Martin v. Lowis * to isolate the problem as it affects Python, but our * conclusion is that this is really a GCC/Solaris problem. * * -- Chris Wicklein * * ---------------------------------------- * * $ uname -a * SunOS solaris1 5.10 s10_63 i86pc i386 i86pc * * $ gcc -v * Reading specs from /opt/gcc/lib/gcc/i386-pc- solaris2.10/3.4.2/specs * Configured with: ../gcc-3.4.2/configure --with- as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls -- prefix=/opt/gcc * Thread model: posix * gcc version 3.4.2 * * $ gcc -o foo foo.c * * $ gcc -D_STDC_C99 -o foo foo.c * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ gcc -D_STDC_C99 -o foo foo.c --save-temps * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ grep __builtin_huge_val foo.i * if (x == __builtin_huge_val) { * * ---------------------------------------- * The problem for GCC is having HUGE_VAL expanded to __builtin_huge_val * (pointer to a function returning a double) rather than to * __builtin_huge_val() (call to a function returning a double.) * * Is this an error in the header file /usr/include/iso/math_c99.h * or something that was done intentionally to support the * Sun ONE compiler? (Is this something for Sun to fix, or should * this be addressed on the GCC end?) */ #include int main (int argc, char **argv) { double x = 3.14; if (x == HUGE_VAL) { x = 2.7; } return 0; } Customer comments: It is my understanding that HUGE_VAL is a standard C feature, and the function __builtin_huge_val() is a GCC- specific extension for implementing this standard C feature. If this is correct, then by referencing __builtin_huge_val in /usr/include/iso/math_c99.h, Solaris 10 is providing GCC- specific header support. (As an aside, it's remotely possible that my copy of math_c99.h was locally modified as part of installing GCC from a third-party package, but I doubt this happened.) Assuming then that Solaris 10 is providing support for a GCC- specific built-in function (__builtin_huge_val) in math_c99.h, then that support should be corrected (by adding the missing parens.) Otherwise, it will be necessary for GCC to work- around this header problem. Here then is the crux of the matter: assuming that math_c99.h contains this reference to __builtin_huge_val without the required parens, was this done to support GCC, or is this also used by the Sun Pro compiler? If this is present only for GCC, then the missing parens should be added by Sun, or I would like to know that Sun sees this as not-a-bug, in which case GCC will have to work around this itself. At any rate, I am not requesting support for GCC, but rather trying to understand 1) why math_c99.h references __builtin_huge_val as it does in Solaris 10, and 2) if this is something Sun views as a problem on the Solaris side to be fixed. > HI Chris, > > We do not support gcc A third-party C compiler; not supported. > ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-03-04 14:26 Message: Logged In: YES user_id=1212585 Below is the official response from Sun. It doesn't look like Sun sees it as a problem. Document Audience: SPECTRUM Document ID: 6173815 Title: bug 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Update Date: Tue Oct 05 06:44:47 MDT 2004 Bug ID: 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Category: c++ Subcategory: compiler State: 11-Closed Description: * * This is a problem I ran into trying to compile Python 2.3.4 on a Solaris * 10 beta 63 (x86) system. I worked with Martin v. Lowis * to isolate the problem as it affects Python, but our * conclusion is that this is really a GCC/Solaris problem. * * -- Chris Wicklein * * ---------------------------------------- * * $ uname -a * SunOS solaris1 5.10 s10_63 i86pc i386 i86pc * * $ gcc -v * Reading specs from /opt/gcc/lib/gcc/i386-pc- solaris2.10/3.4.2/specs * Configured with: ../gcc-3.4.2/configure --with- as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls -- prefix=/opt/gcc * Thread model: posix * gcc version 3.4.2 * * $ gcc -o foo foo.c * * $ gcc -D_STDC_C99 -o foo foo.c * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ gcc -D_STDC_C99 -o foo foo.c --save-temps * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ grep __builtin_huge_val foo.i * if (x == __builtin_huge_val) { * * ---------------------------------------- * The problem for GCC is having HUGE_VAL expanded to __builtin_huge_val * (pointer to a function returning a double) rather than to * __builtin_huge_val() (call to a function returning a double.) * * Is this an error in the header file /usr/include/iso/math_c99.h * or something that was done intentionally to support the * Sun ONE compiler? (Is this something for Sun to fix, or should * this be addressed on the GCC end?) */ #include int main (int argc, char **argv) { double x = 3.14; if (x == HUGE_VAL) { x = 2.7; } return 0; } Customer comments: It is my understanding that HUGE_VAL is a standard C feature, and the function __builtin_huge_val() is a GCC- specific extension for implementing this standard C feature. If this is correct, then by referencing __builtin_huge_val in /usr/include/iso/math_c99.h, Solaris 10 is providing GCC- specific header support. (As an aside, it's remotely possible that my copy of math_c99.h was locally modified as part of installing GCC from a third-party package, but I doubt this happened.) Assuming then that Solaris 10 is providing support for a GCC- specific built-in function (__builtin_huge_val) in math_c99.h, then that support should be corrected (by adding the missing parens.) Otherwise, it will be necessary for GCC to work- around this header problem. Here then is the crux of the matter: assuming that math_c99.h contains this reference to __builtin_huge_val without the required parens, was this done to support GCC, or is this also used by the Sun Pro compiler? If this is present only for GCC, then the missing parens should be added by Sun, or I would like to know that Sun sees this as not-a-bug, in which case GCC will have to work around this itself. At any rate, I am not requesting support for GCC, but rather trying to understand 1) why math_c99.h references __builtin_huge_val as it does in Solaris 10, and 2) if this is something Sun views as a problem on the Solaris side to be fixed. > HI Chris, > > We do not support gcc A third-party C compiler; not supported. > ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 11:04 Message: Logged In: YES user_id=21627 Turns out casevh's report is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 06:18 Message: Logged In: YES user_id=21627 I have now reported this bug to gcc as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20317 ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-10 22:33 Message: Logged In: YES user_id=1212585 Oops. I made a typo in one of my tests. It does include in /include/iso/math_c99.h when you type it correctly. I will work with Sun / gcc to determine a resolution. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-10 22:03 Message: Logged In: YES user_id=1212585 I poked around in the preprocessor outputs and it appears gcc doesn't its specific directory for math_c99.h. It only appears to look in /usr/include/iso. I changed the definition of HUGE_VAL in /usr/include/iso/math_c99.h to read: #define HUGE_VAL __builtin_huge_val() The hv2.c compiled completely and so did Python 2.4. I'll open a bug report with GCC and also with Sun since I used the version of GCC that was distributed by Sun. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-10 21:16 Message: Logged In: YES user_id=1212585 I ran mkheaders to rebuild the gcc headers but that made no difference. The following program (hv.c) compiled correctly: #define _XOPEN_SOURCE 500 #include int main() { double f=HUGE_VAL; } The following program (hv2.c) did not compile. #define _XOPEN_SOURCE 1000 #include int main() { double f=HUGE_VAL; } Output is: $ gcc --save-temps hv.c $ gcc --save-temp hv2.c hv2.c: In function `main': hv2.c:5: error: incompatible types in initialization $ I have attached hv.i and hv2.i. I have also attached complexobject.i I'm not a C programmer so please let me know what else I can do to help. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-10 08:50 Message: Logged In: YES user_id=1212585 I tried steps 1 through 4 and it fails, with and with the (). I'm not sure how to do step 5. I will try the short program snippet later and report back. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-09 20:44 Message: Logged In: YES user_id=31435 Doubt this will help: googling suggests that -Xc has to be passed to Sun's native C compiler to get HUGE_VAL defined correctly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-09 19:23 Message: Logged In: YES user_id=21627 I have the Solaris 10 iso/math_c99.h in front of me, but no gcc, so it is somewhat difficult to get through the ifdefery. It appears that we should have _XOPEN_SOURCE - 0 >= 600, so we should be using #define HUGE_VAL __builtin_huge_val The problem apparently is that in Sun CC, __builtin_huge_val appears to be a constant, whereas in gcc, it probably is a function, so the definition should read #define HUGE_VAL __builtin_huge_val() So there is a bug in the gcc port of Solaris here - fixincludes should adjust the definition of HUGE_VAL when installing its adjusted copy of math_c99.h. I'm willing to accept patches to work around this gcc bug, but only if the bug gets reported to gcc first. So, please, 1. find out the gcc installation directory on your system, using gcc --print-search-dirs 2a. check whether /include/iso/math_c99.h exists 2b. if it does not exist, copy if from /usr/include/iso/math_c99.h 3. edit /include/iso/math_c99.h to add the parentheses after builtin_huge_val 4. check whether this fixes the problem 5a. if not, provide the preprocessor output for complexobject.i, using --save-temps 5b. if it does, make a bug report to gcc, indicating that the program #include int main() { double f=HUGE_VAL; } fails on Solaris 10. For that report - check whether it actually fails without the update math_c99, and succeeds with it (you might have to #define _XOPEN_SOURCE to make it fail) - include the preprocessor output for this sample program, using the original math_c99 - indicate that a solution is to add parentheses 6. Come up with a patch that checks for Solaris 10 and all gcc versions showing the problem (i.e. 3.4.x, with x<=3, perhaps also 3.y, y<=3), and defines Py_HUGE_VAL correctly for this system. 7. Report the gcc bug number and the patch in this report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-09 17:43 Message: Logged In: YES user_id=31435 The C standard requires that "The macro HUGE_VAL expands to a positive double constant expression, not necessarily representable as a float". Python requires that too. #define'ing to worm around a broken compilation environment isn't acceptable to me; finding a switch to make this environment conform to the standard would be OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 From medivisor1 at optonline.net Thu Jun 23 07:00:37 2005 From: medivisor1 at optonline.net (Medivisor) Date: Thu, 23 Jun 2005 01:00:37 -0400 Subject: [Patches] Physician's Member Update Request Message-ID: <3817-2200564235036984@David> David Kary NormalDavid Kary 4132005-02-08T19:42:00Z2005-02-25T16:27:00Z1164938Medivisor72110011.5606 CleanCleanfalsefalsefalseMicrosoftInternetExplorer4 AS we progress into the New Year we have many exciting new plans, programs and services at www.Medivisor.com ? and www.StatDose.com . As a member physician you will be among the first to experience unique online clinical tools, exciting newsletters, new products and the launch of our new medical news radio initiative.? We are very excited about our upcoming offerings for this year and hope you will join us as we start a new era in medical communication technology. In order to continue your participation with us we ask that you take a moment to update your current information below and return to us via return email.? Simply hit the reply button, fill in the fields below and hit send. ? Thank you for your time, we are sure you will appreciate the upcoming medical communication services. Your email address: Your name: Your specialty: Your state: You have received this email as a member physician. If you wish to be removed from our list please CLICK HERE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20050623/f4c09bef/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 78743 bytes Desc: image001.jpg Url : http://mail.python.org/pipermail/patches/attachments/20050623/f4c09bef/attachment-0002.jpeg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3345 bytes Desc: image003.jpg Url : http://mail.python.org/pipermail/patches/attachments/20050623/f4c09bef/attachment-0003.jpeg From noreply at sourceforge.net Thu Jun 23 08:50:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Jun 2005 23:50:09 -0700 Subject: [Patches] [ python-Patches-1116722 ] Solaris 10 fails to compile complexobject.c [FIX incl.] Message-ID: Patches item #1116722, was opened at 2005-02-05 18:02 Message generated for change (Comment added) made by slashlib You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&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: Case Van Horsen (casevh) Assigned to: Martin v. L?wis (loewis) Summary: Solaris 10 fails to compile complexobject.c [FIX incl.] Initial Comment: This is a duplicate of 970334. The fix I used was to make the following change in pyport.h: Change #define Py_HUGE_VAL HUGE_VAL to #define PY_HUGE_VAL DBL_MAX. DBL_MAX is found in float.h Versions used: Python 2.4 gcc 3.4.3 Solaris 10 x86 GA release. ---------------------------------------------------------------------- Comment By: Bill Clarke (slashlib) Date: 2005-06-23 16:50 Message: Logged In: YES user_id=421902 i should clarify my comments, the thing that was recently fixed in gcc is the HUGE_VAL problem, not the XOPEN_SOURCE problem. note: an easy test for the XOPEN_SOURCE problem with g++ is: """ #include #include """ ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-06-23 15:35 Message: Logged In: YES user_id=1212585 "make testall" fails with an error in _curses: missing typeahead(). I don't know it that is normal or not. I will try some additional tests this weekend, including using the new iso/math_c99.h file. A more subtle issue is that some of the the Solaris Express releases identified themselves as 5.10.1 and the latest Solaris Express (and I believe OpenSolaris) identify themselves as 5.11 and will probably use 5.11.x in the future. I will try to upgrade to the latest Solaris Express release this weekend and report how that behaves. ---------------------------------------------------------------------- Comment By: Bill Clarke (slashlib) Date: 2005-06-23 14:54 Message: Logged In: YES user_id=421902 i hit this bug too. this has been fixed in gcc (will be in gcc 3.4.5 and 4.0.1). to workaround with (say) an installed gcc 3.4.4 build current gcc 3.4 cvs and copy the fixed iso/math_c99.h file from the build to the installed gcc fixed includes directory. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-06-23 00:47 Message: Logged In: YES user_id=29957 I haven't had time to try installing Solaris 10 on anything yet - does setting _XOPEN_SOURCE in this way break anything else? (does make testall complete ok?) If you could confirm it doesn't break anything else, I'll make the change for 2.5 and 2.4.2... ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-03-19 17:06 Message: Logged In: YES user_id=1212585 I found a reference in the 2.4a3 release notes that this problem was fixed for Solaris 8 and 9 with Patch #1006629. That patch set _XOPEN_SOURCE to 500. Using 2.4.1c2 source, I patched line 1521 from SunOS/5.8|SunOS/5.9) to SunOS/5.8|SunOS/5.9|SunOS/5.10) I successfully completed a make; make test with a generic Solaris 10 x86 install. I verified that it failed without the patch. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-03-05 09:28 Message: Logged In: YES user_id=1212585 Below is the official response from Sun. It doesn't look like Sun sees it as a problem. Document Audience: SPECTRUM Document ID: 6173815 Title: bug 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Update Date: Tue Oct 05 06:44:47 MDT 2004 Bug ID: 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Category: c++ Subcategory: compiler State: 11-Closed Description: * * This is a problem I ran into trying to compile Python 2.3.4 on a Solaris * 10 beta 63 (x86) system. I worked with Martin v. Lowis * to isolate the problem as it affects Python, but our * conclusion is that this is really a GCC/Solaris problem. * * -- Chris Wicklein * * ---------------------------------------- * * $ uname -a * SunOS solaris1 5.10 s10_63 i86pc i386 i86pc * * $ gcc -v * Reading specs from /opt/gcc/lib/gcc/i386-pc- solaris2.10/3.4.2/specs * Configured with: ../gcc-3.4.2/configure --with- as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls -- prefix=/opt/gcc * Thread model: posix * gcc version 3.4.2 * * $ gcc -o foo foo.c * * $ gcc -D_STDC_C99 -o foo foo.c * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ gcc -D_STDC_C99 -o foo foo.c --save-temps * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ grep __builtin_huge_val foo.i * if (x == __builtin_huge_val) { * * ---------------------------------------- * The problem for GCC is having HUGE_VAL expanded to __builtin_huge_val * (pointer to a function returning a double) rather than to * __builtin_huge_val() (call to a function returning a double.) * * Is this an error in the header file /usr/include/iso/math_c99.h * or something that was done intentionally to support the * Sun ONE compiler? (Is this something for Sun to fix, or should * this be addressed on the GCC end?) */ #include int main (int argc, char **argv) { double x = 3.14; if (x == HUGE_VAL) { x = 2.7; } return 0; } Customer comments: It is my understanding that HUGE_VAL is a standard C feature, and the function __builtin_huge_val() is a GCC- specific extension for implementing this standard C feature. If this is correct, then by referencing __builtin_huge_val in /usr/include/iso/math_c99.h, Solaris 10 is providing GCC- specific header support. (As an aside, it's remotely possible that my copy of math_c99.h was locally modified as part of installing GCC from a third-party package, but I doubt this happened.) Assuming then that Solaris 10 is providing support for a GCC- specific built-in function (__builtin_huge_val) in math_c99.h, then that support should be corrected (by adding the missing parens.) Otherwise, it will be necessary for GCC to work- around this header problem. Here then is the crux of the matter: assuming that math_c99.h contains this reference to __builtin_huge_val without the required parens, was this done to support GCC, or is this also used by the Sun Pro compiler? If this is present only for GCC, then the missing parens should be added by Sun, or I would like to know that Sun sees this as not-a-bug, in which case GCC will have to work around this itself. At any rate, I am not requesting support for GCC, but rather trying to understand 1) why math_c99.h references __builtin_huge_val as it does in Solaris 10, and 2) if this is something Sun views as a problem on the Solaris side to be fixed. > HI Chris, > > We do not support gcc A third-party C compiler; not supported. > ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-03-05 09:26 Message: Logged In: YES user_id=1212585 Below is the official response from Sun. It doesn't look like Sun sees it as a problem. Document Audience: SPECTRUM Document ID: 6173815 Title: bug 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Update Date: Tue Oct 05 06:44:47 MDT 2004 Bug ID: 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Category: c++ Subcategory: compiler State: 11-Closed Description: * * This is a problem I ran into trying to compile Python 2.3.4 on a Solaris * 10 beta 63 (x86) system. I worked with Martin v. Lowis * to isolate the problem as it affects Python, but our * conclusion is that this is really a GCC/Solaris problem. * * -- Chris Wicklein * * ---------------------------------------- * * $ uname -a * SunOS solaris1 5.10 s10_63 i86pc i386 i86pc * * $ gcc -v * Reading specs from /opt/gcc/lib/gcc/i386-pc- solaris2.10/3.4.2/specs * Configured with: ../gcc-3.4.2/configure --with- as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls -- prefix=/opt/gcc * Thread model: posix * gcc version 3.4.2 * * $ gcc -o foo foo.c * * $ gcc -D_STDC_C99 -o foo foo.c * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ gcc -D_STDC_C99 -o foo foo.c --save-temps * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ grep __builtin_huge_val foo.i * if (x == __builtin_huge_val) { * * ---------------------------------------- * The problem for GCC is having HUGE_VAL expanded to __builtin_huge_val * (pointer to a function returning a double) rather than to * __builtin_huge_val() (call to a function returning a double.) * * Is this an error in the header file /usr/include/iso/math_c99.h * or something that was done intentionally to support the * Sun ONE compiler? (Is this something for Sun to fix, or should * this be addressed on the GCC end?) */ #include int main (int argc, char **argv) { double x = 3.14; if (x == HUGE_VAL) { x = 2.7; } return 0; } Customer comments: It is my understanding that HUGE_VAL is a standard C feature, and the function __builtin_huge_val() is a GCC- specific extension for implementing this standard C feature. If this is correct, then by referencing __builtin_huge_val in /usr/include/iso/math_c99.h, Solaris 10 is providing GCC- specific header support. (As an aside, it's remotely possible that my copy of math_c99.h was locally modified as part of installing GCC from a third-party package, but I doubt this happened.) Assuming then that Solaris 10 is providing support for a GCC- specific built-in function (__builtin_huge_val) in math_c99.h, then that support should be corrected (by adding the missing parens.) Otherwise, it will be necessary for GCC to work- around this header problem. Here then is the crux of the matter: assuming that math_c99.h contains this reference to __builtin_huge_val without the required parens, was this done to support GCC, or is this also used by the Sun Pro compiler? If this is present only for GCC, then the missing parens should be added by Sun, or I would like to know that Sun sees this as not-a-bug, in which case GCC will have to work around this itself. At any rate, I am not requesting support for GCC, but rather trying to understand 1) why math_c99.h references __builtin_huge_val as it does in Solaris 10, and 2) if this is something Sun views as a problem on the Solaris side to be fixed. > HI Chris, > > We do not support gcc A third-party C compiler; not supported. > ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-05 06:04 Message: Logged In: YES user_id=21627 Turns out casevh's report is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-05 01:18 Message: Logged In: YES user_id=21627 I have now reported this bug to gcc as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20317 ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 17:33 Message: Logged In: YES user_id=1212585 Oops. I made a typo in one of my tests. It does include in /include/iso/math_c99.h when you type it correctly. I will work with Sun / gcc to determine a resolution. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 17:03 Message: Logged In: YES user_id=1212585 I poked around in the preprocessor outputs and it appears gcc doesn't its specific directory for math_c99.h. It only appears to look in /usr/include/iso. I changed the definition of HUGE_VAL in /usr/include/iso/math_c99.h to read: #define HUGE_VAL __builtin_huge_val() The hv2.c compiled completely and so did Python 2.4. I'll open a bug report with GCC and also with Sun since I used the version of GCC that was distributed by Sun. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 16:16 Message: Logged In: YES user_id=1212585 I ran mkheaders to rebuild the gcc headers but that made no difference. The following program (hv.c) compiled correctly: #define _XOPEN_SOURCE 500 #include int main() { double f=HUGE_VAL; } The following program (hv2.c) did not compile. #define _XOPEN_SOURCE 1000 #include int main() { double f=HUGE_VAL; } Output is: $ gcc --save-temps hv.c $ gcc --save-temp hv2.c hv2.c: In function `main': hv2.c:5: error: incompatible types in initialization $ I have attached hv.i and hv2.i. I have also attached complexobject.i I'm not a C programmer so please let me know what else I can do to help. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 03:50 Message: Logged In: YES user_id=1212585 I tried steps 1 through 4 and it fails, with and with the (). I'm not sure how to do step 5. I will try the short program snippet later and report back. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-10 15:44 Message: Logged In: YES user_id=31435 Doubt this will help: googling suggests that -Xc has to be passed to Sun's native C compiler to get HUGE_VAL defined correctly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-10 14:23 Message: Logged In: YES user_id=21627 I have the Solaris 10 iso/math_c99.h in front of me, but no gcc, so it is somewhat difficult to get through the ifdefery. It appears that we should have _XOPEN_SOURCE - 0 >= 600, so we should be using #define HUGE_VAL __builtin_huge_val The problem apparently is that in Sun CC, __builtin_huge_val appears to be a constant, whereas in gcc, it probably is a function, so the definition should read #define HUGE_VAL __builtin_huge_val() So there is a bug in the gcc port of Solaris here - fixincludes should adjust the definition of HUGE_VAL when installing its adjusted copy of math_c99.h. I'm willing to accept patches to work around this gcc bug, but only if the bug gets reported to gcc first. So, please, 1. find out the gcc installation directory on your system, using gcc --print-search-dirs 2a. check whether /include/iso/math_c99.h exists 2b. if it does not exist, copy if from /usr/include/iso/math_c99.h 3. edit /include/iso/math_c99.h to add the parentheses after builtin_huge_val 4. check whether this fixes the problem 5a. if not, provide the preprocessor output for complexobject.i, using --save-temps 5b. if it does, make a bug report to gcc, indicating that the program #include int main() { double f=HUGE_VAL; } fails on Solaris 10. For that report - check whether it actually fails without the update math_c99, and succeeds with it (you might have to #define _XOPEN_SOURCE to make it fail) - include the preprocessor output for this sample program, using the original math_c99 - indicate that a solution is to add parentheses 6. Come up with a patch that checks for Solaris 10 and all gcc versions showing the problem (i.e. 3.4.x, with x<=3, perhaps also 3.y, y<=3), and defines Py_HUGE_VAL correctly for this system. 7. Report the gcc bug number and the patch in this report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-10 12:43 Message: Logged In: YES user_id=31435 The C standard requires that "The macro HUGE_VAL expands to a positive double constant expression, not necessarily representable as a float". Python requires that too. #define'ing to worm around a broken compilation environment isn't acceptable to me; finding a switch to make this environment conform to the standard would be OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 From noreply at sourceforge.net Thu Jun 23 10:10:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Jun 2005 01:10:32 -0700 Subject: [Patches] [ python-Patches-1116722 ] Solaris 10 fails to compile complexobject.c [FIX incl.] Message-ID: Patches item #1116722, was opened at 2005-02-05 18:02 Message generated for change (Comment added) made by slashlib You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&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: Case Van Horsen (casevh) Assigned to: Martin v. L?wis (loewis) Summary: Solaris 10 fails to compile complexobject.c [FIX incl.] Initial Comment: This is a duplicate of 970334. The fix I used was to make the following change in pyport.h: Change #define Py_HUGE_VAL HUGE_VAL to #define PY_HUGE_VAL DBL_MAX. DBL_MAX is found in float.h Versions used: Python 2.4 gcc 3.4.3 Solaris 10 x86 GA release. ---------------------------------------------------------------------- Comment By: Bill Clarke (slashlib) Date: 2005-06-23 18:10 Message: Logged In: YES user_id=421902 to fix the XOPEN_SOURCE problem on Solaris 10 (and hence to be able to compile python modules with g++) you must _not_ define _XOPEN_SOURCE_EXTENDED. XOPEN_SOURCE must be 500 as well. here's a patch for configure.in for the XOPEN_SOURCE_EXTENDED change: """ --- configure.in~ 2005-03-29 09:23:34.000000000 +1000 +++ configure.in 2005-06-23 18:00:39.596747000 +1000 @@ -198,8 +198,15 @@ # definition of _XOPEN_SOURCE_EXTENDED and _POSIX_C_SOURCE, or else # several APIs are not declared. Since this is also needed in some # cases for HP-UX, we define it globally. - - AC_DEFINE(_XOPEN_SOURCE_EXTENDED, 1, Define to activate Unix95-and-earlier features) + # except for Solaris 10, where it must not be defined! + case $ac_sys_system/$ac_sys_release in + SunOS/5.10) + ;; + *) + AC_DEFINE(_XOPEN_SOURCE_EXTENDED, 1, + Define to activate Unix95-and-earlier features) + ;; + esac AC_DEFINE(_POSIX_C_SOURCE, 200112L, Define to activate features from IEEE Stds 1003.1-2001) """ this fix (along with _XOPEN_SOURCE == 500) means i can compile python modules with g++ now. yay! also note: Solaris 10's feature_tests header will override the setting of _POSIX_C_SOURCE (to 199506L) since _XOPEN_SOURCE is 500. from my reading, _POSIX_C_SOURCE should only be 200112L if _XOPEN_SOURCE is 600, so perhaps the _POSIX_C_SOURCE define should also be disabled for Solaris 10 (although this will make no material difference usually). ---------------------------------------------------------------------- Comment By: Bill Clarke (slashlib) Date: 2005-06-23 16:50 Message: Logged In: YES user_id=421902 i should clarify my comments, the thing that was recently fixed in gcc is the HUGE_VAL problem, not the XOPEN_SOURCE problem. note: an easy test for the XOPEN_SOURCE problem with g++ is: """ #include #include """ ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-06-23 15:35 Message: Logged In: YES user_id=1212585 "make testall" fails with an error in _curses: missing typeahead(). I don't know it that is normal or not. I will try some additional tests this weekend, including using the new iso/math_c99.h file. A more subtle issue is that some of the the Solaris Express releases identified themselves as 5.10.1 and the latest Solaris Express (and I believe OpenSolaris) identify themselves as 5.11 and will probably use 5.11.x in the future. I will try to upgrade to the latest Solaris Express release this weekend and report how that behaves. ---------------------------------------------------------------------- Comment By: Bill Clarke (slashlib) Date: 2005-06-23 14:54 Message: Logged In: YES user_id=421902 i hit this bug too. this has been fixed in gcc (will be in gcc 3.4.5 and 4.0.1). to workaround with (say) an installed gcc 3.4.4 build current gcc 3.4 cvs and copy the fixed iso/math_c99.h file from the build to the installed gcc fixed includes directory. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-06-23 00:47 Message: Logged In: YES user_id=29957 I haven't had time to try installing Solaris 10 on anything yet - does setting _XOPEN_SOURCE in this way break anything else? (does make testall complete ok?) If you could confirm it doesn't break anything else, I'll make the change for 2.5 and 2.4.2... ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-03-19 17:06 Message: Logged In: YES user_id=1212585 I found a reference in the 2.4a3 release notes that this problem was fixed for Solaris 8 and 9 with Patch #1006629. That patch set _XOPEN_SOURCE to 500. Using 2.4.1c2 source, I patched line 1521 from SunOS/5.8|SunOS/5.9) to SunOS/5.8|SunOS/5.9|SunOS/5.10) I successfully completed a make; make test with a generic Solaris 10 x86 install. I verified that it failed without the patch. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-03-05 09:28 Message: Logged In: YES user_id=1212585 Below is the official response from Sun. It doesn't look like Sun sees it as a problem. Document Audience: SPECTRUM Document ID: 6173815 Title: bug 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Update Date: Tue Oct 05 06:44:47 MDT 2004 Bug ID: 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Category: c++ Subcategory: compiler State: 11-Closed Description: * * This is a problem I ran into trying to compile Python 2.3.4 on a Solaris * 10 beta 63 (x86) system. I worked with Martin v. Lowis * to isolate the problem as it affects Python, but our * conclusion is that this is really a GCC/Solaris problem. * * -- Chris Wicklein * * ---------------------------------------- * * $ uname -a * SunOS solaris1 5.10 s10_63 i86pc i386 i86pc * * $ gcc -v * Reading specs from /opt/gcc/lib/gcc/i386-pc- solaris2.10/3.4.2/specs * Configured with: ../gcc-3.4.2/configure --with- as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls -- prefix=/opt/gcc * Thread model: posix * gcc version 3.4.2 * * $ gcc -o foo foo.c * * $ gcc -D_STDC_C99 -o foo foo.c * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ gcc -D_STDC_C99 -o foo foo.c --save-temps * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ grep __builtin_huge_val foo.i * if (x == __builtin_huge_val) { * * ---------------------------------------- * The problem for GCC is having HUGE_VAL expanded to __builtin_huge_val * (pointer to a function returning a double) rather than to * __builtin_huge_val() (call to a function returning a double.) * * Is this an error in the header file /usr/include/iso/math_c99.h * or something that was done intentionally to support the * Sun ONE compiler? (Is this something for Sun to fix, or should * this be addressed on the GCC end?) */ #include int main (int argc, char **argv) { double x = 3.14; if (x == HUGE_VAL) { x = 2.7; } return 0; } Customer comments: It is my understanding that HUGE_VAL is a standard C feature, and the function __builtin_huge_val() is a GCC- specific extension for implementing this standard C feature. If this is correct, then by referencing __builtin_huge_val in /usr/include/iso/math_c99.h, Solaris 10 is providing GCC- specific header support. (As an aside, it's remotely possible that my copy of math_c99.h was locally modified as part of installing GCC from a third-party package, but I doubt this happened.) Assuming then that Solaris 10 is providing support for a GCC- specific built-in function (__builtin_huge_val) in math_c99.h, then that support should be corrected (by adding the missing parens.) Otherwise, it will be necessary for GCC to work- around this header problem. Here then is the crux of the matter: assuming that math_c99.h contains this reference to __builtin_huge_val without the required parens, was this done to support GCC, or is this also used by the Sun Pro compiler? If this is present only for GCC, then the missing parens should be added by Sun, or I would like to know that Sun sees this as not-a-bug, in which case GCC will have to work around this itself. At any rate, I am not requesting support for GCC, but rather trying to understand 1) why math_c99.h references __builtin_huge_val as it does in Solaris 10, and 2) if this is something Sun views as a problem on the Solaris side to be fixed. > HI Chris, > > We do not support gcc A third-party C compiler; not supported. > ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-03-05 09:26 Message: Logged In: YES user_id=1212585 Below is the official response from Sun. It doesn't look like Sun sees it as a problem. Document Audience: SPECTRUM Document ID: 6173815 Title: bug 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Update Date: Tue Oct 05 06:44:47 MDT 2004 Bug ID: 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Category: c++ Subcategory: compiler State: 11-Closed Description: * * This is a problem I ran into trying to compile Python 2.3.4 on a Solaris * 10 beta 63 (x86) system. I worked with Martin v. Lowis * to isolate the problem as it affects Python, but our * conclusion is that this is really a GCC/Solaris problem. * * -- Chris Wicklein * * ---------------------------------------- * * $ uname -a * SunOS solaris1 5.10 s10_63 i86pc i386 i86pc * * $ gcc -v * Reading specs from /opt/gcc/lib/gcc/i386-pc- solaris2.10/3.4.2/specs * Configured with: ../gcc-3.4.2/configure --with- as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls -- prefix=/opt/gcc * Thread model: posix * gcc version 3.4.2 * * $ gcc -o foo foo.c * * $ gcc -D_STDC_C99 -o foo foo.c * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ gcc -D_STDC_C99 -o foo foo.c --save-temps * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ grep __builtin_huge_val foo.i * if (x == __builtin_huge_val) { * * ---------------------------------------- * The problem for GCC is having HUGE_VAL expanded to __builtin_huge_val * (pointer to a function returning a double) rather than to * __builtin_huge_val() (call to a function returning a double.) * * Is this an error in the header file /usr/include/iso/math_c99.h * or something that was done intentionally to support the * Sun ONE compiler? (Is this something for Sun to fix, or should * this be addressed on the GCC end?) */ #include int main (int argc, char **argv) { double x = 3.14; if (x == HUGE_VAL) { x = 2.7; } return 0; } Customer comments: It is my understanding that HUGE_VAL is a standard C feature, and the function __builtin_huge_val() is a GCC- specific extension for implementing this standard C feature. If this is correct, then by referencing __builtin_huge_val in /usr/include/iso/math_c99.h, Solaris 10 is providing GCC- specific header support. (As an aside, it's remotely possible that my copy of math_c99.h was locally modified as part of installing GCC from a third-party package, but I doubt this happened.) Assuming then that Solaris 10 is providing support for a GCC- specific built-in function (__builtin_huge_val) in math_c99.h, then that support should be corrected (by adding the missing parens.) Otherwise, it will be necessary for GCC to work- around this header problem. Here then is the crux of the matter: assuming that math_c99.h contains this reference to __builtin_huge_val without the required parens, was this done to support GCC, or is this also used by the Sun Pro compiler? If this is present only for GCC, then the missing parens should be added by Sun, or I would like to know that Sun sees this as not-a-bug, in which case GCC will have to work around this itself. At any rate, I am not requesting support for GCC, but rather trying to understand 1) why math_c99.h references __builtin_huge_val as it does in Solaris 10, and 2) if this is something Sun views as a problem on the Solaris side to be fixed. > HI Chris, > > We do not support gcc A third-party C compiler; not supported. > ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-05 06:04 Message: Logged In: YES user_id=21627 Turns out casevh's report is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-05 01:18 Message: Logged In: YES user_id=21627 I have now reported this bug to gcc as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20317 ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 17:33 Message: Logged In: YES user_id=1212585 Oops. I made a typo in one of my tests. It does include in /include/iso/math_c99.h when you type it correctly. I will work with Sun / gcc to determine a resolution. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 17:03 Message: Logged In: YES user_id=1212585 I poked around in the preprocessor outputs and it appears gcc doesn't its specific directory for math_c99.h. It only appears to look in /usr/include/iso. I changed the definition of HUGE_VAL in /usr/include/iso/math_c99.h to read: #define HUGE_VAL __builtin_huge_val() The hv2.c compiled completely and so did Python 2.4. I'll open a bug report with GCC and also with Sun since I used the version of GCC that was distributed by Sun. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 16:16 Message: Logged In: YES user_id=1212585 I ran mkheaders to rebuild the gcc headers but that made no difference. The following program (hv.c) compiled correctly: #define _XOPEN_SOURCE 500 #include int main() { double f=HUGE_VAL; } The following program (hv2.c) did not compile. #define _XOPEN_SOURCE 1000 #include int main() { double f=HUGE_VAL; } Output is: $ gcc --save-temps hv.c $ gcc --save-temp hv2.c hv2.c: In function `main': hv2.c:5: error: incompatible types in initialization $ I have attached hv.i and hv2.i. I have also attached complexobject.i I'm not a C programmer so please let me know what else I can do to help. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 03:50 Message: Logged In: YES user_id=1212585 I tried steps 1 through 4 and it fails, with and with the (). I'm not sure how to do step 5. I will try the short program snippet later and report back. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-10 15:44 Message: Logged In: YES user_id=31435 Doubt this will help: googling suggests that -Xc has to be passed to Sun's native C compiler to get HUGE_VAL defined correctly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-10 14:23 Message: Logged In: YES user_id=21627 I have the Solaris 10 iso/math_c99.h in front of me, but no gcc, so it is somewhat difficult to get through the ifdefery. It appears that we should have _XOPEN_SOURCE - 0 >= 600, so we should be using #define HUGE_VAL __builtin_huge_val The problem apparently is that in Sun CC, __builtin_huge_val appears to be a constant, whereas in gcc, it probably is a function, so the definition should read #define HUGE_VAL __builtin_huge_val() So there is a bug in the gcc port of Solaris here - fixincludes should adjust the definition of HUGE_VAL when installing its adjusted copy of math_c99.h. I'm willing to accept patches to work around this gcc bug, but only if the bug gets reported to gcc first. So, please, 1. find out the gcc installation directory on your system, using gcc --print-search-dirs 2a. check whether /include/iso/math_c99.h exists 2b. if it does not exist, copy if from /usr/include/iso/math_c99.h 3. edit /include/iso/math_c99.h to add the parentheses after builtin_huge_val 4. check whether this fixes the problem 5a. if not, provide the preprocessor output for complexobject.i, using --save-temps 5b. if it does, make a bug report to gcc, indicating that the program #include int main() { double f=HUGE_VAL; } fails on Solaris 10. For that report - check whether it actually fails without the update math_c99, and succeeds with it (you might have to #define _XOPEN_SOURCE to make it fail) - include the preprocessor output for this sample program, using the original math_c99 - indicate that a solution is to add parentheses 6. Come up with a patch that checks for Solaris 10 and all gcc versions showing the problem (i.e. 3.4.x, with x<=3, perhaps also 3.y, y<=3), and defines Py_HUGE_VAL correctly for this system. 7. Report the gcc bug number and the patch in this report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-10 12:43 Message: Logged In: YES user_id=31435 The C standard requires that "The macro HUGE_VAL expands to a positive double constant expression, not necessarily representable as a float". Python requires that too. #define'ing to worm around a broken compilation environment isn't acceptable to me; finding a switch to make this environment conform to the standard would be OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 From noreply at sourceforge.net Fri Jun 24 01:07:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Jun 2005 16:07:10 -0700 Subject: [Patches] [ python-Patches-1223381 ] PEP 342/343 Generator enhancements Message-ID: Patches item #1223381, was opened at 2005-06-18 23:08 Message generated for change (Comment added) made by pje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1223381&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: Phillip J. Eby (pje) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 342/343 Generator enhancements Initial Comment: The attached patch implements code and test changes for: * yield expressions * bare yield (short for yield None) * yield in try/finally * generator.send(value) (send value into generator; substituted for PEP 342's next(arg)) * generator.throw(typ[,val[,tb]]) (raise error in generator) * generator.close() (per PEP 343) * GeneratorExit built-in exception type * generator.__del__ (well, the C equivalent) * All necessary mods to the compiler, parser module, and Python 'compiler' package to support these changes. It was necessary to change a small part of the eval loop (well, the initialization, not the loop) and the gc module's has_finalizer() logic in order to support a C equivalent to __del__. Specialists in these areas should probably scrutinize this patch! There is one additional implementation detail that was not contemplated in either PEP. in order to prevent used-up generators from retaining unnecessary references to their frame's contents, I set the generator's gi_frame member to None whenever the generator finishes normally or with an error. Thus, an exhausted generator cannot be part of a cycle, and it releases its frame object sooner than in previous Python versions. For generators used only in a direct "for" loop, this makes no difference, but for generators used with the iterator protocol (i.e. "gen.next()") from Python, this avoids stranding the generator's frame in a traceback cycle. ---------------------------------------------------------------------- >Comment By: Phillip J. Eby (pje) Date: 2005-06-23 23:07 Message: Logged In: YES user_id=56214 No, I haven't, and I never really planned to be the person implementing "with". Doesn't mean I might not end up doing it eventually, but it's not currently in my plans. I'm going to have my hands full just updating PEP 342 (Guido has asked me to take it over), and getting docs written to go with this patch. Between all that and my distutils-related work, my pro-bono Python project time is booked up solid for maybe the next 2 months or so. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-22 20:59 Message: Logged In: YES user_id=6656 Argh, I'd hoped you'd done with, too :) Have you done any work on that yet? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-19 07:37 Message: Logged In: YES user_id=1188172 Minor nit: on line 642, 'yield_stmt' should be changed to 'yield_expr'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1223381&group_id=5470 From noreply at sourceforge.net Fri Jun 24 01:20:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Jun 2005 16:20:13 -0700 Subject: [Patches] [ python-Patches-1223381 ] PEP 342/343 Generator enhancements Message-ID: Patches item #1223381, was opened at 2005-06-19 00:08 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1223381&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: Phillip J. Eby (pje) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 342/343 Generator enhancements Initial Comment: The attached patch implements code and test changes for: * yield expressions * bare yield (short for yield None) * yield in try/finally * generator.send(value) (send value into generator; substituted for PEP 342's next(arg)) * generator.throw(typ[,val[,tb]]) (raise error in generator) * generator.close() (per PEP 343) * GeneratorExit built-in exception type * generator.__del__ (well, the C equivalent) * All necessary mods to the compiler, parser module, and Python 'compiler' package to support these changes. It was necessary to change a small part of the eval loop (well, the initialization, not the loop) and the gc module's has_finalizer() logic in order to support a C equivalent to __del__. Specialists in these areas should probably scrutinize this patch! There is one additional implementation detail that was not contemplated in either PEP. in order to prevent used-up generators from retaining unnecessary references to their frame's contents, I set the generator's gi_frame member to None whenever the generator finishes normally or with an error. Thus, an exhausted generator cannot be part of a cycle, and it releases its frame object sooner than in previous Python versions. For generators used only in a direct "for" loop, this makes no difference, but for generators used with the iterator protocol (i.e. "gen.next()") from Python, this avoids stranding the generator's frame in a traceback cycle. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-06-24 00:20 Message: Logged In: YES user_id=6656 Fair enough. I want to use with statements in a presentation at EuroPython next week, so I've hacked together a truly horrible implementation that will do for now and will see about a real one some time after... ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2005-06-24 00:07 Message: Logged In: YES user_id=56214 No, I haven't, and I never really planned to be the person implementing "with". Doesn't mean I might not end up doing it eventually, but it's not currently in my plans. I'm going to have my hands full just updating PEP 342 (Guido has asked me to take it over), and getting docs written to go with this patch. Between all that and my distutils-related work, my pro-bono Python project time is booked up solid for maybe the next 2 months or so. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-22 21:59 Message: Logged In: YES user_id=6656 Argh, I'd hoped you'd done with, too :) Have you done any work on that yet? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-19 08:37 Message: Logged In: YES user_id=1188172 Minor nit: on line 642, 'yield_stmt' should be changed to 'yield_expr'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1223381&group_id=5470 From noreply at sourceforge.net Sat Jun 25 00:21:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 24 Jun 2005 15:21:53 -0700 Subject: [Patches] [ python-Patches-1225212 ] HP-UX ia64 64-bit Python executable Message-ID: Patches item #1225212, was opened at 2005-06-22 01:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1225212&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: Peter Kropf (peterk) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX ia64 64-bit Python executable Initial Comment: In working on getting a 64-bit Python to build and pass the test suites on a Itanium 2 system running HP-UX 11, there were two major issues that needed to be resolved: - on ia64 HP-UX, unistd.h does not define _POSIX_THREADS and therefore Python/thread.c was not including thread_pthreads.h even though enough of the posix threading API is available to support threads in Python. - isnan() was not being called to check floating point numbers and math.sqrt(-1) would not throw a ValueError. The attached patch make the following changes: - modifies Python/thread.c to check for __hpux and _SC_THREADS and if they're defined, then define _POSIX_THREADS. - modifies Include/pyport.h to check for __hpux and __ia64 in the macro that defines _Py_SET_EDOM_FOR_NAN. - modifies Readme to include details on how to build a 64-bit version of Python on a HP-UX based Itanium 2 system. The patch file was created by running: cvs diff -c | tee ~/hpux_ia64_port.patch from python/dist/src on a current CVS tree. The current Readme also states that there is optimization problems when building Python on an ia64 based HP-UX system using HP's C compiler. I have not found this to be a problem. Should this note be removed or marked as out of date? ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-06-25 00:21 Message: Logged In: YES user_id=21627 The patch looks good, but I have one comment: it would be better if the user would not have to specify flags explicitly. Python should build out of the box on the platform, with not having to set environment variables. Ideally, it should built forall of the most likely configurations, i.e. c89/aCC and gcc, both 64 bits (I guess nobody would want to build an ia32 binary even if this is possible). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1225212&group_id=5470 From noreply at sourceforge.net Sat Jun 25 19:12:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 10:12:53 -0700 Subject: [Patches] [ python-Patches-1203094 ] httplib mentions getreply instead of getresponse Message-ID: Patches item #1203094, was opened at 2005-05-16 16:03 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1203094&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: Accepted Priority: 5 Submitted By: Robert Brewer (aminusfu) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: httplib mentions getreply instead of getresponse Initial Comment: See Bug 1202475. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-25 13:12 Message: Logged In: YES user_id=11375 This looks correct, and can be applied. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 14:11 Message: Logged In: YES user_id=1188172 Okay to check in? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1203094&group_id=5470 From noreply at sourceforge.net Sat Jun 25 19:15:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 10:15:53 -0700 Subject: [Patches] [ python-Patches-1213031 ] note that os.chown can have -1 as an argument Message-ID: Patches item #1213031, was opened at 2005-06-01 16:37 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1213031&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: Python 2.4 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: note that os.chown can have -1 as an argument Initial Comment: See bug #1200804. If you do not know the chown syscall, you can't know that a user/group id of -1 has the special meaning of "don't change". ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-25 13:15 Message: Logged In: YES user_id=11375 Looks correct; can be committed. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 06:27 Message: Logged In: YES user_id=1188172 Okay to check in? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1213031&group_id=5470 From noreply at sourceforge.net Sat Jun 25 19:24:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 10:24:02 -0700 Subject: [Patches] [ python-Patches-1227442 ] Patch for (Doc) bug #1217513 Message-ID: Patches item #1227442, was opened at 2005-06-25 19:24 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=1227442&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) bug #1217513 Initial Comment: to-address also accepts a string ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227442&group_id=5470 From noreply at sourceforge.net Sat Jun 25 19:28:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 10:28:36 -0700 Subject: [Patches] [ python-Patches-1227444 ] Patch for (Doc) bug #1225705 Message-ID: Patches item #1227444, was opened at 2005-06-25 19:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227444&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) bug #1225705 Initial Comment: Mention unsetenv in os documentation. Compare the text of putenv. This is a lot less info because I can't say anything about memory-leaks (don't know anything about that). From the source of os.py it seems that it is checked wether the underlying os supports it and some additional trickery is used to make it 'work' on windows and riscos. (it uses putenv to set the value to an empty string) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227444&group_id=5470 From noreply at sourceforge.net Sat Jun 25 20:25:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 11:25:05 -0700 Subject: [Patches] [ python-Patches-1227442 ] Patch for (Doc) bug #1217513 Message-ID: Patches item #1227442, was opened at 2005-06-25 19:24 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227442&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: Closed >Resolution: Accepted Priority: 5 Submitted By: Peter van Kampen (pterk) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Patch for (Doc) bug #1217513 Initial Comment: to-address also accepts a string ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 20:25 Message: Logged In: YES user_id=1188172 Thanks very much, committed as Doc/lib/libsmtplib.tex r1.26.4.1, r1.27. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227442&group_id=5470 From noreply at sourceforge.net Sat Jun 25 20:48:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 11:48:18 -0700 Subject: [Patches] [ python-Patches-1227444 ] Patch for (Doc) bug #1225705 Message-ID: Patches item #1227444, was opened at 2005-06-25 19:28 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227444&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: Closed >Resolution: Accepted Priority: 5 Submitted By: Peter van Kampen (pterk) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Patch for (Doc) bug #1225705 Initial Comment: Mention unsetenv in os documentation. Compare the text of putenv. This is a lot less info because I can't say anything about memory-leaks (don't know anything about that). From the source of os.py it seems that it is checked wether the underlying os supports it and some additional trickery is used to make it 'work' on windows and riscos. (it uses putenv to set the value to an empty string) ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 20:48 Message: Logged In: YES user_id=1188172 Thanks for the patch! Changed slightly and committed to CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227444&group_id=5470 From noreply at sourceforge.net Sat Jun 25 20:53:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 11:53:45 -0700 Subject: [Patches] [ python-Patches-1213031 ] note that os.chown can have -1 as an argument Message-ID: Patches item #1213031, was opened at 2005-06-01 22:37 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1213031&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: Python 2.4 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: note that os.chown can have -1 as an argument Initial Comment: See bug #1200804. If you do not know the chown syscall, you can't know that a user/group id of -1 has the special meaning of "don't change". ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 20:53 Message: Logged In: YES user_id=1188172 Checked in as Doc/lib/libos.tex r1.159, r1.146.2.5. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-25 19:15 Message: Logged In: YES user_id=11375 Looks correct; can be committed. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 12:27 Message: Logged In: YES user_id=1188172 Okay to check in? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1213031&group_id=5470 From noreply at sourceforge.net Sat Jun 25 21:18:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 12:18:10 -0700 Subject: [Patches] [ python-Patches-1203094 ] httplib mentions getreply instead of getresponse Message-ID: Patches item #1203094, was opened at 2005-05-16 22:03 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1203094&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: Closed Resolution: Accepted Priority: 5 Submitted By: Robert Brewer (aminusfu) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: httplib mentions getreply instead of getresponse Initial Comment: See Bug 1202475. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 21:18 Message: Logged In: YES user_id=1188172 Committed as Doc/lib/libhttplib.tex r1.39, r1.38.2.1. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-25 19:12 Message: Logged In: YES user_id=11375 This looks correct, and can be applied. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 20:11 Message: Logged In: YES user_id=1188172 Okay to check in? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1203094&group_id=5470 From noreply at sourceforge.net Sat Jun 25 21:39:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 12:39:22 -0700 Subject: [Patches] [ python-Patches-1225769 ] Proposal to implement comment rows in csv module Message-ID: Patches item #1225769, was opened at 2005-06-22 14:48 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1225769&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: Iain Haslam (iain_haslam) Assigned to: Skip Montanaro (montanaro) Summary: Proposal to implement comment rows in csv module Initial Comment: Sometimes csv files contain comment rows, for temporarily commenting out data or occasionally for documentation. The current csv module has no built-in ability to skip rows; in order to skip all lines beginning with '#', the programmer writes something like: csv_reader = csv.reader(fp) for row in csv_reader: if row[0][0] != '#': #assuming no blank lines print row I propose adding a "commentchar" parameter to the csv parser, so that the above code could be written (more elegantly, in my opinion): csv_reader = csv.reader(fp, commentchar='#') for row in csv_reader: print row This requires only relatively minor changes to the module, and by defaulting to using no comment character, existing code will behave as before. If you are interested, the patch (diffs against current cvs) required for the second example to run are attached. Note that that implementation adds SKIPPED_RECORD as a pseudonym for START_RECORD, because setting status to START_RECORD after skipping a record would cause a blank record to be returned. Altering that behaviour would cause more changes and the patch would be harder to review. I've also held back on updating tests and documentation to reflect this change, pending any support for it. It shoud be irrelevant, but this has been developed on Debian testing against the cvs head of Python. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-06-25 14:39 Message: Logged In: YES user_id=44345 I'm not inclined to clutter the C code with further complications. Why can't you implement this on an as-needed basis with a file object wrapper, a subclass of the csv.reader class, or just continue to use the example in your submission? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1225769&group_id=5470 From noreply at sourceforge.net Sat Jun 25 21:57:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 12:57:51 -0700 Subject: [Patches] [ python-Patches-1227489 ] Patch for (Doc) bug #1175022 Message-ID: Patches item #1227489, was opened at 2005-06-25 21: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=1227489&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) bug #1175022 Initial Comment: Included extra line so example runs correctly 'as is' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227489&group_id=5470 From noreply at sourceforge.net Sat Jun 25 22:08:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 13:08:40 -0700 Subject: [Patches] [ python-Patches-1227489 ] Patch for (Doc) bug #1175022 Message-ID: Patches item #1227489, was opened at 2005-06-25 21:57 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227489&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: Closed >Resolution: Accepted Priority: 5 Submitted By: Peter van Kampen (pterk) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Patch for (Doc) bug #1175022 Initial Comment: Included extra line so example runs correctly 'as is' ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 22:08 Message: Logged In: YES user_id=1188172 Thanks for the patch; committed as Doc/lib/libfuncs.tex r1.184, r1.175.2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227489&group_id=5470 From noreply at sourceforge.net Sat Jun 25 22:21:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 13:21:42 -0700 Subject: [Patches] [ python-Patches-1227495 ] Patch for (Doc) bug #1186072 Message-ID: Patches item #1227495, was opened at 2005-06-25 22: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=1227495&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) bug #1186072 Initial Comment: Needs checking (of the tex-syntax). I don't know latex but I think these changes result in the requested links. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227495&group_id=5470 From noreply at sourceforge.net Sat Jun 25 22:45:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 13:45:03 -0700 Subject: [Patches] [ python-Patches-1227495 ] Patch for (Doc) bug #1186072 Message-ID: Patches item #1227495, was opened at 2005-06-25 22:21 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227495&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: Closed >Resolution: Accepted Priority: 5 Submitted By: Peter van Kampen (pterk) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Patch for (Doc) bug #1186072 Initial Comment: Needs checking (of the tex-syntax). I don't know latex but I think these changes result in the requested links. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 22:45 Message: Logged In: YES user_id=1188172 Thanks for the patch, committed as Doc/lib/libos.tex r1.161, r1.146.2.7. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227495&group_id=5470 From noreply at sourceforge.net Sat Jun 25 22:52:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 13:52:28 -0700 Subject: [Patches] [ python-Patches-957003 ] RFE: Extend smtplib.py with support for LMTP Message-ID: Patches item #957003, was opened at 2004-05-19 21:56 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957003&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Leif Hedstrom (zwoop) Assigned to: Nobody/Anonymous (nobody) Summary: RFE: Extend smtplib.py with support for LMTP Initial Comment: Hi, attached is a proposal to extend the existing smtplib.py module with support for LMTP (RFC2033). I find it very useful together with IMAP servers like Cyrus. Thanks, -- leif ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 22:52 Message: Logged In: YES user_id=1188172 Moving to the patches tracker. As a new feature, assigning to group Python 2.5. ---------------------------------------------------------------------- Comment By: Leif Hedstrom (zwoop) Date: 2004-06-01 23:14 Message: Logged In: YES user_id=480913 Is the documentation provided in the patch for the LMTP class not sufficient? I can extend on that if necessary, although bear in mind that LMTP is very, very similar to SMTP. The main difference is the support for Unix sockets. As for adding test code, I could do that, although I'm guessing most people will not have an LMTP capable server running. If you feel strongly on this, I'll add something that will check for port 2003, and submit the same test message through an LMTP instance. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-06-01 19:25 Message: Logged In: YES user_id=593130 If you were mere requesting a feature enhancement, this would belong in the RFE list and not the bug list. Since you submitted a patch, and not just a proposal, this belongs in the patch list. However, as a patch submission, it also needs 1) a patch to the documentation for smtplib (at least the suggested new text if you can't do Latex) and 2) a patch to the test suite for smtplib (assuming there is one already). Suggestion: close this bug report as invalid and open a patch item with the additional material. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957003&group_id=5470 From noreply at sourceforge.net Sat Jun 25 22:55:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 13:55:14 -0700 Subject: [Patches] [ python-Patches-1227513 ] Patch for (Doc) bug #1166582 Message-ID: Patches item #1227513, was opened at 2005-06-25 22:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227513&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) bug #1166582 Initial Comment: Added text from the bugreport verbatim. Again: Not 100% sure about tex-syntax ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227513&group_id=5470 From noreply at sourceforge.net Sat Jun 25 23:04:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 14:04:59 -0700 Subject: [Patches] [ python-Patches-1227513 ] Patch for (Doc) bug #1166582 Message-ID: Patches item #1227513, was opened at 2005-06-25 22:55 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227513&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: Closed >Resolution: Accepted Priority: 5 Submitted By: Peter van Kampen (pterk) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Patch for (Doc) bug #1166582 Initial Comment: Added text from the bugreport verbatim. Again: Not 100% sure about tex-syntax ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 23:04 Message: Logged In: YES user_id=1188172 Thanks for the patch; committed as Doc/lib/libuserdict.tex r1.27, r1.24.4.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227513&group_id=5470 From noreply at sourceforge.net Sun Jun 26 00:03:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 15:03:54 -0700 Subject: [Patches] [ python-Patches-1227545 ] Patch for (Doc) bug #1212195 Message-ID: Patches item #1227545, was opened at 2005-06-26 00:03 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=1227545&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) bug #1212195 Initial Comment: Doc-patch for both libstring.tex and libstdtypes.tex. Added warning for the upper, lower and swapcase in libstring.tex and upper, lower, title and swapcase in libstdtypes.tex. warning: {function} can change the encoding of 8-bit strings for some locales. In libstdtypes I left the remark "For 8-bit strings, this method is locale-dependent." intact. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227545&group_id=5470 From noreply at sourceforge.net Sun Jun 26 00:49:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 15:49:15 -0700 Subject: [Patches] [ python-Patches-1227568 ] Patch for (Doc) bug #1219273 Message-ID: Patches item #1227568, was opened at 2005-06-26 00: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=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: Open Resolution: None Priority: 5 Submitted By: Peter van Kampen (pterk) Assigned to: Nobody/Anonymous (nobody) 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? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227568&group_id=5470 From noreply at sourceforge.net Sun Jun 26 19:26:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Jun 2005 10:26:38 -0700 Subject: [Patches] [ python-Patches-1225769 ] Proposal to implement comment rows in csv module Message-ID: Patches item #1225769, was opened at 2005-06-22 19:48 Message generated for change (Comment added) made by iain_haslam You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1225769&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: Iain Haslam (iain_haslam) Assigned to: Skip Montanaro (montanaro) Summary: Proposal to implement comment rows in csv module Initial Comment: Sometimes csv files contain comment rows, for temporarily commenting out data or occasionally for documentation. The current csv module has no built-in ability to skip rows; in order to skip all lines beginning with '#', the programmer writes something like: csv_reader = csv.reader(fp) for row in csv_reader: if row[0][0] != '#': #assuming no blank lines print row I propose adding a "commentchar" parameter to the csv parser, so that the above code could be written (more elegantly, in my opinion): csv_reader = csv.reader(fp, commentchar='#') for row in csv_reader: print row This requires only relatively minor changes to the module, and by defaulting to using no comment character, existing code will behave as before. If you are interested, the patch (diffs against current cvs) required for the second example to run are attached. Note that that implementation adds SKIPPED_RECORD as a pseudonym for START_RECORD, because setting status to START_RECORD after skipping a record would cause a blank record to be returned. Altering that behaviour would cause more changes and the patch would be harder to review. I've also held back on updating tests and documentation to reflect this change, pending any support for it. It shoud be irrelevant, but this has been developed on Debian testing against the cvs head of Python. ---------------------------------------------------------------------- >Comment By: Iain Haslam (iain_haslam) Date: 2005-06-26 17:26 Message: Logged In: YES user_id=1301296 > I'm not inclined to clutter the C code with further > complications. Sorry - I haven't been keeping up with the existing complications! Don't forget that one man's clutter is another man's functionality. It doesn't actually require much of a change to the code, although I was slightly suprised to discover that this module was in C in the first place... Basically, I noticed that the csv module has a bias towards Excel-generated csv files, but most of the time I've come across csv files, they were hand-edited, and I've often seen comment fields as described in the submission. My submission was intended in the "batteries included" spirit (I do understand that you stop short of the kitchen sink), and also seemed in-keeping with the 'skipinitialspace' option within the existing csv module. > Why can't you implement this on an as-needed basis > with a file object wrapper [other options] True, I could do any of those things, but it would be simpler / clearer not to have to. Of course, if you took your argument further, you could cut chunks out of several modules; the argument comes down to whether the benefits outweigh the additional complexity. I was suprised to discover the option wasn't already there, but maybe that's just me. In any case, if your vote goes from your apparent -0 to -1, that's your choice, and you're better placed to make it than I am. Cheers, Iain. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-25 19:39 Message: Logged In: YES user_id=44345 I'm not inclined to clutter the C code with further complications. Why can't you implement this on an as-needed basis with a file object wrapper, a subclass of the csv.reader class, or just continue to use the example in your submission? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1225769&group_id=5470 From noreply at sourceforge.net Sun Jun 26 20:02:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Jun 2005 11:02:02 -0700 Subject: [Patches] [ python-Patches-1225769 ] Proposal to implement comment rows in csv module Message-ID: Patches item #1225769, was opened at 2005-06-22 14:48 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1225769&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: Iain Haslam (iain_haslam) Assigned to: Skip Montanaro (montanaro) Summary: Proposal to implement comment rows in csv module Initial Comment: Sometimes csv files contain comment rows, for temporarily commenting out data or occasionally for documentation. The current csv module has no built-in ability to skip rows; in order to skip all lines beginning with '#', the programmer writes something like: csv_reader = csv.reader(fp) for row in csv_reader: if row[0][0] != '#': #assuming no blank lines print row I propose adding a "commentchar" parameter to the csv parser, so that the above code could be written (more elegantly, in my opinion): csv_reader = csv.reader(fp, commentchar='#') for row in csv_reader: print row This requires only relatively minor changes to the module, and by defaulting to using no comment character, existing code will behave as before. If you are interested, the patch (diffs against current cvs) required for the second example to run are attached. Note that that implementation adds SKIPPED_RECORD as a pseudonym for START_RECORD, because setting status to START_RECORD after skipping a record would cause a blank record to be returned. Altering that behaviour would cause more changes and the patch would be harder to review. I've also held back on updating tests and documentation to reflect this change, pending any support for it. It shoud be irrelevant, but this has been developed on Debian testing against the cvs head of Python. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-06-26 13:02 Message: Logged In: YES user_id=44345 Something else just occurred to me. What about writing csv files with comments? Also, a tweak to the docs would be in order if this is accepted. ---------------------------------------------------------------------- Comment By: Iain Haslam (iain_haslam) Date: 2005-06-26 12:26 Message: Logged In: YES user_id=1301296 > I'm not inclined to clutter the C code with further > complications. Sorry - I haven't been keeping up with the existing complications! Don't forget that one man's clutter is another man's functionality. It doesn't actually require much of a change to the code, although I was slightly suprised to discover that this module was in C in the first place... Basically, I noticed that the csv module has a bias towards Excel-generated csv files, but most of the time I've come across csv files, they were hand-edited, and I've often seen comment fields as described in the submission. My submission was intended in the "batteries included" spirit (I do understand that you stop short of the kitchen sink), and also seemed in-keeping with the 'skipinitialspace' option within the existing csv module. > Why can't you implement this on an as-needed basis > with a file object wrapper [other options] True, I could do any of those things, but it would be simpler / clearer not to have to. Of course, if you took your argument further, you could cut chunks out of several modules; the argument comes down to whether the benefits outweigh the additional complexity. I was suprised to discover the option wasn't already there, but maybe that's just me. In any case, if your vote goes from your apparent -0 to -1, that's your choice, and you're better placed to make it than I am. Cheers, Iain. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-25 14:39 Message: Logged In: YES user_id=44345 I'm not inclined to clutter the C code with further complications. Why can't you implement this on an as-needed basis with a file object wrapper, a subclass of the csv.reader class, or just continue to use the example in your submission? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1225769&group_id=5470 From noreply at sourceforge.net Sun Jun 26 20:33:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Jun 2005 11:33:50 -0700 Subject: [Patches] [ python-Patches-1116722 ] Solaris 10 fails to compile complexobject.c [FIX incl.] Message-ID: Patches item #1116722, was opened at 2005-02-05 08:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 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: Case Van Horsen (casevh) Assigned to: Martin v. L?wis (loewis) Summary: Solaris 10 fails to compile complexobject.c [FIX incl.] Initial Comment: This is a duplicate of 970334. The fix I used was to make the following change in pyport.h: Change #define Py_HUGE_VAL HUGE_VAL to #define PY_HUGE_VAL DBL_MAX. DBL_MAX is found in float.h Versions used: Python 2.4 gcc 3.4.3 Solaris 10 x86 GA release. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-06-26 20:33 Message: Logged In: YES user_id=21627 For the specific bug reported in this report (Py_HUGE_VAL HUGE_VAL), I would like to close this as a third-party bug, and mandate that GCC users use 3.4.5 or 4.0.1 on Solaris 10. However, it appears that the original problem (of g++ pre-defining _XOPEN_SOURCE) also persists. So we just extend the existing configure test to 5.10. slashlib: this bug is only about the HUGE_VAL problem. If additional problems exist, please report them in a separate report. ---------------------------------------------------------------------- Comment By: Bill Clarke (slashlib) Date: 2005-06-23 10:10 Message: Logged In: YES user_id=421902 to fix the XOPEN_SOURCE problem on Solaris 10 (and hence to be able to compile python modules with g++) you must _not_ define _XOPEN_SOURCE_EXTENDED. XOPEN_SOURCE must be 500 as well. here's a patch for configure.in for the XOPEN_SOURCE_EXTENDED change: """ --- configure.in~ 2005-03-29 09:23:34.000000000 +1000 +++ configure.in 2005-06-23 18:00:39.596747000 +1000 @@ -198,8 +198,15 @@ # definition of _XOPEN_SOURCE_EXTENDED and _POSIX_C_SOURCE, or else # several APIs are not declared. Since this is also needed in some # cases for HP-UX, we define it globally. - - AC_DEFINE(_XOPEN_SOURCE_EXTENDED, 1, Define to activate Unix95-and-earlier features) + # except for Solaris 10, where it must not be defined! + case $ac_sys_system/$ac_sys_release in + SunOS/5.10) + ;; + *) + AC_DEFINE(_XOPEN_SOURCE_EXTENDED, 1, + Define to activate Unix95-and-earlier features) + ;; + esac AC_DEFINE(_POSIX_C_SOURCE, 200112L, Define to activate features from IEEE Stds 1003.1-2001) """ this fix (along with _XOPEN_SOURCE == 500) means i can compile python modules with g++ now. yay! also note: Solaris 10's feature_tests header will override the setting of _POSIX_C_SOURCE (to 199506L) since _XOPEN_SOURCE is 500. from my reading, _POSIX_C_SOURCE should only be 200112L if _XOPEN_SOURCE is 600, so perhaps the _POSIX_C_SOURCE define should also be disabled for Solaris 10 (although this will make no material difference usually). ---------------------------------------------------------------------- Comment By: Bill Clarke (slashlib) Date: 2005-06-23 08:50 Message: Logged In: YES user_id=421902 i should clarify my comments, the thing that was recently fixed in gcc is the HUGE_VAL problem, not the XOPEN_SOURCE problem. note: an easy test for the XOPEN_SOURCE problem with g++ is: """ #include #include """ ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-06-23 07:35 Message: Logged In: YES user_id=1212585 "make testall" fails with an error in _curses: missing typeahead(). I don't know it that is normal or not. I will try some additional tests this weekend, including using the new iso/math_c99.h file. A more subtle issue is that some of the the Solaris Express releases identified themselves as 5.10.1 and the latest Solaris Express (and I believe OpenSolaris) identify themselves as 5.11 and will probably use 5.11.x in the future. I will try to upgrade to the latest Solaris Express release this weekend and report how that behaves. ---------------------------------------------------------------------- Comment By: Bill Clarke (slashlib) Date: 2005-06-23 06:54 Message: Logged In: YES user_id=421902 i hit this bug too. this has been fixed in gcc (will be in gcc 3.4.5 and 4.0.1). to workaround with (say) an installed gcc 3.4.4 build current gcc 3.4 cvs and copy the fixed iso/math_c99.h file from the build to the installed gcc fixed includes directory. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-06-22 16:47 Message: Logged In: YES user_id=29957 I haven't had time to try installing Solaris 10 on anything yet - does setting _XOPEN_SOURCE in this way break anything else? (does make testall complete ok?) If you could confirm it doesn't break anything else, I'll make the change for 2.5 and 2.4.2... ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-03-19 07:06 Message: Logged In: YES user_id=1212585 I found a reference in the 2.4a3 release notes that this problem was fixed for Solaris 8 and 9 with Patch #1006629. That patch set _XOPEN_SOURCE to 500. Using 2.4.1c2 source, I patched line 1521 from SunOS/5.8|SunOS/5.9) to SunOS/5.8|SunOS/5.9|SunOS/5.10) I successfully completed a make; make test with a generic Solaris 10 x86 install. I verified that it failed without the patch. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-03-04 23:28 Message: Logged In: YES user_id=1212585 Below is the official response from Sun. It doesn't look like Sun sees it as a problem. Document Audience: SPECTRUM Document ID: 6173815 Title: bug 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Update Date: Tue Oct 05 06:44:47 MDT 2004 Bug ID: 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Category: c++ Subcategory: compiler State: 11-Closed Description: * * This is a problem I ran into trying to compile Python 2.3.4 on a Solaris * 10 beta 63 (x86) system. I worked with Martin v. Lowis * to isolate the problem as it affects Python, but our * conclusion is that this is really a GCC/Solaris problem. * * -- Chris Wicklein * * ---------------------------------------- * * $ uname -a * SunOS solaris1 5.10 s10_63 i86pc i386 i86pc * * $ gcc -v * Reading specs from /opt/gcc/lib/gcc/i386-pc- solaris2.10/3.4.2/specs * Configured with: ../gcc-3.4.2/configure --with- as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls -- prefix=/opt/gcc * Thread model: posix * gcc version 3.4.2 * * $ gcc -o foo foo.c * * $ gcc -D_STDC_C99 -o foo foo.c * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ gcc -D_STDC_C99 -o foo foo.c --save-temps * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ grep __builtin_huge_val foo.i * if (x == __builtin_huge_val) { * * ---------------------------------------- * The problem for GCC is having HUGE_VAL expanded to __builtin_huge_val * (pointer to a function returning a double) rather than to * __builtin_huge_val() (call to a function returning a double.) * * Is this an error in the header file /usr/include/iso/math_c99.h * or something that was done intentionally to support the * Sun ONE compiler? (Is this something for Sun to fix, or should * this be addressed on the GCC end?) */ #include int main (int argc, char **argv) { double x = 3.14; if (x == HUGE_VAL) { x = 2.7; } return 0; } Customer comments: It is my understanding that HUGE_VAL is a standard C feature, and the function __builtin_huge_val() is a GCC- specific extension for implementing this standard C feature. If this is correct, then by referencing __builtin_huge_val in /usr/include/iso/math_c99.h, Solaris 10 is providing GCC- specific header support. (As an aside, it's remotely possible that my copy of math_c99.h was locally modified as part of installing GCC from a third-party package, but I doubt this happened.) Assuming then that Solaris 10 is providing support for a GCC- specific built-in function (__builtin_huge_val) in math_c99.h, then that support should be corrected (by adding the missing parens.) Otherwise, it will be necessary for GCC to work- around this header problem. Here then is the crux of the matter: assuming that math_c99.h contains this reference to __builtin_huge_val without the required parens, was this done to support GCC, or is this also used by the Sun Pro compiler? If this is present only for GCC, then the missing parens should be added by Sun, or I would like to know that Sun sees this as not-a-bug, in which case GCC will have to work around this itself. At any rate, I am not requesting support for GCC, but rather trying to understand 1) why math_c99.h references __builtin_huge_val as it does in Solaris 10, and 2) if this is something Sun views as a problem on the Solaris side to be fixed. > HI Chris, > > We do not support gcc A third-party C compiler; not supported. > ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-03-04 23:26 Message: Logged In: YES user_id=1212585 Below is the official response from Sun. It doesn't look like Sun sees it as a problem. Document Audience: SPECTRUM Document ID: 6173815 Title: bug 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Update Date: Tue Oct 05 06:44:47 MDT 2004 Bug ID: 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Category: c++ Subcategory: compiler State: 11-Closed Description: * * This is a problem I ran into trying to compile Python 2.3.4 on a Solaris * 10 beta 63 (x86) system. I worked with Martin v. Lowis * to isolate the problem as it affects Python, but our * conclusion is that this is really a GCC/Solaris problem. * * -- Chris Wicklein * * ---------------------------------------- * * $ uname -a * SunOS solaris1 5.10 s10_63 i86pc i386 i86pc * * $ gcc -v * Reading specs from /opt/gcc/lib/gcc/i386-pc- solaris2.10/3.4.2/specs * Configured with: ../gcc-3.4.2/configure --with- as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls -- prefix=/opt/gcc * Thread model: posix * gcc version 3.4.2 * * $ gcc -o foo foo.c * * $ gcc -D_STDC_C99 -o foo foo.c * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ gcc -D_STDC_C99 -o foo foo.c --save-temps * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ grep __builtin_huge_val foo.i * if (x == __builtin_huge_val) { * * ---------------------------------------- * The problem for GCC is having HUGE_VAL expanded to __builtin_huge_val * (pointer to a function returning a double) rather than to * __builtin_huge_val() (call to a function returning a double.) * * Is this an error in the header file /usr/include/iso/math_c99.h * or something that was done intentionally to support the * Sun ONE compiler? (Is this something for Sun to fix, or should * this be addressed on the GCC end?) */ #include int main (int argc, char **argv) { double x = 3.14; if (x == HUGE_VAL) { x = 2.7; } return 0; } Customer comments: It is my understanding that HUGE_VAL is a standard C feature, and the function __builtin_huge_val() is a GCC- specific extension for implementing this standard C feature. If this is correct, then by referencing __builtin_huge_val in /usr/include/iso/math_c99.h, Solaris 10 is providing GCC- specific header support. (As an aside, it's remotely possible that my copy of math_c99.h was locally modified as part of installing GCC from a third-party package, but I doubt this happened.) Assuming then that Solaris 10 is providing support for a GCC- specific built-in function (__builtin_huge_val) in math_c99.h, then that support should be corrected (by adding the missing parens.) Otherwise, it will be necessary for GCC to work- around this header problem. Here then is the crux of the matter: assuming that math_c99.h contains this reference to __builtin_huge_val without the required parens, was this done to support GCC, or is this also used by the Sun Pro compiler? If this is present only for GCC, then the missing parens should be added by Sun, or I would like to know that Sun sees this as not-a-bug, in which case GCC will have to work around this itself. At any rate, I am not requesting support for GCC, but rather trying to understand 1) why math_c99.h references __builtin_huge_val as it does in Solaris 10, and 2) if this is something Sun views as a problem on the Solaris side to be fixed. > HI Chris, > > We do not support gcc A third-party C compiler; not supported. > ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 20:04 Message: Logged In: YES user_id=21627 Turns out casevh's report is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 15:18 Message: Logged In: YES user_id=21627 I have now reported this bug to gcc as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20317 ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 07:33 Message: Logged In: YES user_id=1212585 Oops. I made a typo in one of my tests. It does include in /include/iso/math_c99.h when you type it correctly. I will work with Sun / gcc to determine a resolution. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 07:03 Message: Logged In: YES user_id=1212585 I poked around in the preprocessor outputs and it appears gcc doesn't its specific directory for math_c99.h. It only appears to look in /usr/include/iso. I changed the definition of HUGE_VAL in /usr/include/iso/math_c99.h to read: #define HUGE_VAL __builtin_huge_val() The hv2.c compiled completely and so did Python 2.4. I'll open a bug report with GCC and also with Sun since I used the version of GCC that was distributed by Sun. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 06:16 Message: Logged In: YES user_id=1212585 I ran mkheaders to rebuild the gcc headers but that made no difference. The following program (hv.c) compiled correctly: #define _XOPEN_SOURCE 500 #include int main() { double f=HUGE_VAL; } The following program (hv2.c) did not compile. #define _XOPEN_SOURCE 1000 #include int main() { double f=HUGE_VAL; } Output is: $ gcc --save-temps hv.c $ gcc --save-temp hv2.c hv2.c: In function `main': hv2.c:5: error: incompatible types in initialization $ I have attached hv.i and hv2.i. I have also attached complexobject.i I'm not a C programmer so please let me know what else I can do to help. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-10 17:50 Message: Logged In: YES user_id=1212585 I tried steps 1 through 4 and it fails, with and with the (). I'm not sure how to do step 5. I will try the short program snippet later and report back. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-10 05:44 Message: Logged In: YES user_id=31435 Doubt this will help: googling suggests that -Xc has to be passed to Sun's native C compiler to get HUGE_VAL defined correctly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-10 04:23 Message: Logged In: YES user_id=21627 I have the Solaris 10 iso/math_c99.h in front of me, but no gcc, so it is somewhat difficult to get through the ifdefery. It appears that we should have _XOPEN_SOURCE - 0 >= 600, so we should be using #define HUGE_VAL __builtin_huge_val The problem apparently is that in Sun CC, __builtin_huge_val appears to be a constant, whereas in gcc, it probably is a function, so the definition should read #define HUGE_VAL __builtin_huge_val() So there is a bug in the gcc port of Solaris here - fixincludes should adjust the definition of HUGE_VAL when installing its adjusted copy of math_c99.h. I'm willing to accept patches to work around this gcc bug, but only if the bug gets reported to gcc first. So, please, 1. find out the gcc installation directory on your system, using gcc --print-search-dirs 2a. check whether /include/iso/math_c99.h exists 2b. if it does not exist, copy if from /usr/include/iso/math_c99.h 3. edit /include/iso/math_c99.h to add the parentheses after builtin_huge_val 4. check whether this fixes the problem 5a. if not, provide the preprocessor output for complexobject.i, using --save-temps 5b. if it does, make a bug report to gcc, indicating that the program #include int main() { double f=HUGE_VAL; } fails on Solaris 10. For that report - check whether it actually fails without the update math_c99, and succeeds with it (you might have to #define _XOPEN_SOURCE to make it fail) - include the preprocessor output for this sample program, using the original math_c99 - indicate that a solution is to add parentheses 6. Come up with a patch that checks for Solaris 10 and all gcc versions showing the problem (i.e. 3.4.x, with x<=3, perhaps also 3.y, y<=3), and defines Py_HUGE_VAL correctly for this system. 7. Report the gcc bug number and the patch in this report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-10 02:43 Message: Logged In: YES user_id=31435 The C standard requires that "The macro HUGE_VAL expands to a positive double constant expression, not necessarily representable as a float". Python requires that too. #define'ing to worm around a broken compilation environment isn't acceptable to me; finding a switch to make this environment conform to the standard would be OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 From noreply at sourceforge.net Mon Jun 27 00:00:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Jun 2005 15:00:23 -0700 Subject: [Patches] [ python-Patches-1144549 ] cgitb: make more usable for 'binary-only' sw (new patch) Message-ID: Patches item #1144549, was opened at 2005-02-19 23:23 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144549&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: Closed >Resolution: Accepted Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: cgitb: make more usable for 'binary-only' sw (new patch) Initial Comment: see patch #751943: """ I am abusing cgitb to show a traceback window for a GUI application in Qt. In such a case, the source code to the program is not always available. The stack trace is anyway useful to be submitted to the developers of the code. I attach a patch that should add some info to the HTML traceback made by cgitb in case the source file is not available. """ This new patch, however, does not generate a link to "file://?" if the filename is not known. At the same time, it stops shadowing file() by renaming local vars. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-27 00:00 Message: Logged In: YES user_id=1188172 Fixed the link to file://?/. Did not do the renaming of variables. (Don't touch working code.) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-04-02 19:13 Message: Logged In: YES user_id=1188172 Deleted first, useless patch. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-02-20 08:17 Message: Logged In: YES user_id=1188172 You're right, the 'or ?' must vanish; see attached second patch. But I did diff against CVS HEAD, didn't I? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-02-20 03:14 Message: Logged In: NO ! filename = os.path.abspath(filename) or '?' Why is the 'or ?' still there? Also, patches are preferred to be against CVS HEAD, rather than against a previous patched version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144549&group_id=5470 From noreply at sourceforge.net Mon Jun 27 02:32:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Jun 2005 17:32:47 -0700 Subject: [Patches] [ python-Patches-1227966 ] solaris 10 should not define _XOPEN_SOURCE_EXTENDED Message-ID: Patches item #1227966, was opened at 2005-06-27 10:32 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=1227966&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: Bill Clarke (slashlib) Assigned to: Nobody/Anonymous (nobody) Summary: solaris 10 should not define _XOPEN_SOURCE_EXTENDED Initial Comment: on Solaris 10, defining _XOPEN_SOURCE_EXTENDED implies a maximum _XPG specification of _XPG4v2. what we want is _XPG5. note: see also bug 1116722 , _XOPEN_SOURCE must be 500 for Solaris 10. the effect of this bug is that we cannot build python modules with g++. e.g., with this file: """ #include "Python.h" #include """" you get errors like this: """ $ g++ -m64 -I/usr/local/64/include/python2.4 -c test.cc In file included from /usr/local/64/include/python2.4/Python.h:8, from test.cc:1: /usr/local/64/include/python2.4/pyconfig.h:844:1: warning: "_XOPEN_SOURCE" redefined :84:1: warning: this is the location of the previous definition In file included from test.cc:2: [...]../include/c++/3.4.4/cwchar:145: error: `::btowc' has not been declared [...]../include/c++/3.4.4/cwchar:150: error: `::fwide' has not been declared ... """ a patch for configure.in (against 2.4.1) is attached to fix this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227966&group_id=5470 From noreply at sourceforge.net Mon Jun 27 02:38:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Jun 2005 17:38:27 -0700 Subject: [Patches] [ python-Patches-1116722 ] Solaris 10 fails to compile complexobject.c [FIX incl.] Message-ID: Patches item #1116722, was opened at 2005-02-05 18:02 Message generated for change (Comment added) made by slashlib You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&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: Case Van Horsen (casevh) Assigned to: Martin v. L?wis (loewis) Summary: Solaris 10 fails to compile complexobject.c [FIX incl.] Initial Comment: This is a duplicate of 970334. The fix I used was to make the following change in pyport.h: Change #define Py_HUGE_VAL HUGE_VAL to #define PY_HUGE_VAL DBL_MAX. DBL_MAX is found in float.h Versions used: Python 2.4 gcc 3.4.3 Solaris 10 x86 GA release. ---------------------------------------------------------------------- Comment By: Bill Clarke (slashlib) Date: 2005-06-27 10:38 Message: Logged In: YES user_id=421902 >For the specific bug reported in this report (Py_HUGE_VAL > HUGE_VAL), I would like to close this as a third-party bug, > and mandate that GCC users use 3.4.5 or 4.0.1 on Solaris 10. sounds fine to me, except neither of those versions have been released yet (-: > slashlib: this bug is only about the HUGE_VAL problem. If > additional problems exist, please report them in a separate > report. my apologies. new bug report is 1227966 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-06-27 04:33 Message: Logged In: YES user_id=21627 For the specific bug reported in this report (Py_HUGE_VAL HUGE_VAL), I would like to close this as a third-party bug, and mandate that GCC users use 3.4.5 or 4.0.1 on Solaris 10. However, it appears that the original problem (of g++ pre-defining _XOPEN_SOURCE) also persists. So we just extend the existing configure test to 5.10. slashlib: this bug is only about the HUGE_VAL problem. If additional problems exist, please report them in a separate report. ---------------------------------------------------------------------- Comment By: Bill Clarke (slashlib) Date: 2005-06-23 18:10 Message: Logged In: YES user_id=421902 to fix the XOPEN_SOURCE problem on Solaris 10 (and hence to be able to compile python modules with g++) you must _not_ define _XOPEN_SOURCE_EXTENDED. XOPEN_SOURCE must be 500 as well. here's a patch for configure.in for the XOPEN_SOURCE_EXTENDED change: """ --- configure.in~ 2005-03-29 09:23:34.000000000 +1000 +++ configure.in 2005-06-23 18:00:39.596747000 +1000 @@ -198,8 +198,15 @@ # definition of _XOPEN_SOURCE_EXTENDED and _POSIX_C_SOURCE, or else # several APIs are not declared. Since this is also needed in some # cases for HP-UX, we define it globally. - - AC_DEFINE(_XOPEN_SOURCE_EXTENDED, 1, Define to activate Unix95-and-earlier features) + # except for Solaris 10, where it must not be defined! + case $ac_sys_system/$ac_sys_release in + SunOS/5.10) + ;; + *) + AC_DEFINE(_XOPEN_SOURCE_EXTENDED, 1, + Define to activate Unix95-and-earlier features) + ;; + esac AC_DEFINE(_POSIX_C_SOURCE, 200112L, Define to activate features from IEEE Stds 1003.1-2001) """ this fix (along with _XOPEN_SOURCE == 500) means i can compile python modules with g++ now. yay! also note: Solaris 10's feature_tests header will override the setting of _POSIX_C_SOURCE (to 199506L) since _XOPEN_SOURCE is 500. from my reading, _POSIX_C_SOURCE should only be 200112L if _XOPEN_SOURCE is 600, so perhaps the _POSIX_C_SOURCE define should also be disabled for Solaris 10 (although this will make no material difference usually). ---------------------------------------------------------------------- Comment By: Bill Clarke (slashlib) Date: 2005-06-23 16:50 Message: Logged In: YES user_id=421902 i should clarify my comments, the thing that was recently fixed in gcc is the HUGE_VAL problem, not the XOPEN_SOURCE problem. note: an easy test for the XOPEN_SOURCE problem with g++ is: """ #include #include """ ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-06-23 15:35 Message: Logged In: YES user_id=1212585 "make testall" fails with an error in _curses: missing typeahead(). I don't know it that is normal or not. I will try some additional tests this weekend, including using the new iso/math_c99.h file. A more subtle issue is that some of the the Solaris Express releases identified themselves as 5.10.1 and the latest Solaris Express (and I believe OpenSolaris) identify themselves as 5.11 and will probably use 5.11.x in the future. I will try to upgrade to the latest Solaris Express release this weekend and report how that behaves. ---------------------------------------------------------------------- Comment By: Bill Clarke (slashlib) Date: 2005-06-23 14:54 Message: Logged In: YES user_id=421902 i hit this bug too. this has been fixed in gcc (will be in gcc 3.4.5 and 4.0.1). to workaround with (say) an installed gcc 3.4.4 build current gcc 3.4 cvs and copy the fixed iso/math_c99.h file from the build to the installed gcc fixed includes directory. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-06-23 00:47 Message: Logged In: YES user_id=29957 I haven't had time to try installing Solaris 10 on anything yet - does setting _XOPEN_SOURCE in this way break anything else? (does make testall complete ok?) If you could confirm it doesn't break anything else, I'll make the change for 2.5 and 2.4.2... ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-03-19 17:06 Message: Logged In: YES user_id=1212585 I found a reference in the 2.4a3 release notes that this problem was fixed for Solaris 8 and 9 with Patch #1006629. That patch set _XOPEN_SOURCE to 500. Using 2.4.1c2 source, I patched line 1521 from SunOS/5.8|SunOS/5.9) to SunOS/5.8|SunOS/5.9|SunOS/5.10) I successfully completed a make; make test with a generic Solaris 10 x86 install. I verified that it failed without the patch. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-03-05 09:28 Message: Logged In: YES user_id=1212585 Below is the official response from Sun. It doesn't look like Sun sees it as a problem. Document Audience: SPECTRUM Document ID: 6173815 Title: bug 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Update Date: Tue Oct 05 06:44:47 MDT 2004 Bug ID: 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Category: c++ Subcategory: compiler State: 11-Closed Description: * * This is a problem I ran into trying to compile Python 2.3.4 on a Solaris * 10 beta 63 (x86) system. I worked with Martin v. Lowis * to isolate the problem as it affects Python, but our * conclusion is that this is really a GCC/Solaris problem. * * -- Chris Wicklein * * ---------------------------------------- * * $ uname -a * SunOS solaris1 5.10 s10_63 i86pc i386 i86pc * * $ gcc -v * Reading specs from /opt/gcc/lib/gcc/i386-pc- solaris2.10/3.4.2/specs * Configured with: ../gcc-3.4.2/configure --with- as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls -- prefix=/opt/gcc * Thread model: posix * gcc version 3.4.2 * * $ gcc -o foo foo.c * * $ gcc -D_STDC_C99 -o foo foo.c * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ gcc -D_STDC_C99 -o foo foo.c --save-temps * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ grep __builtin_huge_val foo.i * if (x == __builtin_huge_val) { * * ---------------------------------------- * The problem for GCC is having HUGE_VAL expanded to __builtin_huge_val * (pointer to a function returning a double) rather than to * __builtin_huge_val() (call to a function returning a double.) * * Is this an error in the header file /usr/include/iso/math_c99.h * or something that was done intentionally to support the * Sun ONE compiler? (Is this something for Sun to fix, or should * this be addressed on the GCC end?) */ #include int main (int argc, char **argv) { double x = 3.14; if (x == HUGE_VAL) { x = 2.7; } return 0; } Customer comments: It is my understanding that HUGE_VAL is a standard C feature, and the function __builtin_huge_val() is a GCC- specific extension for implementing this standard C feature. If this is correct, then by referencing __builtin_huge_val in /usr/include/iso/math_c99.h, Solaris 10 is providing GCC- specific header support. (As an aside, it's remotely possible that my copy of math_c99.h was locally modified as part of installing GCC from a third-party package, but I doubt this happened.) Assuming then that Solaris 10 is providing support for a GCC- specific built-in function (__builtin_huge_val) in math_c99.h, then that support should be corrected (by adding the missing parens.) Otherwise, it will be necessary for GCC to work- around this header problem. Here then is the crux of the matter: assuming that math_c99.h contains this reference to __builtin_huge_val without the required parens, was this done to support GCC, or is this also used by the Sun Pro compiler? If this is present only for GCC, then the missing parens should be added by Sun, or I would like to know that Sun sees this as not-a-bug, in which case GCC will have to work around this itself. At any rate, I am not requesting support for GCC, but rather trying to understand 1) why math_c99.h references __builtin_huge_val as it does in Solaris 10, and 2) if this is something Sun views as a problem on the Solaris side to be fixed. > HI Chris, > > We do not support gcc A third-party C compiler; not supported. > ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-03-05 09:26 Message: Logged In: YES user_id=1212585 Below is the official response from Sun. It doesn't look like Sun sees it as a problem. Document Audience: SPECTRUM Document ID: 6173815 Title: bug 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Update Date: Tue Oct 05 06:44:47 MDT 2004 Bug ID: 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Category: c++ Subcategory: compiler State: 11-Closed Description: * * This is a problem I ran into trying to compile Python 2.3.4 on a Solaris * 10 beta 63 (x86) system. I worked with Martin v. Lowis * to isolate the problem as it affects Python, but our * conclusion is that this is really a GCC/Solaris problem. * * -- Chris Wicklein * * ---------------------------------------- * * $ uname -a * SunOS solaris1 5.10 s10_63 i86pc i386 i86pc * * $ gcc -v * Reading specs from /opt/gcc/lib/gcc/i386-pc- solaris2.10/3.4.2/specs * Configured with: ../gcc-3.4.2/configure --with- as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls -- prefix=/opt/gcc * Thread model: posix * gcc version 3.4.2 * * $ gcc -o foo foo.c * * $ gcc -D_STDC_C99 -o foo foo.c * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ gcc -D_STDC_C99 -o foo foo.c --save-temps * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ grep __builtin_huge_val foo.i * if (x == __builtin_huge_val) { * * ---------------------------------------- * The problem for GCC is having HUGE_VAL expanded to __builtin_huge_val * (pointer to a function returning a double) rather than to * __builtin_huge_val() (call to a function returning a double.) * * Is this an error in the header file /usr/include/iso/math_c99.h * or something that was done intentionally to support the * Sun ONE compiler? (Is this something for Sun to fix, or should * this be addressed on the GCC end?) */ #include int main (int argc, char **argv) { double x = 3.14; if (x == HUGE_VAL) { x = 2.7; } return 0; } Customer comments: It is my understanding that HUGE_VAL is a standard C feature, and the function __builtin_huge_val() is a GCC- specific extension for implementing this standard C feature. If this is correct, then by referencing __builtin_huge_val in /usr/include/iso/math_c99.h, Solaris 10 is providing GCC- specific header support. (As an aside, it's remotely possible that my copy of math_c99.h was locally modified as part of installing GCC from a third-party package, but I doubt this happened.) Assuming then that Solaris 10 is providing support for a GCC- specific built-in function (__builtin_huge_val) in math_c99.h, then that support should be corrected (by adding the missing parens.) Otherwise, it will be necessary for GCC to work- around this header problem. Here then is the crux of the matter: assuming that math_c99.h contains this reference to __builtin_huge_val without the required parens, was this done to support GCC, or is this also used by the Sun Pro compiler? If this is present only for GCC, then the missing parens should be added by Sun, or I would like to know that Sun sees this as not-a-bug, in which case GCC will have to work around this itself. At any rate, I am not requesting support for GCC, but rather trying to understand 1) why math_c99.h references __builtin_huge_val as it does in Solaris 10, and 2) if this is something Sun views as a problem on the Solaris side to be fixed. > HI Chris, > > We do not support gcc A third-party C compiler; not supported. > ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-05 06:04 Message: Logged In: YES user_id=21627 Turns out casevh's report is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-05 01:18 Message: Logged In: YES user_id=21627 I have now reported this bug to gcc as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20317 ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 17:33 Message: Logged In: YES user_id=1212585 Oops. I made a typo in one of my tests. It does include in /include/iso/math_c99.h when you type it correctly. I will work with Sun / gcc to determine a resolution. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 17:03 Message: Logged In: YES user_id=1212585 I poked around in the preprocessor outputs and it appears gcc doesn't its specific directory for math_c99.h. It only appears to look in /usr/include/iso. I changed the definition of HUGE_VAL in /usr/include/iso/math_c99.h to read: #define HUGE_VAL __builtin_huge_val() The hv2.c compiled completely and so did Python 2.4. I'll open a bug report with GCC and also with Sun since I used the version of GCC that was distributed by Sun. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 16:16 Message: Logged In: YES user_id=1212585 I ran mkheaders to rebuild the gcc headers but that made no difference. The following program (hv.c) compiled correctly: #define _XOPEN_SOURCE 500 #include int main() { double f=HUGE_VAL; } The following program (hv2.c) did not compile. #define _XOPEN_SOURCE 1000 #include int main() { double f=HUGE_VAL; } Output is: $ gcc --save-temps hv.c $ gcc --save-temp hv2.c hv2.c: In function `main': hv2.c:5: error: incompatible types in initialization $ I have attached hv.i and hv2.i. I have also attached complexobject.i I'm not a C programmer so please let me know what else I can do to help. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 03:50 Message: Logged In: YES user_id=1212585 I tried steps 1 through 4 and it fails, with and with the (). I'm not sure how to do step 5. I will try the short program snippet later and report back. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-10 15:44 Message: Logged In: YES user_id=31435 Doubt this will help: googling suggests that -Xc has to be passed to Sun's native C compiler to get HUGE_VAL defined correctly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-10 14:23 Message: Logged In: YES user_id=21627 I have the Solaris 10 iso/math_c99.h in front of me, but no gcc, so it is somewhat difficult to get through the ifdefery. It appears that we should have _XOPEN_SOURCE - 0 >= 600, so we should be using #define HUGE_VAL __builtin_huge_val The problem apparently is that in Sun CC, __builtin_huge_val appears to be a constant, whereas in gcc, it probably is a function, so the definition should read #define HUGE_VAL __builtin_huge_val() So there is a bug in the gcc port of Solaris here - fixincludes should adjust the definition of HUGE_VAL when installing its adjusted copy of math_c99.h. I'm willing to accept patches to work around this gcc bug, but only if the bug gets reported to gcc first. So, please, 1. find out the gcc installation directory on your system, using gcc --print-search-dirs 2a. check whether /include/iso/math_c99.h exists 2b. if it does not exist, copy if from /usr/include/iso/math_c99.h 3. edit /include/iso/math_c99.h to add the parentheses after builtin_huge_val 4. check whether this fixes the problem 5a. if not, provide the preprocessor output for complexobject.i, using --save-temps 5b. if it does, make a bug report to gcc, indicating that the program #include int main() { double f=HUGE_VAL; } fails on Solaris 10. For that report - check whether it actually fails without the update math_c99, and succeeds with it (you might have to #define _XOPEN_SOURCE to make it fail) - include the preprocessor output for this sample program, using the original math_c99 - indicate that a solution is to add parentheses 6. Come up with a patch that checks for Solaris 10 and all gcc versions showing the problem (i.e. 3.4.x, with x<=3, perhaps also 3.y, y<=3), and defines Py_HUGE_VAL correctly for this system. 7. Report the gcc bug number and the patch in this report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-10 12:43 Message: Logged In: YES user_id=31435 The C standard requires that "The macro HUGE_VAL expands to a positive double constant expression, not necessarily representable as a float". Python requires that too. #define'ing to worm around a broken compilation environment isn't acceptable to me; finding a switch to make this environment conform to the standard would be OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 From noreply at sourceforge.net Mon Jun 27 11:33:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Jun 2005 02:33:01 -0700 Subject: [Patches] [ python-Patches-1228112 ] code.py use sys.excepthook to display exceptions Message-ID: Patches item #1228112, was opened at 2005-06-27 12: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=1228112&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: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: code.py use sys.excepthook to display exceptions Initial Comment: This patch makes code.py InteractiveInterpreter use sys.excepthook to display exceptions. This way if a user changes sys.excepthook it will be used by the InteractiveInterpreter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1228112&group_id=5470 From noreply at sourceforge.net Mon Jun 27 12:57:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Jun 2005 03:57:24 -0700 Subject: [Patches] [ python-Patches-1228112 ] code.py use sys.excepthook to display exceptions Message-ID: Patches item #1228112, was opened at 2005-06-27 10:33 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1228112&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: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: code.py use sys.excepthook to display exceptions Initial Comment: This patch makes code.py InteractiveInterpreter use sys.excepthook to display exceptions. This way if a user changes sys.excepthook it will be used by the InteractiveInterpreter. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-06-27 11:57 Message: Logged In: YES user_id=6656 Seems like a good idea to me. The only quibble around the area of self.write -- it might break code that overrides that (IDLE?). Also, shouldn't showsyntaxerror be changed too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1228112&group_id=5470 From noreply at sourceforge.net Mon Jun 27 17:22:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Jun 2005 08:22:56 -0700 Subject: [Patches] [ python-Patches-1223381 ] PEP 342 Generator enhancements Message-ID: Patches item #1223381, was opened at 2005-06-18 19:08 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1223381&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: Phillip J. Eby (pje) Assigned to: Nobody/Anonymous (nobody) >Summary: PEP 342 Generator enhancements Initial Comment: The attached patch implements code and test changes for: * yield expressions * bare yield (short for yield None) * yield in try/finally * generator.send(value) (send value into generator; substituted for PEP 342's next(arg)) * generator.throw(typ[,val[,tb]]) (raise error in generator) * generator.close() (per PEP 343) * GeneratorExit built-in exception type * generator.__del__ (well, the C equivalent) * All necessary mods to the compiler, parser module, and Python 'compiler' package to support these changes. It was necessary to change a small part of the eval loop (well, the initialization, not the loop) and the gc module's has_finalizer() logic in order to support a C equivalent to __del__. Specialists in these areas should probably scrutinize this patch! There is one additional implementation detail that was not contemplated in either PEP. in order to prevent used-up generators from retaining unnecessary references to their frame's contents, I set the generator's gi_frame member to None whenever the generator finishes normally or with an error. Thus, an exhausted generator cannot be part of a cycle, and it releases its frame object sooner than in previous Python versions. For generators used only in a direct "for" loop, this makes no difference, but for generators used with the iterator protocol (i.e. "gen.next()") from Python, this avoids stranding the generator's frame in a traceback cycle. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-27 11:22 Message: Logged In: YES user_id=6380 (Removing 343 from the subject since all this is now in PEP 342.) Playing with the code a bit, I notice that throw() doesn't like string exceptions. That could cause some problems. Also, I think the tb argument should be allowed to be None. Otherwise, great! In a few hours you can check it in. :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-23 19:20 Message: Logged In: YES user_id=6656 Fair enough. I want to use with statements in a presentation at EuroPython next week, so I've hacked together a truly horrible implementation that will do for now and will see about a real one some time after... ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2005-06-23 19:07 Message: Logged In: YES user_id=56214 No, I haven't, and I never really planned to be the person implementing "with". Doesn't mean I might not end up doing it eventually, but it's not currently in my plans. I'm going to have my hands full just updating PEP 342 (Guido has asked me to take it over), and getting docs written to go with this patch. Between all that and my distutils-related work, my pro-bono Python project time is booked up solid for maybe the next 2 months or so. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-22 16:59 Message: Logged In: YES user_id=6656 Argh, I'd hoped you'd done with, too :) Have you done any work on that yet? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-19 03:37 Message: Logged In: YES user_id=1188172 Minor nit: on line 642, 'yield_stmt' should be changed to 'yield_expr'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1223381&group_id=5470 From noreply at sourceforge.net Mon Jun 27 17:31:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Jun 2005 08:31:54 -0700 Subject: [Patches] [ python-Patches-1223381 ] PEP 342 Generator enhancements Message-ID: Patches item #1223381, was opened at 2005-06-19 00:08 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1223381&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: Phillip J. Eby (pje) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 342 Generator enhancements Initial Comment: The attached patch implements code and test changes for: * yield expressions * bare yield (short for yield None) * yield in try/finally * generator.send(value) (send value into generator; substituted for PEP 342's next(arg)) * generator.throw(typ[,val[,tb]]) (raise error in generator) * generator.close() (per PEP 343) * GeneratorExit built-in exception type * generator.__del__ (well, the C equivalent) * All necessary mods to the compiler, parser module, and Python 'compiler' package to support these changes. It was necessary to change a small part of the eval loop (well, the initialization, not the loop) and the gc module's has_finalizer() logic in order to support a C equivalent to __del__. Specialists in these areas should probably scrutinize this patch! There is one additional implementation detail that was not contemplated in either PEP. in order to prevent used-up generators from retaining unnecessary references to their frame's contents, I set the generator's gi_frame member to None whenever the generator finishes normally or with an error. Thus, an exhausted generator cannot be part of a cycle, and it releases its frame object sooner than in previous Python versions. For generators used only in a direct "for" loop, this makes no difference, but for generators used with the iterator protocol (i.e. "gen.next()") from Python, this avoids stranding the generator's frame in a traceback cycle. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-06-27 16:31 Message: Logged In: YES user_id=6656 Heh heh heh. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-27 16:22 Message: Logged In: YES user_id=6380 (Removing 343 from the subject since all this is now in PEP 342.) Playing with the code a bit, I notice that throw() doesn't like string exceptions. That could cause some problems. Also, I think the tb argument should be allowed to be None. Otherwise, great! In a few hours you can check it in. :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-24 00:20 Message: Logged In: YES user_id=6656 Fair enough. I want to use with statements in a presentation at EuroPython next week, so I've hacked together a truly horrible implementation that will do for now and will see about a real one some time after... ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2005-06-24 00:07 Message: Logged In: YES user_id=56214 No, I haven't, and I never really planned to be the person implementing "with". Doesn't mean I might not end up doing it eventually, but it's not currently in my plans. I'm going to have my hands full just updating PEP 342 (Guido has asked me to take it over), and getting docs written to go with this patch. Between all that and my distutils-related work, my pro-bono Python project time is booked up solid for maybe the next 2 months or so. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-22 21:59 Message: Logged In: YES user_id=6656 Argh, I'd hoped you'd done with, too :) Have you done any work on that yet? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-19 08:37 Message: Logged In: YES user_id=1188172 Minor nit: on line 642, 'yield_stmt' should be changed to 'yield_expr'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1223381&group_id=5470 From noreply at sourceforge.net Mon Jun 27 17:40:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Jun 2005 08:40:49 -0700 Subject: [Patches] [ python-Patches-1223381 ] PEP 342 Generator enhancements Message-ID: Patches item #1223381, was opened at 2005-06-18 23:08 Message generated for change (Comment added) made by pje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1223381&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: Phillip J. Eby (pje) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 342 Generator enhancements Initial Comment: The attached patch implements code and test changes for: * yield expressions * bare yield (short for yield None) * yield in try/finally * generator.send(value) (send value into generator; substituted for PEP 342's next(arg)) * generator.throw(typ[,val[,tb]]) (raise error in generator) * generator.close() (per PEP 343) * GeneratorExit built-in exception type * generator.__del__ (well, the C equivalent) * All necessary mods to the compiler, parser module, and Python 'compiler' package to support these changes. It was necessary to change a small part of the eval loop (well, the initialization, not the loop) and the gc module's has_finalizer() logic in order to support a C equivalent to __del__. Specialists in these areas should probably scrutinize this patch! There is one additional implementation detail that was not contemplated in either PEP. in order to prevent used-up generators from retaining unnecessary references to their frame's contents, I set the generator's gi_frame member to None whenever the generator finishes normally or with an error. Thus, an exhausted generator cannot be part of a cycle, and it releases its frame object sooner than in previous Python versions. For generators used only in a direct "for" loop, this makes no difference, but for generators used with the iterator protocol (i.e. "gen.next()") from Python, this avoids stranding the generator's frame in a traceback cycle. ---------------------------------------------------------------------- >Comment By: Phillip J. Eby (pje) Date: 2005-06-27 15:40 Message: Logged In: YES user_id=56214 I had hoped to be able to avoid dealing with string exceptions, but I guess it makes sense that if somebody has thrown one, it should be able to propagate. So I guess I'll take care of that along with the rest. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-27 15:31 Message: Logged In: YES user_id=6656 Heh heh heh. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-27 15:22 Message: Logged In: YES user_id=6380 (Removing 343 from the subject since all this is now in PEP 342.) Playing with the code a bit, I notice that throw() doesn't like string exceptions. That could cause some problems. Also, I think the tb argument should be allowed to be None. Otherwise, great! In a few hours you can check it in. :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-23 23:20 Message: Logged In: YES user_id=6656 Fair enough. I want to use with statements in a presentation at EuroPython next week, so I've hacked together a truly horrible implementation that will do for now and will see about a real one some time after... ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2005-06-23 23:07 Message: Logged In: YES user_id=56214 No, I haven't, and I never really planned to be the person implementing "with". Doesn't mean I might not end up doing it eventually, but it's not currently in my plans. I'm going to have my hands full just updating PEP 342 (Guido has asked me to take it over), and getting docs written to go with this patch. Between all that and my distutils-related work, my pro-bono Python project time is booked up solid for maybe the next 2 months or so. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-22 20:59 Message: Logged In: YES user_id=6656 Argh, I'd hoped you'd done with, too :) Have you done any work on that yet? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-19 07:37 Message: Logged In: YES user_id=1188172 Minor nit: on line 642, 'yield_stmt' should be changed to 'yield_expr'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1223381&group_id=5470 From noreply at sourceforge.net Mon Jun 27 19:25:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Jun 2005 10:25:58 -0700 Subject: [Patches] [ python-Patches-1225769 ] Proposal to implement comment rows in csv module Message-ID: Patches item #1225769, was opened at 2005-06-22 14:48 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1225769&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: Iain Haslam (iain_haslam) Assigned to: Skip Montanaro (montanaro) Summary: Proposal to implement comment rows in csv module Initial Comment: Sometimes csv files contain comment rows, for temporarily commenting out data or occasionally for documentation. The current csv module has no built-in ability to skip rows; in order to skip all lines beginning with '#', the programmer writes something like: csv_reader = csv.reader(fp) for row in csv_reader: if row[0][0] != '#': #assuming no blank lines print row I propose adding a "commentchar" parameter to the csv parser, so that the above code could be written (more elegantly, in my opinion): csv_reader = csv.reader(fp, commentchar='#') for row in csv_reader: print row This requires only relatively minor changes to the module, and by defaulting to using no comment character, existing code will behave as before. If you are interested, the patch (diffs against current cvs) required for the second example to run are attached. Note that that implementation adds SKIPPED_RECORD as a pseudonym for START_RECORD, because setting status to START_RECORD after skipping a record would cause a blank record to be returned. Altering that behaviour would cause more changes and the patch would be harder to review. I've also held back on updating tests and documentation to reflect this change, pending any support for it. It shoud be irrelevant, but this has been developed on Debian testing against the cvs head of Python. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-06-27 12:25 Message: Logged In: YES user_id=44345 Iain - There was some positive response to your patch from the csv mailing list (most notably from one of the authors of the C extension module). Can you provide diffs for the module documentation and necessary test cases to go along with your patch? Also, addressing the issue that CSV files with comments (probably?) won't round-trip would be a good thing to note in the docs. Skip ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-26 13:02 Message: Logged In: YES user_id=44345 Something else just occurred to me. What about writing csv files with comments? Also, a tweak to the docs would be in order if this is accepted. ---------------------------------------------------------------------- Comment By: Iain Haslam (iain_haslam) Date: 2005-06-26 12:26 Message: Logged In: YES user_id=1301296 > I'm not inclined to clutter the C code with further > complications. Sorry - I haven't been keeping up with the existing complications! Don't forget that one man's clutter is another man's functionality. It doesn't actually require much of a change to the code, although I was slightly suprised to discover that this module was in C in the first place... Basically, I noticed that the csv module has a bias towards Excel-generated csv files, but most of the time I've come across csv files, they were hand-edited, and I've often seen comment fields as described in the submission. My submission was intended in the "batteries included" spirit (I do understand that you stop short of the kitchen sink), and also seemed in-keeping with the 'skipinitialspace' option within the existing csv module. > Why can't you implement this on an as-needed basis > with a file object wrapper [other options] True, I could do any of those things, but it would be simpler / clearer not to have to. Of course, if you took your argument further, you could cut chunks out of several modules; the argument comes down to whether the benefits outweigh the additional complexity. I was suprised to discover the option wasn't already there, but maybe that's just me. In any case, if your vote goes from your apparent -0 to -1, that's your choice, and you're better placed to make it than I am. Cheers, Iain. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-25 14:39 Message: Logged In: YES user_id=44345 I'm not inclined to clutter the C code with further complications. Why can't you implement this on an as-needed basis with a file object wrapper, a subclass of the csv.reader class, or just continue to use the example in your submission? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1225769&group_id=5470 From noreply at sourceforge.net Tue Jun 28 07:43:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Jun 2005 22:43:34 -0700 Subject: [Patches] [ python-Patches-1116722 ] Solaris 10 fails to compile complexobject.c [FIX incl.] Message-ID: Patches item #1116722, was opened at 2005-02-04 23:02 Message generated for change (Comment added) made by casevh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 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: Case Van Horsen (casevh) Assigned to: Martin v. L?wis (loewis) Summary: Solaris 10 fails to compile complexobject.c [FIX incl.] Initial Comment: This is a duplicate of 970334. The fix I used was to make the following change in pyport.h: Change #define Py_HUGE_VAL HUGE_VAL to #define PY_HUGE_VAL DBL_MAX. DBL_MAX is found in float.h Versions used: Python 2.4 gcc 3.4.3 Solaris 10 x86 GA release. ---------------------------------------------------------------------- >Comment By: Case Van Horsen (casevh) Date: 2005-06-27 22:43 Message: Logged In: YES user_id=1212585 GCC 3.4.3 is shipped with Solaris 10. I think it would be unfortunate to mandate GCC 3.4.5 or 4.0.1. At my real job, requiring a different version of GCC would be unacceptable. Comments in the README file documenting the problem and listing the word-arounds would be acceptable. I would be willing to write a draft version of the comments. BTW, OpenSolaris and the latest Solaris Express releases from Sun report the OS version as 5.11 and still come with GCC 3.4.3. Some intervening versions report themselves as 5.10.1. Sun's Studio 10 compiler is available for free for use with OpenSolaris and it does compile python properly as is. ---------------------------------------------------------------------- Comment By: Bill Clarke (slashlib) Date: 2005-06-26 17:38 Message: Logged In: YES user_id=421902 >For the specific bug reported in this report (Py_HUGE_VAL > HUGE_VAL), I would like to close this as a third-party bug, > and mandate that GCC users use 3.4.5 or 4.0.1 on Solaris 10. sounds fine to me, except neither of those versions have been released yet (-: > slashlib: this bug is only about the HUGE_VAL problem. If > additional problems exist, please report them in a separate > report. my apologies. new bug report is 1227966 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-06-26 11:33 Message: Logged In: YES user_id=21627 For the specific bug reported in this report (Py_HUGE_VAL HUGE_VAL), I would like to close this as a third-party bug, and mandate that GCC users use 3.4.5 or 4.0.1 on Solaris 10. However, it appears that the original problem (of g++ pre-defining _XOPEN_SOURCE) also persists. So we just extend the existing configure test to 5.10. slashlib: this bug is only about the HUGE_VAL problem. If additional problems exist, please report them in a separate report. ---------------------------------------------------------------------- Comment By: Bill Clarke (slashlib) Date: 2005-06-23 01:10 Message: Logged In: YES user_id=421902 to fix the XOPEN_SOURCE problem on Solaris 10 (and hence to be able to compile python modules with g++) you must _not_ define _XOPEN_SOURCE_EXTENDED. XOPEN_SOURCE must be 500 as well. here's a patch for configure.in for the XOPEN_SOURCE_EXTENDED change: """ --- configure.in~ 2005-03-29 09:23:34.000000000 +1000 +++ configure.in 2005-06-23 18:00:39.596747000 +1000 @@ -198,8 +198,15 @@ # definition of _XOPEN_SOURCE_EXTENDED and _POSIX_C_SOURCE, or else # several APIs are not declared. Since this is also needed in some # cases for HP-UX, we define it globally. - - AC_DEFINE(_XOPEN_SOURCE_EXTENDED, 1, Define to activate Unix95-and-earlier features) + # except for Solaris 10, where it must not be defined! + case $ac_sys_system/$ac_sys_release in + SunOS/5.10) + ;; + *) + AC_DEFINE(_XOPEN_SOURCE_EXTENDED, 1, + Define to activate Unix95-and-earlier features) + ;; + esac AC_DEFINE(_POSIX_C_SOURCE, 200112L, Define to activate features from IEEE Stds 1003.1-2001) """ this fix (along with _XOPEN_SOURCE == 500) means i can compile python modules with g++ now. yay! also note: Solaris 10's feature_tests header will override the setting of _POSIX_C_SOURCE (to 199506L) since _XOPEN_SOURCE is 500. from my reading, _POSIX_C_SOURCE should only be 200112L if _XOPEN_SOURCE is 600, so perhaps the _POSIX_C_SOURCE define should also be disabled for Solaris 10 (although this will make no material difference usually). ---------------------------------------------------------------------- Comment By: Bill Clarke (slashlib) Date: 2005-06-22 23:50 Message: Logged In: YES user_id=421902 i should clarify my comments, the thing that was recently fixed in gcc is the HUGE_VAL problem, not the XOPEN_SOURCE problem. note: an easy test for the XOPEN_SOURCE problem with g++ is: """ #include #include """ ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-06-22 22:35 Message: Logged In: YES user_id=1212585 "make testall" fails with an error in _curses: missing typeahead(). I don't know it that is normal or not. I will try some additional tests this weekend, including using the new iso/math_c99.h file. A more subtle issue is that some of the the Solaris Express releases identified themselves as 5.10.1 and the latest Solaris Express (and I believe OpenSolaris) identify themselves as 5.11 and will probably use 5.11.x in the future. I will try to upgrade to the latest Solaris Express release this weekend and report how that behaves. ---------------------------------------------------------------------- Comment By: Bill Clarke (slashlib) Date: 2005-06-22 21:54 Message: Logged In: YES user_id=421902 i hit this bug too. this has been fixed in gcc (will be in gcc 3.4.5 and 4.0.1). to workaround with (say) an installed gcc 3.4.4 build current gcc 3.4 cvs and copy the fixed iso/math_c99.h file from the build to the installed gcc fixed includes directory. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-06-22 07:47 Message: Logged In: YES user_id=29957 I haven't had time to try installing Solaris 10 on anything yet - does setting _XOPEN_SOURCE in this way break anything else? (does make testall complete ok?) If you could confirm it doesn't break anything else, I'll make the change for 2.5 and 2.4.2... ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-03-18 22:06 Message: Logged In: YES user_id=1212585 I found a reference in the 2.4a3 release notes that this problem was fixed for Solaris 8 and 9 with Patch #1006629. That patch set _XOPEN_SOURCE to 500. Using 2.4.1c2 source, I patched line 1521 from SunOS/5.8|SunOS/5.9) to SunOS/5.8|SunOS/5.9|SunOS/5.10) I successfully completed a make; make test with a generic Solaris 10 x86 install. I verified that it failed without the patch. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-03-04 14:28 Message: Logged In: YES user_id=1212585 Below is the official response from Sun. It doesn't look like Sun sees it as a problem. Document Audience: SPECTRUM Document ID: 6173815 Title: bug 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Update Date: Tue Oct 05 06:44:47 MDT 2004 Bug ID: 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Category: c++ Subcategory: compiler State: 11-Closed Description: * * This is a problem I ran into trying to compile Python 2.3.4 on a Solaris * 10 beta 63 (x86) system. I worked with Martin v. Lowis * to isolate the problem as it affects Python, but our * conclusion is that this is really a GCC/Solaris problem. * * -- Chris Wicklein * * ---------------------------------------- * * $ uname -a * SunOS solaris1 5.10 s10_63 i86pc i386 i86pc * * $ gcc -v * Reading specs from /opt/gcc/lib/gcc/i386-pc- solaris2.10/3.4.2/specs * Configured with: ../gcc-3.4.2/configure --with- as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls -- prefix=/opt/gcc * Thread model: posix * gcc version 3.4.2 * * $ gcc -o foo foo.c * * $ gcc -D_STDC_C99 -o foo foo.c * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ gcc -D_STDC_C99 -o foo foo.c --save-temps * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ grep __builtin_huge_val foo.i * if (x == __builtin_huge_val) { * * ---------------------------------------- * The problem for GCC is having HUGE_VAL expanded to __builtin_huge_val * (pointer to a function returning a double) rather than to * __builtin_huge_val() (call to a function returning a double.) * * Is this an error in the header file /usr/include/iso/math_c99.h * or something that was done intentionally to support the * Sun ONE compiler? (Is this something for Sun to fix, or should * this be addressed on the GCC end?) */ #include int main (int argc, char **argv) { double x = 3.14; if (x == HUGE_VAL) { x = 2.7; } return 0; } Customer comments: It is my understanding that HUGE_VAL is a standard C feature, and the function __builtin_huge_val() is a GCC- specific extension for implementing this standard C feature. If this is correct, then by referencing __builtin_huge_val in /usr/include/iso/math_c99.h, Solaris 10 is providing GCC- specific header support. (As an aside, it's remotely possible that my copy of math_c99.h was locally modified as part of installing GCC from a third-party package, but I doubt this happened.) Assuming then that Solaris 10 is providing support for a GCC- specific built-in function (__builtin_huge_val) in math_c99.h, then that support should be corrected (by adding the missing parens.) Otherwise, it will be necessary for GCC to work- around this header problem. Here then is the crux of the matter: assuming that math_c99.h contains this reference to __builtin_huge_val without the required parens, was this done to support GCC, or is this also used by the Sun Pro compiler? If this is present only for GCC, then the missing parens should be added by Sun, or I would like to know that Sun sees this as not-a-bug, in which case GCC will have to work around this itself. At any rate, I am not requesting support for GCC, but rather trying to understand 1) why math_c99.h references __builtin_huge_val as it does in Solaris 10, and 2) if this is something Sun views as a problem on the Solaris side to be fixed. > HI Chris, > > We do not support gcc A third-party C compiler; not supported. > ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-03-04 14:26 Message: Logged In: YES user_id=1212585 Below is the official response from Sun. It doesn't look like Sun sees it as a problem. Document Audience: SPECTRUM Document ID: 6173815 Title: bug 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Update Date: Tue Oct 05 06:44:47 MDT 2004 Bug ID: 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Category: c++ Subcategory: compiler State: 11-Closed Description: * * This is a problem I ran into trying to compile Python 2.3.4 on a Solaris * 10 beta 63 (x86) system. I worked with Martin v. Lowis * to isolate the problem as it affects Python, but our * conclusion is that this is really a GCC/Solaris problem. * * -- Chris Wicklein * * ---------------------------------------- * * $ uname -a * SunOS solaris1 5.10 s10_63 i86pc i386 i86pc * * $ gcc -v * Reading specs from /opt/gcc/lib/gcc/i386-pc- solaris2.10/3.4.2/specs * Configured with: ../gcc-3.4.2/configure --with- as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls -- prefix=/opt/gcc * Thread model: posix * gcc version 3.4.2 * * $ gcc -o foo foo.c * * $ gcc -D_STDC_C99 -o foo foo.c * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ gcc -D_STDC_C99 -o foo foo.c --save-temps * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ grep __builtin_huge_val foo.i * if (x == __builtin_huge_val) { * * ---------------------------------------- * The problem for GCC is having HUGE_VAL expanded to __builtin_huge_val * (pointer to a function returning a double) rather than to * __builtin_huge_val() (call to a function returning a double.) * * Is this an error in the header file /usr/include/iso/math_c99.h * or something that was done intentionally to support the * Sun ONE compiler? (Is this something for Sun to fix, or should * this be addressed on the GCC end?) */ #include int main (int argc, char **argv) { double x = 3.14; if (x == HUGE_VAL) { x = 2.7; } return 0; } Customer comments: It is my understanding that HUGE_VAL is a standard C feature, and the function __builtin_huge_val() is a GCC- specific extension for implementing this standard C feature. If this is correct, then by referencing __builtin_huge_val in /usr/include/iso/math_c99.h, Solaris 10 is providing GCC- specific header support. (As an aside, it's remotely possible that my copy of math_c99.h was locally modified as part of installing GCC from a third-party package, but I doubt this happened.) Assuming then that Solaris 10 is providing support for a GCC- specific built-in function (__builtin_huge_val) in math_c99.h, then that support should be corrected (by adding the missing parens.) Otherwise, it will be necessary for GCC to work- around this header problem. Here then is the crux of the matter: assuming that math_c99.h contains this reference to __builtin_huge_val without the required parens, was this done to support GCC, or is this also used by the Sun Pro compiler? If this is present only for GCC, then the missing parens should be added by Sun, or I would like to know that Sun sees this as not-a-bug, in which case GCC will have to work around this itself. At any rate, I am not requesting support for GCC, but rather trying to understand 1) why math_c99.h references __builtin_huge_val as it does in Solaris 10, and 2) if this is something Sun views as a problem on the Solaris side to be fixed. > HI Chris, > > We do not support gcc A third-party C compiler; not supported. > ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 11:04 Message: Logged In: YES user_id=21627 Turns out casevh's report is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 06:18 Message: Logged In: YES user_id=21627 I have now reported this bug to gcc as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20317 ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-10 22:33 Message: Logged In: YES user_id=1212585 Oops. I made a typo in one of my tests. It does include in /include/iso/math_c99.h when you type it correctly. I will work with Sun / gcc to determine a resolution. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-10 22:03 Message: Logged In: YES user_id=1212585 I poked around in the preprocessor outputs and it appears gcc doesn't its specific directory for math_c99.h. It only appears to look in /usr/include/iso. I changed the definition of HUGE_VAL in /usr/include/iso/math_c99.h to read: #define HUGE_VAL __builtin_huge_val() The hv2.c compiled completely and so did Python 2.4. I'll open a bug report with GCC and also with Sun since I used the version of GCC that was distributed by Sun. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-10 21:16 Message: Logged In: YES user_id=1212585 I ran mkheaders to rebuild the gcc headers but that made no difference. The following program (hv.c) compiled correctly: #define _XOPEN_SOURCE 500 #include int main() { double f=HUGE_VAL; } The following program (hv2.c) did not compile. #define _XOPEN_SOURCE 1000 #include int main() { double f=HUGE_VAL; } Output is: $ gcc --save-temps hv.c $ gcc --save-temp hv2.c hv2.c: In function `main': hv2.c:5: error: incompatible types in initialization $ I have attached hv.i and hv2.i. I have also attached complexobject.i I'm not a C programmer so please let me know what else I can do to help. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-10 08:50 Message: Logged In: YES user_id=1212585 I tried steps 1 through 4 and it fails, with and with the (). I'm not sure how to do step 5. I will try the short program snippet later and report back. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-09 20:44 Message: Logged In: YES user_id=31435 Doubt this will help: googling suggests that -Xc has to be passed to Sun's native C compiler to get HUGE_VAL defined correctly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-09 19:23 Message: Logged In: YES user_id=21627 I have the Solaris 10 iso/math_c99.h in front of me, but no gcc, so it is somewhat difficult to get through the ifdefery. It appears that we should have _XOPEN_SOURCE - 0 >= 600, so we should be using #define HUGE_VAL __builtin_huge_val The problem apparently is that in Sun CC, __builtin_huge_val appears to be a constant, whereas in gcc, it probably is a function, so the definition should read #define HUGE_VAL __builtin_huge_val() So there is a bug in the gcc port of Solaris here - fixincludes should adjust the definition of HUGE_VAL when installing its adjusted copy of math_c99.h. I'm willing to accept patches to work around this gcc bug, but only if the bug gets reported to gcc first. So, please, 1. find out the gcc installation directory on your system, using gcc --print-search-dirs 2a. check whether /include/iso/math_c99.h exists 2b. if it does not exist, copy if from /usr/include/iso/math_c99.h 3. edit /include/iso/math_c99.h to add the parentheses after builtin_huge_val 4. check whether this fixes the problem 5a. if not, provide the preprocessor output for complexobject.i, using --save-temps 5b. if it does, make a bug report to gcc, indicating that the program #include int main() { double f=HUGE_VAL; } fails on Solaris 10. For that report - check whether it actually fails without the update math_c99, and succeeds with it (you might have to #define _XOPEN_SOURCE to make it fail) - include the preprocessor output for this sample program, using the original math_c99 - indicate that a solution is to add parentheses 6. Come up with a patch that checks for Solaris 10 and all gcc versions showing the problem (i.e. 3.4.x, with x<=3, perhaps also 3.y, y<=3), and defines Py_HUGE_VAL correctly for this system. 7. Report the gcc bug number and the patch in this report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-09 17:43 Message: Logged In: YES user_id=31435 The C standard requires that "The macro HUGE_VAL expands to a positive double constant expression, not necessarily representable as a float". Python requires that too. #define'ing to worm around a broken compilation environment isn't acceptable to me; finding a switch to make this environment conform to the standard would be OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 From noreply at sourceforge.net Tue Jun 28 08:44:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Jun 2005 23:44:24 -0700 Subject: [Patches] [ python-Patches-1228112 ] code.py use sys.excepthook to display exceptions Message-ID: Patches item #1228112, was opened at 2005-06-27 12:33 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1228112&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: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: code.py use sys.excepthook to display exceptions Initial Comment: This patch makes code.py InteractiveInterpreter use sys.excepthook to display exceptions. This way if a user changes sys.excepthook it will be used by the InteractiveInterpreter. ---------------------------------------------------------------------- >Comment By: Miki Tebeka (tebeka) Date: 2005-06-28 09:44 Message: Logged In: YES user_id=358087 OK. Changed syntaxerror as well (see attached patch). Not sure I understand the comment about self.write. Overiding sys.excepthook in IDLE does *not* work. (sys.displayhook does though). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-27 13:57 Message: Logged In: YES user_id=6656 Seems like a good idea to me. The only quibble around the area of self.write -- it might break code that overrides that (IDLE?). Also, shouldn't showsyntaxerror be changed too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1228112&group_id=5470 From noreply at sourceforge.net Tue Jun 28 09:10:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 28 Jun 2005 00:10:22 -0700 Subject: [Patches] [ python-Patches-1223381 ] PEP 342 Generator enhancements Message-ID: Patches item #1223381, was opened at 2005-06-18 19:08 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1223381&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: Phillip J. Eby (pje) >Assigned to: Phillip J. Eby (pje) Summary: PEP 342 Generator enhancements Initial Comment: The attached patch implements code and test changes for: * yield expressions * bare yield (short for yield None) * yield in try/finally * generator.send(value) (send value into generator; substituted for PEP 342's next(arg)) * generator.throw(typ[,val[,tb]]) (raise error in generator) * generator.close() (per PEP 343) * GeneratorExit built-in exception type * generator.__del__ (well, the C equivalent) * All necessary mods to the compiler, parser module, and Python 'compiler' package to support these changes. It was necessary to change a small part of the eval loop (well, the initialization, not the loop) and the gc module's has_finalizer() logic in order to support a C equivalent to __del__. Specialists in these areas should probably scrutinize this patch! There is one additional implementation detail that was not contemplated in either PEP. in order to prevent used-up generators from retaining unnecessary references to their frame's contents, I set the generator's gi_frame member to None whenever the generator finishes normally or with an error. Thus, an exhausted generator cannot be part of a cycle, and it releases its frame object sooner than in previous Python versions. For generators used only in a direct "for" loop, this makes no difference, but for generators used with the iterator protocol (i.e. "gen.next()") from Python, this avoids stranding the generator's frame in a traceback cycle. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-28 03:10 Message: Logged In: YES user_id=6380 Since I've accepted PEP 342+343 last night in my Europython keynote, you can check this in now. ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2005-06-27 11:40 Message: Logged In: YES user_id=56214 I had hoped to be able to avoid dealing with string exceptions, but I guess it makes sense that if somebody has thrown one, it should be able to propagate. So I guess I'll take care of that along with the rest. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-27 11:31 Message: Logged In: YES user_id=6656 Heh heh heh. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-27 11:22 Message: Logged In: YES user_id=6380 (Removing 343 from the subject since all this is now in PEP 342.) Playing with the code a bit, I notice that throw() doesn't like string exceptions. That could cause some problems. Also, I think the tb argument should be allowed to be None. Otherwise, great! In a few hours you can check it in. :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-23 19:20 Message: Logged In: YES user_id=6656 Fair enough. I want to use with statements in a presentation at EuroPython next week, so I've hacked together a truly horrible implementation that will do for now and will see about a real one some time after... ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2005-06-23 19:07 Message: Logged In: YES user_id=56214 No, I haven't, and I never really planned to be the person implementing "with". Doesn't mean I might not end up doing it eventually, but it's not currently in my plans. I'm going to have my hands full just updating PEP 342 (Guido has asked me to take it over), and getting docs written to go with this patch. Between all that and my distutils-related work, my pro-bono Python project time is booked up solid for maybe the next 2 months or so. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-22 16:59 Message: Logged In: YES user_id=6656 Argh, I'd hoped you'd done with, too :) Have you done any work on that yet? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-19 03:37 Message: Logged In: YES user_id=1188172 Minor nit: on line 642, 'yield_stmt' should be changed to 'yield_expr'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1223381&group_id=5470 From noreply at sourceforge.net Tue Jun 28 10:08:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 28 Jun 2005 01:08:53 -0700 Subject: [Patches] [ python-Patches-1228112 ] code.py use sys.excepthook to display exceptions Message-ID: Patches item #1228112, was opened at 2005-06-27 10:33 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1228112&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: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: code.py use sys.excepthook to display exceptions Initial Comment: This patch makes code.py InteractiveInterpreter use sys.excepthook to display exceptions. This way if a user changes sys.excepthook it will be used by the InteractiveInterpreter. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-06-28 09:08 Message: Logged In: YES user_id=6656 > Not sure I understand the comment about self.write. > Overiding sys.excepthook in IDLE does *not* work. > (sys.displayhook does though). Yeah, sure, your patch changes that, but I think that with your patch idle will need to install its own sys.excepthook or exception messages will end up on the real stderr. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2005-06-28 07:44 Message: Logged In: YES user_id=358087 OK. Changed syntaxerror as well (see attached patch). Not sure I understand the comment about self.write. Overiding sys.excepthook in IDLE does *not* work. (sys.displayhook does though). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-27 11:57 Message: Logged In: YES user_id=6656 Seems like a good idea to me. The only quibble around the area of self.write -- it might break code that overrides that (IDLE?). Also, shouldn't showsyntaxerror be changed too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1228112&group_id=5470 From noreply at sourceforge.net Tue Jun 28 20:57:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 28 Jun 2005 11:57:26 -0700 Subject: [Patches] [ python-Patches-1229239 ] optionally allow mutable builtin types Message-ID: Patches item #1229239, was opened at 2005-06-28 11: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=1229239&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: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: optionally allow mutable builtin types Initial Comment: Non-heap types, aka builtin types, cannot have their attributes changed by Python code -- see Objects/typeobject.c: type_setattro(). This limitation is good for Python's core builtin types (int, float, list, dict, ...), but not necessarily for non-heap types in extension modules. The attached patch allows for non-heap types to mutate iff the Py_TPFLAGS_MUTABLE_BUILTIN flag is set. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1229239&group_id=5470 From noreply at sourceforge.net Tue Jun 28 22:11:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 28 Jun 2005 13:11:03 -0700 Subject: [Patches] [ python-Patches-1229280 ] optionally allow mutable builtin types Message-ID: Patches item #1229280, was opened at 2005-06-28 13:11 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=1229280&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: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: optionally allow mutable builtin types Initial Comment: Non-heap types, aka builtin types, cannot have their attributes changed by Python code -- see Objects/typeobject.c: type_setattro(). This limitation is good for Python's core builtin types (int, float, list, dict, ...), but not necessarily for non-heap types in extension modules. The attached patch allows for non-heap types to mutate iff the Py_TPFLAGS_MUTABLE_BUILTIN flag is set. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1229280&group_id=5470 From noreply at sourceforge.net Tue Jun 28 22:11:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 28 Jun 2005 13:11:56 -0700 Subject: [Patches] [ python-Patches-1229280 ] optionally allow mutable builtin types Message-ID: Patches item #1229280, was opened at 2005-06-28 13:11 Message generated for change (Settings changed) made by gregcouch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1229280&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: Deleted Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: optionally allow mutable builtin types Initial Comment: Non-heap types, aka builtin types, cannot have their attributes changed by Python code -- see Objects/typeobject.c: type_setattro(). This limitation is good for Python's core builtin types (int, float, list, dict, ...), but not necessarily for non-heap types in extension modules. The attached patch allows for non-heap types to mutate iff the Py_TPFLAGS_MUTABLE_BUILTIN flag is set. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1229280&group_id=5470 From noreply at sourceforge.net Wed Jun 29 09:47:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Jun 2005 00:47:31 -0700 Subject: [Patches] [ python-Patches-1229511 ] Zipfile fix create_system information Message-ID: Patches item #1229511, was opened at 2005-06-29 09:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1229511&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: Hendrik Muhs (hendriktt) Assigned to: Nobody/Anonymous (nobody) Summary: Zipfile fix create_system information Initial Comment: this patches corrects the create_system value for created zipfiles with the zipfile module, which is platform dependent (better: filesystem dependent). It fixes the following bug: if a zipfile is created with Python on Unix and the files have executable flags the file rights are correctly saved into the zipfile. But when extracting the file with unzip (from Info-zip) the filerights (executable flags) are not reassigned correctly. This is due to the wrong create_system flag. The patch is not the 100% correct way to do it, but it is better as the situation now (completly ignore the system and always set create_system to 0). The right way to fix this would be to set the create_system flag dependent on the platform and the filesystem but I do not know how to do this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1229511&group_id=5470 From eurosemi at eurosemi.eu.com Wed Jun 29 13:08:36 2005 From: eurosemi at eurosemi.eu.com (eurosemi@eurosemi.eu.com) Date: Wed, 29 Jun 2005 12:08:36 +0100 (BST) Subject: [Patches] Eurosemi E-News Message-ID: <20050629110836.DD84BD66F9@silux.angelbc.co.uk> charset="iso-8859-1" Content-Transfer-Encoding:8bit +---------------------------------------------------------+ | EUROSEMI NEWSLETTER - PLAIN TEXT VERSION | | if you would like to see this in HTML goto: | | http://www.eurosemi.eu.com | +---------------------------------------------------------+ | 29th June 2005 +---------------------------------------------------------+ | Contents | | ~~~~~~~~~ | | - SECAP ends with working 300mm line | - CEA Leti announces low power transistors for 45nm and beyond | - SEMI report looks at Chinese manufacturing trends | - Price Erosion Spurs NOR Flash Revenue Decline in 2005 +---------------------------------------------------------+ +---------------------------------------------------------+ SECAP ends with working 300mm line The Semiconductor Equipment Consortium for Advanced Packaging (SECAP) has announced that they will disband now that the consortium has successfully established 300 mm Wafer Level Packaging as a functional technology and full-volume production on the first installed wafer-bumping line is underway. To view the whole story goto:http://www.eurosemi.eu.com/cgi-bin/viewnew22.pl?id=6414 +---------------------------------------------------------+ CEA Leti announces low power transistors for 45nm and beyond Just one year after the inauguration of the Nanotec 300 research platform for the 45 and 32 nanometer microelectronics nodes, CEA Leti announced the successful completion of its first High K metal gate transistors on 300mm wafers. To view the whole story goto:http://www.eurosemi.eu.com/cgi-bin/viewnew22.pl?id=6415 +---------------------------------------------------------+ SEMI report looks at Chinese manufacturing trends SEMI has released a report that shows the Chinese semiconductor market is increasing faster than the rest of the world with 300mm wafers already being tested well before predictions based on external restrictions placed upon the country's technological growth. To view the whole story goto:http://www.eurosemi.eu.com/cgi-bin/viewnew22.pl?id=6416 +---------------------------------------------------------+ Price Erosion Spurs NOR Flash Revenue Decline in 2005 Cutthroat competition is spurring continued price erosion for NOR-type flash memory, resulting in a significant decline in market revenue this year, according to iSuppli Corp. To view the whole story goto:http://www.eurosemi.eu.com/cgi-bin/viewnew22.pl?id=6417 +--------------------------------------------------------+ | To Unsubscribe Goto | +-------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20050629/b0c0d238/attachment-0001.htm From noreply at sourceforge.net Wed Jun 29 21:45:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Jun 2005 12:45:02 -0700 Subject: [Patches] [ python-Patches-1229935 ] Patch for (Doc) bug #1228904 Message-ID: Patches item #1229935, was opened at 2005-06-29 21: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=1229935&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) bug #1228904 Initial Comment: Provide working (and shorter) example. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1229935&group_id=5470 From noreply at sourceforge.net Thu Jun 30 09:51:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Jun 2005 00:51:40 -0700 Subject: [Patches] [ python-Patches-1225466 ] fileinput openfile patch, bz2fileinput Message-ID: Patches item #1225466, was opened at 2005-06-22 11:50 Message generated for change (Comment added) made by hoffmanm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1225466&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: Stephan Boettcher (sib4) Assigned to: Nobody/Anonymous (nobody) Summary: fileinput openfile patch, bz2fileinput Initial Comment: Please consider the enclosed patch to fileinput.py, which implements an openfile method of FileInput. Included is a use case bz2fileinput.py. ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2005-06-30 07:51 Message: Logged In: YES user_id=987664 Hmmm. This could be useful. Pythonistas could also supply openfile for, say, URLs as well. I'm kind of lukewarm on it for some reason--I think that you'd be better off decompressing the data somewhere else. I also did some benchmarking the other day and found that fileinput is really, really slow. I don't understand the change from Fileinput to _Fileinput. You're going to need to fix the inplace stuff in Fileinput.readline(). This needs documentation, and a more detailed description. Please provide a patch against the latest CVS instead of Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1225466&group_id=5470 From noreply at sourceforge.net Thu Jun 30 18:23:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Jun 2005 09:23:29 -0700 Subject: [Patches] [ python-Patches-1230446 ] tarfile.py: ExFileObject's tell() is wrong after readline() Message-ID: Patches item #1230446, was opened at 2005-06-30 18: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=1230446&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: ExFileObject's tell() is wrong after readline() Initial Comment: This patch is intended to be the solution to a problem that Niklas Volbers reported on comp.lang.python on June 1st. ExFileObject is the pseudo file object that is returned by TarFile.extractfile() and allows a user to read a file from the tar archive using a file interface. Niklas discovered that the tell() method didn't give correct results if he used it in conjunction with readline(). The cause for this is that readline() buffers the file data in 100 char blocks to be able to split it into lines. Thus, tell() always returns the file position in 100 byte steps. While I was looking for a fix to that problem in tarfile.py, I discovered that ExFileObject has another flaw as well: I read in readline()'s docstring that mixing calls to read() and readline() is not allowed, which is nowhere documented. I decided to put a little effort into a rewrite of ExFileObject. Here it is, tests included. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1230446&group_id=5470 From noreply at sourceforge.net Thu Jun 30 23:38:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Jun 2005 14:38:05 -0700 Subject: [Patches] [ python-Patches-1230615 ] Patch for (Doc) #1168746 Message-ID: Patches item #1230615, was opened at 2005-06-30 23: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=1230615&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) #1168746 Initial Comment: I will try to add another file later on. On 'undocuments' these attributes as per Arigo's suggestion ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1230615&group_id=5470 From noreply at sourceforge.net Thu Jun 30 23:49:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Jun 2005 14:49:41 -0700 Subject: [Patches] [ python-Patches-1230615 ] Patch for (Doc) #1168746 Message-ID: Patches item #1230615, was opened at 2005-06-30 23:38 Message generated for change (Comment added) made by pterk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1230615&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) #1168746 Initial Comment: I will try to add another file later on. On 'undocuments' these attributes as per Arigo's suggestion ---------------------------------------------------------------------- >Comment By: Peter van Kampen (pterk) Date: 2005-06-30 23:49 Message: Logged In: YES user_id=174455 The second patch 'corrects' the docs using Arigo's description. This should make it easy to close this one by someone who can make a good estimate of the usefullness of these values to anyone. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1230615&group_id=5470