From noreply at sourceforge.net Sun May 1 01:13:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun May 1 01:13:24 2005 Subject: [ python-Bugs-1193180 ] Strange os.path.exists() results with invalid chars Message-ID: Bugs item #1193180, was opened at 2005-04-30 23:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193180&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Daniele Varrazzo (dvarrazzo) Assigned to: Nobody/Anonymous (nobody) Summary: Strange os.path.exists() results with invalid chars Initial Comment: Hi, when there are invalid chars in a filename, os.path.exists () behaves oddly, returning True. The bug appears on win32 system, not on unix ones. Thus is probably related to some weird windows api call and doesn't maybe worth fixing. Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> f = file("a_b", "w") >>> f.close() >>> os.listdir(".") ['a_b'] >>> os.path.exists("a>> os.path.exists("a>b") True And, even more strange... >>> os.path.exists("a<") True >>> os.path.exists("a>") False Better answers would have been: * False * raise ValueError ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193180&group_id=5470 From noreply at sourceforge.net Sun May 1 02:15:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun May 1 02:15:37 2005 Subject: [ python-Bugs-1193190 ] MACOSX_DEPLOYMENT_TARGET checked incorrectly Message-ID: Bugs item #1193190, was opened at 2005-04-30 20:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193190&group_id=5470 Category: Distutils Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Bob Ippolito (etrepum) Summary: MACOSX_DEPLOYMENT_TARGET checked incorrectly Initial Comment: MACOSX_DEPLOYMENT_TARGET should be checked to be >= the configure time value (or not set). Currently, it checks for equality. For example, this is necessary in order to use a Python built for Mac OS X 10.3 but build an extension with features specific to Mac OS X 10.4. Backport candidate to 2.4, patches attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193190&group_id=5470 From noreply at sourceforge.net Sun May 1 11:55:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun May 1 11:55:28 2005 Subject: [ python-Feature Requests-1184678 ] "replace" function should accept lists. Message-ID: Feature Requests item #1184678, was opened at 2005-04-17 19:05 Message generated for change (Comment added) made by poromenos You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1184678&group_id=5470 Category: None Group: None Status: Open Resolution: Rejected Priority: 5 Submitted By: Poromenos (poromenos) Assigned to: Nobody/Anonymous (nobody) Summary: "replace" function should accept lists. Initial Comment: It would be nice if the "replace" function accepted lists/ tuples and replaced each item in the "old" list with the corresponding item in the "new" list. ---------------------------------------------------------------------- >Comment By: Poromenos (poromenos) Date: 2005-05-01 12:55 Message: Logged In: YES user_id=267121 Ah, okay. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-30 15:30 Message: Logged In: YES user_id=80475 Sorry, am not going to gum up the API for this. It doesn't come up much and when it does it is an easy problem. Each additional option on a function makes it harder to learn, use, and remember. Likewise, it complicates maintenance. Also, this one has its own complexities that make it worth avoiding (examples can be contrived when the for-loop version produces a different result than replacing each match as found). A good implementation would take time. It would involve regexps and have to be done for unicode objects. ---------------------------------------------------------------------- Comment By: Poromenos (poromenos) Date: 2005-04-30 12:48 Message: Logged In: YES user_id=267121 That is true, the alternative loop is quite usable, but the API change would be backwards-compatible, and the implementation is not very difficult... I just see this as a nice feature of replace, it's not really necessary if it'll break other stuff. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-29 17:10 Message: Logged In: YES user_id=80475 Given the multiple alternative input matches, this is a job for regular expressions. See the string.substitute() source code for an approach to making the transformation you outlined. I do not think multi-replace is sufficiently common to warrant a change to the API. If needed and if the regexp solution is too hard, then a regular for-loop is a reasonable alternative: for old, new in zip(oldlist, newlist): s = s.replace(old, new) ---------------------------------------------------------------------- Comment By: Poromenos (poromenos) Date: 2005-04-29 16:03 Message: Logged In: YES user_id=267121 There was an oversight on my part... Translate can only be used to change individual characters, what I am proposing could replace strings of multiple characters, essentially concatenating multiple replace()s in one: >>> "h.w".replace(["h", ".", "w"], ["Hello", " ", "World!"]) 'Hello, World!' ---------------------------------------------------------------------- Comment By: Poromenos (poromenos) Date: 2005-04-19 01:23 Message: Logged In: YES user_id=267121 Ah, I did not know that... The docs are a bit complicated on . translate, but since it can do that, yes, it would be unwise to implement my suggestion. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-19 01:20 Message: Logged In: YES user_id=80475 I'm -1 on complicating str.replace()'s API for functionality that substantially duplicates that offered by str.translate(): >>> "Hello world".translate(string.maketrans('ed', 'ae')) 'Hallo worle' ---------------------------------------------------------------------- Comment By: Poromenos (poromenos) Date: 2005-04-19 00:15 Message: Logged In: YES user_id=267121 Hmm, actually I was requesting that string.replace() accepted lists of substitutions, like so: >>> "Hello world".replace(["e", "d"], ["a", "e"]) 'Hallo worle' But your suggestion would also be very useful. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-19 00:11 Message: Logged In: YES user_id=80475 Are you requesting that lists be given a replace() method that parallels the replace() method for strings? def replace(self, old, new): result = [] for elem in self: if elem == old: result.append(new) else: result.append(elem) self[:] = result ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1184678&group_id=5470 From noreply at sourceforge.net Sun May 1 17:00:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun May 1 17:01:05 2005 Subject: [ python-Bugs-1190599 ] dir() docs show incorrect output Message-ID: Bugs item #1190599, was opened at 2005-04-27 07:20 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190599&group_id=5470 Category: Documentation Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Martin Chase (stillflame) Assigned to: Michael Hudson (mwh) Summary: dir() docs show incorrect output Initial Comment: on the web at http://docs.python.org/tut/node8.html under "6.3 The dir() Function", the following text reports incorrectly what the dir() call would return: >>> a = [1, 2, 3, 4, 5] >>> import fibo, sys >>> fib = fibo.fib >>> dir() ['__builtins__', '__doc__', '__file__', '__name__', 'fib', 'fib2'] it should have 'a' and 'fibo', but not 'fib2'. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-05-02 00:00 Message: Logged In: YES user_id=671362 > -['__builtins__', '__doc__', '__file__', '__name__', 'fib', 'fib2'] > +['__builtins__', '__doc__', '__file__', '__name__', 'a', 'fib'] So, where is 'fibo'? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-27 19:00 Message: Logged In: YES user_id=6656 Fixed in rev 1.270 of Doc/tut.tex. Thanks for the report! ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-04-27 12:36 Message: Logged In: YES user_id=671362 A minor nit. > it should have 'a' and 'fibo', 'sys' is also missing from the list. >>> dir() ['__builtins__', '__doc__', '__file__', '__name__', 'a', 'fib', 'fibo', ' sys'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190599&group_id=5470 From noreply at sourceforge.net Mon May 2 05:04:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 01 May 2005 20:04:36 -0700 Subject: [ python-Feature Requests-1193577 ] add server.shutdown() method and daemon arg to SocketServer Message-ID: Feature Requests item #1193577, was opened at 2005-05-02 03:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1193577&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: add server.shutdown() method and daemon arg to SocketServer Initial Comment: First of all the daemon_threads property on socket servers should be added as an optional arg to the server constructor, so you can say: TCPServer(..., daemon_threads=True).serve_forever() instead of temp = TCPServer(...) temp.daemon_threads=True temp.serve_forever Secondly there should be a way to STOP the server, once you've started serving forever! A request handler should be able to say self.server.stop_serving() This would work by setting a flag in the server object. The serve_forever loop would use select with a timeout (default 0.5 sec, also settable as an optional arg to the server constructor) or alternatively set a timeout on the socket object. So it would block listening for new connections, but every 0.5 sec it would check the stop_serving flag and break out of the loop if the flag was set. This method was suggested by Skip Montanaro in a clpy thread about how to stop SocketServer and it's useful enough that I think it should be part of the standard impl. I can make a patch if it's not obvious how to do it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1193577&group_id=5470 From noreply at sourceforge.net Mon May 2 08:12:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 01 May 2005 23:12:54 -0700 Subject: [ python-Feature Requests-1193610 ] Expat Parser to supply document locator in incremental parse Message-ID: Feature Requests item #1193610, was opened at 2005-05-02 16:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1193610&group_id=5470 Category: XML Group: None Status: Open Resolution: None Priority: 5 Submitted By: GaryD (gazzadee) Assigned to: Nobody/Anonymous (nobody) Summary: Expat Parser to supply document locator in incremental parse Initial Comment: The standard Expat SAX Parser supplied with Python (xml.sax.expatreader.ExpatParser) does not set the document locator (using ContentHandler.setDocumentLocator) when you are doing an incremental parse (ie. using feed instead of parse), although it does supply the locator when you do a full parse. Is there a reason why this is so, or is it just an oversight? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1193610&group_id=5470 From noreply at sourceforge.net Mon May 2 10:00:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 May 2005 01:00:58 -0700 Subject: [ python-Bugs-1193061 ] Python and Turkish Locale Message-ID: Bugs item #1193061, was opened at 2005-04-30 19:37 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193061&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: S.?ağlar Onur (caglar) Assigned to: M.-A. Lemburg (lemburg) Summary: Python and Turkish Locale Initial Comment: On behalf of this thread; http://mail.python.org/pipermail/python-dev/2005-April/052968.html As described in http://www.i18nguy.com/unicode/turkish-i18n.html [ How Applications Fail With Turkish Language ] , Turkish has 4 "i" in their alphabet. Without --with-wctype-functions support Python convert these characters locare-independent manner in tr_TR.UTF-8 locale. So all conversitons maps to "i" or "I" which is wrong in Turkish locale. So if Python Developers will remove the wctype functions from Python, then there must be a locale-dependent upper/lower funtion to handle these characters properly. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-05-02 10:00 Message: Logged In: YES user_id=38388 I'm not sure I understand: are you saying that the Unicode mappings for upper and lower case are wrong in the standard ? Note that removing the wctype functions will only remove the possibility to use these functions for case mapping of Unicode characters instead of using the builtin Unicode character database. This was originally meant as optimization to avoid having to load the Unicode database - nowadays the database is always included, so the optimization is no longer needed. Even worse: the wctype functions sometimes behave differently than the mappings in the Unicode database (due to differences in the Unicode database version or implementation s). Now, since the string .lower() and .upper() methods are locale dependent (due to their reliance on the C functions toupper() and tolower() - not by intent), while the Unicode versions are not, we have a rather annoying situation where switching from strings to Unicode cause semantic differences. Ideally, both string and Unicode methods should do case mapping in an locale independent way. The support for differences in locale dependent case mapping, collation, etc. should be moved to an external module, e.g. the locale module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193061&group_id=5470 From noreply at sourceforge.net Mon May 2 10:45:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 May 2005 01:45:12 -0700 Subject: [ python-Bugs-1193061 ] Python and Turkish Locale Message-ID: Bugs item #1193061, was opened at 2005-04-30 20:37 Message generated for change (Comment added) made by caglar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193061&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: S.?ağlar Onur (caglar) Assigned to: M.-A. Lemburg (lemburg) Summary: Python and Turkish Locale Initial Comment: On behalf of this thread; http://mail.python.org/pipermail/python-dev/2005-April/052968.html As described in http://www.i18nguy.com/unicode/turkish-i18n.html [ How Applications Fail With Turkish Language ] , Turkish has 4 "i" in their alphabet. Without --with-wctype-functions support Python convert these characters locare-independent manner in tr_TR.UTF-8 locale. So all conversitons maps to "i" or "I" which is wrong in Turkish locale. So if Python Developers will remove the wctype functions from Python, then there must be a locale-dependent upper/lower funtion to handle these characters properly. ---------------------------------------------------------------------- >Comment By: S.?ağlar Onur (caglar) Date: 2005-05-02 11:45 Message: Logged In: YES user_id=858447 No, im not. These rules defined in http://www.unicode.org/Public/UNIDATA/CaseFolding.txt and http://www.unicode.org/Public/UNIDATA/SpecialCasing.txt. Note that there is a comments says; # T: special case for uppercase I and dotted uppercase I # - For non-Turkic languages, this mapping is normally not used. # - For Turkic languages (tr, az), this mapping can be used instead of the normal mapping for these characters. # Note that the Turkic mappings do not maintain canonical equivalence without additional processing. # See the discussions of case mapping in the Unicode Standard for more information. So without wctype functions support, python can't convert these. This _is_ the problem. As a side effect of this, another huge problem occurs, keywords can't be locale dependent. If Python compiled with wctype support functions, all "i".upper() turns into "İ" which is wrong for keyword comparision ( like quit v.s QUİT ) So i suggest implement two new functions like localeAwareLower()/localeAwareUpper() for python and let lower()/upper() locale independent. And as you wrote locale module may be a perfect home for these :) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-05-02 11:00 Message: Logged In: YES user_id=38388 I'm not sure I understand: are you saying that the Unicode mappings for upper and lower case are wrong in the standard ? Note that removing the wctype functions will only remove the possibility to use these functions for case mapping of Unicode characters instead of using the builtin Unicode character database. This was originally meant as optimization to avoid having to load the Unicode database - nowadays the database is always included, so the optimization is no longer needed. Even worse: the wctype functions sometimes behave differently than the mappings in the Unicode database (due to differences in the Unicode database version or implementation s). Now, since the string .lower() and .upper() methods are locale dependent (due to their reliance on the C functions toupper() and tolower() - not by intent), while the Unicode versions are not, we have a rather annoying situation where switching from strings to Unicode cause semantic differences. Ideally, both string and Unicode methods should do case mapping in an locale independent way. The support for differences in locale dependent case mapping, collation, etc. should be moved to an external module, e.g. the locale module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193061&group_id=5470 From noreply at sourceforge.net Mon May 2 13:56:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 May 2005 04:56:18 -0700 Subject: [ python-Bugs-1192554 ] doctest's ELLIPSIS and multiline statements Message-ID: Bugs item #1192554, was opened at 2005-04-29 19:36 Message generated for change (Settings changed) made by boisgerault You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1192554&group_id=5470 Category: Python Library Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: S?bastien Boisg?rault (boisgerault) Assigned to: Nobody/Anonymous (nobody) Summary: doctest's ELLIPSIS and multiline statements Initial Comment: The doctest ELLPSIS marker (default: "...") may be confused by the doctest parser with the multiline statement marker ("..."). Example: in the following code, the intent was to accept any result after "print 42". This is NOT a multiline statement, but however the test fails (Expected: nothing, Got: 42). ---------------------------------------- #!/usr/bin/env python import doctest def test(): """ >>> print 42 #doctest: +ELLIPSIS ... """ def run(): "Run the test." doctest.testmod() if __name__ == '__main__': run() ---------------------------------------- ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-04-29 19:52 Message: Logged In: YES user_id=31435 That's true. doctest has few syntax requirements, but the inability to start an expected output block with "..." has always been one of them, and is independent of the ELLIPSIS gimmick. I doubt this will change, in part because the complications needed to "do something about it" are probably pig ugly, in part because it's so rare a desire, and in part because there are easy ways to work around it (like arranging for the expected output to start with something other than '...'). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1192554&group_id=5470 From noreply at sourceforge.net Mon May 2 14:04:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 May 2005 05:04:50 -0700 Subject: [ python-Bugs-1193180 ] Strange os.path.exists() results with invalid chars Message-ID: Bugs item #1193180, was opened at 2005-05-01 01:13 Message generated for change (Comment added) made by zgoda You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193180&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Daniele Varrazzo (dvarrazzo) Assigned to: Nobody/Anonymous (nobody) Summary: Strange os.path.exists() results with invalid chars Initial Comment: Hi, when there are invalid chars in a filename, os.path.exists () behaves oddly, returning True. The bug appears on win32 system, not on unix ones. Thus is probably related to some weird windows api call and doesn't maybe worth fixing. Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> f = file("a_b", "w") >>> f.close() >>> os.listdir(".") ['a_b'] >>> os.path.exists("a>> os.path.exists("a>b") True And, even more strange... >>> os.path.exists("a<") True >>> os.path.exists("a>") False Better answers would have been: * False * raise ValueError ---------------------------------------------------------------------- Comment By: Jarek Zgoda (zgoda) Date: 2005-05-02 14:04 Message: Logged In: YES user_id=92222 Same for Python 2.3.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193180&group_id=5470 From noreply at sourceforge.net Mon May 2 17:02:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 May 2005 08:02:44 -0700 Subject: [ python-Bugs-1193849 ] os.path.expanduser documentation wrt. empty $HOME Message-ID: Bugs item #1193849, was opened at 2005-05-02 17:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193849&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.expanduser documentation wrt. empty $HOME Initial Comment: If $HOME is unset, an initial "~" should not be expanded according to the documentation. But instead it somehow is expanded, perhaps through the pwd module: $ env -u HOME python -c "import os.path; print os.path.expanduser('~/foo')" /home/calvin/foo The result should be "~/foo" instead of "/home/calvin/foo". I suggest adjusting the documentation to state the also a single "~" is looked up in the pwd module, not only "~user". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193849&group_id=5470 From noreply at sourceforge.net Mon May 2 17:56:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 May 2005 08:56:56 -0700 Subject: [ python-Bugs-1193890 ] calendar.weekheader not found in __all__ Message-ID: Bugs item #1193890, was opened at 2005-05-03 00:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193890&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: calendar.weekheader not found in __all__ Initial Comment: calendar.weekheader is documented and a public function form its beginning but not included in calendar.__all__. So >>> from calendar import *; weekheader triggers a NameError. Fix is trivial. Just add 'weekheader' to __all__. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193890&group_id=5470 From noreply at sourceforge.net Mon May 2 20:31:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 May 2005 11:31:38 -0700 Subject: [ python-Bugs-1193966 ] Weakref types documentation bugs Message-ID: Bugs item #1193966, was opened at 2005-05-02 14:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193966&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Weakref types documentation bugs Initial Comment: This page (section 3.3.3 of the library reference manual): http://www.python.org/doc/current/lib/weakref-extension.html#weakref-extension contains a description of what you need to do to make your extension types weakrefable. There are a few problems with this page. First, it really belongs in the C API and/or extending and embedding documentation, not in the library reference manual. Second, the page describes having to set Py_TPFLAGS_HAVE_WEAKREFS in tp_flags, but that's unnecessary because Py_TPFLAGS_HAVE_WEAKREFS is already in Py_TPFLAGS_DEFAULT. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193966&group_id=5470 From noreply at sourceforge.net Mon May 2 23:13:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 May 2005 14:13:42 -0700 Subject: [ python-Bugs-1189330 ] LINKCC incorrect Message-ID: Bugs item #1189330, was opened at 2005-04-25 11:01 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1189330&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Christoph Ludwig (cludwig) Assigned to: Nobody/Anonymous (nobody) Summary: LINKCC incorrect Initial Comment: I configured Python 2.4.1 as follows ../Python-2.4.1/configure \ --prefix=/home/cludwig/C++/gcc4.0/Python-2.4.1 \ --with-cxx=/opt/gcc/gcc-4.0.0/bin/g++ --enable-shared \ --enable-unicode --with-signal-module \ --with-universal-newlines --with-doc-strings on a i686-pc-linux-gnu system. make fails when linking the python binariy due to an undefined reference to `__gxx_personality_v0'. In fact, configure set CC= gcc -pthread CXX= /opt/gcc/gcc-4.0.0/bin/g++ -pthread LINKCC= $(PURIFY) $(CC) but the python executable needs to be linked with $(CXX). (Note the `--with-cxx' option in the configure command line.) I did not observe this problem with Python 2.4.0 / gcc 3.4.2. This seems to be a regression w.r.t. PR #569668 that was closed as fixed on 2002-12-03. I can submit config.log and the output of make on request. Regards Christoph ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-05-02 23:13 Message: Logged In: YES user_id=21627 Can you propose a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1189330&group_id=5470 From noreply at sourceforge.net Mon May 2 23:16:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 May 2005 14:16:37 -0700 Subject: [ python-Bugs-1188231 ] Rebuilding from source on RH9 fails (_tkinter.so missing) Message-ID: Bugs item #1188231, was opened at 2005-04-22 20:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1188231&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Marty Heyman (mheyman) Assigned to: Nobody/Anonymous (nobody) Summary: Rebuilding from source on RH9 fails (_tkinter.so missing) Initial Comment: On a Red Hat 9 system, I downloaded the python2.4-2.4. 1-1pydotorg.src.rpm and, following the web page ran "rpm --rebuild . ..". It went a long for a good long while with no apparent errors and then said: --- RPM build errors: File not found by glob: /var/tmp/python2.4-2.4. 1-root/usr/lib/python2.4/lib-dynload/_tkinter.so* --- I looked in the directory and there is, in fact, no _tkinter.so file(s) there. -- Marty Heyman ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-05-02 23:16 Message: Logged In: YES user_id=21627 Ah, so it seems you are lacking the X11 header files. They should have been installed as a dependency on the Tk headers. So this is either a Redhat bug (for not including a dependency of the -dev packages) or a local misconfiguration of some kind (e.g. forcefully installing Tk headers without all prerequisites present). ---------------------------------------------------------------------- Comment By: Marty Heyman (mheyman) Date: 2005-04-22 20:42 Message: Logged In: YES user_id=421967 APOLOGIES: ADDITIONAL INFO FOLLOWS ---Snip from rebuild output follows In file included from /usr/src/redhat/BUILD/Python-2.4.1/Modules/_tkinter.c:67: /usr/include/tk.h:83:29: X11/Xlib.h: No such file or directory In file included from /usr/src/redhat/BUILD/Python-2.4.1/Modules/_tkinter.c:67: /usr/include/tk.h:581: parse error before "Bool" /usr/include/tk.h:583: parse error before "event" /usr/include/tk.h:584: parse error before "root" /usr/include/tk.h:585: parse error before "subwindow" /usr/include/tk.h:586: parse error before "time" /usr/include/tk.h:586: `time' redeclared as different kind of symbol /usr/include/time.h:184: previous declaration of `time' /usr/include/tk.h:591: parse error before "same_screen" --- snip ends many more "parse error lines occurred after this. I doubt they're interesting . A bit later, another group of failures begins --Snip starts In file included from /usr/include/tk.h:1361, from /usr/src/redhat/BUILD/Python-2.4.1/Modules/_tkinter.c:67: /usr/include/tkDecls.h:37: parse error before '*' token /usr/include/tkDecls.h:39: parse error before "Tk_3DBorderGC" /usr/include/tkDecls.h:45: parse error before "Drawable" /usr/include/tkDecls.h:50: parse error before "Drawable" /usr/include/tkDecls.h:58: parse error before "XEvent" --Snip ends Again, there are many more similar messages following those and then: --Snip starts /usr/include/tkDecls.h:843: `GC' declared as function returning a function ... [parse errors] /usr/include/tkDecls.h:906: `Font' declared as function returning a function --Snip ends There are many such embedded in that group. Then the messages stop followed by a line that says: "running build_scripts" ... and things proceed as if all was OK for hundreds more lines of output before the failure copied into the original report. I captured the complete log and can upload it if needed on request. I'd need to trim it and it doesn't look all that interesting otherwise but then, what do I know :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1188231&group_id=5470 From noreply at sourceforge.net Tue May 3 01:23:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 May 2005 16:23:52 -0700 Subject: [ python-Feature Requests-1190689 ] logging module root logger name Message-ID: Feature Requests item #1190689, was opened at 2005-04-26 20:19 Message generated for change (Comment added) made by cxdunn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190689&group_id=5470 Category: Python Library Group: None >Status: Open >Resolution: None Priority: 5 Submitted By: Christopher Dunn (cxdunn) Assigned to: Vinay Sajip (vsajip) Summary: logging module root logger name Initial Comment: I would like a trailing '.' to be ignored in names passed to getLogger(), like a trainling '/' in a Unix path. In module 'foo': logfoo = getLogger('.foo.') # logger '"" should be the parent of ".foo" Elsewhere, controlled by the user of that module: import foo logdefault = getLogger('.') hdlr = StreamHandler() fmtr = Formatter("%(name)s:%(msg)s") hdlr.setFormatter(fmtr) logdefault.addHandler(hdlr) Given this change, I would also like the name of the default logger to be displayed as '.', or even "", rather than 'root'. The current behavior is odd: logfoo.info("Foo message") displays .foo:Foo message buf logdefault.info("Default message") displays root:Default message I NEVER mentioned the word "root" anywhere! And I don't think it's very descriptive. I would rather see ANY of these: :Default message .:Default message default:Default message logging:Default message These changes would make the system more intuitive. -cxdunn ---------------------------------------------------------------------- >Comment By: Christopher Dunn (cxdunn) Date: 2005-05-02 18:23 Message: Logged In: YES user_id=1267419 There's a bug wrt renaming the root logger: >>> import logging.config >>> logging.root.name = "snafu" >>> logging.config.fileConfig("test.cfg") Traceback (most recent call last): File "python2.3/logging/config.py", line 132, in fileConfig llist.remove("root") ValueError: list.remove(x): x not in list This is no different in 2.4. list.remove(root.name) is an easy fix. Also, logging.getLogger() != logging.getLogger("root") or any other name. I now access the root logger strictly via logging.root getRootLogger(), which is deprecated, should be preferred, since the root logger's name is not actually in the hash-table. We need to make a sharp distinction between the root logger and the others. There is only one root; you cannot look it up by name; and the "dot" hierarchy does not apply to the root (for if it did, we would have to look specify children as .child, a convention that you've already rejected). -cxdunn P.S. I've posted some useful logging-related stuff at the ActivePython Cookbook. Feel free to add any of that to the module. Especially, the Unique filter could be added to logging.filters ---------------------------------------------------------------------- Comment By: Christopher Dunn (cxdunn) Date: 2005-04-28 14:23 Message: Logged In: YES user_id=1267419 You're right! That works like a charm: >>> import logging >>> logging.getLogger().name = '.' >>> logging.warning("I am root") WARNING:.:I am root >>> sub = logging.getLogger('.sub') >>> sub.warning("I am a child") WARNING:.sub:I am a child Setting the root to "" also works: >>> import logging >>> logging.getLogger().name = "" >>> logging.warning("I am root") WARNING::I am root >>> sub = logging.getLogger('sub') >>> sub.warning("I am a child") WARNING:sub:I am a child I agree with your other points. The flexibility would add little value. I brought this issue up b/c I was confused by the docs. Clearly, But it is not so clear that "A" is a child of "root". * "A.B" is obviously a child of "A" * ".A" is *clearly* a child of "." * And "A" is presumably a child of "". * But it is not so clear that "A" is a child of "root" Since *everything* is a child of the root logger, that's worth reiterating in the docs. And if there is truly only 1 root logger, then it should be possible to find it by name: >>> import logging >>> logging.getLogger().name ="." >>> logging.warning("I am root") WARNING:.:I am root >>> unknown = logging.getLogger(".") >>> unknown.warning("Who am I?") WARNING:.:Who am I? >>> unknown == logging.getLogger() False In fact: >>> import logging >>> logging.getLogger() == logging.getLogger() #just a test True >>> logging.getLogger() == logging.getLogger("root") #should be same! False This is not an easy module to understand, but it's amazingly powerful. One last suggestion. You have logging.handlers. You could also have logging.filters. For example: class Opaque(Filter): """A simple way to prevent any messages from getting through.""" def __init__(self, name=None): pass def filter(self, rec): return False class Unique(Filter): """Messages are allowed through just once. The 'message' includes substitutions, but is not formatted by the handler. If it were, then practically all messages would be unique! """ def __init__(self, name=""): Filter.__init__(self, name) self.reset() def reset(self): """Act as if nothing has happened.""" self.__logged = {} def filter(self, rec): return Filter.filter(self, rec) and self.__is_first_time(rec) def __is_first_time(self, rec): """Emit a message only once.""" msg = rec.msg %(rec.args) if msg in self.__logged: self.__logged[msg] += 1 return False else: self.__logged[msg] = 1 return True Actually, this might be Cookbook material. I'll write it up. Thanks for your time. -cxdunn ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2005-04-28 02:43 Message: Logged In: YES user_id=308438 Whoops! I don't quite know what happened, but I think both of us were updating this RFE entry concurrently. I only saw your followup starting "Novices always ask..." before I posted my response. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2005-04-28 02:36 Message: Logged In: YES user_id=308438 Logger names are hierarchical with dots separating levels in the hierarchy. So to me it does not make sense to have logger names which end in a dot, and you have given no reason why trailing dots should be supported. However, the hierarchy is not completely anologous to file system hierarchies - there is by design no concept of a "default" or "current" logger. I do not propose to make a change to this. However, I agree that the name of the root logger being "root" might be seen as unintuitive by some. Of your alternatives I think "logging" is best. I propose to add to the documentation the suggestion that users can define their own name for the root logger as in the following example: logging.getLogger().name = "myapp" People who use the root logger directly typically don't use other (named) loggers, because the whole point of using named loggers is to pinpoint areas of the application. Those users who use the root logger directly are typically not interested in finer granularity than the application or script itself. ---------------------------------------------------------------------- Comment By: Christopher Dunn (cxdunn) Date: 2005-04-28 02:29 Message: Logged In: YES user_id=1267419 Oops. Where I wrote abspath.rstrip('.'), I meant abspath.strip('.') Drop both leading and trailing dots for the prettified path. -cdunn ---------------------------------------------------------------------- Comment By: Christopher Dunn (cxdunn) Date: 2005-04-28 02:21 Message: Logged In: YES user_id=1267419 I am attaching a first pass it it. I've stored the "absolute" names everywhere, including both leading and trailing '.' I call this "absolute" by analogy with os.path.abspath(). I believe that similarities within the Python library help the user remember key concepts. What's missing: * I don't have aliases. * The "current working logger" is always '.' * And I haven't added any extra tags for the Formatter. But those are all very simple changes. The tough part is getting the path-searching correct. I have a big UnitTest suite which I can send to you if you'd like. The most important thing is that the word "root" is completely gone, but perhaps %(name)s should translate '.' to 'root' for backwards compatibility. The second-most important thing is that getLogger('.') returns the root logger. Third is that getLogger("Package.Module") is equivalent to getLogger(".Package.Module.") As for tags in the Formatter, after some testing I suggest these: %(name)s => abspath.rstrip('.'), but "." becomes "root" %(absname)s => abspath, with leading AND trailing dot, like a directory, so there is no question about whether the root displays as "." or "". It is always just dot in absolute notation. %(logger)s => abspath.rstrip('.'), maybe the prettiest I must tell you that, once I figured out how the logging module works, I really love it! Other possible additions: * Some useful, predefined filter classes: Never, OneTime (which must have a reset() method to clear its cache). I can send my version if you want. * A PipedStreamHandler. I'm not sure how to make this work. The idea is that, in UnitTesting, I want to read from some stream immediately after an operation, and I want the logged data to be immediately available, but to disappear as soon as I've read it. Does that make sense? Right now, I use a cStringIO object, with s.seek(0); s.truncate() after every read. -cxdunn ---------------------------------------------------------------------- Comment By: Christopher Dunn (cxdunn) Date: 2005-04-27 15:37 Message: Logged In: YES user_id=1267419 Novices always ask, "Why did it print 'root'? Where did that come from? After discussing this with some other "logging" module users, I think we've come up with a very good idea, which would maintain BACKWARDS COMPATIBILITY. Essentially, treat the logging module as a shell and the logger name as a path. Specifically, * Let the global logging functions operate on the "current worrking logger", which by default is "." (Let "root" be an alias for ".") * Change getLogger() so that it works on both absolute and relative logger paths. (Since the default current logger is "root", we maintain backwards compatibility.) * Change the format function so that %(name)s shows the relative path, if the absolute path starts with the current working logger name. * Add a format keyword, %(absname)s, which prints the absolute logger path. * Add another format keyword, %(logger)s, which prints what most people expect to see: the absolute logger name, sans the leading dot. (The "root" or "." logger would display as "", exactly the way it is usually accessed.) * Add global functions, change_current_logger() and get_current_logger(). * Add global function, alias(). Always create an alias for "root" to "." Examples:: from logging import * log = getLogger() #or getLogger(".") or getLogger("root") h1 = StreamHandler() f1 = Formatter("[%(name)s]%(message)s") h1.setFormatter(f1) log.addHandler(h1) h2 = StreamHandler() f2 = Formatter("[%(absname)s]%(message)s") h2.setFormatter(f2) log.addHandler(h2) h3 = StreamHandler() f3 = Formatter("[%(logger)s]%(message)s") h3.setFormatter(f3) log.addHandler(h3) log.error("First message") # ... child = getLogger("child") # or getLogger(".child") child.error("Bad news") This should print: [root]First message [.]First message []First message [child]Bad news [.child]Bad news [child]Bad news This would create tremendous flexibility, add some clarity to the meaning of the "root" logger, and still maintain complete backwards compatibility. I am willing to make the changes myself, including UnitTests, if there is agreement that they would be adopted. (Note that String.before() and String.after() would make the coding a little easier/clearer, but that's a different feature request.) -cxdunn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190689&group_id=5470 From noreply at sourceforge.net Tue May 3 04:39:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 May 2005 19:39:06 -0700 Subject: [ python-Bugs-1194181 ] bz2.BZ2File doesn't handle modes correctly Message-ID: Bugs item #1194181, was opened at 2005-05-02 22:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194181&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: bz2.BZ2File doesn't handle modes correctly Initial Comment: I've noticed that if I specify a file mode of 'U' to bz2.BZ2File, it will erase my file. That's bad. Specifying 'rU' works as expected. Basically, it assumes that you want a writable file unless it sees an 'r' in the mode, or no mode is given. Ugh. I've attached a patch that fixes this on CVS HEAD, it looks like it should apply cleanly to 2.4 as well. This is a backport candidate if I've ever seen one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194181&group_id=5470 From noreply at sourceforge.net Tue May 3 06:02:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 May 2005 21:02:15 -0700 Subject: [ python-Bugs-1194209 ] Error in section 4.2 of Python Tutorial Message-ID: Bugs item #1194209, was opened at 2005-05-03 00:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194209&group_id=5470 Category: Documentation Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Andrina Kelly (andrina) Assigned to: Nobody/Anonymous (nobody) Summary: Error in section 4.2 of Python Tutorial Initial Comment: The example in section 4.2 of the on-line tutorial should read as follows: >>> # Measure some strings: ... a = ['cat', 'window', 'defenestrate'] >>> for x in a: ... print x, len(a) ... cat 3 window 6 defenestrate 12 currently the print line has len(x) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194209&group_id=5470 From noreply at sourceforge.net Tue May 3 06:05:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 May 2005 21:05:24 -0700 Subject: [ python-Bugs-1194209 ] Error in section 4.2 of Python Tutorial Message-ID: Bugs item #1194209, was opened at 2005-05-03 00:02 Message generated for change (Settings changed) made by andrina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194209&group_id=5470 Category: Documentation Group: Not a Bug Status: Open Resolution: None >Priority: 3 Submitted By: Andrina Kelly (andrina) Assigned to: Nobody/Anonymous (nobody) Summary: Error in section 4.2 of Python Tutorial Initial Comment: The example in section 4.2 of the on-line tutorial should read as follows: >>> # Measure some strings: ... a = ['cat', 'window', 'defenestrate'] >>> for x in a: ... print x, len(a) ... cat 3 window 6 defenestrate 12 currently the print line has len(x) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194209&group_id=5470 From noreply at sourceforge.net Tue May 3 06:37:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 May 2005 21:37:01 -0700 Subject: [ python-Bugs-1194222 ] parsedate and Y2K Message-ID: Bugs item #1194222, was opened at 2005-05-02 21:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194222&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Nottingham (mnot) Assigned to: Nobody/Anonymous (nobody) Summary: parsedate and Y2K Initial Comment: rfc822.parsedate and email.Utils.parsedate don't take Y2K into account when parsing two-digit years, even though they're allowed by RFC822. Even though that spec has since been superseded, there are still systems generating dates in the old format, and RFC2616, which bases its dates on RFC822, still allows two-digit years. For example, >>> email.Utils.parsedate("Sun, 6 Nov 94 08:49:37 GMT") (94, 11, 6, 8, 49, 37, 0, 0, 0) Here's a trivial patch to behave as outlined in the time module (I don't test for time.accept2dyear because the input is outside the system's control, and RFC-specified); it's against 2.3, but should be easy to integrate into later versions. 125a126,130 > if yy < 100: > if yy > 68: > yy = yy + 1900 > else: > yy = yy + 2000 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194222&group_id=5470 From noreply at sourceforge.net Tue May 3 08:31:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 May 2005 23:31:17 -0700 Subject: [ python-Bugs-1194249 ] Minor bug in urllib docs Message-ID: Bugs item #1194249, was opened at 2005-05-03 06:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194249&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: Minor bug in urllib docs Initial Comment: The urllib docs contain an example which starts as follows: # Use http://www.someproxy.com:3128 for http proxying proxies = proxies={'http': 'http://www.someproxy.com:3128'} filehandle = urllib.urlopen(some_url, proxies=proxies) The double "proxies=" is most likely a mistake and should be removed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194249&group_id=5470 From noreply at sourceforge.net Tue May 3 10:29:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 May 2005 01:29:38 -0700 Subject: [ python-Bugs-1189330 ] LINKCC incorrect Message-ID: Bugs item #1189330, was opened at 2005-04-25 11:01 Message generated for change (Comment added) made by cludwig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1189330&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Christoph Ludwig (cludwig) Assigned to: Nobody/Anonymous (nobody) Summary: LINKCC incorrect Initial Comment: I configured Python 2.4.1 as follows ../Python-2.4.1/configure \ --prefix=/home/cludwig/C++/gcc4.0/Python-2.4.1 \ --with-cxx=/opt/gcc/gcc-4.0.0/bin/g++ --enable-shared \ --enable-unicode --with-signal-module \ --with-universal-newlines --with-doc-strings on a i686-pc-linux-gnu system. make fails when linking the python binariy due to an undefined reference to `__gxx_personality_v0'. In fact, configure set CC= gcc -pthread CXX= /opt/gcc/gcc-4.0.0/bin/g++ -pthread LINKCC= $(PURIFY) $(CC) but the python executable needs to be linked with $(CXX). (Note the `--with-cxx' option in the configure command line.) I did not observe this problem with Python 2.4.0 / gcc 3.4.2. This seems to be a regression w.r.t. PR #569668 that was closed as fixed on 2002-12-03. I can submit config.log and the output of make on request. Regards Christoph ---------------------------------------------------------------------- >Comment By: Christoph Ludwig (cludwig) Date: 2005-05-03 10:29 Message: Logged In: YES user_id=1266029 That depends on how clever the patch is supposed to be. I am going to attach a patch against configure.in (from current CVS) that enforces `LINKCC = $(PURIFY) $(CXX)' if --with-cxx= is passed to configure. My rationale is that a user who specifies --with-cxx wants python to be build with the C++ compiler and therefore won't mind if the executable depends on the C++ runtime library. The previous code in configure.in tried to determine if one can link the executable with the C compiler/linker even if some of the object files were compiled by a C++ compiler. The approach taken seems to be fragile, though: In simple cases g++ 4.0 seems to realize there is no need for the C++ runtime libraries, but in more complex cases it adds a dependency on the C++ runtime anyway. Even if you add a more complex test case to configure.in, how do you know your testcase mirrors the complexity of the python executable and any C++ extension loaded at runtime? I think a proper test would be quite involved whence I prefer the simplistic approach taken by my patch. Do you know a system / use case where one needs to compile python.c with a C++ compiler but needs to avoid the dependency on the C++ runtime? Regards Christoph ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-02 23:13 Message: Logged In: YES user_id=21627 Can you propose a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1189330&group_id=5470 From noreply at sourceforge.net Tue May 3 10:33:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 May 2005 01:33:10 -0700 Subject: [ python-Bugs-1190580 ] SimpleHTTPServer sends wrong c-length and locks up client Message-ID: Bugs item #1190580, was opened at 2005-04-26 23:32 Message generated for change (Comment added) made by irmen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190580&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexander Schremmer (alexanderweb) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleHTTPServer sends wrong c-length and locks up client Initial Comment: On windows, SimpleHTTPServer shows a severe bug: it sends a wrong content-length header. In fact, it sends the wrong data. It differentiates between the mime types "text/" and the remaining ones and decides upon that if it should open the file in binary mode. That is illegal according to the RFCs, any text/ mimetype has to be served using \r\n line endings, therefore it may not read it in non-binary mode. My suggestion: remove the disambiguation (that means the if block). Umm, yeah, my initial reason to report this: if the content-length value is greater than the actual delivered data size, gateways/clients may lock up if they use pipelining. (And they do, BTDT). The reason for that wrong value: the filesize if determined before line end conversion (implicit because of non-binary read file mode) . ---------------------------------------------------------------------- >Comment By: Irmen de Jong (irmen) Date: 2005-05-03 10:33 Message: Logged In: YES user_id=129426 This is a dupe of my patch [ 839496 ] SimpleHTTPServer reports wrong content-length for text files, which has already been applied & closed (Python 2.4.1 contains the patch already, for instance). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190580&group_id=5470 From noreply at sourceforge.net Tue May 3 11:44:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 May 2005 02:44:06 -0700 Subject: [ python-Bugs-1194328 ] Reading from a killed shell script with popen* under linux Message-ID: Bugs item #1194328, was opened at 2005-05-03 09:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194328&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Vinz (boukthor) Assigned to: Nobody/Anonymous (nobody) Summary: Reading from a killed shell script with popen* under linux Initial Comment: These are problems I've run into under linux (Mandrake 10.0 through 2006.0, Debian 3.1 and Gentoo) with python versions ranging from 2.3.3 to 2.4: If you run this: import os pout = os.popen("/bin/sleep 999") print pout.read() print pout.close() and kill the "sleep", you get the desired behaviour: the read returns an empty string when the process gets killed and the close returns the killing signal. However, if you put the "sleep" command in a shell script, for example this simple "/tmp/test.sh": #!/bin/sh sleep 999 and run the script through popen (or one of the popen* method of the os and popen2 module) import os pout = os.popen("/tmp/test.sh") print pout.read() print pout.close() then kill the sh running "test.sh", the read never returns and the shell remains as a zombie. You can get some strange behaviour with the Popen* classes too (whether bypassing the shell intervention or not). For example, run this (and kill the subshell): import popen2 sub = popen2.Popen3("/tmp/test.sh") print sub.wait() print sub.fromchild.read() this time the wait correctly returns the signal that killed the shell and removes it from the process table, but the read hangs again. As an added oddity, if you run the popen command from an interactive prompt and raise a KeyboardInterrupt by pressing Ctrl-C before trying to read from the pipe, you kill the subprocess with the SIGINT... I have a final suggestion: if you try reading the output of a popen* method with a "for" statement like this: import os pout = os.popen("for i in $(seq 1 10); do echo $i; sleep 1; done") for l in pout: print l, it waits for the subprocess to complete before going into the loop. To get the output as it is piped, you have to use the poll method of the Popen* classes (which is not available under OSes other than Unix): sub = popen2.Popen3("for i in $(seq 1 10); do echo $i; sleep 1; done") while (-1 == sub.poll()): print sub.fromchild.readline() I don't know if this last behaviour can be fixed or not but I'd suggest some mention of this in the manual if it can't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194328&group_id=5470 From noreply at sourceforge.net Tue May 3 11:49:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 May 2005 02:49:51 -0700 Subject: [ python-Bugs-1194328 ] Reading from a killed shell script with popen* under linux Message-ID: Bugs item #1194328, was opened at 2005-05-03 09:44 Message generated for change (Comment added) made by boukthor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194328&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Vinz (boukthor) Assigned to: Nobody/Anonymous (nobody) Summary: Reading from a killed shell script with popen* under linux Initial Comment: These are problems I've run into under linux (Mandrake 10.0 through 2006.0, Debian 3.1 and Gentoo) with python versions ranging from 2.3.3 to 2.4: If you run this: import os pout = os.popen("/bin/sleep 999") print pout.read() print pout.close() and kill the "sleep", you get the desired behaviour: the read returns an empty string when the process gets killed and the close returns the killing signal. However, if you put the "sleep" command in a shell script, for example this simple "/tmp/test.sh": #!/bin/sh sleep 999 and run the script through popen (or one of the popen* method of the os and popen2 module) import os pout = os.popen("/tmp/test.sh") print pout.read() print pout.close() then kill the sh running "test.sh", the read never returns and the shell remains as a zombie. You can get some strange behaviour with the Popen* classes too (whether bypassing the shell intervention or not). For example, run this (and kill the subshell): import popen2 sub = popen2.Popen3("/tmp/test.sh") print sub.wait() print sub.fromchild.read() this time the wait correctly returns the signal that killed the shell and removes it from the process table, but the read hangs again. As an added oddity, if you run the popen command from an interactive prompt and raise a KeyboardInterrupt by pressing Ctrl-C before trying to read from the pipe, you kill the subprocess with the SIGINT... I have a final suggestion: if you try reading the output of a popen* method with a "for" statement like this: import os pout = os.popen("for i in $(seq 1 10); do echo $i; sleep 1; done") for l in pout: print l, it waits for the subprocess to complete before going into the loop. To get the output as it is piped, you have to use the poll method of the Popen* classes (which is not available under OSes other than Unix): sub = popen2.Popen3("for i in $(seq 1 10); do echo $i; sleep 1; done") while (-1 == sub.poll()): print sub.fromchild.readline() I don't know if this last behaviour can be fixed or not but I'd suggest some mention of this in the manual if it can't. ---------------------------------------------------------------------- >Comment By: Vinz (boukthor) Date: 2005-05-03 09:49 Message: Logged In: YES user_id=638508 Oops, just saw the report #1180160. I missed it because I searched for popen, not Popen before posting. My bad. I'll cross-reference the two. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194328&group_id=5470 From noreply at sourceforge.net Tue May 3 14:07:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 May 2005 05:07:59 -0700 Subject: [ python-Feature Requests-1190689 ] logging module root logger name Message-ID: Feature Requests item #1190689, was opened at 2005-04-27 01:19 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190689&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Christopher Dunn (cxdunn) Assigned to: Vinay Sajip (vsajip) Summary: logging module root logger name Initial Comment: I would like a trailing '.' to be ignored in names passed to getLogger(), like a trainling '/' in a Unix path. In module 'foo': logfoo = getLogger('.foo.') # logger '"" should be the parent of ".foo" Elsewhere, controlled by the user of that module: import foo logdefault = getLogger('.') hdlr = StreamHandler() fmtr = Formatter("%(name)s:%(msg)s") hdlr.setFormatter(fmtr) logdefault.addHandler(hdlr) Given this change, I would also like the name of the default logger to be displayed as '.', or even "", rather than 'root'. The current behavior is odd: logfoo.info("Foo message") displays .foo:Foo message buf logdefault.info("Default message") displays root:Default message I NEVER mentioned the word "root" anywhere! And I don't think it's very descriptive. I would rather see ANY of these: :Default message .:Default message default:Default message logging:Default message These changes would make the system more intuitive. -cxdunn ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2005-05-03 12:07 Message: Logged In: YES user_id=308438 There's no need to rename the root logger in a configuration file, so it can still be called "root" in the configuration file and have a different name displayed in messages. The config logic specifically looks for the section name "logger_root" and associates that section with the root logger. There is no reason to change this. You should not use logging.root to get the root logger. Instead, use logging.getLogger(). If you want to make clearer a distinction between root logger and other loggers (they're not that different, in my view - see the docstring for the RootLogger class), please submit a documentation patch. ---------------------------------------------------------------------- Comment By: Christopher Dunn (cxdunn) Date: 2005-05-02 23:23 Message: Logged In: YES user_id=1267419 There's a bug wrt renaming the root logger: >>> import logging.config >>> logging.root.name = "snafu" >>> logging.config.fileConfig("test.cfg") Traceback (most recent call last): File "python2.3/logging/config.py", line 132, in fileConfig llist.remove("root") ValueError: list.remove(x): x not in list This is no different in 2.4. list.remove(root.name) is an easy fix. Also, logging.getLogger() != logging.getLogger("root") or any other name. I now access the root logger strictly via logging.root getRootLogger(), which is deprecated, should be preferred, since the root logger's name is not actually in the hash-table. We need to make a sharp distinction between the root logger and the others. There is only one root; you cannot look it up by name; and the "dot" hierarchy does not apply to the root (for if it did, we would have to look specify children as .child, a convention that you've already rejected). -cxdunn P.S. I've posted some useful logging-related stuff at the ActivePython Cookbook. Feel free to add any of that to the module. Especially, the Unique filter could be added to logging.filters ---------------------------------------------------------------------- Comment By: Christopher Dunn (cxdunn) Date: 2005-04-28 19:23 Message: Logged In: YES user_id=1267419 You're right! That works like a charm: >>> import logging >>> logging.getLogger().name = '.' >>> logging.warning("I am root") WARNING:.:I am root >>> sub = logging.getLogger('.sub') >>> sub.warning("I am a child") WARNING:.sub:I am a child Setting the root to "" also works: >>> import logging >>> logging.getLogger().name = "" >>> logging.warning("I am root") WARNING::I am root >>> sub = logging.getLogger('sub') >>> sub.warning("I am a child") WARNING:sub:I am a child I agree with your other points. The flexibility would add little value. I brought this issue up b/c I was confused by the docs. Clearly, But it is not so clear that "A" is a child of "root". * "A.B" is obviously a child of "A" * ".A" is *clearly* a child of "." * And "A" is presumably a child of "". * But it is not so clear that "A" is a child of "root" Since *everything* is a child of the root logger, that's worth reiterating in the docs. And if there is truly only 1 root logger, then it should be possible to find it by name: >>> import logging >>> logging.getLogger().name ="." >>> logging.warning("I am root") WARNING:.:I am root >>> unknown = logging.getLogger(".") >>> unknown.warning("Who am I?") WARNING:.:Who am I? >>> unknown == logging.getLogger() False In fact: >>> import logging >>> logging.getLogger() == logging.getLogger() #just a test True >>> logging.getLogger() == logging.getLogger("root") #should be same! False This is not an easy module to understand, but it's amazingly powerful. One last suggestion. You have logging.handlers. You could also have logging.filters. For example: class Opaque(Filter): """A simple way to prevent any messages from getting through.""" def __init__(self, name=None): pass def filter(self, rec): return False class Unique(Filter): """Messages are allowed through just once. The 'message' includes substitutions, but is not formatted by the handler. If it were, then practically all messages would be unique! """ def __init__(self, name=""): Filter.__init__(self, name) self.reset() def reset(self): """Act as if nothing has happened.""" self.__logged = {} def filter(self, rec): return Filter.filter(self, rec) and self.__is_first_time(rec) def __is_first_time(self, rec): """Emit a message only once.""" msg = rec.msg %(rec.args) if msg in self.__logged: self.__logged[msg] += 1 return False else: self.__logged[msg] = 1 return True Actually, this might be Cookbook material. I'll write it up. Thanks for your time. -cxdunn ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2005-04-28 07:43 Message: Logged In: YES user_id=308438 Whoops! I don't quite know what happened, but I think both of us were updating this RFE entry concurrently. I only saw your followup starting "Novices always ask..." before I posted my response. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2005-04-28 07:36 Message: Logged In: YES user_id=308438 Logger names are hierarchical with dots separating levels in the hierarchy. So to me it does not make sense to have logger names which end in a dot, and you have given no reason why trailing dots should be supported. However, the hierarchy is not completely anologous to file system hierarchies - there is by design no concept of a "default" or "current" logger. I do not propose to make a change to this. However, I agree that the name of the root logger being "root" might be seen as unintuitive by some. Of your alternatives I think "logging" is best. I propose to add to the documentation the suggestion that users can define their own name for the root logger as in the following example: logging.getLogger().name = "myapp" People who use the root logger directly typically don't use other (named) loggers, because the whole point of using named loggers is to pinpoint areas of the application. Those users who use the root logger directly are typically not interested in finer granularity than the application or script itself. ---------------------------------------------------------------------- Comment By: Christopher Dunn (cxdunn) Date: 2005-04-28 07:29 Message: Logged In: YES user_id=1267419 Oops. Where I wrote abspath.rstrip('.'), I meant abspath.strip('.') Drop both leading and trailing dots for the prettified path. -cdunn ---------------------------------------------------------------------- Comment By: Christopher Dunn (cxdunn) Date: 2005-04-28 07:21 Message: Logged In: YES user_id=1267419 I am attaching a first pass it it. I've stored the "absolute" names everywhere, including both leading and trailing '.' I call this "absolute" by analogy with os.path.abspath(). I believe that similarities within the Python library help the user remember key concepts. What's missing: * I don't have aliases. * The "current working logger" is always '.' * And I haven't added any extra tags for the Formatter. But those are all very simple changes. The tough part is getting the path-searching correct. I have a big UnitTest suite which I can send to you if you'd like. The most important thing is that the word "root" is completely gone, but perhaps %(name)s should translate '.' to 'root' for backwards compatibility. The second-most important thing is that getLogger('.') returns the root logger. Third is that getLogger("Package.Module") is equivalent to getLogger(".Package.Module.") As for tags in the Formatter, after some testing I suggest these: %(name)s => abspath.rstrip('.'), but "." becomes "root" %(absname)s => abspath, with leading AND trailing dot, like a directory, so there is no question about whether the root displays as "." or "". It is always just dot in absolute notation. %(logger)s => abspath.rstrip('.'), maybe the prettiest I must tell you that, once I figured out how the logging module works, I really love it! Other possible additions: * Some useful, predefined filter classes: Never, OneTime (which must have a reset() method to clear its cache). I can send my version if you want. * A PipedStreamHandler. I'm not sure how to make this work. The idea is that, in UnitTesting, I want to read from some stream immediately after an operation, and I want the logged data to be immediately available, but to disappear as soon as I've read it. Does that make sense? Right now, I use a cStringIO object, with s.seek(0); s.truncate() after every read. -cxdunn ---------------------------------------------------------------------- Comment By: Christopher Dunn (cxdunn) Date: 2005-04-27 20:37 Message: Logged In: YES user_id=1267419 Novices always ask, "Why did it print 'root'? Where did that come from? After discussing this with some other "logging" module users, I think we've come up with a very good idea, which would maintain BACKWARDS COMPATIBILITY. Essentially, treat the logging module as a shell and the logger name as a path. Specifically, * Let the global logging functions operate on the "current worrking logger", which by default is "." (Let "root" be an alias for ".") * Change getLogger() so that it works on both absolute and relative logger paths. (Since the default current logger is "root", we maintain backwards compatibility.) * Change the format function so that %(name)s shows the relative path, if the absolute path starts with the current working logger name. * Add a format keyword, %(absname)s, which prints the absolute logger path. * Add another format keyword, %(logger)s, which prints what most people expect to see: the absolute logger name, sans the leading dot. (The "root" or "." logger would display as "", exactly the way it is usually accessed.) * Add global functions, change_current_logger() and get_current_logger(). * Add global function, alias(). Always create an alias for "root" to "." Examples:: from logging import * log = getLogger() #or getLogger(".") or getLogger("root") h1 = StreamHandler() f1 = Formatter("[%(name)s]%(message)s") h1.setFormatter(f1) log.addHandler(h1) h2 = StreamHandler() f2 = Formatter("[%(absname)s]%(message)s") h2.setFormatter(f2) log.addHandler(h2) h3 = StreamHandler() f3 = Formatter("[%(logger)s]%(message)s") h3.setFormatter(f3) log.addHandler(h3) log.error("First message") # ... child = getLogger("child") # or getLogger(".child") child.error("Bad news") This should print: [root]First message [.]First message []First message [child]Bad news [.child]Bad news [child]Bad news This would create tremendous flexibility, add some clarity to the meaning of the "root" logger, and still maintain complete backwards compatibility. I am willing to make the changes myself, including UnitTests, if there is agreement that they would be adopted. (Note that String.before() and String.after() would make the coding a little easier/clearer, but that's a different feature request.) -cxdunn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190689&group_id=5470 From noreply at sourceforge.net Tue May 3 15:31:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 May 2005 06:31:17 -0700 Subject: [ python-Feature Requests-1193577 ] add server.shutdown() method and daemon arg to SocketServer Message-ID: Feature Requests item #1193577, was opened at 2005-05-01 22:04 Message generated for change (Settings changed) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1193577&group_id=5470 >Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) >Assigned to: Skip Montanaro (montanaro) Summary: add server.shutdown() method and daemon arg to SocketServer Initial Comment: First of all the daemon_threads property on socket servers should be added as an optional arg to the server constructor, so you can say: TCPServer(..., daemon_threads=True).serve_forever() instead of temp = TCPServer(...) temp.daemon_threads=True temp.serve_forever Secondly there should be a way to STOP the server, once you've started serving forever! A request handler should be able to say self.server.stop_serving() This would work by setting a flag in the server object. The serve_forever loop would use select with a timeout (default 0.5 sec, also settable as an optional arg to the server constructor) or alternatively set a timeout on the socket object. So it would block listening for new connections, but every 0.5 sec it would check the stop_serving flag and break out of the loop if the flag was set. This method was suggested by Skip Montanaro in a clpy thread about how to stop SocketServer and it's useful enough that I think it should be part of the standard impl. I can make a patch if it's not obvious how to do it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1193577&group_id=5470 From noreply at sourceforge.net Tue May 3 16:50:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 May 2005 07:50:57 -0700 Subject: [ python-Bugs-1194497 ] ImportError: No module named os Message-ID: Bugs item #1194497, was opened at 2005-05-03 14:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194497&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Will L G (diskman) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError: No module named os Initial Comment: Compiling on the following system: Redhat 7.2 [alpha] Kernel-2.6.11.4 Compaq C 6.5.9 GLIBC-2.3.2 Make-2.80 Binutils-2.15 Receiving the following error: /usr/share/printconf/util/queueTree.py:89: GtkWarning: gtk_label_set_use_underline: assertion `GTK_IS_LABEL (label)' failed domain = domain) Traceback (most recent call last): File "/usr/sbin/redhat-config-printer-gui", line 7, in ? import queueTree File "/usr/share/printconf/util/queueTree.py", line 1091, in ? queueTree() File "/usr/share/printconf/util/queueTree.py", line 128, in __init__ if cups_import.import_needed (): File "/usr/share/printconf/util/cups_import.py", line 200, in import_needed which = which_spooler () File "/usr/share/printconf/util/cups_import.py", line 195, in which_spooler return which UnboundLocalError: local variable 'which' referenced before assignment ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194497&group_id=5470 From noreply at sourceforge.net Tue May 3 16:51:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 May 2005 07:51:48 -0700 Subject: [ python-Bugs-1194497 ] ImportError: No module named os Message-ID: Bugs item #1194497, was opened at 2005-05-03 14:50 Message generated for change (Settings changed) made by diskman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194497&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None >Priority: 7 Submitted By: Will L G (diskman) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError: No module named os Initial Comment: Compiling on the following system: Redhat 7.2 [alpha] Kernel-2.6.11.4 Compaq C 6.5.9 GLIBC-2.3.2 Make-2.80 Binutils-2.15 Receiving the following error: /usr/share/printconf/util/queueTree.py:89: GtkWarning: gtk_label_set_use_underline: assertion `GTK_IS_LABEL (label)' failed domain = domain) Traceback (most recent call last): File "/usr/sbin/redhat-config-printer-gui", line 7, in ? import queueTree File "/usr/share/printconf/util/queueTree.py", line 1091, in ? queueTree() File "/usr/share/printconf/util/queueTree.py", line 128, in __init__ if cups_import.import_needed (): File "/usr/share/printconf/util/cups_import.py", line 200, in import_needed which = which_spooler () File "/usr/share/printconf/util/cups_import.py", line 195, in which_spooler return which UnboundLocalError: local variable 'which' referenced before assignment ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194497&group_id=5470 From noreply at sourceforge.net Tue May 3 16:53:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 May 2005 07:53:01 -0700 Subject: [ python-Bugs-1194497 ] ImportError: No module named os Message-ID: Bugs item #1194497, was opened at 2005-05-03 14:50 Message generated for change (Comment added) made by diskman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194497&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Will L G (diskman) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError: No module named os Initial Comment: Compiling on the following system: Redhat 7.2 [alpha] Kernel-2.6.11.4 Compaq C 6.5.9 GLIBC-2.3.2 Make-2.80 Binutils-2.15 Receiving the following error: /usr/share/printconf/util/queueTree.py:89: GtkWarning: gtk_label_set_use_underline: assertion `GTK_IS_LABEL (label)' failed domain = domain) Traceback (most recent call last): File "/usr/sbin/redhat-config-printer-gui", line 7, in ? import queueTree File "/usr/share/printconf/util/queueTree.py", line 1091, in ? queueTree() File "/usr/share/printconf/util/queueTree.py", line 128, in __init__ if cups_import.import_needed (): File "/usr/share/printconf/util/cups_import.py", line 200, in import_needed which = which_spooler () File "/usr/share/printconf/util/cups_import.py", line 195, in which_spooler return which UnboundLocalError: local variable 'which' referenced before assignment ---------------------------------------------------------------------- >Comment By: Will L G (diskman) Date: 2005-05-03 14:53 Message: Logged In: YES user_id=312992 Whoops, did a cut and paste... the previous error was from printconfig... I was upgrading python to fix that and this is what I received from Python while building: [root at jericho Python-2.4.1]# make case $MAKEFLAGS in *-s*) LD_LIBRARY_PATH=/usr2/www/linux- related/programming/python/Python- 2.4.1:/usr/X11R6/lib:/usr/lib:/usr/local/lib CC='ccache ccc - pthread' LDSHARED='ccache ccc -pthread -shared' OPT='- DNDEBUG -O' ./python -E ./setup.py -q build;; *) LD_LIBRARY_PATH=/usr2/www/linux- related/programming/python/Python- 2.4.1:/usr/X11R6/lib:/usr/lib:/usr/local/lib CC='ccache ccc - pthread' LDSHARED='ccache ccc -pthread -shared' OPT='- DNDEBUG -O' ./python -E ./setup.py build;; esac Could not find platform independent libraries Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] 'import site' failed; use -v for traceback Traceback (most recent call last): File "./setup.py", line 6, in ? import sys, os, getopt, imp, re ImportError: No module named os make: *** [sharedmods] Error 1 [root at jericho Python-2.4.1]# ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194497&group_id=5470 From noreply at sourceforge.net Tue May 3 20:07:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 May 2005 11:07:05 -0700 Subject: [ python-Bugs-1190580 ] SimpleHTTPServer sends wrong c-length and locks up client Message-ID: Bugs item #1190580, was opened at 2005-04-26 23:32 Message generated for change (Comment added) made by alexanderweb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190580&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Alexander Schremmer (alexanderweb) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleHTTPServer sends wrong c-length and locks up client Initial Comment: On windows, SimpleHTTPServer shows a severe bug: it sends a wrong content-length header. In fact, it sends the wrong data. It differentiates between the mime types "text/" and the remaining ones and decides upon that if it should open the file in binary mode. That is illegal according to the RFCs, any text/ mimetype has to be served using \r\n line endings, therefore it may not read it in non-binary mode. My suggestion: remove the disambiguation (that means the if block). Umm, yeah, my initial reason to report this: if the content-length value is greater than the actual delivered data size, gateways/clients may lock up if they use pipelining. (And they do, BTDT). The reason for that wrong value: the filesize if determined before line end conversion (implicit because of non-binary read file mode) . ---------------------------------------------------------------------- >Comment By: Alexander Schremmer (alexanderweb) Date: 2005-05-03 20:07 Message: Logged In: YES user_id=254738 Indeed :-) ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-05-03 10:33 Message: Logged In: YES user_id=129426 This is a dupe of my patch [ 839496 ] SimpleHTTPServer reports wrong content-length for text files, which has already been applied & closed (Python 2.4.1 contains the patch already, for instance). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190580&group_id=5470 From noreply at sourceforge.net Tue May 3 22:08:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 May 2005 13:08:12 -0700 Subject: [ python-Feature Requests-1190689 ] logging module root logger name Message-ID: Feature Requests item #1190689, was opened at 2005-04-26 20:19 Message generated for change (Comment added) made by cxdunn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190689&group_id=5470 Category: Python Library Group: None Status: Closed >Resolution: Works For Me >Priority: 1 Submitted By: Christopher Dunn (cxdunn) Assigned to: Vinay Sajip (vsajip) Summary: logging module root logger name Initial Comment: I would like a trailing '.' to be ignored in names passed to getLogger(), like a trainling '/' in a Unix path. In module 'foo': logfoo = getLogger('.foo.') # logger '"" should be the parent of ".foo" Elsewhere, controlled by the user of that module: import foo logdefault = getLogger('.') hdlr = StreamHandler() fmtr = Formatter("%(name)s:%(msg)s") hdlr.setFormatter(fmtr) logdefault.addHandler(hdlr) Given this change, I would also like the name of the default logger to be displayed as '.', or even "", rather than 'root'. The current behavior is odd: logfoo.info("Foo message") displays .foo:Foo message buf logdefault.info("Default message") displays root:Default message I NEVER mentioned the word "root" anywhere! And I don't think it's very descriptive. I would rather see ANY of these: :Default message .:Default message default:Default message logging:Default message These changes would make the system more intuitive. -cxdunn ---------------------------------------------------------------------- >Comment By: Christopher Dunn (cxdunn) Date: 2005-05-03 15:08 Message: Logged In: YES user_id=1267419 You're right. The following works: >>> import logging, logging.config >>> logging.root.name = "snafu" >>> logging.config.fileConfig('test.cfg') >>> logging.warning("Hello") [snafu] Hello Where test.cfg is: [loggers] keys=root [handlers] keys=hand01 [formatters] keys=form01 [logger_root] level=NOTSET handlers=hand01 [handler_hand01] class=StreamHandler level=NOTSET formatter=form01 args=(sys.stderr,) [formatter_form01] format=[%(name)s] %(message)s "If you want to make clearer a distinction between root logger and other loggers ... please submit a documentation patch." OK.... ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2005-05-03 07:07 Message: Logged In: YES user_id=308438 There's no need to rename the root logger in a configuration file, so it can still be called "root" in the configuration file and have a different name displayed in messages. The config logic specifically looks for the section name "logger_root" and associates that section with the root logger. There is no reason to change this. You should not use logging.root to get the root logger. Instead, use logging.getLogger(). If you want to make clearer a distinction between root logger and other loggers (they're not that different, in my view - see the docstring for the RootLogger class), please submit a documentation patch. ---------------------------------------------------------------------- Comment By: Christopher Dunn (cxdunn) Date: 2005-05-02 18:23 Message: Logged In: YES user_id=1267419 There's a bug wrt renaming the root logger: >>> import logging.config >>> logging.root.name = "snafu" >>> logging.config.fileConfig("test.cfg") Traceback (most recent call last): File "python2.3/logging/config.py", line 132, in fileConfig llist.remove("root") ValueError: list.remove(x): x not in list This is no different in 2.4. list.remove(root.name) is an easy fix. Also, logging.getLogger() != logging.getLogger("root") or any other name. I now access the root logger strictly via logging.root getRootLogger(), which is deprecated, should be preferred, since the root logger's name is not actually in the hash-table. We need to make a sharp distinction between the root logger and the others. There is only one root; you cannot look it up by name; and the "dot" hierarchy does not apply to the root (for if it did, we would have to look specify children as .child, a convention that you've already rejected). -cxdunn P.S. I've posted some useful logging-related stuff at the ActivePython Cookbook. Feel free to add any of that to the module. Especially, the Unique filter could be added to logging.filters ---------------------------------------------------------------------- Comment By: Christopher Dunn (cxdunn) Date: 2005-04-28 14:23 Message: Logged In: YES user_id=1267419 You're right! That works like a charm: >>> import logging >>> logging.getLogger().name = '.' >>> logging.warning("I am root") WARNING:.:I am root >>> sub = logging.getLogger('.sub') >>> sub.warning("I am a child") WARNING:.sub:I am a child Setting the root to "" also works: >>> import logging >>> logging.getLogger().name = "" >>> logging.warning("I am root") WARNING::I am root >>> sub = logging.getLogger('sub') >>> sub.warning("I am a child") WARNING:sub:I am a child I agree with your other points. The flexibility would add little value. I brought this issue up b/c I was confused by the docs. Clearly, But it is not so clear that "A" is a child of "root". * "A.B" is obviously a child of "A" * ".A" is *clearly* a child of "." * And "A" is presumably a child of "". * But it is not so clear that "A" is a child of "root" Since *everything* is a child of the root logger, that's worth reiterating in the docs. And if there is truly only 1 root logger, then it should be possible to find it by name: >>> import logging >>> logging.getLogger().name ="." >>> logging.warning("I am root") WARNING:.:I am root >>> unknown = logging.getLogger(".") >>> unknown.warning("Who am I?") WARNING:.:Who am I? >>> unknown == logging.getLogger() False In fact: >>> import logging >>> logging.getLogger() == logging.getLogger() #just a test True >>> logging.getLogger() == logging.getLogger("root") #should be same! False This is not an easy module to understand, but it's amazingly powerful. One last suggestion. You have logging.handlers. You could also have logging.filters. For example: class Opaque(Filter): """A simple way to prevent any messages from getting through.""" def __init__(self, name=None): pass def filter(self, rec): return False class Unique(Filter): """Messages are allowed through just once. The 'message' includes substitutions, but is not formatted by the handler. If it were, then practically all messages would be unique! """ def __init__(self, name=""): Filter.__init__(self, name) self.reset() def reset(self): """Act as if nothing has happened.""" self.__logged = {} def filter(self, rec): return Filter.filter(self, rec) and self.__is_first_time(rec) def __is_first_time(self, rec): """Emit a message only once.""" msg = rec.msg %(rec.args) if msg in self.__logged: self.__logged[msg] += 1 return False else: self.__logged[msg] = 1 return True Actually, this might be Cookbook material. I'll write it up. Thanks for your time. -cxdunn ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2005-04-28 02:43 Message: Logged In: YES user_id=308438 Whoops! I don't quite know what happened, but I think both of us were updating this RFE entry concurrently. I only saw your followup starting "Novices always ask..." before I posted my response. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2005-04-28 02:36 Message: Logged In: YES user_id=308438 Logger names are hierarchical with dots separating levels in the hierarchy. So to me it does not make sense to have logger names which end in a dot, and you have given no reason why trailing dots should be supported. However, the hierarchy is not completely anologous to file system hierarchies - there is by design no concept of a "default" or "current" logger. I do not propose to make a change to this. However, I agree that the name of the root logger being "root" might be seen as unintuitive by some. Of your alternatives I think "logging" is best. I propose to add to the documentation the suggestion that users can define their own name for the root logger as in the following example: logging.getLogger().name = "myapp" People who use the root logger directly typically don't use other (named) loggers, because the whole point of using named loggers is to pinpoint areas of the application. Those users who use the root logger directly are typically not interested in finer granularity than the application or script itself. ---------------------------------------------------------------------- Comment By: Christopher Dunn (cxdunn) Date: 2005-04-28 02:29 Message: Logged In: YES user_id=1267419 Oops. Where I wrote abspath.rstrip('.'), I meant abspath.strip('.') Drop both leading and trailing dots for the prettified path. -cdunn ---------------------------------------------------------------------- Comment By: Christopher Dunn (cxdunn) Date: 2005-04-28 02:21 Message: Logged In: YES user_id=1267419 I am attaching a first pass it it. I've stored the "absolute" names everywhere, including both leading and trailing '.' I call this "absolute" by analogy with os.path.abspath(). I believe that similarities within the Python library help the user remember key concepts. What's missing: * I don't have aliases. * The "current working logger" is always '.' * And I haven't added any extra tags for the Formatter. But those are all very simple changes. The tough part is getting the path-searching correct. I have a big UnitTest suite which I can send to you if you'd like. The most important thing is that the word "root" is completely gone, but perhaps %(name)s should translate '.' to 'root' for backwards compatibility. The second-most important thing is that getLogger('.') returns the root logger. Third is that getLogger("Package.Module") is equivalent to getLogger(".Package.Module.") As for tags in the Formatter, after some testing I suggest these: %(name)s => abspath.rstrip('.'), but "." becomes "root" %(absname)s => abspath, with leading AND trailing dot, like a directory, so there is no question about whether the root displays as "." or "". It is always just dot in absolute notation. %(logger)s => abspath.rstrip('.'), maybe the prettiest I must tell you that, once I figured out how the logging module works, I really love it! Other possible additions: * Some useful, predefined filter classes: Never, OneTime (which must have a reset() method to clear its cache). I can send my version if you want. * A PipedStreamHandler. I'm not sure how to make this work. The idea is that, in UnitTesting, I want to read from some stream immediately after an operation, and I want the logged data to be immediately available, but to disappear as soon as I've read it. Does that make sense? Right now, I use a cStringIO object, with s.seek(0); s.truncate() after every read. -cxdunn ---------------------------------------------------------------------- Comment By: Christopher Dunn (cxdunn) Date: 2005-04-27 15:37 Message: Logged In: YES user_id=1267419 Novices always ask, "Why did it print 'root'? Where did that come from? After discussing this with some other "logging" module users, I think we've come up with a very good idea, which would maintain BACKWARDS COMPATIBILITY. Essentially, treat the logging module as a shell and the logger name as a path. Specifically, * Let the global logging functions operate on the "current worrking logger", which by default is "." (Let "root" be an alias for ".") * Change getLogger() so that it works on both absolute and relative logger paths. (Since the default current logger is "root", we maintain backwards compatibility.) * Change the format function so that %(name)s shows the relative path, if the absolute path starts with the current working logger name. * Add a format keyword, %(absname)s, which prints the absolute logger path. * Add another format keyword, %(logger)s, which prints what most people expect to see: the absolute logger name, sans the leading dot. (The "root" or "." logger would display as "", exactly the way it is usually accessed.) * Add global functions, change_current_logger() and get_current_logger(). * Add global function, alias(). Always create an alias for "root" to "." Examples:: from logging import * log = getLogger() #or getLogger(".") or getLogger("root") h1 = StreamHandler() f1 = Formatter("[%(name)s]%(message)s") h1.setFormatter(f1) log.addHandler(h1) h2 = StreamHandler() f2 = Formatter("[%(absname)s]%(message)s") h2.setFormatter(f2) log.addHandler(h2) h3 = StreamHandler() f3 = Formatter("[%(logger)s]%(message)s") h3.setFormatter(f3) log.addHandler(h3) log.error("First message") # ... child = getLogger("child") # or getLogger(".child") child.error("Bad news") This should print: [root]First message [.]First message []First message [child]Bad news [.child]Bad news [child]Bad news This would create tremendous flexibility, add some clarity to the meaning of the "root" logger, and still maintain complete backwards compatibility. I am willing to make the changes myself, including UnitTests, if there is agreement that they would be adopted. (Note that String.before() and String.after() would make the coding a little easier/clearer, but that's a different feature request.) -cxdunn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190689&group_id=5470 From noreply at sourceforge.net Wed May 4 15:34:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 May 2005 06:34:30 -0700 Subject: [ python-Bugs-1194209 ] Error in section 4.2 of Python Tutorial Message-ID: Bugs item #1194209, was opened at 2005-05-02 23:02 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194209&group_id=5470 Category: Documentation Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 3 Submitted By: Andrina Kelly (andrina) Assigned to: Nobody/Anonymous (nobody) Summary: Error in section 4.2 of Python Tutorial Initial Comment: The example in section 4.2 of the on-line tutorial should read as follows: >>> # Measure some strings: ... a = ['cat', 'window', 'defenestrate'] >>> for x in a: ... print x, len(a) ... cat 3 window 6 defenestrate 12 currently the print line has len(x) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-04 08:34 Message: Logged In: YES user_id=80475 Sorry, this is correct as is. I'm not sure why you would think that len(a) is appropriate. That would give the length of the list which is always equal to three. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194209&group_id=5470 From noreply at sourceforge.net Wed May 4 18:18:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 May 2005 09:18:01 -0700 Subject: [ python-Bugs-849046 ] gzip.GzipFile is slow Message-ID: Bugs item #849046, was opened at 2003-11-25 09:45 Message generated for change (Comment added) made by marumari You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=849046&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 3 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: gzip.GzipFile is slow Initial Comment: gzip.GzipFile is significantly (an order of a magnitude) slower than using the gzip binary. I've been bitten by this several times, and have replaced "fd = gzip.open('somefile', 'r')" by "fd = os.popen('gzcat somefile', 'r')" on several occassions. Would a patch that implemented GzipFile in C have any change of being accepted? ---------------------------------------------------------------------- Comment By: April King (marumari) Date: 2005-05-04 11:18 Message: Logged In: YES user_id=747439 readlines(X) is even worse, as all it does is call readline() X times. readline() is also biased towards files where each line is less than 100 characters: readsize = min(100, size) So, if it's longer than that, it calls read, which calls _read, and so on. I've found using popen to be roughly 20x faster than using the gzip module. That's pretty bad. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2003-12-28 10:25 Message: Logged In: YES user_id=580910 Leaving out the assignment sure sped thing up, but only because the input didn't contain lines anymore ;-) I did an experiment where I replaced self.extrabuf by a list, but that did slow things down. This may be because there seemed to be very few chunks in the buffer (most of the time just 2) According to profile.run('testit()') the function below spends about 50% of its time in the readline method: def testit() fd = gzip.open('testfile.gz', 'r') ln = fd.readline() cnt = bcnt = 0 while ln: ln = fd.readline() cnt += 1 bcnt += len(ln) print bcnt, cnt return bcnt,cnt testfile.gz is a simple textfile containing 40K lines of about 70 characters each. Replacing the 'buffers' in readline by a string (instead of a list) slightly speeds things up (about 10%). Other experiments did not bring any improvement. Even writing a simple C function to split the buffer returned by self.read() didn't help a lot (splitline(strval, max) -> match, rest, match is strval upto the first newline and at most max characters, rest is the rest of strval). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-12-23 11:10 Message: Logged In: YES user_id=11375 It should be simple to check if the string operations are responsible -- comment out the 'self.extrabuf = self.extrabuf + data' in _add_read_data. If that makes a big difference, then _read should probably be building a list instead of modifying a string. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-12-04 13:51 Message: Logged In: YES user_id=357491 Looking at GzipFile.read and ._read , I think a large chunk of time is burned in the decompression of small chunks of data. It initially reads and decompresses 1024 bits, and then if that read did not hit the EOF, it multiplies it by 2 and continues until the EOF is reached and then finishes up. The problem is that for each read a call to _read is made that sets up a bunch of objects. I would not be surprised if the object creation and teardown is hurting the performance. I would also not be surprised if the reading of small chunks of data is an initial problem as well. This is all guesswork, though, since I did not run the profiler on this. *But*, there might be a good reason for reading small chunks. If you are decompressing a large file, you might run out of memory very quickly by reading the file into memory *and* decompressing at the same time. Reading it in successively larger chunks means you don't hold the file's entire contents in memory at any one time. So the question becomes whether causing your memory to get overloaded and major thrashing on your swap space is worth the performance increase. There is also the option of inlining _read into 'read', but since it makes two calls that seems like poor abstraction and thus would most likely not be accepted as a solution. Might be better to just have some temporary storage in an attribute of objects that are used in every call to _read and then delete the attribute once the reading is done. Or maybe allow for an optional argument to read that allowed one to specify the initial read size (and that might be a good way to see if any of these ideas are reasonable; just modify the code to read the whole thing and go at it from that). But I am in no position to make any of these calls, though, since I never use gzip. If someone cares to write up a patch to try to fix any of this it will be considered. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2003-11-25 16:05 Message: Logged In: YES user_id=764593 In the library, I see a fair amount of work that doesn't really do anything except make sure you're getting exactly a line at a time. Would it be an option to just read the file in all at once, split it on newlines, and then loop over the list? (Or read it into a cStringIO, I suppose.) ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2003-11-25 15:12 Message: Logged In: YES user_id=580910 To be more precise: $ ls -l gzippedfile -rw-r--r-- 1 ronald admin 354581 18 Nov 10:21 gzippedfile $ gzip -l gzippedfile compressed uncompr. ratio uncompressed_name 354581 1403838 74.7% gzippedfile The file contains about 45K lines of text (about 40 characters/line) $ time gzip -dc gzippedfile > /dev/null real 0m0.100s user 0m0.060s sys 0m0.000s $ python read.py gzippedfile > /dev/null real 0m3.222s user 0m3.020s sys 0m0.070s $ cat read.py #!/usr/bin/env python import sys import gzip fd = gzip.open(sys.argv[1], 'r') ln = fd.readline() while ln: sys.stdout.write(ln) ln = fd.readline() The difference is also significant for larger files (e.g. the difference is not caused by the different startup-times) ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2003-11-25 15:03 Message: Logged In: YES user_id=580910 The files are created using GzipFile. That speed is acceptable because it happens in a batch-job, reading back is the problem because that happens on demand and a user is waiting for the results. gzcat is a *uncompress* utility (specifically it is "gzip -dc"), the compression level is irrelevant for this discussion. The python code seems to do quite some string manipulation, maybe that is causing the slowdown (I'm using fd.readline() in a fairly tight loop). I'll do some profiling to check what is taking so much time. BTW. I'm doing this on Unix systems (Sun Solaris and Mac OS X). ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2003-11-25 11:35 Message: Logged In: YES user_id=764593 Which compression level are you using? It looks like most of the work is already done by zlib (which is in C), but GzipFile defaults to compression level 9. Many other zips (including your gzcat?) default to a lower (but much faster) compression level. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=849046&group_id=5470 From noreply at sourceforge.net Thu May 5 00:12:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 May 2005 15:12:42 -0700 Subject: [ python-Bugs-1194497 ] ImportError: No module named os Message-ID: Bugs item #1194497, was opened at 2005-05-03 14:50 Message generated for change (Settings changed) made by diskman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194497&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None >Priority: 9 Submitted By: Will L G (diskman) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError: No module named os Initial Comment: Compiling on the following system: Redhat 7.2 [alpha] Kernel-2.6.11.4 Compaq C 6.5.9 GLIBC-2.3.2 Make-2.80 Binutils-2.15 Receiving the following error: /usr/share/printconf/util/queueTree.py:89: GtkWarning: gtk_label_set_use_underline: assertion `GTK_IS_LABEL (label)' failed domain = domain) Traceback (most recent call last): File "/usr/sbin/redhat-config-printer-gui", line 7, in ? import queueTree File "/usr/share/printconf/util/queueTree.py", line 1091, in ? queueTree() File "/usr/share/printconf/util/queueTree.py", line 128, in __init__ if cups_import.import_needed (): File "/usr/share/printconf/util/cups_import.py", line 200, in import_needed which = which_spooler () File "/usr/share/printconf/util/cups_import.py", line 195, in which_spooler return which UnboundLocalError: local variable 'which' referenced before assignment ---------------------------------------------------------------------- Comment By: Will L G (diskman) Date: 2005-05-03 14:53 Message: Logged In: YES user_id=312992 Whoops, did a cut and paste... the previous error was from printconfig... I was upgrading python to fix that and this is what I received from Python while building: [root at jericho Python-2.4.1]# make case $MAKEFLAGS in *-s*) LD_LIBRARY_PATH=/usr2/www/linux- related/programming/python/Python- 2.4.1:/usr/X11R6/lib:/usr/lib:/usr/local/lib CC='ccache ccc - pthread' LDSHARED='ccache ccc -pthread -shared' OPT='- DNDEBUG -O' ./python -E ./setup.py -q build;; *) LD_LIBRARY_PATH=/usr2/www/linux- related/programming/python/Python- 2.4.1:/usr/X11R6/lib:/usr/lib:/usr/local/lib CC='ccache ccc - pthread' LDSHARED='ccache ccc -pthread -shared' OPT='- DNDEBUG -O' ./python -E ./setup.py build;; esac Could not find platform independent libraries Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] 'import site' failed; use -v for traceback Traceback (most recent call last): File "./setup.py", line 6, in ? import sys, os, getopt, imp, re ImportError: No module named os make: *** [sharedmods] Error 1 [root at jericho Python-2.4.1]# ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194497&group_id=5470 From noreply at sourceforge.net Thu May 5 01:13:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 May 2005 16:13:15 -0700 Subject: [ python-Bugs-1195576 ] [AST] Patch [ 1190012 ] should've checked for SyntaxWarnings Message-ID: Bugs item #1195576, was opened at 2005-05-04 18:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1195576&group_id=5470 Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: [AST] Patch [ 1190012 ] should've checked for SyntaxWarnings Initial Comment: "[ 1190012 ] don't assume all errors are syntax errors" should also check allow SyntaxWarnings to pass. This is a one-line fix at around line 104 in ast_error_finish in ast.c. This causes the failure in test_warnings.py. Brett, If you really want a patch, I can get you one, but right now my copy of ast.c is a little too far out of sync to generate a clean patch. The fix is pretty trivial though. Let me know. -Grant ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1195576&group_id=5470 From noreply at sourceforge.net Thu May 5 01:13:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 May 2005 16:13:51 -0700 Subject: [ python-Bugs-1195576 ] [AST] Patch [ 1190012 ] should've checked for SyntaxWarnings Message-ID: Bugs item #1195576, was opened at 2005-05-04 18:13 Message generated for change (Settings changed) made by logistix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1195576&group_id=5470 Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) >Assigned to: Brett Cannon (bcannon) Summary: [AST] Patch [ 1190012 ] should've checked for SyntaxWarnings Initial Comment: "[ 1190012 ] don't assume all errors are syntax errors" should also check allow SyntaxWarnings to pass. This is a one-line fix at around line 104 in ast_error_finish in ast.c. This causes the failure in test_warnings.py. Brett, If you really want a patch, I can get you one, but right now my copy of ast.c is a little too far out of sync to generate a clean patch. The fix is pretty trivial though. Let me know. -Grant ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1195576&group_id=5470 From noreply at sourceforge.net Thu May 5 01:14:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 May 2005 16:14:53 -0700 Subject: [ python-Bugs-1190012 ] ``from sys import stdin, `` doesn't raise a SyntaxError Message-ID: Bugs item #1190012, was opened at 2005-04-26 01:11 Message generated for change (Comment added) made by logistix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190012&group_id=5470 Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: ``from sys import stdin,`` doesn't raise a SyntaxError Initial Comment: Python 2.4 raises a SyntaxError: "trailing comma not allowed without surrounding parentheses". Detected by test_compile. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2005-05-04 18:14 Message: Logged In: YES user_id=699438 Patch 1194895 fixes this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190012&group_id=5470 From noreply at sourceforge.net Thu May 5 17:38:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 May 2005 08:38:50 -0700 Subject: [ python-Bugs-1195984 ] SystemError: error return without exception set Message-ID: Bugs item #1195984, was opened at 2005-05-05 11:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1195984&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Niraj Bajpai (nbajpai) Assigned to: Nobody/Anonymous (nobody) Summary: SystemError: error return without exception set Initial Comment: I am getting following error with Python 2.4.1 relase: "SystemError: error return without exception set" my code works fine with earlier release (python 2.4). Its a C code build in python so does not leave much traces to describe problem more. Important Notes: Release name: 2.4.1(final) Platform: Solaris 2.8 Error: "SystemError: error return without exception set" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1195984&group_id=5470 From noreply at sourceforge.net Thu May 5 21:54:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 May 2005 12:54:00 -0700 Subject: [ python-Bugs-1196154 ] Error: ... ossaudiodev.c, line 48: Missing type specifier Message-ID: Bugs item #1196154, was opened at 2005-05-05 19:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196154&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Will L G (diskman) Assigned to: Nobody/Anonymous (nobody) Summary: Error: ... ossaudiodev.c, line 48: Missing type specifier Initial Comment: RedHat Linux 7.2 [alpha] Kernel 2.6.11.6 Compaq C 6.5.2 Binutils 2.15 Make 2.8 Was receiving the error below and then a few little changes to make the configure script think I was using gcc while still using ccc... [root at jericho Python-2.4.1]# make case $MAKEFLAGS in *-s*) LD_LIBRARY_PATH=/usr2/www/linux- related/programming/python/Python- 2.4.1:/usr/X11R6/lib:/usr/lib:/usr/local/lib CC='ccache ccc - pthread' LDSHARED='ccache ccc -pthread -shared' OPT='- DNDEBUG -O' ./python -E ./setup.py -q build;; *) LD_LIBRARY_PATH=/usr2/www/linux- related/programming/python/Python- 2.4.1:/usr/X11R6/lib:/usr/lib:/usr/local/lib CC='ccache ccc - pthread' LDSHARED='ccache ccc -pthread -shared' OPT='- DNDEBUG -O' ./python -E ./setup.py build;; esac Could not find platform independent libraries Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] 'import site' failed; use -v for traceback Traceback (most recent call last): File "./setup.py", line 6, in ? import sys, os, getopt, imp, re ImportError: No module named os make: *** [sharedmods] Error 1 [root at jericho Python-2.4.1]# Here is a copy of the little script I used to set the env to use ccc while configuring python to compile using gcc and thus build the appropriate extensions: ./configure --prefix=/usr --sysconfdir=/etc --build=alphapca56-alpha-linux-gnu --without-gcc --enable-shared --with-dec-threads --with-cxx="ccache cxx" --with-cc="ccache ccc" --without-threads make CC="ccache ccc" CXX="ccache cxx" CFLAGS="-O5 -fast -mtune=ev56 -w -pipe - lpthread -threads" CXXFLAGS="-O5 -fast -mtune=ev56 -w -pipe - lpthread -threads" EVERYTHING compiled fine but for one little thing, two extensions didn't compile: building 'ossaudiodev' extension ccache ccc -DNDEBUG -O -fPIC -OPT:Olimit=0 -I. - I/usr2/www/pub/alpha-RH7/programming/python/Python- 2.4.1/./Include -I/usr/local/include -I/usr2/www/pub/alpha- RH7/programming/python/Python-2.4.1/Include - I/usr2/www/pub/alpha-RH7/programming/python/Python- 2.4.1 -c /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c -o build/temp.linux-alpha- 2.4/ossaudiodev.o cc: Error: /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c, line 48: Missing type specifier or type qualifier. (missingtype) PyObject_HEAD; -----------------^ cc: Error: /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c, line 57: Missing type specifier or type qualifier. (missingtype) PyObject_HEAD; -----------------^ ccache ccc -DNDEBUG -O -fPIC -OPT:Olimit=0 -I. - I/usr2/www/pub/alpha-RH7/programming/python/Python- 2.4.1/./Include -I/usr/local/include -I/usr2/www/pub/alpha- RH7/programming/python/Python-2.4.1/Include - I/usr2/www/pub/alpha-RH7/programming/python/Python- 2.4.1 -c /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c -o build/temp.linux-alpha- 2.4/ossaudiodev.o cc: Error: /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c, line 48: Missing type specifier or type qualifier. (missingtype) PyObject_HEAD; -----------------^ cc: Error: /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c, line 57: Missing type specifier or type qualifier. (missingtype) PyObject_HEAD; -----------------^ cc: Info: /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/./Include/objimpl.h, line 255: In this declaration, type long double has the same representation as type double on this platform. (longdoublenyi) long double dummy; /* force worst-case alignment */ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196154&group_id=5470 From noreply at sourceforge.net Thu May 5 21:54:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 May 2005 12:54:31 -0700 Subject: [ python-Bugs-1196154 ] Error: ... ossaudiodev.c, line 48: Missing type specifier Message-ID: Bugs item #1196154, was opened at 2005-05-05 19:53 Message generated for change (Settings changed) made by diskman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196154&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None >Priority: 7 Submitted By: Will L G (diskman) Assigned to: Nobody/Anonymous (nobody) Summary: Error: ... ossaudiodev.c, line 48: Missing type specifier Initial Comment: RedHat Linux 7.2 [alpha] Kernel 2.6.11.6 Compaq C 6.5.2 Binutils 2.15 Make 2.8 Was receiving the error below and then a few little changes to make the configure script think I was using gcc while still using ccc... [root at jericho Python-2.4.1]# make case $MAKEFLAGS in *-s*) LD_LIBRARY_PATH=/usr2/www/linux- related/programming/python/Python- 2.4.1:/usr/X11R6/lib:/usr/lib:/usr/local/lib CC='ccache ccc - pthread' LDSHARED='ccache ccc -pthread -shared' OPT='- DNDEBUG -O' ./python -E ./setup.py -q build;; *) LD_LIBRARY_PATH=/usr2/www/linux- related/programming/python/Python- 2.4.1:/usr/X11R6/lib:/usr/lib:/usr/local/lib CC='ccache ccc - pthread' LDSHARED='ccache ccc -pthread -shared' OPT='- DNDEBUG -O' ./python -E ./setup.py build;; esac Could not find platform independent libraries Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] 'import site' failed; use -v for traceback Traceback (most recent call last): File "./setup.py", line 6, in ? import sys, os, getopt, imp, re ImportError: No module named os make: *** [sharedmods] Error 1 [root at jericho Python-2.4.1]# Here is a copy of the little script I used to set the env to use ccc while configuring python to compile using gcc and thus build the appropriate extensions: ./configure --prefix=/usr --sysconfdir=/etc --build=alphapca56-alpha-linux-gnu --without-gcc --enable-shared --with-dec-threads --with-cxx="ccache cxx" --with-cc="ccache ccc" --without-threads make CC="ccache ccc" CXX="ccache cxx" CFLAGS="-O5 -fast -mtune=ev56 -w -pipe - lpthread -threads" CXXFLAGS="-O5 -fast -mtune=ev56 -w -pipe - lpthread -threads" EVERYTHING compiled fine but for one little thing, two extensions didn't compile: building 'ossaudiodev' extension ccache ccc -DNDEBUG -O -fPIC -OPT:Olimit=0 -I. - I/usr2/www/pub/alpha-RH7/programming/python/Python- 2.4.1/./Include -I/usr/local/include -I/usr2/www/pub/alpha- RH7/programming/python/Python-2.4.1/Include - I/usr2/www/pub/alpha-RH7/programming/python/Python- 2.4.1 -c /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c -o build/temp.linux-alpha- 2.4/ossaudiodev.o cc: Error: /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c, line 48: Missing type specifier or type qualifier. (missingtype) PyObject_HEAD; -----------------^ cc: Error: /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c, line 57: Missing type specifier or type qualifier. (missingtype) PyObject_HEAD; -----------------^ ccache ccc -DNDEBUG -O -fPIC -OPT:Olimit=0 -I. - I/usr2/www/pub/alpha-RH7/programming/python/Python- 2.4.1/./Include -I/usr/local/include -I/usr2/www/pub/alpha- RH7/programming/python/Python-2.4.1/Include - I/usr2/www/pub/alpha-RH7/programming/python/Python- 2.4.1 -c /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c -o build/temp.linux-alpha- 2.4/ossaudiodev.o cc: Error: /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c, line 48: Missing type specifier or type qualifier. (missingtype) PyObject_HEAD; -----------------^ cc: Error: /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c, line 57: Missing type specifier or type qualifier. (missingtype) PyObject_HEAD; -----------------^ cc: Info: /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/./Include/objimpl.h, line 255: In this declaration, type long double has the same representation as type double on this platform. (longdoublenyi) long double dummy; /* force worst-case alignment */ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196154&group_id=5470 From noreply at sourceforge.net Thu May 5 21:55:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 May 2005 12:55:31 -0700 Subject: [ python-Bugs-1194497 ] ImportError: No module named os Message-ID: Bugs item #1194497, was opened at 2005-05-03 14:50 Message generated for change (Comment added) made by diskman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194497&group_id=5470 Category: Build Group: Python 2.4 Status: Open >Resolution: Duplicate Priority: 9 Submitted By: Will L G (diskman) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError: No module named os Initial Comment: Compiling on the following system: Redhat 7.2 [alpha] Kernel-2.6.11.4 Compaq C 6.5.9 GLIBC-2.3.2 Make-2.80 Binutils-2.15 Receiving the following error: /usr/share/printconf/util/queueTree.py:89: GtkWarning: gtk_label_set_use_underline: assertion `GTK_IS_LABEL (label)' failed domain = domain) Traceback (most recent call last): File "/usr/sbin/redhat-config-printer-gui", line 7, in ? import queueTree File "/usr/share/printconf/util/queueTree.py", line 1091, in ? queueTree() File "/usr/share/printconf/util/queueTree.py", line 128, in __init__ if cups_import.import_needed (): File "/usr/share/printconf/util/cups_import.py", line 200, in import_needed which = which_spooler () File "/usr/share/printconf/util/cups_import.py", line 195, in which_spooler return which UnboundLocalError: local variable 'which' referenced before assignment ---------------------------------------------------------------------- >Comment By: Will L G (diskman) Date: 2005-05-05 19:55 Message: Logged In: YES user_id=312992 Duplicate of BugReport 1196154 ---------------------------------------------------------------------- Comment By: Will L G (diskman) Date: 2005-05-03 14:53 Message: Logged In: YES user_id=312992 Whoops, did a cut and paste... the previous error was from printconfig... I was upgrading python to fix that and this is what I received from Python while building: [root at jericho Python-2.4.1]# make case $MAKEFLAGS in *-s*) LD_LIBRARY_PATH=/usr2/www/linux- related/programming/python/Python- 2.4.1:/usr/X11R6/lib:/usr/lib:/usr/local/lib CC='ccache ccc - pthread' LDSHARED='ccache ccc -pthread -shared' OPT='- DNDEBUG -O' ./python -E ./setup.py -q build;; *) LD_LIBRARY_PATH=/usr2/www/linux- related/programming/python/Python- 2.4.1:/usr/X11R6/lib:/usr/lib:/usr/local/lib CC='ccache ccc - pthread' LDSHARED='ccache ccc -pthread -shared' OPT='- DNDEBUG -O' ./python -E ./setup.py build;; esac Could not find platform independent libraries Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] 'import site' failed; use -v for traceback Traceback (most recent call last): File "./setup.py", line 6, in ? import sys, os, getopt, imp, re ImportError: No module named os make: *** [sharedmods] Error 1 [root at jericho Python-2.4.1]# ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194497&group_id=5470 From noreply at sourceforge.net Fri May 6 03:59:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 May 2005 18:59:22 -0700 Subject: [ python-Bugs-1196315 ] WeakValueDictionary.__init__ is backwards Message-ID: Bugs item #1196315, was opened at 2005-05-05 18:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196315&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Pavel Pergamenshchik (ppergame) Assigned to: Nobody/Anonymous (nobody) Summary: WeakValueDictionary.__init__ is backwards Initial Comment: >>> from weakref import WeakValueDictionary as wvd >>> class A: ... pass ... >>> wvd({1:A()}) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/weakref.py", line 46, in __init__ UserDict.UserDict.__init__(self, *args, **kw) File "/usr/lib/python2.4/UserDict.py", line 7, in __init__ self.update(dict) File "/usr/lib/python2.4/weakref.py", line 161, in update d[key] = KeyedRef(o, self._remove, key) AttributeError: WeakValueDictionary instance has no attribute '_remove' WeakValueDictionary.__init__ calls UserDict.__init__ first and sets self._remove second. It should do it the other way around. This is a regression from 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196315&group_id=5470 From noreply at sourceforge.net Fri May 6 13:45:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 May 2005 04:45:03 -0700 Subject: [ python-Bugs-1195984 ] SystemError: error return without exception set Message-ID: Bugs item #1195984, was opened at 2005-05-05 16:38 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1195984&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Niraj Bajpai (nbajpai) Assigned to: Nobody/Anonymous (nobody) Summary: SystemError: error return without exception set Initial Comment: I am getting following error with Python 2.4.1 relase: "SystemError: error return without exception set" my code works fine with earlier release (python 2.4). Its a C code build in python so does not leave much traces to describe problem more. Important Notes: Release name: 2.4.1(final) Platform: Solaris 2.8 Error: "SystemError: error return without exception set" ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-05-06 12:45 Message: Logged In: YES user_id=6656 Uh, there's not a lot to go on here. Can you post some code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1195984&group_id=5470 From noreply at sourceforge.net Fri May 6 21:46:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 May 2005 12:46:05 -0700 Subject: [ python-Bugs-1196824 ] string.rstrip strips more than supposed to in some cases Message-ID: Bugs item #1196824, was opened at 2005-05-06 15:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196824&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Francois Payette (headgasket-) Assigned to: Nobody/Anonymous (nobody) Summary: string.rstrip strips more than supposed to in some cases Initial Comment: import string lfile = "test.zip.gpg" print lfile lfile = lfile.rstrip(".gpg") print lfile should result in the same thing as: lfile = "test.zip.gpg" print lfile lfile = lfile.rstrip("gpg") lfile = lfile.rstrip(".") print lfile but it does not ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196824&group_id=5470 From noreply at sourceforge.net Fri May 6 21:46:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 May 2005 12:46:40 -0700 Subject: [ python-Bugs-1196824 ] string.rstrip strips more than supposed to in some cases Message-ID: Bugs item #1196824, was opened at 2005-05-06 15:46 Message generated for change (Comment added) made by headgasket- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196824&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Francois Payette (headgasket-) Assigned to: Nobody/Anonymous (nobody) Summary: string.rstrip strips more than supposed to in some cases Initial Comment: import string lfile = "test.zip.gpg" print lfile lfile = lfile.rstrip(".gpg") print lfile should result in the same thing as: lfile = "test.zip.gpg" print lfile lfile = lfile.rstrip("gpg") lfile = lfile.rstrip(".") print lfile but it does not ---------------------------------------------------------------------- >Comment By: Francois Payette (headgasket-) Date: 2005-05-06 15:46 Message: Logged In: YES user_id=1273811 version 2.4.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196824&group_id=5470 From noreply at sourceforge.net Fri May 6 21:53:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 May 2005 12:53:55 -0700 Subject: [ python-Bugs-1196824 ] string.rstrip strips more than supposed to in some cases Message-ID: Bugs item #1196824, was opened at 2005-05-06 19:46 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196824&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Francois Payette (headgasket-) Assigned to: Nobody/Anonymous (nobody) Summary: string.rstrip strips more than supposed to in some cases Initial Comment: import string lfile = "test.zip.gpg" print lfile lfile = lfile.rstrip(".gpg") print lfile should result in the same thing as: lfile = "test.zip.gpg" print lfile lfile = lfile.rstrip("gpg") lfile = lfile.rstrip(".") print lfile but it does not ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2005-05-06 19:53 Message: Logged In: YES user_id=849994 This is not a bug. The argument to rstrip is a string that contains the individual characters that are to be removed. They can occur in any order and quantity at the end of the string. ---------------------------------------------------------------------- Comment By: Francois Payette (headgasket-) Date: 2005-05-06 19:46 Message: Logged In: YES user_id=1273811 version 2.4.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196824&group_id=5470 From noreply at sourceforge.net Fri May 6 22:01:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 May 2005 13:01:09 -0700 Subject: [ python-Bugs-1195576 ] [AST] Patch [ 1190012 ] should've checked for SyntaxWarnings Message-ID: Bugs item #1195576, was opened at 2005-05-04 16:13 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1195576&group_id=5470 Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Brett Cannon (bcannon) Summary: [AST] Patch [ 1190012 ] should've checked for SyntaxWarnings Initial Comment: "[ 1190012 ] don't assume all errors are syntax errors" should also check allow SyntaxWarnings to pass. This is a one-line fix at around line 104 in ast_error_finish in ast.c. This causes the failure in test_warnings.py. Brett, If you really want a patch, I can get you one, but right now my copy of ast.c is a little too far out of sync to generate a clean patch. The fix is pretty trivial though. Let me know. -Grant ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-05-06 13:01 Message: Logged In: YES user_id=357491 I shouldn't need a patch, but it might be a little while until I get to this. I am down to the last couple of weeks of the quarter and I am racing to get my masters thesis done before I graduate. Plus a quick recompile the other night under gcc 4 led to a ton of errors for me (hoping it was just a fluke; something about sem_init() ). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1195576&group_id=5470 From noreply at sourceforge.net Fri May 6 23:17:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 May 2005 14:17:06 -0700 Subject: [ python-Bugs-1196824 ] string.rstrip strips more than supposed to in some cases Message-ID: Bugs item #1196824, was opened at 2005-05-06 15:46 Message generated for change (Comment added) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196824&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Francois Payette (headgasket-) Assigned to: Nobody/Anonymous (nobody) Summary: string.rstrip strips more than supposed to in some cases Initial Comment: import string lfile = "test.zip.gpg" print lfile lfile = lfile.rstrip(".gpg") print lfile should result in the same thing as: lfile = "test.zip.gpg" print lfile lfile = lfile.rstrip("gpg") lfile = lfile.rstrip(".") print lfile but it does not ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2005-05-06 17:17 Message: Logged In: YES user_id=7733 Agreed, this is not a bug. Closing bug report. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2005-05-06 15:53 Message: Logged In: YES user_id=849994 This is not a bug. The argument to rstrip is a string that contains the individual characters that are to be removed. They can occur in any order and quantity at the end of the string. ---------------------------------------------------------------------- Comment By: Francois Payette (headgasket-) Date: 2005-05-06 15:46 Message: Logged In: YES user_id=1273811 version 2.4.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196824&group_id=5470 From noreply at sourceforge.net Fri May 6 23:19:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 May 2005 14:19:02 -0700 Subject: [ python-Bugs-1196824 ] string.rstrip strips more than supposed to in some cases Message-ID: Bugs item #1196824, was opened at 2005-05-06 15:46 Message generated for change (Comment added) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196824&group_id=5470 Category: None Group: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: Francois Payette (headgasket-) Assigned to: Nobody/Anonymous (nobody) Summary: string.rstrip strips more than supposed to in some cases Initial Comment: import string lfile = "test.zip.gpg" print lfile lfile = lfile.rstrip(".gpg") print lfile should result in the same thing as: lfile = "test.zip.gpg" print lfile lfile = lfile.rstrip("gpg") lfile = lfile.rstrip(".") print lfile but it does not ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2005-05-06 17:19 Message: Logged In: YES user_id=7733 BTW, one way to do what you want is: if lfile.endswith('.gpg'): lfile = lfile(:-4) ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2005-05-06 17:17 Message: Logged In: YES user_id=7733 Agreed, this is not a bug. Closing bug report. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2005-05-06 15:53 Message: Logged In: YES user_id=849994 This is not a bug. The argument to rstrip is a string that contains the individual characters that are to be removed. They can occur in any order and quantity at the end of the string. ---------------------------------------------------------------------- Comment By: Francois Payette (headgasket-) Date: 2005-05-06 15:46 Message: Logged In: YES user_id=1273811 version 2.4.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196824&group_id=5470 From noreply at sourceforge.net Sat May 7 03:08:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 May 2005 18:08:31 -0700 Subject: [ python-Bugs-1196980 ] trivial bug in error message text Message-ID: Bugs item #1196980, was opened at 2005-05-06 21:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196980&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Shute (jshute) Assigned to: Nobody/Anonymous (nobody) 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=105470&aid=1196980&group_id=5470 From noreply at sourceforge.net Sat May 7 15:00:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 May 2005 06:00:16 -0700 Subject: [ python-Bugs-815668 ] test_locale and en_US Message-ID: Bugs item #815668, was opened at 2003-10-01 17:28 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815668&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: test_locale and en_US Initial Comment: Is it worth making test_locale try first "en_US", then "C", as locale names? None of the systems I've tried have "en_US" as a valid locale. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2005-05-07 23:00 Message: Logged In: YES user_id=29957 I just submitted a patch http://www.python.org/sf/1197218 that makes test_locale try each of en_US.UTF-8, en_US.US-ASCII and en_US in turn. ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-11-03 06:56 Message: Logged In: YES user_id=60314 hmmm -- my Linux Mandrake 9.1 does succeed happily with en_US (and on Windows we already use 'en' instead). What systems have you tried, Anthony? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 23:30 Message: Logged In: YES user_id=21627 That would be incorrect. The test whether there is grouping in numeric formatting. However, in the C locale, there is no grouping. Most systems should have an English locale - it might have a different name, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815668&group_id=5470 From noreply at sourceforge.net Sun May 8 21:35:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 May 2005 12:35:28 -0700 Subject: [ python-Bugs-1197806 ] % gives wrong results Message-ID: Bugs item #1197806, was opened at 2005-05-08 19:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1197806&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jonathan (nathanoj) Assigned to: Nobody/Anonymous (nobody) Summary: % gives wrong results Initial Comment: when playing with % i got 5 % -3 = -1 This occured on the windows python 2.3 build, and a python 2.4.1 build on a linux pc (with gcc 3.3.5) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1197806&group_id=5470 From noreply at sourceforge.net Sun May 8 22:08:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 May 2005 13:08:05 -0700 Subject: [ python-Bugs-1197806 ] % gives wrong results Message-ID: Bugs item #1197806, was opened at 2005-05-08 20:35 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1197806&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jonathan (nathanoj) Assigned to: Nobody/Anonymous (nobody) Summary: % gives wrong results Initial Comment: when playing with % i got 5 % -3 = -1 This occured on the windows python 2.3 build, and a python 2.4.1 build on a linux pc (with gcc 3.3.5) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-05-08 21:08 Message: Logged In: YES user_id=6656 Why do you think this is a bug? On http://docs.python.org/ref/binary.html we find: The modulo operator always yields a result with the same sign as its second operand (or zero); the absolute value of the result is strictly smaller than the absolute value of the second operand. Closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1197806&group_id=5470 From noreply at sourceforge.net Mon May 9 00:56:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 May 2005 15:56:35 -0700 Subject: [ python-Bugs-1197883 ] Installation path sent to configure Message-ID: Bugs item #1197883, was opened at 2005-05-09 00:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1197883&group_id=5470 Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Installation path sent to configure Initial Comment: This is a minor problem but it makes some regression tests that rely upon Python's installation path to fail. $ ./configure --prefix=/opt/ All Python stuff will be installed with an extra '/'. /opt//bin/python /opt//lib/python2.5 etc. Not good. Configure or some other installation script should recognise the redundant '/' and strip it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1197883&group_id=5470 From noreply at sourceforge.net Mon May 9 14:07:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 May 2005 05:07:14 -0700 Subject: [ python-Bugs-686667 ] os.spawnv(P_WAIT, ...) on Linux doesn't handle EINTR Message-ID: Bugs item #686667, was opened at 2003-02-14 17:47 Message generated for change (Comment added) made by markmc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=686667&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bernhard Herzog (bernhard) Assigned to: Nobody/Anonymous (nobody) Summary: os.spawnv(P_WAIT, ...) on Linux doesn't handle EINTR Initial Comment: The implementation of os.spawnv when called with the P_WAIT flag calls waitpid to wait for the subprocess. If this function is aborted early because of a signal, i.e. if it raises OSError with EINTR, it should be called again. I ran across this bug when trying to write a test case for a script that stops another process. Both the script and the other process are executed as subprocesses of the test program. The stop script is executed with os.spawnv(P_WAIT, ...) to wait until the script completed. Unfortunately when it stops the other process a SIGCHLD is sent to the test program which then aborts the waitpid with an exception. Tested with Python 2.1.3, 2.2 and CVS from 2003-02-13 Platform: Debian GNU/Linux, Kernel 2.4.20 ---------------------------------------------------------------------- Comment By: Mark Mc Loughlin (markmc) Date: 2005-05-09 13:07 Message: Logged In: YES user_id=116392 Seeing this on Ubuntu with Sabayon (www.gnome.org/projects/sabayon): http://bugzilla.gnome.org/show_bug.cgi?id=303034 Python version is 2.4.1 This is particularily painful because there's no way to get the PID of the process which waitpid was wating on when it was interrupted, so there's no way to reap the child ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=686667&group_id=5470 From noreply at sourceforge.net Mon May 9 15:14:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 May 2005 06:14:51 -0700 Subject: [ python-Bugs-1198275 ] time module ignores timezone changes Message-ID: Bugs item #1198275, was opened at 2005-05-09 08:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1198275&group_id=5470 Category: Extension Modules Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Lambert (jdalambert) Assigned to: Nobody/Anonymous (nobody) Summary: time module ignores timezone changes Initial Comment: Running on Fedora Core 3 Linux Consider the simple program import time while 1: print time.localtime() time.sleep(1) The tuple printed by this program does not reflect any change in the system timezone until the interpreter is exited and restarted. Using reload(time) does not fix the problem. Are there any workarounds? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1198275&group_id=5470 From noreply at sourceforge.net Mon May 9 22:10:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 May 2005 13:10:46 -0700 Subject: [ python-Bugs-1177964 ] Iterator on Fileobject gives no MemoryError Message-ID: Bugs item #1177964, was opened at 2005-04-06 19:55 Message generated for change (Settings changed) made by zypher You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177964&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None >Priority: 7 Submitted By: Folke Lemaitre (zypher) Assigned to: Nobody/Anonymous (nobody) Summary: Iterator on Fileobject gives no MemoryError Initial Comment: The following problem has only been tested on linux. Suppose at a certain time that your machine can allocate a maximum of X megabytes of memory. Allocating more than X should result in python MemoryErrors. Also suppose you have a file containing one big line taking more than X bytes (Large binary file for example). In this case, if you read lines from a file through the file objects iterator, you do NOT get the expected MemoryError as result, but an empty list. To reproduce, create a file twice as big as your machines memory and disable the swap. If you run the following code: # import os.path # # def test(input): # print "Testing %s (%sMB)"%(repr(input), os.path.getsize(input)/(1024.0*1024.0)) # count = 0 # for line in open(input): # count = count + 1 # print " >> Total Number of Lines: %s"%count # # if __name__ == "__main__": # test('test.small') # test('test.big') you'll get something like: # folke at wladimir devel $ python2.4 bug.py # Testing 'test.small' (20.0MB) # >> Total Number of Lines: 1 # Testing 'test.big' (2000.0MB) # >> Total Number of Lines: 0 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177964&group_id=5470 From noreply at sourceforge.net Mon May 9 22:55:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 May 2005 13:55:26 -0700 Subject: [ python-Bugs-1198569 ] string.Template not flexible enough to subclass (regexes) Message-ID: Bugs item #1198569, was opened at 2005-05-09 15:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1198569&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ian Bicking (ianbicking) Assigned to: Nobody/Anonymous (nobody) Summary: string.Template not flexible enough to subclass (regexes) Initial Comment: The regular expressions in string.Template can be overidden, but there's not an easy way to override the expression for variables inside braces and to a different expression than variables not in braces. E.g., you might allow full expressions in braces (including arbitrary punctuation), but only normal variable names outside. An example of using this kind of technique: http://svn.colorstudy.com/home/ianb/recipes/sub_expr.py So, in summary, idpattern should be split into two, idpattern and bracepattern. (Maybe a default of None for bracepattern, and use idpattern if bracepattern is None -- this would be backward compatible so that overriding only idpattern will effect both) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1198569&group_id=5470 From noreply at sourceforge.net Tue May 10 04:46:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 May 2005 19:46:19 -0700 Subject: [ python-Bugs-1155638 ] self.length shield exception in httplib Message-ID: Bugs item #1155638, was opened at 2005-03-03 02:22 Message generated for change (Comment added) made by euske You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155638&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew P. Lentvorski, Jr. (bsder) Assigned to: Nobody/Anonymous (nobody) Summary: self.length shield exception in httplib Initial Comment: Under certain conditions (I'm trying to open a Shoutcast stream), I wind up with the following exception from httplib: Traceback (most recent call last): File "/home/devel/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "avalanche.py", line 86, in run streamData = streamResponse.read(256) File "/home/devel/lib/python2.4/httplib.py", line 478, in read self.length -= len(s) TypeError: unsupported operand type(s) for -=: 'str' and 'int' Normally, self.length has many shields of the form "if self.length is None:"; however, self.length gets initialize to _UNKNOWN which is the string "UNKNOWN" rather than None. As such, all of the shields are useless. Am I using a deprecated library or something? I'm really surprised no one else has bumped into this. ---------------------------------------------------------------------- Comment By: Yusuke Shinyama (euske) Date: 2005-05-09 22:46 Message: Logged In: YES user_id=385990 I did bump into the same problem. Apparently when I got HTTP/0.9 connection, self.length is not initialized. Inserting a line into l.362 at httplib.py (v2.4) seems to solve this problem. I will also post a patch: if self.version == 9: self.chunked = 0 self.will_close = 1 self.msg = HTTPMessage(StringIO()) + self.length = None return ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155638&group_id=5470 From noreply at sourceforge.net Tue May 10 05:08:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 May 2005 20:08:41 -0700 Subject: [ python-Feature Requests-1198569 ] string.Template not flexible enough to subclass (regexes) Message-ID: Feature Requests item #1198569, was opened at 2005-05-09 15:55 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1198569&group_id=5470 >Category: Python Library >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ian Bicking (ianbicking) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: string.Template not flexible enough to subclass (regexes) Initial Comment: The regular expressions in string.Template can be overidden, but there's not an easy way to override the expression for variables inside braces and to a different expression than variables not in braces. E.g., you might allow full expressions in braces (including arbitrary punctuation), but only normal variable names outside. An example of using this kind of technique: http://svn.colorstudy.com/home/ianb/recipes/sub_expr.py So, in summary, idpattern should be split into two, idpattern and bracepattern. (Maybe a default of None for bracepattern, and use idpattern if bracepattern is None -- this would be backward compatible so that overriding only idpattern will effect both) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1198569&group_id=5470 From noreply at sourceforge.net Tue May 10 05:09:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 May 2005 20:09:29 -0700 Subject: [ python-Bugs-1198275 ] time module ignores timezone changes Message-ID: Bugs item #1198275, was opened at 2005-05-09 08:14 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1198275&group_id=5470 Category: Extension Modules Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Lambert (jdalambert) >Assigned to: Brett Cannon (bcannon) Summary: time module ignores timezone changes Initial Comment: Running on Fedora Core 3 Linux Consider the simple program import time while 1: print time.localtime() time.sleep(1) The tuple printed by this program does not reflect any change in the system timezone until the interpreter is exited and restarted. Using reload(time) does not fix the problem. Are there any workarounds? ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-09 22:09 Message: Logged In: YES user_id=80475 Brett, are you still in the time business? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1198275&group_id=5470 From noreply at sourceforge.net Tue May 10 05:13:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 May 2005 20:13:14 -0700 Subject: [ python-Bugs-1194497 ] ImportError: No module named os Message-ID: Bugs item #1194497, was opened at 2005-05-03 09:50 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194497&group_id=5470 Category: Build Group: Python 2.4 >Status: Closed Resolution: Duplicate Priority: 9 Submitted By: Will L G (diskman) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError: No module named os Initial Comment: Compiling on the following system: Redhat 7.2 [alpha] Kernel-2.6.11.4 Compaq C 6.5.9 GLIBC-2.3.2 Make-2.80 Binutils-2.15 Receiving the following error: /usr/share/printconf/util/queueTree.py:89: GtkWarning: gtk_label_set_use_underline: assertion `GTK_IS_LABEL (label)' failed domain = domain) Traceback (most recent call last): File "/usr/sbin/redhat-config-printer-gui", line 7, in ? import queueTree File "/usr/share/printconf/util/queueTree.py", line 1091, in ? queueTree() File "/usr/share/printconf/util/queueTree.py", line 128, in __init__ if cups_import.import_needed (): File "/usr/share/printconf/util/cups_import.py", line 200, in import_needed which = which_spooler () File "/usr/share/printconf/util/cups_import.py", line 195, in which_spooler return which UnboundLocalError: local variable 'which' referenced before assignment ---------------------------------------------------------------------- Comment By: Will L G (diskman) Date: 2005-05-05 14:55 Message: Logged In: YES user_id=312992 Duplicate of BugReport 1196154 ---------------------------------------------------------------------- Comment By: Will L G (diskman) Date: 2005-05-03 09:53 Message: Logged In: YES user_id=312992 Whoops, did a cut and paste... the previous error was from printconfig... I was upgrading python to fix that and this is what I received from Python while building: [root at jericho Python-2.4.1]# make case $MAKEFLAGS in *-s*) LD_LIBRARY_PATH=/usr2/www/linux- related/programming/python/Python- 2.4.1:/usr/X11R6/lib:/usr/lib:/usr/local/lib CC='ccache ccc - pthread' LDSHARED='ccache ccc -pthread -shared' OPT='- DNDEBUG -O' ./python -E ./setup.py -q build;; *) LD_LIBRARY_PATH=/usr2/www/linux- related/programming/python/Python- 2.4.1:/usr/X11R6/lib:/usr/lib:/usr/local/lib CC='ccache ccc - pthread' LDSHARED='ccache ccc -pthread -shared' OPT='- DNDEBUG -O' ./python -E ./setup.py build;; esac Could not find platform independent libraries Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] 'import site' failed; use -v for traceback Traceback (most recent call last): File "./setup.py", line 6, in ? import sys, os, getopt, imp, re ImportError: No module named os make: *** [sharedmods] Error 1 [root at jericho Python-2.4.1]# ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194497&group_id=5470 From noreply at sourceforge.net Tue May 10 05:22:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 May 2005 20:22:46 -0700 Subject: [ python-Bugs-1193890 ] calendar.weekheader not found in __all__ Message-ID: Bugs item #1193890, was opened at 2005-05-02 10:56 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193890&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: calendar.weekheader not found in __all__ Initial Comment: calendar.weekheader is documented and a public function form its beginning but not included in calendar.__all__. So >>> from calendar import *; weekheader triggers a NameError. Fix is trivial. Just add 'weekheader' to __all__. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-09 22:22 Message: Logged In: YES user_id=80475 Lib/calendar.py 1.36 and 1.35.2.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193890&group_id=5470 From noreply at sourceforge.net Tue May 10 05:36:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 May 2005 20:36:27 -0700 Subject: [ python-Bugs-1196315 ] WeakValueDictionary.__init__ is backwards Message-ID: Bugs item #1196315, was opened at 2005-05-05 20:59 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196315&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Pavel Pergamenshchik (ppergame) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: WeakValueDictionary.__init__ is backwards Initial Comment: >>> from weakref import WeakValueDictionary as wvd >>> class A: ... pass ... >>> wvd({1:A()}) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/weakref.py", line 46, in __init__ UserDict.UserDict.__init__(self, *args, **kw) File "/usr/lib/python2.4/UserDict.py", line 7, in __init__ self.update(dict) File "/usr/lib/python2.4/weakref.py", line 161, in update d[key] = KeyedRef(o, self._remove, key) AttributeError: WeakValueDictionary instance has no attribute '_remove' WeakValueDictionary.__init__ calls UserDict.__init__ first and sets self._remove second. It should do it the other way around. This is a regression from 2.3. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-09 22:36 Message: Logged In: YES user_id=80475 Fred, I believe this was your change (1.23). The OP's request apprears correct to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196315&group_id=5470 From noreply at sourceforge.net Tue May 10 15:50:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 May 2005 06:50:46 -0700 Subject: [ python-Bugs-1195984 ] SystemError: error return without exception set Message-ID: Bugs item #1195984, was opened at 2005-05-05 11:38 Message generated for change (Comment added) made by nbajpai You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1195984&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None >Priority: 6 Submitted By: Niraj Bajpai (nbajpai) Assigned to: Nobody/Anonymous (nobody) Summary: SystemError: error return without exception set Initial Comment: I am getting following error with Python 2.4.1 relase: "SystemError: error return without exception set" my code works fine with earlier release (python 2.4). Its a C code build in python so does not leave much traces to describe problem more. Important Notes: Release name: 2.4.1(final) Platform: Solaris 2.8 Error: "SystemError: error return without exception set" ---------------------------------------------------------------------- >Comment By: Niraj Bajpai (nbajpai) Date: 2005-05-10 09:50 Message: Logged In: YES user_id=1165734 Actually the same error happens in both 2.4 and 2.4.1. I call in python code to receive events from C code embedded in python interpreter. There are two meaningful events and idle event. I commented idle event in the code (C-code) and start seeing this error. from python code: x.receive(A) <<<<<<-------- Error happens here where A can be , receive "X" or receive "Y" or receive "NOTHING" In C code when I comment "NOTHING" event generator, I get the error. Some meaningful exception in python would have been better. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-06 07:45 Message: Logged In: YES user_id=6656 Uh, there's not a lot to go on here. Can you post some code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1195984&group_id=5470 From noreply at sourceforge.net Tue May 10 15:52:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 May 2005 06:52:12 -0700 Subject: [ python-Bugs-1195984 ] SystemError: error return without exception set Message-ID: Bugs item #1195984, was opened at 2005-05-05 16:38 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1195984&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None >Priority: 5 Submitted By: Niraj Bajpai (nbajpai) Assigned to: Nobody/Anonymous (nobody) Summary: SystemError: error return without exception set Initial Comment: I am getting following error with Python 2.4.1 relase: "SystemError: error return without exception set" my code works fine with earlier release (python 2.4). Its a C code build in python so does not leave much traces to describe problem more. Important Notes: Release name: 2.4.1(final) Platform: Solaris 2.8 Error: "SystemError: error return without exception set" ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-05-10 14:52 Message: Logged In: YES user_id=6656 Are you writing your own C code? If so, why do you suspect a bug in Python itself? (Also, a debug build of python can be useful for this sort of thing). ---------------------------------------------------------------------- Comment By: Niraj Bajpai (nbajpai) Date: 2005-05-10 14:50 Message: Logged In: YES user_id=1165734 Actually the same error happens in both 2.4 and 2.4.1. I call in python code to receive events from C code embedded in python interpreter. There are two meaningful events and idle event. I commented idle event in the code (C-code) and start seeing this error. from python code: x.receive(A) <<<<<<-------- Error happens here where A can be , receive "X" or receive "Y" or receive "NOTHING" In C code when I comment "NOTHING" event generator, I get the error. Some meaningful exception in python would have been better. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-06 12:45 Message: Logged In: YES user_id=6656 Uh, there's not a lot to go on here. Can you post some code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1195984&group_id=5470 From noreply at sourceforge.net Tue May 10 20:24:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 May 2005 11:24:30 -0700 Subject: [ python-Bugs-1199282 ] subprocess _active.remove(self) self not in list _active Message-ID: Bugs item #1199282, was opened at 2005-05-10 18:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470 Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: cheops (atila-cheops) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess _active.remove(self) self not in list _active Initial Comment: I start a subprocess in a seperate thread (25 concurrent threads) in some of the threads the following error occurs Exception in thread Thread-4: Traceback (most recent call last): File "C:\Python24\lib\threading.py", line 442, in __bootstrap self.run() File "upgrade.py", line 45, in run returncode = p.wait() File "C:\Python24\lib\subprocess.py", line 765, in wait _active.remove(self) ValueError: list.remove(x): x not in list this is the code that starts the subprocess and where I wait for the result p = subprocess.Popen('command', stdin=None, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, universal_newlines=True) returncode = p.wait() errormessage = p.stdout.readlines() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470 From noreply at sourceforge.net Tue May 10 21:58:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 May 2005 12:58:10 -0700 Subject: [ python-Bugs-1085208 ] Installation ends prematurely Message-ID: Bugs item #1085208, was opened at 2004-12-14 08:18 Message generated for change (Comment added) made by tungwaiyip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085208&group_id=5470 Category: Installation Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: anamh0001 (anamh0001) Assigned to: Martin v. L?wis (loewis) Summary: Installation ends prematurely Initial Comment: Test machine: Pentium 4M 1.7Ghz Win XP Pro w/ SP2 512Mb RAM 30Gb HD .Net Framework 1.0 and 1.1 Windows Scripting Host 5.6 After double clicking the installation file. It proceeds to act like any other Windows Installer. After accepting c:\Python24 as the install directory, I am presented with this screen saying that there was an error and that the installation has ended prematurely. FYI, I tried to install over Python 2.3 (as in upgrade) but I got the same error. So I proceeded to uninstall Python 2.3 and other installed libraries. I then restarted the PC and tried to install Python 2.4 again. This bug is the symptom of this second try. Please find the screenshot attached showing the final screen. ---------------------------------------------------------------------- Comment By: Wai Yip Tung (tungwaiyip) Date: 2005-05-10 12:58 Message: Logged In: YES user_id=561546 Having previously sucessfully installer Python 2.4. I run into this same error with both 2.4 and 2.4.1.msi on a new computer. Running x.vbs gives me 0. Doing regsvr32 c:\windows\system32\scrrun.dll does not help. cscript shows version info below: Microsoft (R) Windows Script Host Version 5.6 Copyright (C) Microsoft Corporation 1996-2001. All rights reserved. I have captured a log file but perhaps I'm not the orginator of this bug I don't seems to have the capability to upload it. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-22 04:41 Message: Logged In: YES user_id=21627 This is fixed for 2.4.1, which will not require VB anymore. ---------------------------------------------------------------------- Comment By: anamh0001 (anamh0001) Date: 2004-12-16 07:21 Message: Logged In: YES user_id=1178107 BUG FIXED -- solution below. 1) BTW I actually thought the installer was looking for c:\python24. So I created the folder before running the installer again. But it didnt work. When I ran the script. It returned this error: I used cscript. c:\x.vbs(2, 7) (null): The specified module could not be found. 2) The version of wscript and cscript is 5.6.0.8825 3) This is latest version because I read that installing the latest version of scripting host fixes installation problems. **** I managed to fix it. I registered scrrun.dll by typing: regsvr32 c:\windows\system32\scrrun.dll Thanks for all the help.. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-16 05:07 Message: Logged In: YES user_id=21627 Can you please try the following things? 1. Run the script ========== SNIP ============ Function CheckDir() Set FSO = CreateObject("Scripting.FileSystemObject") if FSO.FolderExists("c:\python24") then wscript.echo "1" else wscript.echo "0" end if End Function CheckDir() ============= SNIP ============== in wscript.exe (i.e. save it into c:\x.vbs, then run c:\x.vbs) 2. Report the version of C:\WINDOWS\SYSTEM32\wscript.exe (5.6 is too imprecise - could it be that you have 5.6.0.8820?) 3. Install VBScript, from http://www.microsoft.com/downloads/details.aspx?FamilyId=C717D943 -7E4B-4622-86EB-95A22B832CAA&displaylang=en ---------------------------------------------------------------------- Comment By: anamh0001 (anamh0001) Date: 2004-12-16 02:04 Message: Logged In: YES user_id=1178107 Please find the msi log file attached. I managed to pinpoint the area where it breaks.. It's failing on CheckDir with an error 2896. ----- MSI (c) (88:54) [09:50:38:430]: Doing action: CheckDir Action start 09:50:38: CheckDir. MSI (c) (88:3C) [09:50:38:440]: Cloaking enabled. MSI (c) (88:3C) [09:50:38:440]: Attempting to enable all disabled priveleges before calling Install on Server MSI (c) (88:3C) [09:50:38:440]: Connected to service for CA interface. MSI (c) (88:88) [09:50:38:580]: Entering MsiProvideComponentFromDescriptor. Descriptor: 2eAq^]D2g (8V7Xaq(hoRIngresDBMS>M5KDYSUnf(HA*L[xeX)y, PathBuf: 1C4F348, pcchPathBuf: 1C4F344, pcchArgsOffset: 1C4F2A4 MSI (c) (88:88) [09:50:38:580]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value MSI (c) (88:88) [09:50:38:580]: MsiProvideComponentFromDescriptor is returning: 0 Action ended 09:50:38: CheckDir. Return value 3. MSI (c) (88:54) [09:50:38:921]: Note: 1: 2262 2: Error 3: - 2147287038 DEBUG: Error 2896: Executing action CheckDir failed. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2896. The arguments are: CheckDir, , Action ended 09:50:38: SelectDirectoryDlg. Return value 3. MSI (c) (88:94) [09:50:38:931]: Doing action: FatalError Action start 09:50:38: FatalError. Action 09:50:38: FatalError. Dialog created Action ended 09:50:39: FatalError. Return value 2. Action ended 09:50:40: INSTALL. Return value 3. MSI (c) (88:94) [09:50:40:012]: Destroying RemoteAPI object. MSI (c) (88:3C) [09:50:40:012]: Custom Action Manager thread ending. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-15 14:35 Message: Logged In: YES user_id=21627 Can you please run msiexec /i python-2.4.msi /l*v python.log and attach the resulting python.log (do NOT paste it into the SF comment box). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085208&group_id=5470 From noreply at sourceforge.net Wed May 11 01:07:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 May 2005 16:07:29 -0700 Subject: [ python-Bugs-1198275 ] time module ignores timezone changes Message-ID: Bugs item #1198275, was opened at 2005-05-09 06:14 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1198275&group_id=5470 Category: Extension Modules Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Lambert (jdalambert) Assigned to: Brett Cannon (bcannon) Summary: time module ignores timezone changes Initial Comment: Running on Fedora Core 3 Linux Consider the simple program import time while 1: print time.localtime() time.sleep(1) The tuple printed by this program does not reflect any change in the system timezone until the interpreter is exited and restarted. Using reload(time) does not fix the problem. Are there any workarounds? ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-05-10 16:07 Message: Logged In: YES user_id=357491 David, how did you change the timezone? And did you call time.tzset()? If you didn't call time.tzset(), that's the problem. If you did, then there is a bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-09 20:09 Message: Logged In: YES user_id=80475 Brett, are you still in the time business? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1198275&group_id=5470 From noreply at sourceforge.net Wed May 11 01:10:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 May 2005 16:10:12 -0700 Subject: [ python-Bugs-1198275 ] time module ignores timezone changes Message-ID: Bugs item #1198275, was opened at 2005-05-09 06:14 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1198275&group_id=5470 Category: Extension Modules Group: Python 2.2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: David Lambert (jdalambert) Assigned to: Brett Cannon (bcannon) Summary: time module ignores timezone changes Initial Comment: Running on Fedora Core 3 Linux Consider the simple program import time while 1: print time.localtime() time.sleep(1) The tuple printed by this program does not reflect any change in the system timezone until the interpreter is exited and restarted. Using reload(time) does not fix the problem. Are there any workarounds? ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-05-10 16:10 Message: Logged In: YES user_id=357491 Wait, I just noticed after I sent my follow-up that this bug report is against Python 2.2.3 . You won't find time.tzset() that far back. The issue is that you need to use time.tzset() to reset the timezone for the C library functions to use any change you have made since they cache information internally. I am closing this as "won't fix" since it has been resolved in later versions and 2.2 is too old to bother backporting for. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-05-10 16:07 Message: Logged In: YES user_id=357491 David, how did you change the timezone? And did you call time.tzset()? If you didn't call time.tzset(), that's the problem. If you did, then there is a bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-09 20:09 Message: Logged In: YES user_id=80475 Brett, are you still in the time business? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1198275&group_id=5470 From noreply at sourceforge.net Wed May 11 04:33:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 May 2005 19:33:40 -0700 Subject: [ python-Bugs-1198275 ] time module ignores timezone changes Message-ID: Bugs item #1198275, was opened at 2005-05-09 08:14 Message generated for change (Comment added) made by jdalambert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1198275&group_id=5470 Category: Extension Modules Group: Python 2.2.3 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: David Lambert (jdalambert) Assigned to: Brett Cannon (bcannon) Summary: time module ignores timezone changes Initial Comment: Running on Fedora Core 3 Linux Consider the simple program import time while 1: print time.localtime() time.sleep(1) The tuple printed by this program does not reflect any change in the system timezone until the interpreter is exited and restarted. Using reload(time) does not fix the problem. Are there any workarounds? ---------------------------------------------------------------------- >Comment By: David Lambert (jdalambert) Date: 2005-05-10 21:33 Message: Logged In: YES user_id=845425 Ouch! I don't know how I got 2.2.3 on the bug report? My version of Python is 2.3.4. Sorry for the confusion.:-( Let me explain further. The problem is that I have a Python script that is run as a daemon and uses localtime(). If another program (outside of my control) changes the timezone, the my daemon gets the local time according to the original timezone. Do I have to periodically poll to see if the timezone has changed? That seems somewhat inelegant. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-05-10 18:10 Message: Logged In: YES user_id=357491 Wait, I just noticed after I sent my follow-up that this bug report is against Python 2.2.3 . You won't find time.tzset() that far back. The issue is that you need to use time.tzset() to reset the timezone for the C library functions to use any change you have made since they cache information internally. I am closing this as "won't fix" since it has been resolved in later versions and 2.2 is too old to bother backporting for. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-05-10 18:07 Message: Logged In: YES user_id=357491 David, how did you change the timezone? And did you call time.tzset()? If you didn't call time.tzset(), that's the problem. If you did, then there is a bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-09 22:09 Message: Logged In: YES user_id=80475 Brett, are you still in the time business? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1198275&group_id=5470 From noreply at sourceforge.net Wed May 11 07:39:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 May 2005 22:39:59 -0700 Subject: [ python-Bugs-1085208 ] Installation ends prematurely Message-ID: Bugs item #1085208, was opened at 2004-12-14 17:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085208&group_id=5470 Category: Installation Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: anamh0001 (anamh0001) Assigned to: Martin v. L?wis (loewis) Summary: Installation ends prematurely Initial Comment: Test machine: Pentium 4M 1.7Ghz Win XP Pro w/ SP2 512Mb RAM 30Gb HD .Net Framework 1.0 and 1.1 Windows Scripting Host 5.6 After double clicking the installation file. It proceeds to act like any other Windows Installer. After accepting c:\Python24 as the install directory, I am presented with this screen saying that there was an error and that the installation has ended prematurely. FYI, I tried to install over Python 2.3 (as in upgrade) but I got the same error. So I proceeded to uninstall Python 2.3 and other installed libraries. I then restarted the PC and tried to install Python 2.4 again. This bug is the symptom of this second try. Please find the screenshot attached showing the final screen. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-05-11 07:39 Message: Logged In: YES user_id=21627 This can't be the same bug (maybe the same symptom), so please submit a new bug report. ---------------------------------------------------------------------- Comment By: Wai Yip Tung (tungwaiyip) Date: 2005-05-10 21:58 Message: Logged In: YES user_id=561546 Having previously sucessfully installer Python 2.4. I run into this same error with both 2.4 and 2.4.1.msi on a new computer. Running x.vbs gives me 0. Doing regsvr32 c:\windows\system32\scrrun.dll does not help. cscript shows version info below: Microsoft (R) Windows Script Host Version 5.6 Copyright (C) Microsoft Corporation 1996-2001. All rights reserved. I have captured a log file but perhaps I'm not the orginator of this bug I don't seems to have the capability to upload it. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-22 13:41 Message: Logged In: YES user_id=21627 This is fixed for 2.4.1, which will not require VB anymore. ---------------------------------------------------------------------- Comment By: anamh0001 (anamh0001) Date: 2004-12-16 16:21 Message: Logged In: YES user_id=1178107 BUG FIXED -- solution below. 1) BTW I actually thought the installer was looking for c:\python24. So I created the folder before running the installer again. But it didnt work. When I ran the script. It returned this error: I used cscript. c:\x.vbs(2, 7) (null): The specified module could not be found. 2) The version of wscript and cscript is 5.6.0.8825 3) This is latest version because I read that installing the latest version of scripting host fixes installation problems. **** I managed to fix it. I registered scrrun.dll by typing: regsvr32 c:\windows\system32\scrrun.dll Thanks for all the help.. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-16 14:07 Message: Logged In: YES user_id=21627 Can you please try the following things? 1. Run the script ========== SNIP ============ Function CheckDir() Set FSO = CreateObject("Scripting.FileSystemObject") if FSO.FolderExists("c:\python24") then wscript.echo "1" else wscript.echo "0" end if End Function CheckDir() ============= SNIP ============== in wscript.exe (i.e. save it into c:\x.vbs, then run c:\x.vbs) 2. Report the version of C:\WINDOWS\SYSTEM32\wscript.exe (5.6 is too imprecise - could it be that you have 5.6.0.8820?) 3. Install VBScript, from http://www.microsoft.com/downloads/details.aspx?FamilyId=C717D943 -7E4B-4622-86EB-95A22B832CAA&displaylang=en ---------------------------------------------------------------------- Comment By: anamh0001 (anamh0001) Date: 2004-12-16 11:04 Message: Logged In: YES user_id=1178107 Please find the msi log file attached. I managed to pinpoint the area where it breaks.. It's failing on CheckDir with an error 2896. ----- MSI (c) (88:54) [09:50:38:430]: Doing action: CheckDir Action start 09:50:38: CheckDir. MSI (c) (88:3C) [09:50:38:440]: Cloaking enabled. MSI (c) (88:3C) [09:50:38:440]: Attempting to enable all disabled priveleges before calling Install on Server MSI (c) (88:3C) [09:50:38:440]: Connected to service for CA interface. MSI (c) (88:88) [09:50:38:580]: Entering MsiProvideComponentFromDescriptor. Descriptor: 2eAq^]D2g (8V7Xaq(hoRIngresDBMS>M5KDYSUnf(HA*L[xeX)y, PathBuf: 1C4F348, pcchPathBuf: 1C4F344, pcchArgsOffset: 1C4F2A4 MSI (c) (88:88) [09:50:38:580]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value MSI (c) (88:88) [09:50:38:580]: MsiProvideComponentFromDescriptor is returning: 0 Action ended 09:50:38: CheckDir. Return value 3. MSI (c) (88:54) [09:50:38:921]: Note: 1: 2262 2: Error 3: - 2147287038 DEBUG: Error 2896: Executing action CheckDir failed. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2896. The arguments are: CheckDir, , Action ended 09:50:38: SelectDirectoryDlg. Return value 3. MSI (c) (88:94) [09:50:38:931]: Doing action: FatalError Action start 09:50:38: FatalError. Action 09:50:38: FatalError. Dialog created Action ended 09:50:39: FatalError. Return value 2. Action ended 09:50:40: INSTALL. Return value 3. MSI (c) (88:94) [09:50:40:012]: Destroying RemoteAPI object. MSI (c) (88:3C) [09:50:40:012]: Custom Action Manager thread ending. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-15 23:35 Message: Logged In: YES user_id=21627 Can you please run msiexec /i python-2.4.msi /l*v python.log and attach the resulting python.log (do NOT paste it into the SF comment box). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085208&group_id=5470 From noreply at sourceforge.net Wed May 11 14:50:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 May 2005 05:50:53 -0700 Subject: [ python-Bugs-1199808 ] installation problem with python 2.4.1 on Win2k system Message-ID: Bugs item #1199808, was opened at 2005-05-11 05:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199808&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: mmkobayashi (mmkobayashi) Assigned to: Nobody/Anonymous (nobody) Summary: installation problem with python 2.4.1 on Win2k system Initial Comment: After several attempts to install python2.4.1 on a win2k systems with doing all windows updates, we have been unable to install python2.4.1 on this system. We have attached an error logfile. The main thing that happens is that the install proceeds as normal but at some point the install decides that something has gone wrong and uninstalls itself. Any help in this matter would be greatly appreciated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199808&group_id=5470 From noreply at sourceforge.net Wed May 11 18:01:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 May 2005 09:01:56 -0700 Subject: [ python-Bugs-1199947 ] Python 2.4.1 Installer ended prematurely Message-ID: Bugs item #1199947, was opened at 2005-05-11 09:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199947&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Wai Yip Tung (tungwaiyip) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.1 Installer ended prematurely Initial Comment: Similar symptom to bug 105470 http://sourceforge.net/tracker/index.php? func=detail&aid=1085208&group_id=5470&atid=105470 Running python-2.4.1.msi with all default setting. It ends quickly with a dialogbox titled "Python 2.4.1 Installer ended prematurely". Same problem running the 2.4 msi. Machine information: Windows XP Professional V2002 SP2 Dell Latitude D600 640MB RAM Symantec Antivirus 9.0.1.1000 (disable it does not help) cscript.exe version 5.6.0.8825 (upgraded from 8820?) The workaround mentioned in 105470 does not help. Running x.vbs gives me 0. Doing regsvr32 c:\windows\system32\scrrun.dll makes no difference. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199947&group_id=5470 From noreply at sourceforge.net Wed May 11 21:23:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 May 2005 12:23:11 -0700 Subject: [ python-Bugs-1196315 ] WeakValueDictionary.__init__ is backwards Message-ID: Bugs item #1196315, was opened at 2005-05-05 21:59 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196315&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Pavel Pergamenshchik (ppergame) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: WeakValueDictionary.__init__ is backwards Initial Comment: >>> from weakref import WeakValueDictionary as wvd >>> class A: ... pass ... >>> wvd({1:A()}) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/weakref.py", line 46, in __init__ UserDict.UserDict.__init__(self, *args, **kw) File "/usr/lib/python2.4/UserDict.py", line 7, in __init__ self.update(dict) File "/usr/lib/python2.4/weakref.py", line 161, in update d[key] = KeyedRef(o, self._remove, key) AttributeError: WeakValueDictionary instance has no attribute '_remove' WeakValueDictionary.__init__ calls UserDict.__init__ first and sets self._remove second. It should do it the other way around. This is a regression from 2.3. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2005-05-11 15:23 Message: Logged In: YES user_id=34901 I would agree that the order is definitely broken. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-09 23:36 Message: Logged In: YES user_id=80475 Fred, I believe this was your change (1.23). The OP's request apprears correct to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196315&group_id=5470 From noreply at sourceforge.net Wed May 11 22:35:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 May 2005 13:35:13 -0700 Subject: [ python-Bugs-1198275 ] time module ignores timezone changes Message-ID: Bugs item #1198275, was opened at 2005-05-09 06:14 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1198275&group_id=5470 Category: Extension Modules >Group: Python 2.3 >Status: Open >Resolution: None Priority: 5 Submitted By: David Lambert (jdalambert) Assigned to: Brett Cannon (bcannon) Summary: time module ignores timezone changes Initial Comment: Running on Fedora Core 3 Linux Consider the simple program import time while 1: print time.localtime() time.sleep(1) The tuple printed by this program does not reflect any change in the system timezone until the interpreter is exited and restarted. Using reload(time) does not fix the problem. Are there any workarounds? ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-05-11 13:35 Message: Logged In: YES user_id=357491 OK, fixed the version and reopened this. No, you don't need to poll, just call time.tzset() before you call time.localtime() or anything else that relies on the timezone. It isn't that expensive of a call. Post here if that fixes it or not. And in terms of inelegance, the only other solution is to implicitly call time.tzset() internally for all time functions. This is an issue imposed by the ISO C libraries. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-05-10 19:33 Message: Logged In: YES user_id=845425 Ouch! I don't know how I got 2.2.3 on the bug report? My version of Python is 2.3.4. Sorry for the confusion.:-( Let me explain further. The problem is that I have a Python script that is run as a daemon and uses localtime(). If another program (outside of my control) changes the timezone, the my daemon gets the local time according to the original timezone. Do I have to periodically poll to see if the timezone has changed? That seems somewhat inelegant. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-05-10 16:10 Message: Logged In: YES user_id=357491 Wait, I just noticed after I sent my follow-up that this bug report is against Python 2.2.3 . You won't find time.tzset() that far back. The issue is that you need to use time.tzset() to reset the timezone for the C library functions to use any change you have made since they cache information internally. I am closing this as "won't fix" since it has been resolved in later versions and 2.2 is too old to bother backporting for. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-05-10 16:07 Message: Logged In: YES user_id=357491 David, how did you change the timezone? And did you call time.tzset()? If you didn't call time.tzset(), that's the problem. If you did, then there is a bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-09 20:09 Message: Logged In: YES user_id=80475 Brett, are you still in the time business? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1198275&group_id=5470 From noreply at sourceforge.net Thu May 12 01:07:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 May 2005 16:07:30 -0700 Subject: [ python-Bugs-1195984 ] SystemError: error return without exception set Message-ID: Bugs item #1195984, was opened at 2005-05-05 11:38 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1195984&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Niraj Bajpai (nbajpai) Assigned to: Nobody/Anonymous (nobody) Summary: SystemError: error return without exception set Initial Comment: I am getting following error with Python 2.4.1 relase: "SystemError: error return without exception set" my code works fine with earlier release (python 2.4). Its a C code build in python so does not leave much traces to describe problem more. Important Notes: Release name: 2.4.1(final) Platform: Solaris 2.8 Error: "SystemError: error return without exception set" ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-11 19:07 Message: Logged In: YES user_id=593130 When people mix their own C code with CPython and get a SystemError like this, the probability that the error is in the added code and not the core code is perhaps greater than .95. Please consider closing this report as invalid unless and until you have evidence that the problem is indeed in the core code. To get help reviewing your added code, you can post to comp.lang.python, the general Python mailing list (python.org), or gmane.comp.python.general (gmane.org). To me, the Python error message seems meaningful enough. It seems to claim that you made an error return without setting an exception according to the rules of the C API. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-10 09:52 Message: Logged In: YES user_id=6656 Are you writing your own C code? If so, why do you suspect a bug in Python itself? (Also, a debug build of python can be useful for this sort of thing). ---------------------------------------------------------------------- Comment By: Niraj Bajpai (nbajpai) Date: 2005-05-10 09:50 Message: Logged In: YES user_id=1165734 Actually the same error happens in both 2.4 and 2.4.1. I call in python code to receive events from C code embedded in python interpreter. There are two meaningful events and idle event. I commented idle event in the code (C-code) and start seeing this error. from python code: x.receive(A) <<<<<<-------- Error happens here where A can be , receive "X" or receive "Y" or receive "NOTHING" In C code when I comment "NOTHING" event generator, I get the error. Some meaningful exception in python would have been better. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-06 07:45 Message: Logged In: YES user_id=6656 Uh, there's not a lot to go on here. Can you post some code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1195984&group_id=5470 From noreply at sourceforge.net Thu May 12 02:55:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 May 2005 17:55:09 -0700 Subject: [ python-Bugs-1200287 ] Windows msi installer fails on virtual drives Message-ID: Bugs item #1200287, was opened at 2005-05-11 19:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200287&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: bartgrantham (bartgrantham) Assigned to: Nobody/Anonymous (nobody) Summary: Windows msi installer fails on virtual drives Initial Comment: The MSI installer for 2.4.1 failed to install from a virtual drive under windows (ie. a drive created with subst). It would error out without an error code, immediately after package selection and before "thinking...". Not sure if this also applies to network mapped drives. Moving installer to genuine C: drive and running from there fixed the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200287&group_id=5470 From noreply at sourceforge.net Thu May 12 07:53:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 May 2005 22:53:33 -0700 Subject: [ python-Bugs-1199808 ] installation problem with python 2.4.1 on Win2k system Message-ID: Bugs item #1199808, was opened at 2005-05-11 05:50 Message generated for change (Comment added) made by mmkobayashi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199808&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: mmkobayashi (mmkobayashi) Assigned to: Nobody/Anonymous (nobody) Summary: installation problem with python 2.4.1 on Win2k system Initial Comment: After several attempts to install python2.4.1 on a win2k systems with doing all windows updates, we have been unable to install python2.4.1 on this system. We have attached an error logfile. The main thing that happens is that the install proceeds as normal but at some point the install decides that something has gone wrong and uninstalls itself. Any help in this matter would be greatly appreciated. ---------------------------------------------------------------------- >Comment By: mmkobayashi (mmkobayashi) Date: 2005-05-11 22:53 Message: Logged In: YES user_id=1273313 add file ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199808&group_id=5470 From noreply at sourceforge.net Thu May 12 09:35:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 May 2005 00:35:46 -0700 Subject: [ python-Bugs-1163563 ] Sub threads execute in restricted mode Message-ID: Bugs item #1163563, was opened at 2005-03-15 09:56 Message generated for change (Comment added) made by yetanothermax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None >Priority: 8 Submitted By: anothermax (yetanothermax) Assigned to: Nobody/Anonymous (nobody) Summary: Sub threads execute in restricted mode Initial Comment: I'm using the JEP product which allows integration of Java with Python (see http://jepp.sourceforge.net) via starting a Python interpreter in the same process as the JVM. This integrates with python via the C interface, allowing the user to 'eval' python code (amongst other features). It seems that since Python 2.3.5 any threads (using the threading module) created via code that has been evaluated through the jep.eval() interface (i.e.Python C interface )are executed in restricted mode and cannot, for example, create files. Code that is just evaled (i.e not in a subthread) thread has no restrictions. The error reported is: IOError: file() constructor not accessible in restricted mode (see http://sourceforge.net/forum/forum.php? thread_id=1247793&forum_id=376782) - I've given a JEP specific example here. There seems to be a similar problem with mod_python (see http://www.modpython.org/pipermail/mod_python/2005- January/017129.html) Reading through the release notes for Python 2.3.5 I see: Bug #754449: threading.Thread will no longer mask exceptions raised during interpreter shutdown with another exception caused by attempting to output the initial exception. This fix also includes a backport of rev. 1.41 from HEAD. This might be the problem as it seems to involve the porting of 2.4 threading code back to the 2.3 tree. I've attached a Java file which shows the problem when using JEP. The error output is: Exception in thread Thread-1: Traceback (most recent call last): File "C:\Python24\Lib\threading.py", line 442, in __bootstrap File "", line 5, in run IOError: file() constructor not accessible in restricted mode 2.4.1c1 (#63, Mar 10 2005, 10:36:41) [MSC v.1310 32 bit (Intel)] Creating file from main thread... Done Creating file from sub thread... Done ---------------------------------------------------------------------- >Comment By: anothermax (yetanothermax) Date: 2005-05-12 09:35 Message: Logged In: YES user_id=1218811 This problem prevents us from upgrading to Python 2.4. I've attached a another 'fixed' threadmodule.c which is based upon the lastest CVS release.(Only change from the last threadmodule.c attachment is the removal of a '\n' from an error message). The threadtest.c program demonstrates the problem (seems to be the use of Py_NewInterpreter() with the PyGIL_StateXXX functions in the current threadmodule.c). How do we get this solved for the next Python release? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-21 14:05 Message: Logged In: YES user_id=1218811 I've attached a file (threadtest.c) that is adapted from the the way JEP uses Py_NewInterpreter. This runs correctly under 2.3.4 but fails under 2.3.5 and later Pythons. ---------------------------------------------------------------------- Comment By: mrjohnson (mrjohnson0) Date: 2005-04-21 07:51 Message: Logged In: YES user_id=1044885 In interactive mode, Jep uses Py_NewInterpreter, Py_CompileString, and PyRun_String for its eval(). This file handles java -> python: http://204.156.146.230/cgi-bin/viewcvs.cgi/jep/pyembed.c?rev=1.29&content-type=text/vnd.viewcvs-markup You'd be looking for pyembed_eval(). ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-04-21 05:11 Message: Logged In: YES user_id=14198 Can anyone tell me specifically what Python C API function is involved here? ie, the "entry point" that these external threads use to call into Python. ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 13:51 Message: Logged In: YES user_id=1218811 I didn't see jbelmote's comment, perhaps my updated threadmodule.c will reopen the #1010677 bug. ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 13:39 Message: Logged In: YES user_id=1218811 Here's the updated threadmodule.c for 2.4.1 ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 13:36 Message: Logged In: YES user_id=1218811 I've finally got access to a C compiler and it looks like the 'pure' Python changes for #754449 are in the clear (apologies to bcannon). The problem actually seems to relate to changes to threadmodule.c of the Python Modules directory. In versions greater than 2.3.4 it uses the PyGILState_XXX constructs t_bootstrap() function. These do not seem to be compatible with running sub interpreters as JEP (and probably mod_python) do. The python documentation (http://docs.python.org/api/threads.html) says "Note that the PyGILState_*() functions assume there is only one global interpreter (created automatically by Py_Initialize()). Python still supports the creation of additional interpreters (using Py_NewInterpreter()), but mixing multiple interpreters and the PyGILState_*() API is unsupported. " I've compiled a new versions of the python2X.dll for both 2.3.5 and 2.4.1 changing the use of these PyGIL_StateXXX constructs back to the 2.3.4 form and this seems to resolve the problem (I've attached the updated threadmodule.c files for both 2.3.5 and 2.4.1). ---------------------------------------------------------------------- Comment By: John Belmonte (jbelmonte) Date: 2005-04-16 22:27 Message: Logged In: YES user_id=282299 This problem also occurs on Linux. Note however that I've traced the source of the symptom to a different bug fix, namely [1010677] thread Module Breaks PyGILState_Ensure() (http://sourceforge.net/tracker/index.php?func=detail&aid=1010677&group_id=5470&atid=305470). Specifically, the change from v2.56 to v2.56.8.1 of threadmodule.c. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-16 21:21 Message: Logged In: YES user_id=357491 To answer the comment on bug #754449 and the email I got from someone, there is no way my fix for that bug would cause this. I only touched the 'threading' module, nothing else. That is in pure Python and thus has no direct way of modifying what does and does not execute in restricted mode. If I understand how restricted execution works that is all set at the C level. Plus the fix only deals with the teardown code; it in no way interfaces with how threads are executed. All changed code come after the thread and completed execution. The only thing it does ahead of time is store a reference to stdout. In other words it ain't my fault to the best of my knowledge. =) ---------------------------------------------------------------------- Comment By: Alan Davies (goatpunch) Date: 2005-03-31 08:24 Message: Logged In: YES user_id=967140 The same problem definately does occur with mod_python, I've found it to occur with Python 2.3.5 and 2.4 on Win32: http://www.modpython.org/pipermail/mod_python/2005- March/017802.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 From noreply at sourceforge.net Thu May 12 09:43:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 May 2005 00:43:51 -0700 Subject: [ python-Bugs-1163563 ] Sub threads execute in restricted mode Message-ID: Bugs item #1163563, was opened at 2005-03-15 08:56 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: anothermax (yetanothermax) Assigned to: Nobody/Anonymous (nobody) Summary: Sub threads execute in restricted mode Initial Comment: I'm using the JEP product which allows integration of Java with Python (see http://jepp.sourceforge.net) via starting a Python interpreter in the same process as the JVM. This integrates with python via the C interface, allowing the user to 'eval' python code (amongst other features). It seems that since Python 2.3.5 any threads (using the threading module) created via code that has been evaluated through the jep.eval() interface (i.e.Python C interface )are executed in restricted mode and cannot, for example, create files. Code that is just evaled (i.e not in a subthread) thread has no restrictions. The error reported is: IOError: file() constructor not accessible in restricted mode (see http://sourceforge.net/forum/forum.php? thread_id=1247793&forum_id=376782) - I've given a JEP specific example here. There seems to be a similar problem with mod_python (see http://www.modpython.org/pipermail/mod_python/2005- January/017129.html) Reading through the release notes for Python 2.3.5 I see: Bug #754449: threading.Thread will no longer mask exceptions raised during interpreter shutdown with another exception caused by attempting to output the initial exception. This fix also includes a backport of rev. 1.41 from HEAD. This might be the problem as it seems to involve the porting of 2.4 threading code back to the 2.3 tree. I've attached a Java file which shows the problem when using JEP. The error output is: Exception in thread Thread-1: Traceback (most recent call last): File "C:\Python24\Lib\threading.py", line 442, in __bootstrap File "", line 5, in run IOError: file() constructor not accessible in restricted mode 2.4.1c1 (#63, Mar 10 2005, 10:36:41) [MSC v.1310 32 bit (Intel)] Creating file from main thread... Done Creating file from sub thread... Done ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-05-12 08:43 Message: Logged In: YES user_id=6656 I saw the subject and thought "Hmm, should raise the priority of this so it gets at least thought about hard by the next release", then saw that you did that... > How do we get this solved for the next Python release? I don't know. It's possible it should be raised on python-dev (it seems fairly quiet just now, so it might be a good time :). Basically, it seems that the whole multiple interpreters facility is screwed, correct? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-12 08:35 Message: Logged In: YES user_id=1218811 This problem prevents us from upgrading to Python 2.4. I've attached a another 'fixed' threadmodule.c which is based upon the lastest CVS release.(Only change from the last threadmodule.c attachment is the removal of a '\n' from an error message). The threadtest.c program demonstrates the problem (seems to be the use of Py_NewInterpreter() with the PyGIL_StateXXX functions in the current threadmodule.c). How do we get this solved for the next Python release? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-21 13:05 Message: Logged In: YES user_id=1218811 I've attached a file (threadtest.c) that is adapted from the the way JEP uses Py_NewInterpreter. This runs correctly under 2.3.4 but fails under 2.3.5 and later Pythons. ---------------------------------------------------------------------- Comment By: mrjohnson (mrjohnson0) Date: 2005-04-21 06:51 Message: Logged In: YES user_id=1044885 In interactive mode, Jep uses Py_NewInterpreter, Py_CompileString, and PyRun_String for its eval(). This file handles java -> python: http://204.156.146.230/cgi-bin/viewcvs.cgi/jep/pyembed.c?rev=1.29&content-type=text/vnd.viewcvs-markup You'd be looking for pyembed_eval(). ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-04-21 04:11 Message: Logged In: YES user_id=14198 Can anyone tell me specifically what Python C API function is involved here? ie, the "entry point" that these external threads use to call into Python. ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 12:51 Message: Logged In: YES user_id=1218811 I didn't see jbelmote's comment, perhaps my updated threadmodule.c will reopen the #1010677 bug. ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 12:39 Message: Logged In: YES user_id=1218811 Here's the updated threadmodule.c for 2.4.1 ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 12:36 Message: Logged In: YES user_id=1218811 I've finally got access to a C compiler and it looks like the 'pure' Python changes for #754449 are in the clear (apologies to bcannon). The problem actually seems to relate to changes to threadmodule.c of the Python Modules directory. In versions greater than 2.3.4 it uses the PyGILState_XXX constructs t_bootstrap() function. These do not seem to be compatible with running sub interpreters as JEP (and probably mod_python) do. The python documentation (http://docs.python.org/api/threads.html) says "Note that the PyGILState_*() functions assume there is only one global interpreter (created automatically by Py_Initialize()). Python still supports the creation of additional interpreters (using Py_NewInterpreter()), but mixing multiple interpreters and the PyGILState_*() API is unsupported. " I've compiled a new versions of the python2X.dll for both 2.3.5 and 2.4.1 changing the use of these PyGIL_StateXXX constructs back to the 2.3.4 form and this seems to resolve the problem (I've attached the updated threadmodule.c files for both 2.3.5 and 2.4.1). ---------------------------------------------------------------------- Comment By: John Belmonte (jbelmonte) Date: 2005-04-16 21:27 Message: Logged In: YES user_id=282299 This problem also occurs on Linux. Note however that I've traced the source of the symptom to a different bug fix, namely [1010677] thread Module Breaks PyGILState_Ensure() (http://sourceforge.net/tracker/index.php?func=detail&aid=1010677&group_id=5470&atid=305470). Specifically, the change from v2.56 to v2.56.8.1 of threadmodule.c. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-16 20:21 Message: Logged In: YES user_id=357491 To answer the comment on bug #754449 and the email I got from someone, there is no way my fix for that bug would cause this. I only touched the 'threading' module, nothing else. That is in pure Python and thus has no direct way of modifying what does and does not execute in restricted mode. If I understand how restricted execution works that is all set at the C level. Plus the fix only deals with the teardown code; it in no way interfaces with how threads are executed. All changed code come after the thread and completed execution. The only thing it does ahead of time is store a reference to stdout. In other words it ain't my fault to the best of my knowledge. =) ---------------------------------------------------------------------- Comment By: Alan Davies (goatpunch) Date: 2005-03-31 07:24 Message: Logged In: YES user_id=967140 The same problem definately does occur with mod_python, I've found it to occur with Python 2.3.5 and 2.4 on Win32: http://www.modpython.org/pipermail/mod_python/2005- March/017802.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 From noreply at sourceforge.net Thu May 12 10:48:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 May 2005 01:48:05 -0700 Subject: [ python-Bugs-1163563 ] Sub threads execute in restricted mode Message-ID: Bugs item #1163563, was opened at 2005-03-15 09:56 Message generated for change (Comment added) made by yetanothermax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: anothermax (yetanothermax) Assigned to: Nobody/Anonymous (nobody) Summary: Sub threads execute in restricted mode Initial Comment: I'm using the JEP product which allows integration of Java with Python (see http://jepp.sourceforge.net) via starting a Python interpreter in the same process as the JVM. This integrates with python via the C interface, allowing the user to 'eval' python code (amongst other features). It seems that since Python 2.3.5 any threads (using the threading module) created via code that has been evaluated through the jep.eval() interface (i.e.Python C interface )are executed in restricted mode and cannot, for example, create files. Code that is just evaled (i.e not in a subthread) thread has no restrictions. The error reported is: IOError: file() constructor not accessible in restricted mode (see http://sourceforge.net/forum/forum.php? thread_id=1247793&forum_id=376782) - I've given a JEP specific example here. There seems to be a similar problem with mod_python (see http://www.modpython.org/pipermail/mod_python/2005- January/017129.html) Reading through the release notes for Python 2.3.5 I see: Bug #754449: threading.Thread will no longer mask exceptions raised during interpreter shutdown with another exception caused by attempting to output the initial exception. This fix also includes a backport of rev. 1.41 from HEAD. This might be the problem as it seems to involve the porting of 2.4 threading code back to the 2.3 tree. I've attached a Java file which shows the problem when using JEP. The error output is: Exception in thread Thread-1: Traceback (most recent call last): File "C:\Python24\Lib\threading.py", line 442, in __bootstrap File "", line 5, in run IOError: file() constructor not accessible in restricted mode 2.4.1c1 (#63, Mar 10 2005, 10:36:41) [MSC v.1310 32 bit (Intel)] Creating file from main thread... Done Creating file from sub thread... Done ---------------------------------------------------------------------- >Comment By: anothermax (yetanothermax) Date: 2005-05-12 10:48 Message: Logged In: YES user_id=1218811 It looks like with Python versions > 2.3.4 threads are off limits for multiple interpreters. If that's your definition of screwed then I guess the answer's yes. I'm surprised more mod_python users haven't been bitten by this. Shall I raise theproblem on the list (I've already done so on comp.lang.python a while ago) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-12 09:43 Message: Logged In: YES user_id=6656 I saw the subject and thought "Hmm, should raise the priority of this so it gets at least thought about hard by the next release", then saw that you did that... > How do we get this solved for the next Python release? I don't know. It's possible it should be raised on python-dev (it seems fairly quiet just now, so it might be a good time :). Basically, it seems that the whole multiple interpreters facility is screwed, correct? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-12 09:35 Message: Logged In: YES user_id=1218811 This problem prevents us from upgrading to Python 2.4. I've attached a another 'fixed' threadmodule.c which is based upon the lastest CVS release.(Only change from the last threadmodule.c attachment is the removal of a '\n' from an error message). The threadtest.c program demonstrates the problem (seems to be the use of Py_NewInterpreter() with the PyGIL_StateXXX functions in the current threadmodule.c). How do we get this solved for the next Python release? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-21 14:05 Message: Logged In: YES user_id=1218811 I've attached a file (threadtest.c) that is adapted from the the way JEP uses Py_NewInterpreter. This runs correctly under 2.3.4 but fails under 2.3.5 and later Pythons. ---------------------------------------------------------------------- Comment By: mrjohnson (mrjohnson0) Date: 2005-04-21 07:51 Message: Logged In: YES user_id=1044885 In interactive mode, Jep uses Py_NewInterpreter, Py_CompileString, and PyRun_String for its eval(). This file handles java -> python: http://204.156.146.230/cgi-bin/viewcvs.cgi/jep/pyembed.c?rev=1.29&content-type=text/vnd.viewcvs-markup You'd be looking for pyembed_eval(). ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-04-21 05:11 Message: Logged In: YES user_id=14198 Can anyone tell me specifically what Python C API function is involved here? ie, the "entry point" that these external threads use to call into Python. ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 13:51 Message: Logged In: YES user_id=1218811 I didn't see jbelmote's comment, perhaps my updated threadmodule.c will reopen the #1010677 bug. ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 13:39 Message: Logged In: YES user_id=1218811 Here's the updated threadmodule.c for 2.4.1 ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 13:36 Message: Logged In: YES user_id=1218811 I've finally got access to a C compiler and it looks like the 'pure' Python changes for #754449 are in the clear (apologies to bcannon). The problem actually seems to relate to changes to threadmodule.c of the Python Modules directory. In versions greater than 2.3.4 it uses the PyGILState_XXX constructs t_bootstrap() function. These do not seem to be compatible with running sub interpreters as JEP (and probably mod_python) do. The python documentation (http://docs.python.org/api/threads.html) says "Note that the PyGILState_*() functions assume there is only one global interpreter (created automatically by Py_Initialize()). Python still supports the creation of additional interpreters (using Py_NewInterpreter()), but mixing multiple interpreters and the PyGILState_*() API is unsupported. " I've compiled a new versions of the python2X.dll for both 2.3.5 and 2.4.1 changing the use of these PyGIL_StateXXX constructs back to the 2.3.4 form and this seems to resolve the problem (I've attached the updated threadmodule.c files for both 2.3.5 and 2.4.1). ---------------------------------------------------------------------- Comment By: John Belmonte (jbelmonte) Date: 2005-04-16 22:27 Message: Logged In: YES user_id=282299 This problem also occurs on Linux. Note however that I've traced the source of the symptom to a different bug fix, namely [1010677] thread Module Breaks PyGILState_Ensure() (http://sourceforge.net/tracker/index.php?func=detail&aid=1010677&group_id=5470&atid=305470). Specifically, the change from v2.56 to v2.56.8.1 of threadmodule.c. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-16 21:21 Message: Logged In: YES user_id=357491 To answer the comment on bug #754449 and the email I got from someone, there is no way my fix for that bug would cause this. I only touched the 'threading' module, nothing else. That is in pure Python and thus has no direct way of modifying what does and does not execute in restricted mode. If I understand how restricted execution works that is all set at the C level. Plus the fix only deals with the teardown code; it in no way interfaces with how threads are executed. All changed code come after the thread and completed execution. The only thing it does ahead of time is store a reference to stdout. In other words it ain't my fault to the best of my knowledge. =) ---------------------------------------------------------------------- Comment By: Alan Davies (goatpunch) Date: 2005-03-31 08:24 Message: Logged In: YES user_id=967140 The same problem definately does occur with mod_python, I've found it to occur with Python 2.3.5 and 2.4 on Win32: http://www.modpython.org/pipermail/mod_python/2005- March/017802.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 From noreply at sourceforge.net Thu May 12 12:17:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 May 2005 03:17:28 -0700 Subject: [ python-Bugs-1199282 ] subprocess _active.remove(self) self not in list _active Message-ID: Bugs item #1199282, was opened at 2005-05-10 18:24 Message generated for change (Comment added) made by atila-cheops You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470 Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: cheops (atila-cheops) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess _active.remove(self) self not in list _active Initial Comment: I start a subprocess in a seperate thread (25 concurrent threads) in some of the threads the following error occurs Exception in thread Thread-4: Traceback (most recent call last): File "C:\Python24\lib\threading.py", line 442, in __bootstrap self.run() File "upgrade.py", line 45, in run returncode = p.wait() File "C:\Python24\lib\subprocess.py", line 765, in wait _active.remove(self) ValueError: list.remove(x): x not in list this is the code that starts the subprocess and where I wait for the result p = subprocess.Popen('command', stdin=None, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, universal_newlines=True) returncode = p.wait() errormessage = p.stdout.readlines() ---------------------------------------------------------------------- >Comment By: cheops (atila-cheops) Date: 2005-05-12 10:17 Message: Logged In: YES user_id=1276121 this might be related to bug 1183780 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470 From noreply at sourceforge.net Thu May 12 16:19:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 May 2005 07:19:31 -0700 Subject: [ python-Bugs-1200686 ] SyntaxError raised on win32 for correct files Message-ID: Bugs item #1200686, was opened at 2005-05-12 16:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200686&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Federico Di Gregorio (fog) Assigned to: Nobody/Anonymous (nobody) Summary: SyntaxError raised on win32 for correct files Initial Comment: Try to import the attached file (dt.py) on Windows with Python 2.4 or 2.4.1 and you'll get a SyntaxError (the file was written a long time ago, and worked perfectly well on Python 2.1, 2.2 and 2.3.) The same does not happen when importing the same module on Linux (tested with 2.4 and 2.4.1). When the module imports fine you'll get an ImportError (don't want to attach all dependencies here) but the SyntaxError comes before that. Also note that compiling the file with compiler.compileFile("dt.py") generates a perfectly good .pyc file that can be later imported just fine (tested with 2.4 and 2.4.1 on Windows). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200686&group_id=5470 From noreply at sourceforge.net Thu May 12 16:34:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 May 2005 07:34:30 -0700 Subject: [ python-Bugs-1195984 ] SystemError: error return without exception set Message-ID: Bugs item #1195984, was opened at 2005-05-05 11:38 Message generated for change (Comment added) made by nbajpai You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1195984&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Niraj Bajpai (nbajpai) Assigned to: Nobody/Anonymous (nobody) Summary: SystemError: error return without exception set Initial Comment: I am getting following error with Python 2.4.1 relase: "SystemError: error return without exception set" my code works fine with earlier release (python 2.4). Its a C code build in python so does not leave much traces to describe problem more. Important Notes: Release name: 2.4.1(final) Platform: Solaris 2.8 Error: "SystemError: error return without exception set" ---------------------------------------------------------------------- >Comment By: Niraj Bajpai (nbajpai) Date: 2005-05-12 10:34 Message: Logged In: YES user_id=1165734 Agree with the comments made. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-11 19:07 Message: Logged In: YES user_id=593130 When people mix their own C code with CPython and get a SystemError like this, the probability that the error is in the added code and not the core code is perhaps greater than .95. Please consider closing this report as invalid unless and until you have evidence that the problem is indeed in the core code. To get help reviewing your added code, you can post to comp.lang.python, the general Python mailing list (python.org), or gmane.comp.python.general (gmane.org). To me, the Python error message seems meaningful enough. It seems to claim that you made an error return without setting an exception according to the rules of the C API. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-10 09:52 Message: Logged In: YES user_id=6656 Are you writing your own C code? If so, why do you suspect a bug in Python itself? (Also, a debug build of python can be useful for this sort of thing). ---------------------------------------------------------------------- Comment By: Niraj Bajpai (nbajpai) Date: 2005-05-10 09:50 Message: Logged In: YES user_id=1165734 Actually the same error happens in both 2.4 and 2.4.1. I call in python code to receive events from C code embedded in python interpreter. There are two meaningful events and idle event. I commented idle event in the code (C-code) and start seeing this error. from python code: x.receive(A) <<<<<<-------- Error happens here where A can be , receive "X" or receive "Y" or receive "NOTHING" In C code when I comment "NOTHING" event generator, I get the error. Some meaningful exception in python would have been better. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-06 07:45 Message: Logged In: YES user_id=6656 Uh, there's not a lot to go on here. Can you post some code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1195984&group_id=5470 From noreply at sourceforge.net Thu May 12 16:41:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 May 2005 07:41:01 -0700 Subject: [ python-Bugs-834351 ] Mouse wheel crashes program Message-ID: Bugs item #834351, was opened at 2003-11-02 00:37 Message generated for change (Comment added) made by orthorim You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834351&group_id=5470 Category: Tkinter Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary Richardson (garyrxx) Assigned to: Martin v. L?wis (loewis) Summary: Mouse wheel crashes program Initial Comment: The following program (by Michael Peuser) crashes as soon as the mouse wheel is moved. See my post to c.l.p. on Oct 29. Gary Richardson #------------------------- from Tkinter import * def _onMouseWheel(event): print event root = Tk() root.bind('<MouseWheel>',_onMouseWheel) root.mainloop() ---------------------------------------------------------------------- Comment By: nikolaus heger (orthorim) Date: 2005-05-12 14:41 Message: Logged In: YES user_id=933256 sdati, thanks for this workaround. it's awesome. i am now happily mouse-wheeling :) I did make a small improvement to it so it works for all MouseWheel type events. Instead of if sequence == "": i say if type(sequence) == str and sequence.__contains__("MouseWheel"): This way, all permutations of mouse events are covered, e.g. "" ---------------------------------------------------------------------- Comment By: Steve Davis (sdati) Date: 2005-02-08 02:40 Message: Logged In: YES user_id=1214285 I have determined the root cause of this problem. It actually does lie in Tk, but is only revealed by Python Tkinter because of the way Python deals with events. >From Tk source -- tkWinX.c: case WM_MOUSEWHEEL: ... event.xany.send_event = -1 ... This line causes Tk to call TkpGetString() when ExpandPercents() is called with '%A' (which is done by Python for ALL events, including ). This, in turn, causes segmentation fault because event.xkey.trans_chars and event.xkey.nbytes are not initialized. So, the workaround from the Python side is pretty ugly, but I have tested it and verified that it works. There is probably a better way, but this was the obvious solution to me, since I have never needed to look at the Tkinter interface before: In Tkinter.py, define a new _subst_format and _subst_format_str: _subst_format_workaround = ('%#', '%b', '%f', '%h', '%k', '%s', '%t', '%w', '%x', '%y', '%D', '%E', '%K', '%N', '%W', '%T', '%X', '%Y', '%D') _subst_format_str_workaround = " ".join(_subst_format_workaround) Note that '%A' entry in _subst_format is replaced with '%D' entry in _subst_format_workaround. Now, in Misc._bind(), if sequence == "": cmd = ('%sif {"[%s %s]" == "break"} break\n' % (add and '+' or '', funcid, self._subst_format_str_workaround)) else: cmd = ('%sif {"[%s %s]" == "break"} break\n' % (add and '+' or '', funcid, self._subst_format_str)) I am submitting this bug to Tcl/Tk maintainers to request that they fix (Project: Tk Toolkit Request ID 1118340), but in the meantime (and for all older versions of Tk), it seems like a workaround in the Tkinter code might be appropriate. ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2005-01-04 15:40 Message: Logged In: YES user_id=2138 I wasn't able to reproduce this in pure Tcl/Tk (under Wish). No surprise there. In wish, I used this: toplevel .top bind .top {puts 'foo'} And mouse wheeling in the Toplevel widget made a bunch of 'foo's appear in the wish console without crashing. HTH. ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2005-01-04 15:02 Message: Logged In: YES user_id=2138 Me too. Python 2.3.4 with Tcl/Tk 8.4.9. Crash on Scroll Wheeling in WinXP SP 1. (users report it happening in SP 2 also). I'll try to make this happen in pure Tcl/Tk rather than Tkinter too. ---------------------------------------------------------------------- Comment By: John Fouhy (johnfouhy) Date: 2004-10-26 04:13 Message: Logged In: YES user_id=1084032 I can reproduce this bug. I am running Python 2.3.4 on WinXP SP2. tk84.dll is version 8.4.3; tcl84.dll is also 8.4.3. The mousewheel works correctly with a Tkinter.Text object with no additional bindings. ---------------------------------------------------------------------- Comment By: Jon Ashley (ash101) Date: 2003-12-04 17:02 Message: Logged In: YES user_id=923903 Happens for me too, on Win2K with python 2.3.2. The fault is in TCL84.DLL at an offset of 1002a58c, if that means anything to anyone. ---------------------------------------------------------------------- Comment By: Gary Richardson (garyrxx) Date: 2003-11-03 02:42 Message: Logged In: YES user_id=899035 I'm using Win98SE. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-02 18:37 Message: Logged In: YES user_id=21627 What operating system are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834351&group_id=5470 From noreply at sourceforge.net Thu May 12 18:26:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 May 2005 09:26:34 -0700 Subject: [ python-Feature Requests-1200804 ] enhancing os.chown functionality Message-ID: Feature Requests item #1200804, was opened at 2005-05-12 16:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1200804&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: gyrof (gyrof) Assigned to: Nobody/Anonymous (nobody) Summary: enhancing os.chown functionality Initial Comment: Hi, I don't think it is currently possible (with os.chown or any other Python library function) to change the groupId of a file without specifying the userId (like posix 'chgrp' does), or to change the userId without specifying the groupId. I would suggest adding the option of having os.chown accept None as either the userId or groupId, and having the function change only the 'non-None' portion of the file ownership. Thanks for your consideration. -g ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1200804&group_id=5470 From noreply at sourceforge.net Fri May 13 17:23:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 May 2005 08:23:05 -0700 Subject: [ python-Bugs-1201438 ] Wrong word on "raise" page Message-ID: Bugs item #1201438, was opened at 2005-05-13 11:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201438&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Erik Rose (grincheroo) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong word on "raise" page Initial Comment: At http://python.org/doc/2.4.1/ref/raise.html, the first occurrence of "last expression" should be "last exception". This is corroborated by the next clause, which reads, correctly, "If no exception is active in the current scope...". Thanks for fine docs! Erik ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201438&group_id=5470 From noreply at sourceforge.net Fri May 13 17:43:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 May 2005 08:43:20 -0700 Subject: [ python-Bugs-1201456 ] Problem with recursion in dict (crash with core dump) Message-ID: Bugs item #1201456, was opened at 2005-05-13 19:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Vladimir Yu. Stepanov (vys) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with recursion in dict (crash with core dump) Initial Comment: Please see example code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&group_id=5470 From noreply at sourceforge.net Fri May 13 17:46:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 May 2005 08:46:21 -0700 Subject: [ python-Bugs-1201456 ] Problem with recursion in dict (crash with core dump) Message-ID: Bugs item #1201456, was opened at 2005-05-13 16:43 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Vladimir Yu. Stepanov (vys) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with recursion in dict (crash with core dump) Initial Comment: Please see example code. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-05-13 16:46 Message: Logged In: YES user_id=6656 I see no code. SF can be a pain with this... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&group_id=5470 From noreply at sourceforge.net Fri May 13 17:46:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 May 2005 08:46:59 -0700 Subject: [ python-Bugs-1201456 ] Problem with recursion in dict (crash with core dump) Message-ID: Bugs item #1201456, was opened at 2005-05-13 19:43 Message generated for change (Comment added) made by vys You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Vladimir Yu. Stepanov (vys) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with recursion in dict (crash with core dump) Initial Comment: Please see example code. ---------------------------------------------------------------------- >Comment By: Vladimir Yu. Stepanov (vys) Date: 2005-05-13 19:46 Message: Logged In: YES user_id=384980 d = {} class test: def __hash__(self): d[self] = None d[test()] = None ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-13 19:46 Message: Logged In: YES user_id=6656 I see no code. SF can be a pain with this... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&group_id=5470 From noreply at sourceforge.net Fri May 13 17:49:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 May 2005 08:49:18 -0700 Subject: [ python-Bugs-1201461 ] suspected cPickle memory leak Message-ID: Bugs item #1201461, was opened at 2005-05-13 15:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201461&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Alan (franz2) Assigned to: Nobody/Anonymous (nobody) Summary: suspected cPickle memory leak Initial Comment: I believe there is a memory leak in cPickle. I have a parallel code which uses array() and indices() from Numeric to massage data buffers before being sent and received by Pypar. Pypar subsequently uses cPickle to pickle the data. After many hours of execution, my code crashes with one of the following error messages (depending upon the run): a = zeros(shape, typecode, savespace) MemoryError: can't allocate memory for array or: s = dumps(x, 1) MemoryError: out of memory I have since modified my code to use a different data format so cPickle is no longer used from PyPar and now the code runs fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201461&group_id=5470 From noreply at sourceforge.net Fri May 13 17:55:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 May 2005 08:55:00 -0700 Subject: [ python-Bugs-1201456 ] Problem with recursion in dict (crash with core dump) Message-ID: Bugs item #1201456, was opened at 2005-05-13 16:43 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Vladimir Yu. Stepanov (vys) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with recursion in dict (crash with core dump) Initial Comment: Please see example code. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-05-13 16:55 Message: Logged In: YES user_id=6656 I get an infinite recursion runtime error. What platform are you on? ---------------------------------------------------------------------- Comment By: Vladimir Yu. Stepanov (vys) Date: 2005-05-13 16:46 Message: Logged In: YES user_id=384980 d = {} class test: def __hash__(self): d[self] = None d[test()] = None ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-13 16:46 Message: Logged In: YES user_id=6656 I see no code. SF can be a pain with this... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&group_id=5470 From noreply at sourceforge.net Fri May 13 17:55:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 May 2005 08:55:25 -0700 Subject: [ python-Bugs-1201456 ] Problem with recursion in dict (crash with core dump) Message-ID: Bugs item #1201456, was opened at 2005-05-13 10:43 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Vladimir Yu. Stepanov (vys) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with recursion in dict (crash with core dump) Initial Comment: Please see example code. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-13 10:55 Message: Logged In: YES user_id=80475 I get the expected behavior: RuntimeError: maximum recursion depth exceeded ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-13 10:55 Message: Logged In: YES user_id=6656 I get an infinite recursion runtime error. What platform are you on? ---------------------------------------------------------------------- Comment By: Vladimir Yu. Stepanov (vys) Date: 2005-05-13 10:46 Message: Logged In: YES user_id=384980 d = {} class test: def __hash__(self): d[self] = None d[test()] = None ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-13 10:46 Message: Logged In: YES user_id=6656 I see no code. SF can be a pain with this... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&group_id=5470 From noreply at sourceforge.net Fri May 13 17:58:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 May 2005 08:58:06 -0700 Subject: [ python-Bugs-1201438 ] Wrong word on "raise" page Message-ID: Bugs item #1201438, was opened at 2005-05-13 10:23 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201438&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Erik Rose (grincheroo) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong word on "raise" page Initial Comment: At http://python.org/doc/2.4.1/ref/raise.html, the first occurrence of "last expression" should be "last exception". This is corroborated by the next clause, which reads, correctly, "If no exception is active in the current scope...". Thanks for fine docs! Erik ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-13 10:58 Message: Logged In: YES user_id=80475 This duplicates SF bug #1190451 which was fixed on 4/28/2005. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201438&group_id=5470 From noreply at sourceforge.net Fri May 13 18:06:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 May 2005 09:06:53 -0700 Subject: [ python-Bugs-1201456 ] Problem with recursion in dict (crash with core dump) Message-ID: Bugs item #1201456, was opened at 2005-05-13 19:43 Message generated for change (Comment added) made by vys You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Vladimir Yu. Stepanov (vys) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with recursion in dict (crash with core dump) Initial Comment: Please see example code. ---------------------------------------------------------------------- >Comment By: Vladimir Yu. Stepanov (vys) Date: 2005-05-13 20:06 Message: Logged In: YES user_id=384980 This is output from `uname -a`: FreeBSD fox.renet.ru 5.3-RELEASE FreeBSD 5.3-RELEASE #1: Fri Apr 15 10:38:49 MSD 2005 root at fox.renet.ru:/M/safedir/src/sys/i386/compile/FOX i386 I get some others with this code: Python 2.4.1 (#2, Apr 26 2005, 14:16:31) [GCC 3.4.2 [FreeBSD] 20040728] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> d = {} >>> >>> class test: ... def __hash__(self): ... d[self] = None ... >>> d[test()] = None Bus error (core dumped) fox:vys!~ > gdb python python.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Core was generated by `python'. Program terminated with signal 10, Bus error. (gdb) where #0 0x2828b3b1 in ldexp () from /lib/libc.so.5 #1 0x2828b618 in malloc () from /lib/libc.so.5 #2 0x080bdca1 in _PyObject_GC_Malloc () #3 0x080bdd4a in _PyObject_GC_New () #4 0x0805f556 in PyMethod_New () #5 0x0805c1a6 in PyInstance_NewRaw () #6 0x0805c66a in PyInstance_New () #7 0x0805cca1 in _PyInstance_Lookup () #8 0x080703e6 in PyDict_SetItem () #9 0x0809bb0e in PyEval_EvalFrame () #10 0x0809fc20 in PyEval_EvalCodeEx () #11 0x080d4d66 in PyFunction_SetClosure () #12 0x0805a38c in PyObject_Call () #13 0x0805fbe2 in PyMethod_New () #14 0x0805a38c in PyObject_Call () #15 0x08099f1b in PyEval_CallObjectWithKeywords () #16 0x0805ccb9 in _PyInstance_Lookup () #17 0x080703e6 in PyDict_SetItem () #18 0x0809bb0e in PyEval_EvalFrame () #19 0x0809fc20 in PyEval_EvalCodeEx () #20 0x080d4d66 in PyFunction_SetClosure () #21 0x0805a38c in PyObject_Call () #22 0x0805fbe2 in PyMethod_New () ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-13 19:55 Message: Logged In: YES user_id=80475 I get the expected behavior: RuntimeError: maximum recursion depth exceeded ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-13 19:55 Message: Logged In: YES user_id=6656 I get an infinite recursion runtime error. What platform are you on? ---------------------------------------------------------------------- Comment By: Vladimir Yu. Stepanov (vys) Date: 2005-05-13 19:46 Message: Logged In: YES user_id=384980 d = {} class test: def __hash__(self): d[self] = None d[test()] = None ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-13 19:46 Message: Logged In: YES user_id=6656 I see no code. SF can be a pain with this... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&group_id=5470 From noreply at sourceforge.net Fri May 13 21:07:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 May 2005 12:07:15 -0700 Subject: [ python-Bugs-1198275 ] time module ignores timezone changes Message-ID: Bugs item #1198275, was opened at 2005-05-09 08:14 Message generated for change (Comment added) made by jdalambert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1198275&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Lambert (jdalambert) Assigned to: Brett Cannon (bcannon) Summary: time module ignores timezone changes Initial Comment: Running on Fedora Core 3 Linux Consider the simple program import time while 1: print time.localtime() time.sleep(1) The tuple printed by this program does not reflect any change in the system timezone until the interpreter is exited and restarted. Using reload(time) does not fix the problem. Are there any workarounds? ---------------------------------------------------------------------- >Comment By: David Lambert (jdalambert) Date: 2005-05-13 14:07 Message: Logged In: YES user_id=845425 Yes that worked fine thanks. I guess I just had not been Reading The (updated) Fine Manual :-( ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-05-11 15:35 Message: Logged In: YES user_id=357491 OK, fixed the version and reopened this. No, you don't need to poll, just call time.tzset() before you call time.localtime() or anything else that relies on the timezone. It isn't that expensive of a call. Post here if that fixes it or not. And in terms of inelegance, the only other solution is to implicitly call time.tzset() internally for all time functions. This is an issue imposed by the ISO C libraries. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-05-10 21:33 Message: Logged In: YES user_id=845425 Ouch! I don't know how I got 2.2.3 on the bug report? My version of Python is 2.3.4. Sorry for the confusion.:-( Let me explain further. The problem is that I have a Python script that is run as a daemon and uses localtime(). If another program (outside of my control) changes the timezone, the my daemon gets the local time according to the original timezone. Do I have to periodically poll to see if the timezone has changed? That seems somewhat inelegant. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-05-10 18:10 Message: Logged In: YES user_id=357491 Wait, I just noticed after I sent my follow-up that this bug report is against Python 2.2.3 . You won't find time.tzset() that far back. The issue is that you need to use time.tzset() to reset the timezone for the C library functions to use any change you have made since they cache information internally. I am closing this as "won't fix" since it has been resolved in later versions and 2.2 is too old to bother backporting for. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-05-10 18:07 Message: Logged In: YES user_id=357491 David, how did you change the timezone? And did you call time.tzset()? If you didn't call time.tzset(), that's the problem. If you did, then there is a bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-09 22:09 Message: Logged In: YES user_id=80475 Brett, are you still in the time business? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1198275&group_id=5470 From noreply at sourceforge.net Fri May 13 23:04:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 May 2005 14:04:29 -0700 Subject: [ python-Bugs-1198275 ] time module ignores timezone changes Message-ID: Bugs item #1198275, was opened at 2005-05-09 06:14 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1198275&group_id=5470 Category: Extension Modules Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: David Lambert (jdalambert) Assigned to: Brett Cannon (bcannon) Summary: time module ignores timezone changes Initial Comment: Running on Fedora Core 3 Linux Consider the simple program import time while 1: print time.localtime() time.sleep(1) The tuple printed by this program does not reflect any change in the system timezone until the interpreter is exited and restarted. Using reload(time) does not fix the problem. Are there any workarounds? ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-05-13 14:04 Message: Logged In: YES user_id=357491 Cool, glad it worked out. Closed as invalid. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-05-13 12:07 Message: Logged In: YES user_id=845425 Yes that worked fine thanks. I guess I just had not been Reading The (updated) Fine Manual :-( ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-05-11 13:35 Message: Logged In: YES user_id=357491 OK, fixed the version and reopened this. No, you don't need to poll, just call time.tzset() before you call time.localtime() or anything else that relies on the timezone. It isn't that expensive of a call. Post here if that fixes it or not. And in terms of inelegance, the only other solution is to implicitly call time.tzset() internally for all time functions. This is an issue imposed by the ISO C libraries. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-05-10 19:33 Message: Logged In: YES user_id=845425 Ouch! I don't know how I got 2.2.3 on the bug report? My version of Python is 2.3.4. Sorry for the confusion.:-( Let me explain further. The problem is that I have a Python script that is run as a daemon and uses localtime(). If another program (outside of my control) changes the timezone, the my daemon gets the local time according to the original timezone. Do I have to periodically poll to see if the timezone has changed? That seems somewhat inelegant. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-05-10 16:10 Message: Logged In: YES user_id=357491 Wait, I just noticed after I sent my follow-up that this bug report is against Python 2.2.3 . You won't find time.tzset() that far back. The issue is that you need to use time.tzset() to reset the timezone for the C library functions to use any change you have made since they cache information internally. I am closing this as "won't fix" since it has been resolved in later versions and 2.2 is too old to bother backporting for. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-05-10 16:07 Message: Logged In: YES user_id=357491 David, how did you change the timezone? And did you call time.tzset()? If you didn't call time.tzset(), that's the problem. If you did, then there is a bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-09 20:09 Message: Logged In: YES user_id=80475 Brett, are you still in the time business? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1198275&group_id=5470 From noreply at sourceforge.net Sat May 14 08:11:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 May 2005 23:11:46 -0700 Subject: [ python-Bugs-1201807 ] Glossary listing bug Message-ID: Bugs item #1201807, was opened at 2005-05-14 15:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201807&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: Glossary listing bug Initial Comment: On the glossary page[*], "duck-typing" is not recognized as an entry for glossary. Currently, the rendered html is:
duck-typing Pythonic programming style ...
And this should look like:
duck-typing
Pythonic programming style ...
Replacing '{' mark with '[' mark should fix this. \index{duck-typing} -\item{duck-typing} +\item[duck-typing] [*] http://docs.python.org/tut/node18.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201807&group_id=5470 From noreply at sourceforge.net Sat May 14 18:57:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 May 2005 09:57:28 -0700 Subject: [ python-Bugs-1202018 ] mimetypes.py does not find mime.types on Mac OS X Message-ID: Bugs item #1202018, was opened at 2005-05-14 18:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202018&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan H. Holek (shh42) Assigned to: Nobody/Anonymous (nobody) Summary: mimetypes.py does not find mime.types on Mac OS X Initial Comment: Python 2.3 and 2.4 (dunno about 2.5) The mimetypes.py library does not find the mime.types files on Mac OS X. They are in: /etc/cups/mime.types and /etc/httpd/mime.types respectively. As a result not all mimetypes are recognized by Python. The one in / etc/cups is fairly limited, so including the Apache one as well seems like a good idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202018&group_id=5470 From noreply at sourceforge.net Sat May 14 18:59:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 May 2005 09:59:56 -0700 Subject: [ python-Bugs-1202018 ] mimetypes.py does not find mime.types on Mac OS X Message-ID: Bugs item #1202018, was opened at 2005-05-14 18:57 Message generated for change (Comment added) made by shh42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202018&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan H. Holek (shh42) Assigned to: Nobody/Anonymous (nobody) Summary: mimetypes.py does not find mime.types on Mac OS X Initial Comment: Python 2.3 and 2.4 (dunno about 2.5) The mimetypes.py library does not find the mime.types files on Mac OS X. They are in: /etc/cups/mime.types and /etc/httpd/mime.types respectively. As a result not all mimetypes are recognized by Python. The one in / etc/cups is fairly limited, so including the Apache one as well seems like a good idea. ---------------------------------------------------------------------- >Comment By: Stefan H. Holek (shh42) Date: 2005-05-14 18:59 Message: Logged In: YES user_id=864871 This is a with a standalone build of Python, I am not talking about the Python shipping with the system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202018&group_id=5470 From noreply at sourceforge.net Sat May 14 19:26:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 May 2005 10:26:08 -0700 Subject: [ python-Bugs-1201807 ] Glossary listing bug Message-ID: Bugs item #1201807, was opened at 2005-05-14 01:11 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201807&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: Glossary listing bug Initial Comment: On the glossary page[*], "duck-typing" is not recognized as an entry for glossary. Currently, the rendered html is:
duck-typing Pythonic programming style ...
And this should look like:
duck-typing
Pythonic programming style ...
Replacing '{' mark with '[' mark should fix this. \index{duck-typing} -\item{duck-typing} +\item[duck-typing] [*] http://docs.python.org/tut/node18.html ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-14 12:26 Message: Logged In: YES user_id=80475 Fixed. Thanks for the report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201807&group_id=5470 From noreply at sourceforge.net Sun May 15 09:57:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 May 2005 00:57:26 -0700 Subject: [ python-Bugs-1118729 ] Error in representation of complex numbers(again) Message-ID: Bugs item #1118729, was opened at 2005-02-08 17:26 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118729&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Martin v. L?wis (loewis) Summary: Error in representation of complex numbers(again) Initial Comment: >>> -(1+0j) (-1+-0j) I encountered this while I was calculating conjugate of complex numbers(e.g. z.conjugate()). Related bug * http://www.python.org/sf/1013908 One thing to note is that -(0j) can return 0j or -0j dependeing on OSes. Confirmed on SuSE 9.1 & cygwin. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-05-15 09:57 Message: Logged In: YES user_id=21627 What do you think about the patch attached? ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-03-19 18:11 Message: Logged In: YES user_id=671362 Martin, what's your take on this? The representation of '-(1+0j)' has changed since Revision 2.71 (complexobject.c) and you applied the patch. # original patch making Python LC_NUMERIC agnostic http://www.python.org/sf/774665 ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-02-10 01:02 Message: Logged In: YES user_id=671362 Hi, Bj?rn. Sorry, not to be clear about what my complaint is. I'm not talking about if -(0j) should be 0j or -0j. It's been that way for a long time, so changing it would break old codes. My point is the signature of imaginary part. As you can see, it's represented as '+-'. Before the commit of patch #774665, it was represented as '-1-0j'. But after that, '-1+-0j'. If you test it with Python <= 2.3, you'll get (-1-0j) and I think this is how -(1+0j) should be represented on machines where - (0j) is represented as -0j. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2005-02-09 19:54 Message: Logged In: YES user_id=51702 What you are seeing is negative zero (-0.0). It is distinct from positive zero (0.0) but 0.0 == -0.0 is always true. On some machines you can also see it by typing: >>> -0.0 -0.0 On other machines you will see "0.0" instead. You can also try printf("%f\n", -0.0); and you will notice the same thing. So I'm not sure it is a bug per se. However, it can be worked around by adding "if (v->cval.imag == 0.) v->cval.imag = 0.0;" to complexobject.c, assuming ofcourse it is OK to change negative zeros to positive ones. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118729&group_id=5470 From noreply at sourceforge.net Sun May 15 14:22:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 May 2005 05:22:33 -0700 Subject: [ python-Bugs-1118729 ] Error in representation of complex numbers(again) Message-ID: Bugs item #1118729, was opened at 2005-02-09 01:26 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118729&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Martin v. L?wis (loewis) Summary: Error in representation of complex numbers(again) Initial Comment: >>> -(1+0j) (-1+-0j) I encountered this while I was calculating conjugate of complex numbers(e.g. z.conjugate()). Related bug * http://www.python.org/sf/1013908 One thing to note is that -(0j) can return 0j or -0j dependeing on OSes. Confirmed on SuSE 9.1 & cygwin. ---------------------------------------------------------------------- >Comment By: George Yoshida (quiver) Date: 2005-05-15 21:22 Message: Logged In: YES user_id=671362 The fix seems reasonable to me and it passed the test suites. Please apply it. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-15 16:57 Message: Logged In: YES user_id=21627 What do you think about the patch attached? ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-03-20 02:11 Message: Logged In: YES user_id=671362 Martin, what's your take on this? The representation of '-(1+0j)' has changed since Revision 2.71 (complexobject.c) and you applied the patch. # original patch making Python LC_NUMERIC agnostic http://www.python.org/sf/774665 ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-02-10 09:02 Message: Logged In: YES user_id=671362 Hi, Bj?rn. Sorry, not to be clear about what my complaint is. I'm not talking about if -(0j) should be 0j or -0j. It's been that way for a long time, so changing it would break old codes. My point is the signature of imaginary part. As you can see, it's represented as '+-'. Before the commit of patch #774665, it was represented as '-1-0j'. But after that, '-1+-0j'. If you test it with Python <= 2.3, you'll get (-1-0j) and I think this is how -(1+0j) should be represented on machines where - (0j) is represented as -0j. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2005-02-10 03:54 Message: Logged In: YES user_id=51702 What you are seeing is negative zero (-0.0). It is distinct from positive zero (0.0) but 0.0 == -0.0 is always true. On some machines you can also see it by typing: >>> -0.0 -0.0 On other machines you will see "0.0" instead. You can also try printf("%f\n", -0.0); and you will notice the same thing. So I'm not sure it is a bug per se. However, it can be worked around by adding "if (v->cval.imag == 0.) v->cval.imag = 0.0;" to complexobject.c, assuming ofcourse it is OK to change negative zeros to positive ones. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118729&group_id=5470 From noreply at sourceforge.net Sun May 15 19:50:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 May 2005 10:50:30 -0700 Subject: [ python-Bugs-1202395 ] Description of string.lstrip() needs improvement Message-ID: Bugs item #1202395, was opened at 2005-05-15 13:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202395&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Roy Smith (roysmith) Assigned to: Nobody/Anonymous (nobody) Summary: Description of string.lstrip() needs improvement Initial Comment: In http://docs.python.org/lib/string-methods.html, under lstrip(), it says, "chars must be a string; the characters in the string will be stripped from the beginning of the string this method is called on". It would be clearer if it said: "chars must be a string; the characters in the string constitute a set of characters to be stripped from the beginning of the string this method is called on". Similarly for rstrip() and strip(). There was a recent posting to comp.lang.python where it appears that the poster thought the argument to lstrip() was a leading string to be removed, not a set of characters. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202395&group_id=5470 From noreply at sourceforge.net Sun May 15 19:55:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 May 2005 10:55:07 -0700 Subject: [ python-Bugs-1202395 ] Description of string.lstrip() needs improvement Message-ID: Bugs item #1202395, was opened at 2005-05-15 13:50 Message generated for change (Comment added) made by roysmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202395&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Roy Smith (roysmith) Assigned to: Nobody/Anonymous (nobody) Summary: Description of string.lstrip() needs improvement Initial Comment: In http://docs.python.org/lib/string-methods.html, under lstrip(), it says, "chars must be a string; the characters in the string will be stripped from the beginning of the string this method is called on". It would be clearer if it said: "chars must be a string; the characters in the string constitute a set of characters to be stripped from the beginning of the string this method is called on". Similarly for rstrip() and strip(). There was a recent posting to comp.lang.python where it appears that the poster thought the argument to lstrip() was a leading string to be removed, not a set of characters. ---------------------------------------------------------------------- >Comment By: Roy Smith (roysmith) Date: 2005-05-15 13:55 Message: Logged In: YES user_id=390499 I notice bug #1196824 (recently submitted and closed as "not a bug") relates to the same issue. It seems more than one person has gotten confused by this :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202395&group_id=5470 From noreply at sourceforge.net Sun May 15 22:53:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 May 2005 13:53:33 -0700 Subject: [ python-Bugs-1202475 ] httplib docs mentioning HTTPConnection.getreply Message-ID: Bugs item #1202475, was opened at 2005-05-15 20:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202475&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: httplib docs mentioning HTTPConnection.getreply Initial Comment: ... instead of getresponse in the description of send(). Also, a general note or explanation like that could be given before the description of send(): """ You can send requests in two ways: either using the request() method as described above, which combines all request parameters, or using a sequence of putrequest(), zero or more times addheader(), endheaders() and then send(). """ It is sort of confusing in its current state. Oh yes, and while you're at it ;), you could add a note that the response object must be read completely before a new request can be sent. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202475&group_id=5470 From noreply at sourceforge.net Sun May 15 23:59:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 May 2005 14:59:16 -0700 Subject: [ python-Bugs-1202493 ] RE parser too loose with {m,n} construct Message-ID: Bugs item #1202493, was opened at 2005-05-15 16:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470 Category: Regular Expressions Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Gustavo Niemeyer (niemeyer) Summary: RE parser too loose with {m,n} construct Initial Comment: This seems wrong to me: >>> re.match("(UNIX{})", "UNIX{}").groups() ('UNIX',) With no numbers or commas, "{}" should not be considered special in the pattern. The docs identify three numeric repetition possibilities: {m}, {m,} and {m,n}. There's no description of {} meaning anything. Either the docs should say {} implies {1,1}, {} should have no special meaning, or an exception should be raised during compilation of the regular expression. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470 From noreply at sourceforge.net Mon May 16 01:43:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 May 2005 16:43:48 -0700 Subject: [ python-Bugs-1202533 ] a bunch of infinite C recursions Message-ID: Bugs item #1202533, was opened at 2005-05-15 23:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 From noreply at sourceforge.net Mon May 16 18:32:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 May 2005 09:32:16 -0700 Subject: [ python-Bugs-1202946 ] Problem with abs function Message-ID: Bugs item #1202946, was opened at 2005-05-16 16:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202946&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ric-b (ric-b) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with abs function Initial Comment: On windows version I get : >>> abs(-9999999999999999999) Traceback (most recent call last): File "", line 1, in -toplevel- abs(-9999999999999999999) OverflowError: long too big to convert does not handle new longs. I am using the following work around: t = a - b # calc t = abs(a - b) if t < 0 : t *= -1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202946&group_id=5470 From noreply at sourceforge.net Mon May 16 19:33:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 May 2005 10:33:52 -0700 Subject: [ python-Bugs-1202946 ] Problem with abs function Message-ID: Bugs item #1202946, was opened at 2005-05-16 11:32 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202946&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ric-b (ric-b) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with abs function Initial Comment: On windows version I get : >>> abs(-9999999999999999999) Traceback (most recent call last): File "", line 1, in -toplevel- abs(-9999999999999999999) OverflowError: long too big to convert does not handle new longs. I am using the following work around: t = a - b # calc t = abs(a - b) if t < 0 : t *= -1 ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-16 12:33 Message: Logged In: YES user_id=80475 That's odd. It works for me: Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> abs(-9999999999999999999) 9999999999999999999L ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202946&group_id=5470 From noreply at sourceforge.net Mon May 16 19:34:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 May 2005 10:34:32 -0700 Subject: [ python-Bugs-602627 ] pydoc -g dumps core on Solaris 2.8 Message-ID: Bugs item #602627, was opened at 2002-08-30 20:51 Message generated for change (Comment added) made by arkoenig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602627&group_id=5470 Category: Demos and Tools Group: Python 2.2.1 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc -g dumps core on Solaris 2.8 Initial Comment: Python 2.2.1, Solaris 2.8, gcc 3.2, binutils 2.12.1 When I execute "pydoc -g", it pops up a dialog box saying "Starting server" and "Search for", and then dumps core before I have time to type anything. The same problem happens on Solaris 2.7 The traceback: Core was generated by `/usr/gnu/bin/python /usr/gnu/bin/pydoc -g'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libsocket.so.1...done. Loaded symbols for /usr/lib/libsocket.so.1 Reading symbols from /usr/lib/libnsl.so.1...done. Loaded symbols for /usr/lib/libnsl.so.1 Reading symbols from /usr/lib/libdl.so.1...done. Loaded symbols for /usr/lib/libdl.so.1 Reading symbols from /usr/lib/libpthread.so.1...done. Loaded symbols for /usr/lib/libpthread.so.1 Reading symbols from /usr/lib/libthread.so.1...done. Loaded symbols for /usr/lib/libthread.so.1 Reading symbols from /usr/gnu/lib/libreadline.so.4...done. Loaded symbols for /usr/gnu/lib/libreadline.so.4 Reading symbols from /usr/lib/libcurses.so.1...done. Loaded symbols for /usr/lib/libcurses.so.1 Reading symbols from /usr/lib/libcrypt_i.so.1...done. Loaded symbols for /usr/lib/libcrypt_i.so.1 Reading symbols from /usr/gnu/lib/libtk8.3.so...done. Loaded symbols for /usr/gnu/lib/libtk8.3.so Reading symbols from /usr/gnu/lib/libtcl8.3.so...done. Loaded symbols for /usr/gnu/lib/libtcl8.3.so Reading symbols from /usr/lib/libX11.so.4...done. Loaded symbols for /usr/lib/libX11.so.4 Reading symbols from /usr/lib/libm.so.1...done. Loaded symbols for /usr/lib/libm.so.1 Reading symbols from /usr/lib/libc.so.1...done. Loaded symbols for /usr/lib/libc.so.1 Reading symbols from /usr/gnu/lib/libgcc_s.so.1...done. Loaded symbols for /usr/gnu/lib/libgcc_s.so.1 Reading symbols from /usr/lib/libmp.so.2...done. Loaded symbols for /usr/lib/libmp.so.2 Reading symbols from /usr/lib/libgen.so.1...done. Loaded symbols for /usr/lib/libgen.so.1 Reading symbols from /usr/openwin/lib/libXext.so.0...done. Loaded symbols for /usr/openwin/lib/libXext.so.0 Reading symbols from /usr/openwin/lib/libdga.so.1...done. Loaded symbols for /usr/openwin/lib/libdga.so.1 Reading symbols from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1...done. Loaded symbols for /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1 Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/strop.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/strop.so Reading symbols from /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2...done. Loaded symbols for /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2 Reading symbols from /usr/openwin/lib/locale/common/xlibi18n.so.2...done. Loaded symbols for /usr/openwin/lib/locale/common/xlibi18n.so.2 Reading symbols from /usr/openwin/lib/locale/common/ximlocal.so.2...done. Loaded symbols for /usr/openwin/lib/locale/common/ximlocal.so.2 Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/time.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/time.so Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/errno.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/errno.so Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/_socket.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/_socket.so Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/select.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/select.so #0 0xff0b2be0 in Tk_FreeGC () from /usr/gnu/lib/libtk8.3.so (gdb) bt #0 0xff0b2be0 in Tk_FreeGC () from /usr/gnu/lib/libtk8.3.so #1 0xff0da71c in TkButtonWorldChanged () from /usr/gnu/lib/libtk8.3.so #2 0xff0da66c in ConfigureButton () from /usr/gnu/lib/libtk8.3.so #3 0xff0d9dc8 in ButtonWidgetObjCmd () from /usr/gnu/lib/libtk8.3.so #4 0xfefe0b50 in EvalObjv () from /usr/gnu/lib/libtcl8.3.so #5 0xfefe0c80 in Tcl_EvalObjv () from /usr/gnu/lib/libtcl8.3.so #6 0x0008deb8 in Tkapp_Call (self=0x159c88, args=0x2c60d8) at Modules/_tkinter.c:619 #7 0x00049e28 in fast_cfunction (func=0x159c88, pp_stack=0xfe908780, na=1089160) at Python/ceval.c:3131 #8 0x00047ea0 in eval_frame (f=0x1cc7c0) at Python/ceval.c:2007 #9 0x00048b30 in PyEval_EvalCodeEx (co=0x220340, globals=0x1cc7c0, locals=0x0, args=0x8, argcount=1, kws=0x1c1dd8, kwcount=1, defs=0x1d76ec, defcount=1, closure=0x0) at Python/ceval.c:2585 #10 0x00049f20 in fast_function (func=0x1, pp_stack=0x8, n=1842656, na=1, nk=1) at Python/ceval.c:3161 #11 0x00047de0 in eval_frame (f=0x1c1c80) at Python/ceval.c:2024 #12 0x00048b30 in PyEval_EvalCodeEx (co=0x1983a8, globals=0x1c1c80, locals=0x0, args=0x30fd50, argcount=2, kws=0x30fd58, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #13 0x00049f20 in fast_function (func=0x0, pp_stack=0x30fd50, n=3210584, na=2, nk=0) at Python/ceval.c:3161 #14 0x00047de0 in eval_frame (f=0x30fc00) at Python/ceval.c:2024 #15 0x00048b30 in PyEval_EvalCodeEx (co=0x12f788, globals=0x30fc00, locals=0x0, args=0x1c0bc8, argcount=1, kws=0x1c0bcc, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #16 0x00049f20 in fast_function (func=0x0, pp_stack=0x1c0bc8, n=1838028, na=1, nk=0) at Python/ceval.c:3161 #17 0x00047de0 in eval_frame (f=0x1c0a70) at Python/ceval.c:2024 #18 0x00048b30 in PyEval_EvalCodeEx (co=0x300058, globals=0x1c0a70, locals=0x0, args=0x301a6c, argcount=3, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #19 0x000aaa9c in function_call (func=0x2fc3c0, arg=0x301a60, kw=0x0) at Objects/funcobject.c:374 #20 0x00095d00 in PyObject_Call (func=0x2fc3c0, arg=0x301a60, kw=0x0) at Objects/abstract.c:1684 #21 0x0009e644 in instancemethod_call (func=0x2fc3c0, arg=0x301a60, kw=0x0) at Objects/classobject.c:2276 #22 0x00095d00 in PyObject_Call (func=0x2fc3c0, arg=0x301a60, kw=0x0) at Objects/abstract.c:1684 #23 0x00049fe4 in do_call (func=0x2c5718, pp_stack=0xfe908fd8, na=3, nk=3152480) at Python/ceval.c:3262 #24 0x00047d28 in eval_frame (f=0x1cc5f8) at Python/ceval.c:2027 #25 0x00048b30 in PyEval_EvalCodeEx (co=0x12f398, globals=0x1cc5f8, locals=0x0, args=0x2cba54, argcount=3, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #26 0x000aaa9c in function_call (func=0x301bf0, arg=0x2cba48, kw=0x0) at Objects/funcobject.c:374 #27 0x00095d00 in PyObject_Call (func=0x301bf0, arg=0x2cba48, kw=0x0) at Objects/abstract.c:1684 #28 0x0009e644 in instancemethod_call (func=0x301bf0, arg=0x2cba48, kw=0x0) at Objects/classobject.c:2276 #29 0x00095d00 in PyObject_Call (func=0x301bf0, arg=0x2e3bb0, kw=0x0) at Objects/abstract.c:1684 #30 0x00049c94 in PyEval_CallObjectWithKeywords (func=0x2da810, arg=0x2e3bb0, kw=0x0) at Python/ceval.c:3049 #31 0x00097d9c in PyInstance_New (klass=0x2da810, arg=0x2e3bb0, kw=0x0) at Objects/classobject.c:557 #32 0x00095d00 in PyObject_Call (func=0x2da810, arg=0x2e3bb0, kw=0x0) at Objects/abstract.c:1684 #33 0x00049fe4 in do_call (func=0x316828, pp_stack=0xfe9094a0, na=2, nk=3029936) at Python/ceval.c:3262 #34 0x00047d28 in eval_frame (f=0x1a3d20) at Python/ceval.c:2027 #35 0x00048b30 in PyEval_EvalCodeEx (co=0x12fab0, globals=0x1a3d20, locals=0x0, args=0x186414, argcount=3, kws=0x2b1228, kwcount=0, defs=0x1cd87c, defcount=2, closure=0x0) at Python/ceval.c:2585 #36 0x000aaa9c in function_call (func=0x1d1dc8, arg=0x186408, kw=0x2d6238) at Objects/funcobject.c:374 #37 0x00095d00 in PyObject_Call (func=0x1d1dc8, arg=0x186408, kw=0x2d6238) at Objects/abstract.c:1684 #38 0x00049c94 in PyEval_CallObjectWithKeywords (func=0x1d1dc8, arg=0x186408, kw=0x2d6238) at Python/ceval.c:3049 #39 0x000bcb3c in builtin_apply (self=0x0, args=0x1d1dc8) at Python/bltinmodule.c:95 #40 0x000ba398 in PyCFunction_Call (func=0x101d18, arg=0x1c4910, kw=0x0) at Objects/methodobject.c:69 #41 0x00047ec8 in eval_frame (f=0x1a4078) at Python/ceval.c:2004 #42 0x00048b30 in PyEval_EvalCodeEx (co=0x2c86c8, globals=0x1a4078, locals=0x0, args=0x1612d4, argcount=1, kws=0x1612d8, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #43 0x00049f20 in fast_function (func=0x0, pp_stack=0x1612d4, n=1446616, na=1, nk=0) at Python/ceval.c:3161 #44 0x00047de0 in eval_frame (f=0x161180) at Python/ceval.c:2024 #45 0x00048b30 in PyEval_EvalCodeEx (co=0x2c8cd0, globals=0x161180, locals=0x0, args=0x265e4c, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #46 0x000aaa9c in function_call (func=0x2d6518, arg=0x265e40, kw=0x0) at Objects/funcobject.c:374 #47 0x00095d00 in PyObject_Call (func=0x2d6518, arg=0x265e40, kw=0x0) at Objects/abstract.c:1684 #48 0x0009e644 in instancemethod_call (func=0x2d6518, arg=0x265e40, kw=0x0) at Objects/classobject.c:2276 #49 0x00095d00 in PyObject_Call (func=0x2d6518, arg=0x100368, kw=0x0) at Objects/abstract.c:1684 #50 0x00049c94 in PyEval_CallObjectWithKeywords (func=0x2d7350, arg=0x100368, kw=0x0) at Python/ceval.c:3049 #51 0x0007f508 in t_bootstrap (boot_raw=0x28bdf8) at Modules/threadmodule.c:190 ---------------------------------------------------------------------- >Comment By: Andrew Koenig (arkoenig) Date: 2005-05-16 17:34 Message: Logged In: YES user_id=418174 I have installed gcc 4.0, binutils 2.16, and Python 2.4.1, and the problem is no longer occurring. So whatever it may have been, it's fixed now :-) ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-03-22 22:03 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-01 02:20 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-29 02:17 Message: Logged In: YES user_id=33168 I notice that you are using Tk 8.4. Have you (or can you) tried with Tk 8.3? Do you have the most recent version 8.4.1 from Oct 22, 2002? ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2003-01-06 17:10 Message: Logged In: YES user_id=418174 I rebuilt python with -O0 and it still crashes. The new traceback is attached. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-06 13:46 Message: Logged In: YES user_id=33168 Andrew, could I get you to look at bug 662787? http://python.org/sf/662787 We are having problems with solaris boxes and could use some help. Thanks. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-09-17 14:54 Message: Logged In: YES user_id=418174 I rebuilt python from scratch by saying "make configure", then going into Makefile and removing "-O3" from the definition of the OPT macro, then saying "make". The resulting python still dumps core when executing "./python Lib/pydoc.py -g". Of course there could still be a platform or optimization dependency in tcl, or tk, or some other library. Suggestions? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-14 01:30 Message: Logged In: YES user_id=33168 I built python 2.2.1+ w/gcc 2.95.3 and did not have the problem. So I think this may be specific to gcc 3.2. Can you try building w/lower optimization or turning off optimization? -O1, -O0 or no -O option? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602627&group_id=5470 From noreply at sourceforge.net Mon May 16 22:32:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 May 2005 13:32:15 -0700 Subject: [ python-Bugs-1199947 ] Python 2.4.1 Installer ended prematurely Message-ID: Bugs item #1199947, was opened at 2005-05-11 09:01 Message generated for change (Comment added) made by tungwaiyip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199947&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Wai Yip Tung (tungwaiyip) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.1 Installer ended prematurely Initial Comment: Similar symptom to bug 105470 http://sourceforge.net/tracker/index.php? func=detail&aid=1085208&group_id=5470&atid=105470 Running python-2.4.1.msi with all default setting. It ends quickly with a dialogbox titled "Python 2.4.1 Installer ended prematurely". Same problem running the 2.4 msi. Machine information: Windows XP Professional V2002 SP2 Dell Latitude D600 640MB RAM Symantec Antivirus 9.0.1.1000 (disable it does not help) cscript.exe version 5.6.0.8825 (upgraded from 8820?) The workaround mentioned in 105470 does not help. Running x.vbs gives me 0. Doing regsvr32 c:\windows\system32\scrrun.dll makes no difference. ---------------------------------------------------------------------- >Comment By: Wai Yip Tung (tungwaiyip) Date: 2005-05-16 13:32 Message: Logged In: YES user_id=561546 Problem solved: I copied the msi file to the root directory (e.g. c:\) and launch from there. it works prefectly. I found that not only Python installer gave me problem, any msi installer gave me problem on this machine. Then I found the clue from Ultramon's FAQ: http://www.realtimesoft.com/ultramon/support.asp#2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199947&group_id=5470 From noreply at sourceforge.net Mon May 16 16:20:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 May 2005 07:20:21 -0700 Subject: [ python-Bugs-1175396 ] codecs.readline sometimes removes newline chars Message-ID: Bugs item #1175396, was opened at 2005-04-02 17:14 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175396&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Walter D?rwald (doerwalter) Summary: codecs.readline sometimes removes newline chars Initial Comment: In Python 2.4.1 i observed a new bug in codecs.readline, it seems that with certain inputs it removes newline characters from the end of the line.... Probably related to bug #1076985 (Incorrect behaviour of StreamReader.readline leads to crash) and bug #1098990 codec readline() splits lines apart (both with status closed) so I'm assigning this to Walter. See the attached files that demonstrate the problem. Reproduced with Python 2.4.1 on windows XP and on Linux. The problem does not occur with Python 2.4. (btw, it seems bug #1076985 was fixed in python 2.4.1, but the other one (#1098990) not? ) ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-05-16 16:20 Message: Logged In: YES user_id=89016 > > 1) How do we handle the problem of a truncated line, if the > > data comes from the charbuffer instead of being read from > > > the stream? > > > > My suggestion is to make the top of the loop look like: > > > > while True: > > havecharbuffer = bool(self.charbuffer) > > > > And then the break condition (when no line break found) > > should be: > > > > # we didn't get anything or this was our only try > > if not data or (size is not None and not havecharbuffer): > > > > (too many negatives in that). Anyway, the idea is that, if > > size specified, there will be at most one read of the > > underlying stream (using the size). So if you enter the > > loop with a charbuffer, and that charbuffer does not have a > > line break, then you redo the loop once (the second time it > > will break, because havecharbuffer will be False). This makes sense. However, with the current state of the tokenizer this might be to dangerous, because the resulting line might be twice as long. So fixing the tokenizer should be the first step. BTW, your patch fixes the problems with the fix for #1178484, so I think I'm going to apply the patch in the next days, if there are no objections. > > Also, not sure about this, but should the size parameter > > default to -1 (to keep it in sync with read)? None seems to be a better default from an API viewpoint, but -1 is better for "C compatibility". > > As to issue 2, it looks like it should be possible to get > > the line number right, because the UnicodeDecodeError > > exception object has all the necessary information in it > > (including the original string). I think this should be > > done by fp_readl (in tokenizer.c). The patch for #1178484 fixes this. Combined with this patch I think we're in good shape. > > By the way, using a findlinebreak function (using sre) turns > > out to be slower than splitting/joining when no size is > > specified (which I assume will be the overwhelmingly most > > common case), so that turned out to be a bad idea on my part. Coding this on the C level and using Py_UNICODE_ISLINEBREAK() should be the fastest version, but I don't know if this is worth it. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-04-23 18:46 Message: Logged In: YES user_id=86307 > 1) How do we handle the problem of a truncated line, if the > data comes from the charbuffer instead of being read from > the stream? My suggestion is to make the top of the loop look like: while True: havecharbuffer = bool(self.charbuffer) And then the break condition (when no line break found) should be: # we didn't get anything or this was our only try if not data or (size is not None and not havecharbuffer): (too many negatives in that). Anyway, the idea is that, if size specified, there will be at most one read of the underlying stream (using the size). So if you enter the loop with a charbuffer, and that charbuffer does not have a line break, then you redo the loop once (the second time it will break, because havecharbuffer will be False). Also, not sure about this, but should the size parameter default to -1 (to keep it in sync with read)? As to issue 2, it looks like it should be possible to get the line number right, because the UnicodeDecodeError exception object has all the necessary information in it (including the original string). I think this should be done by fp_readl (in tokenizer.c). By the way, using a findlinebreak function (using sre) turns out to be slower than splitting/joining when no size is specified (which I assume will be the overwhelmingly most common case), so that turned out to be a bad idea on my part. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-21 23:55 Message: Logged In: YES user_id=89016 OK, I've checked in the following: Lib/codecs.py 1.44 Lib/test/test_codecs.py 1.23 Lib/codecs.py 1.35.2.7 Lib/test/test_codecs.py 1.15.2.5 with the following changes as suggested by glchapman: If a chunk read has a trailing "\r", read one more character even if the user has passed a size parameter. Remove the atcr logic. This should fix most of the problems. There are three open issues: 1) How do we handle the problem of a truncated line, if the data comes from the charbuffer instead of being read from the stream? 2) How do we handle error reporting? The buffering code might read more data than the current line. If this data has a decoding error the caller might report a wrong line number. (See bug #1178484) 3) Fixing the tokenizer. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-15 20:16 Message: Logged In: YES user_id=89016 The current readline() is implemented so that even if the complete line ending (i.e. '\r\n') can't be read within size bytes, at least something that might work as a line end (i.e. '\r') is available at the end of the string, so that the user knowns that the line is complete. The atcr members makes sure that the '\n' that is read next isn't misinterpreted as another line. Unfortunately the import mechanisn doesn't work that way: It demands a '\n' as line terminator and will continue reading if it only finds the '\r'. This means that the '\n' will be skipped and the import mechanisn treats those two lines as one. IMHO the best solution would be the read the extra character even if size is None, as glchapman suggested, so the above situation would really only happen if the last character from the stream is '\r'. I think the tokenizer should be able to survive this. What it didn't survive in 2.4 was that readline() tried to get it's hand on a complete line even if the length of the line was way bigger than the size passed in. If we remove the "size is None" restriction from the current code, then I think we should remove the atcr logic too, because it could only happen under exceptional circumstances and the old handling might be better for those users that don't recognize '\r' as a line end. But in any case the tokenizer should be fixed to be able to handle any line length returned from readline(). I'd really like to get a review by Martin v. L?wis of glchapman's patch #1101726. Of course the simplest solution would be: "If you want a complete line, don't pass a size parameter to readline()". I don't know if it would make sense to change the PEP263 machinery to support this. The other problem is if readline() returns data from the charbuffer. I don't really see how this can be fixed. We might call read() with a size parameter even if there are characters in the charbuffer, but what happens if the user calls readline(size=100000) first and then readline(size=10)? The first readline() call might put a very long string into the charbuffer and then the second call will return a unicode string whose length is in no way correlated to the size parameter. (This happens even even with the current code of course, so the message should be: Don't trust the size parameter, it only tells the underlying stream how many bytes to read (approximately), it's doesn't tell you *anything* about the amount of data returned.). This was different in 2.3.x, because the readline() method of the underlying stream was used, which handled this properly, but only worked if an encoded linefeed was recognizable as a normal 8bit '\n' linefeed by the underlying readline() (i.e. the UTF-16 encodings didn't work). ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-04-15 01:25 Message: Logged In: YES user_id=86307 I think the foo2.py from 1163244 is probably the same bug; at any rate, the reason for it is that a \r is at the beginning of the last line when read in by decoding_fgets. I have simpler test file which shows the bug which I'll email to Walter (you basically just have to get a \r as the last character in the block read by StreamReader, so that atcr will be true). The problem is caused by StreamReader.readline doing: if self.atcr and data.startswith(u"\n"): data = data[1:] since the tokenizer relies on '\n' as the line break character, but it will never see the '\n' removed by the above. FWIW (not much), I think the 2.4 StreamReader.readline actually made more sense than the current code, although a few changes would seem useful (see below). I don't think it is particularly useful to treat the size parameter as a fixed maximum number of bytes to read, since the number of bytes read has no fixed relationship to the number of decoded unicode characters (and also, in the case of the tokenizer, no fixed relationship to the number of bytes of encoded utf8). Also, given the current code, the size parameter is effectively ignored if there is a charbuffer: if you have 5 characters sitting in the charbuffer and use a size of 0x1FF, you only get back the 5 characters, even if they do not end in a linebreak. For the tokenizer, this means an unnecessary PyMem_RESIZE and an extra call to decoding_readline roughly every BUFSIZ bytes in the file (since the tokenizer assumes failure to fetch a complete line means its buffer is too small, whereas in fact it was caused by an incomplete line being stored in the StreamReader's charbuffer). As to changes from 2.4, if the unicode object were to add a findlinebreak method which returns the index of the first character for which Py_UNICODE_ISLINEBREAK is true, readline could use that instead of find("\n"). If it used such a method, readline would also need to explicitly handle a "\r\n" sequence, including a potential read(1) if a '\r' appears at the end of the data (in the case where size is not None). Of course, one problem with that idea is it requires a new method, which may not be allowed until 2.5, and the 2.4.1 behavior definitely needs to be fixed some way. (Interestingly, it looks to me like sre has everything necessary for searching for unicode linebreaks except syntax with which to express the idea in a pattern (maybe I'm missing something, but I can't find a way to get a compiled pattern to emit CATEGORY_UNI_LINEBREAK).) ---------------------------------------------------------------------- Comment By: Michal Rydlo (mmm) Date: 2005-04-15 00:04 Message: Logged In: YES user_id=65460 foo2.py from #1163244 fails to import. Not being expert in Python internals I hope it is due to this bug. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-11 23:42 Message: Logged In: YES user_id=89016 OK, I'm reopening to bug report. I didn't manage to install pythondoc. cElementTree complains about: No such file or directory: './pyconfig.h'. Can you provide a simple Python file that fails when imported? ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-04-10 00:47 Message: Logged In: YES user_id=86307 Sorry to comment on a closed report, but perhaps this fix should not be limited only to cases where size is None. Today, I ran into a spurious syntax error when trying to import pythondoc (from http://effbot.org/downloads/pythondoc-2.1b3-20050325.zip). It turned out a \r was ending up in what looked to the parser like the middle of a line, presumably because a \n was dropped. Anyway, I applied the referenced patch to 2.4.1, except I left out the "size is None" condition, since I knew the tokenizer passes in a size param. With that change pythondoc import successfully. (Also, I just ran the test suite and nothing broke.) Since the size parameter is already documented as being passed to StreamReader.read (in codecs.py -- the HTML documentation needs to be updated), and since StreamReader.read says size is an approximate maximum, perhaps it's OK to read one extra byte. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-05 00:01 Message: Logged In: YES user_id=89016 Checked in a fix as: Lib/codecs.py 1.42/1.43 Lib/test/test_codecs.py 1.22 Lib/codecs.py 1.35.2.6 Lib/test/test_codecs.py 1.15.2.4 Are you really sure, that the fix for #1098990 is not in 2.4.1? According to the tracker for #1098990 the fix was in lib/codecs.py revision 1.35.2.2 and revision 1.35.2.3 is the one that got the r241c1 tag, so the fix should be in 2.4.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175396&group_id=5470 From noreply at sourceforge.net Mon May 16 10:35:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 May 2005 01:35:49 -0700 Subject: [ python-Bugs-1178484 ] Erroneous line number error in Py2.4.1 Message-ID: Bugs item #1178484, was opened at 2005-04-07 14:33 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Timo Linna (tilinna) >Assigned to: Martin v. L?wis (loewis) Summary: Erroneous line number error in Py2.4.1 Initial Comment: For some reason Python 2.3.5 reports the error in the following program correctly: File "C:\Temp\problem.py", line 7 SyntaxError: unknown decode error ..whereas Python 2.4.1 reports an invalid line number: File "C:\Temp\problem.py", line 2 SyntaxError: unknown decode error ----- problem.py starts ----- # -*- coding: ascii -*- """ Foo bar """ # ? is not allowed in ascii coding ----- problem.py ends ----- Without the encoding declaration both Python versions report the usual deprecation warning (just like they should be doing). My environment: Windows 2000 + SP3. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-05-16 10:35 Message: Logged In: YES user_id=89016 OK, here is a patch. It adds an additional argument firstline to read(). If this argument is true (i.e. if called from readline()) and a decoding error happens, this error will only be reported if it is in the first line. Otherwise read() will decode up to the error position and put the rest in the bytebuffer. Unfortunately with this patch, I get a segfault with the following stacktrace if I run the test. I don't know if this is related to bug #1089395/patch #1101726. Martin, can you take a look? #0 0x08057ad1 in tok_nextc (tok=0x81ca7b0) at tokenizer.c:719 #1 0x08058558 in tok_get (tok=0x81ca7b0, p_start=0xbffff3d4, p_end=0xbffff3d0) at tokenizer.c:1075 #2 0x08059331 in PyTokenizer_Get (tok=0x81ca7b0, p_start=0xbffff3d4, p_end=0xbffff3d0) at tokenizer.c:1466 #3 0x080561b1 in parsetok (tok=0x81ca7b0, g=0x8167980, start=257, err_ret=0xbffff440, flags=0) at parsetok.c:125 #4 0x0805613c in PyParser_ParseFileFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", g=0x8167980, start=257, ps1=0x0, ps2=0x0, err_ret=0xbffff440, flags=0) at parsetok.c:90 #5 0x080f3926 in PyParser_SimpleParseFileFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", start=257, flags=0) at pythonrun.c:1345 #6 0x080f352b in PyRun_FileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", start=257, globals=0xb7d62e94, locals=0xb7d62e94, closeit=1, flags=0xbffff544) at pythonrun.c:1239 #7 0x080f22f2 in PyRun_SimpleFileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", closeit=1, flags=0xbffff544) at pythonrun.c:860 #8 0x080f1b16 in PyRun_AnyFileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", closeit=1, flags=0xbffff544) at pythonrun.c:664 #9 0x08055e45 in Py_Main (argc=2, argv=0xbffff5f4) at main.c:484 #10 0x08055366 in main (argc=2, argv=0xbffff5f4) at python.c:23 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-07 16:28 Message: Logged In: YES user_id=89016 The reason for this is the new codec buffering code in 2.4: The codec might read and decode more data from the byte stream than is neccessary for decoding one line. I.e. when reading line n, the codec might decode bytes that belong to line n+1, n+2 etc. too. If there's a decoding error in this data, line n gets reported. I don't think there's a simple fix for this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&group_id=5470 From noreply at sourceforge.net Tue May 17 07:02:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 May 2005 22:02:07 -0700 Subject: [ python-Bugs-1183585 ] try to open /dev/null as directory Message-ID: Bugs item #1183585, was opened at 2005-04-15 01:56 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183585&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Roberto A. Foglietta (robang) Assigned to: Nobody/Anonymous (nobody) Summary: try to open /dev/null as directory Initial Comment: bash-2.05b# strace python 2>&1 | grep open | grep null open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory) ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-05-16 22:02 Message: Logged In: YES user_id=971153 2 questions though: 1. Does this cause any problems? 2. I observe exactly the same behaviour for ls! (I'm on Debian, kernel 2.4.25) bagira:~> strace ls | & grep open | grep null open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory) and for du: bagira:~> strace du /etc | & grep open |grep null open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory) So, I'm almost ready to say that even if it's a bug, it's not a python's bug... (Search for /dev/null in python source also does not find anything interesting).. ---------------------------------------------------------------------- Comment By: Roberto A. Foglietta (robang) Date: 2005-04-20 11:02 Message: Logged In: YES user_id=36141 I downloaded the python-2.4.1 sources and compiled under slack 10 and Mandrake 10.1 and in both case it tried to open /dev/null as a directory. Some debian users reported me the same behaviure. [roberto at wsraf roberto]$ uname -ar Linux wsraf.sad.it 2.6.8.1-24mdksmp #1 SMP Thu Jan 13 23:11:43 MST 2005 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz unknown GNU/Linux ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2005-04-16 00:54 Message: Logged In: YES user_id=849994 I don't quite understand what you're trying to tell us here. Are you just calling Python this way and observing the system calls? Then, what system do you use? What version? What kernel, etc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183585&group_id=5470 From noreply at sourceforge.net Tue May 17 10:49:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 May 2005 01:49:10 -0700 Subject: [ python-Bugs-1163563 ] Sub threads execute in restricted mode Message-ID: Bugs item #1163563, was opened at 2005-03-15 09:56 Message generated for change (Comment added) made by yetanothermax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: anothermax (yetanothermax) Assigned to: Nobody/Anonymous (nobody) Summary: Sub threads execute in restricted mode Initial Comment: I'm using the JEP product which allows integration of Java with Python (see http://jepp.sourceforge.net) via starting a Python interpreter in the same process as the JVM. This integrates with python via the C interface, allowing the user to 'eval' python code (amongst other features). It seems that since Python 2.3.5 any threads (using the threading module) created via code that has been evaluated through the jep.eval() interface (i.e.Python C interface )are executed in restricted mode and cannot, for example, create files. Code that is just evaled (i.e not in a subthread) thread has no restrictions. The error reported is: IOError: file() constructor not accessible in restricted mode (see http://sourceforge.net/forum/forum.php? thread_id=1247793&forum_id=376782) - I've given a JEP specific example here. There seems to be a similar problem with mod_python (see http://www.modpython.org/pipermail/mod_python/2005- January/017129.html) Reading through the release notes for Python 2.3.5 I see: Bug #754449: threading.Thread will no longer mask exceptions raised during interpreter shutdown with another exception caused by attempting to output the initial exception. This fix also includes a backport of rev. 1.41 from HEAD. This might be the problem as it seems to involve the porting of 2.4 threading code back to the 2.3 tree. I've attached a Java file which shows the problem when using JEP. The error output is: Exception in thread Thread-1: Traceback (most recent call last): File "C:\Python24\Lib\threading.py", line 442, in __bootstrap File "", line 5, in run IOError: file() constructor not accessible in restricted mode 2.4.1c1 (#63, Mar 10 2005, 10:36:41) [MSC v.1310 32 bit (Intel)] Creating file from main thread... Done Creating file from sub thread... Done ---------------------------------------------------------------------- >Comment By: anothermax (yetanothermax) Date: 2005-05-17 10:49 Message: Logged In: YES user_id=1218811 I've created a patch for threadmodule.c http://sourceforge.net/tracker/index.php? func=detail&aid=1203393&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-12 10:48 Message: Logged In: YES user_id=1218811 It looks like with Python versions > 2.3.4 threads are off limits for multiple interpreters. If that's your definition of screwed then I guess the answer's yes. I'm surprised more mod_python users haven't been bitten by this. Shall I raise theproblem on the list (I've already done so on comp.lang.python a while ago) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-12 09:43 Message: Logged In: YES user_id=6656 I saw the subject and thought "Hmm, should raise the priority of this so it gets at least thought about hard by the next release", then saw that you did that... > How do we get this solved for the next Python release? I don't know. It's possible it should be raised on python-dev (it seems fairly quiet just now, so it might be a good time :). Basically, it seems that the whole multiple interpreters facility is screwed, correct? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-12 09:35 Message: Logged In: YES user_id=1218811 This problem prevents us from upgrading to Python 2.4. I've attached a another 'fixed' threadmodule.c which is based upon the lastest CVS release.(Only change from the last threadmodule.c attachment is the removal of a '\n' from an error message). The threadtest.c program demonstrates the problem (seems to be the use of Py_NewInterpreter() with the PyGIL_StateXXX functions in the current threadmodule.c). How do we get this solved for the next Python release? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-21 14:05 Message: Logged In: YES user_id=1218811 I've attached a file (threadtest.c) that is adapted from the the way JEP uses Py_NewInterpreter. This runs correctly under 2.3.4 but fails under 2.3.5 and later Pythons. ---------------------------------------------------------------------- Comment By: mrjohnson (mrjohnson0) Date: 2005-04-21 07:51 Message: Logged In: YES user_id=1044885 In interactive mode, Jep uses Py_NewInterpreter, Py_CompileString, and PyRun_String for its eval(). This file handles java -> python: http://204.156.146.230/cgi-bin/viewcvs.cgi/jep/pyembed.c?rev=1.29&content-type=text/vnd.viewcvs-markup You'd be looking for pyembed_eval(). ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-04-21 05:11 Message: Logged In: YES user_id=14198 Can anyone tell me specifically what Python C API function is involved here? ie, the "entry point" that these external threads use to call into Python. ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 13:51 Message: Logged In: YES user_id=1218811 I didn't see jbelmote's comment, perhaps my updated threadmodule.c will reopen the #1010677 bug. ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 13:39 Message: Logged In: YES user_id=1218811 Here's the updated threadmodule.c for 2.4.1 ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 13:36 Message: Logged In: YES user_id=1218811 I've finally got access to a C compiler and it looks like the 'pure' Python changes for #754449 are in the clear (apologies to bcannon). The problem actually seems to relate to changes to threadmodule.c of the Python Modules directory. In versions greater than 2.3.4 it uses the PyGILState_XXX constructs t_bootstrap() function. These do not seem to be compatible with running sub interpreters as JEP (and probably mod_python) do. The python documentation (http://docs.python.org/api/threads.html) says "Note that the PyGILState_*() functions assume there is only one global interpreter (created automatically by Py_Initialize()). Python still supports the creation of additional interpreters (using Py_NewInterpreter()), but mixing multiple interpreters and the PyGILState_*() API is unsupported. " I've compiled a new versions of the python2X.dll for both 2.3.5 and 2.4.1 changing the use of these PyGIL_StateXXX constructs back to the 2.3.4 form and this seems to resolve the problem (I've attached the updated threadmodule.c files for both 2.3.5 and 2.4.1). ---------------------------------------------------------------------- Comment By: John Belmonte (jbelmonte) Date: 2005-04-16 22:27 Message: Logged In: YES user_id=282299 This problem also occurs on Linux. Note however that I've traced the source of the symptom to a different bug fix, namely [1010677] thread Module Breaks PyGILState_Ensure() (http://sourceforge.net/tracker/index.php?func=detail&aid=1010677&group_id=5470&atid=305470). Specifically, the change from v2.56 to v2.56.8.1 of threadmodule.c. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-16 21:21 Message: Logged In: YES user_id=357491 To answer the comment on bug #754449 and the email I got from someone, there is no way my fix for that bug would cause this. I only touched the 'threading' module, nothing else. That is in pure Python and thus has no direct way of modifying what does and does not execute in restricted mode. If I understand how restricted execution works that is all set at the C level. Plus the fix only deals with the teardown code; it in no way interfaces with how threads are executed. All changed code come after the thread and completed execution. The only thing it does ahead of time is store a reference to stdout. In other words it ain't my fault to the best of my knowledge. =) ---------------------------------------------------------------------- Comment By: Alan Davies (goatpunch) Date: 2005-03-31 08:24 Message: Logged In: YES user_id=967140 The same problem definately does occur with mod_python, I've found it to occur with Python 2.3.5 and 2.4 on Win32: http://www.modpython.org/pipermail/mod_python/2005- March/017802.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 From noreply at sourceforge.net Tue May 17 11:13:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 May 2005 02:13:19 -0700 Subject: [ python-Bugs-1178484 ] Erroneous line number error in Py2.4.1 Message-ID: Bugs item #1178484, was opened at 2005-04-07 14:33 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Timo Linna (tilinna) Assigned to: Martin v. L?wis (loewis) Summary: Erroneous line number error in Py2.4.1 Initial Comment: For some reason Python 2.3.5 reports the error in the following program correctly: File "C:\Temp\problem.py", line 7 SyntaxError: unknown decode error ..whereas Python 2.4.1 reports an invalid line number: File "C:\Temp\problem.py", line 2 SyntaxError: unknown decode error ----- problem.py starts ----- # -*- coding: ascii -*- """ Foo bar """ # ? is not allowed in ascii coding ----- problem.py ends ----- Without the encoding declaration both Python versions report the usual deprecation warning (just like they should be doing). My environment: Windows 2000 + SP3. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-05-17 11:13 Message: Logged In: YES user_id=38388 Walter, I think that instead of trying to get the tokenizer to work with the buffer support in the codecs, you should add a flag that allows to switch off the buffer support in the codecs altogether and then use the unbuffered mode codecs in the tokenizer. I expect that other applications will run into the same kind of problem, so it should be possible to switch off buffering if needed (maybe we should make this the default ?!). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-05-16 10:35 Message: Logged In: YES user_id=89016 OK, here is a patch. It adds an additional argument firstline to read(). If this argument is true (i.e. if called from readline()) and a decoding error happens, this error will only be reported if it is in the first line. Otherwise read() will decode up to the error position and put the rest in the bytebuffer. Unfortunately with this patch, I get a segfault with the following stacktrace if I run the test. I don't know if this is related to bug #1089395/patch #1101726. Martin, can you take a look? #0 0x08057ad1 in tok_nextc (tok=0x81ca7b0) at tokenizer.c:719 #1 0x08058558 in tok_get (tok=0x81ca7b0, p_start=0xbffff3d4, p_end=0xbffff3d0) at tokenizer.c:1075 #2 0x08059331 in PyTokenizer_Get (tok=0x81ca7b0, p_start=0xbffff3d4, p_end=0xbffff3d0) at tokenizer.c:1466 #3 0x080561b1 in parsetok (tok=0x81ca7b0, g=0x8167980, start=257, err_ret=0xbffff440, flags=0) at parsetok.c:125 #4 0x0805613c in PyParser_ParseFileFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", g=0x8167980, start=257, ps1=0x0, ps2=0x0, err_ret=0xbffff440, flags=0) at parsetok.c:90 #5 0x080f3926 in PyParser_SimpleParseFileFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", start=257, flags=0) at pythonrun.c:1345 #6 0x080f352b in PyRun_FileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", start=257, globals=0xb7d62e94, locals=0xb7d62e94, closeit=1, flags=0xbffff544) at pythonrun.c:1239 #7 0x080f22f2 in PyRun_SimpleFileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", closeit=1, flags=0xbffff544) at pythonrun.c:860 #8 0x080f1b16 in PyRun_AnyFileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", closeit=1, flags=0xbffff544) at pythonrun.c:664 #9 0x08055e45 in Py_Main (argc=2, argv=0xbffff5f4) at main.c:484 #10 0x08055366 in main (argc=2, argv=0xbffff5f4) at python.c:23 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-07 16:28 Message: Logged In: YES user_id=89016 The reason for this is the new codec buffering code in 2.4: The codec might read and decode more data from the byte stream than is neccessary for decoding one line. I.e. when reading line n, the codec might decode bytes that belong to line n+1, n+2 etc. too. If there's a decoding error in this data, line n gets reported. I don't think there's a simple fix for this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&group_id=5470 From noreply at sourceforge.net Tue May 17 18:16:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 May 2005 09:16:51 -0700 Subject: [ python-Bugs-901727 ] extra_path kwarg to setup() undocumented Message-ID: Bugs item #901727, was opened at 2004-02-21 16:04 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901727&group_id=5470 Category: Distutils Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Thomas Heller (theller) Summary: extra_path kwarg to setup() undocumented Initial Comment: I can't find documentation for extra_path anywhere.. but this is the documentation I found by searching google ( http:// mail.python.org/pipermail/distutils-sig/2000-March/000803.html ), from an old USAGE.txt that sits in the CVS attic now: extra_path: information about extra intervening directories to put between 'install_lib' and 'install_sitelib', along with a .pth file to ensure that those directories wind up in sys.path. Can be a 1- or 2-tuple, or a comma-delimited string with 1 or 2 parts. The 1-element case is simpler: the .pth file and directory have the same name (except for ".pth"). Eg. if extra_path is "foo" or ("foo",), then Distutils sets 'install_site_lib' to 'install_lib' + "site-packages/foo", and puts foo.path in the "site-packages" directory; it contains just "foo". The 2-element case allows the .pth file and intervening directories to be named differently; eg. if 'extra_path' is ("foo","foo/bar/baz") (or "foo,foo/bar/baz"), then Distutils will set 'install_site_lib' to 'install_lib' + "site-packages/foo/bar/baz", and put "foo.pth" containing "foo/bar/baz" in the "site-packages" directory. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2005-05-17 18:16 Message: Logged In: YES user_id=580910 extra_path also doesn't have a command-line equivalent. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901727&group_id=5470 From noreply at sourceforge.net Tue May 17 18:50:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 May 2005 09:50:37 -0700 Subject: [ python-Bugs-1178484 ] Erroneous line number error in Py2.4.1 Message-ID: Bugs item #1178484, was opened at 2005-04-07 14:33 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Timo Linna (tilinna) Assigned to: Martin v. L?wis (loewis) Summary: Erroneous line number error in Py2.4.1 Initial Comment: For some reason Python 2.3.5 reports the error in the following program correctly: File "C:\Temp\problem.py", line 7 SyntaxError: unknown decode error ..whereas Python 2.4.1 reports an invalid line number: File "C:\Temp\problem.py", line 2 SyntaxError: unknown decode error ----- problem.py starts ----- # -*- coding: ascii -*- """ Foo bar """ # ? is not allowed in ascii coding ----- problem.py ends ----- Without the encoding declaration both Python versions report the usual deprecation warning (just like they should be doing). My environment: Windows 2000 + SP3. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-05-17 18:50 Message: Logged In: YES user_id=89016 It isn't the buffering support per se that breaks the tokenizer. This problem exists even in Python 2.3.x (Simply try the test scripts from http://www.python.org/sf/1089395 with Python 2.3.5 and you'll get a segfault). Applications that rely on len(readline(x)) == x or anything similar are broken anyway. Supporting buffered and unbuffered reading would mean keeping the 2.3 mode of doing things around indefinitely, and we'd loose readline() support for UTF-16 again. BTW, applying Greg Chapman's patch (http://www.python.org/sf/1101726, which fixes the tokenizer) together with this one seems to fix the problem from my previous post. So if you could give http://www.python.org/sf/1101726 a third look, so we can get it into 2.4.2, this would be great. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-05-17 11:13 Message: Logged In: YES user_id=38388 Walter, I think that instead of trying to get the tokenizer to work with the buffer support in the codecs, you should add a flag that allows to switch off the buffer support in the codecs altogether and then use the unbuffered mode codecs in the tokenizer. I expect that other applications will run into the same kind of problem, so it should be possible to switch off buffering if needed (maybe we should make this the default ?!). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-05-16 10:35 Message: Logged In: YES user_id=89016 OK, here is a patch. It adds an additional argument firstline to read(). If this argument is true (i.e. if called from readline()) and a decoding error happens, this error will only be reported if it is in the first line. Otherwise read() will decode up to the error position and put the rest in the bytebuffer. Unfortunately with this patch, I get a segfault with the following stacktrace if I run the test. I don't know if this is related to bug #1089395/patch #1101726. Martin, can you take a look? #0 0x08057ad1 in tok_nextc (tok=0x81ca7b0) at tokenizer.c:719 #1 0x08058558 in tok_get (tok=0x81ca7b0, p_start=0xbffff3d4, p_end=0xbffff3d0) at tokenizer.c:1075 #2 0x08059331 in PyTokenizer_Get (tok=0x81ca7b0, p_start=0xbffff3d4, p_end=0xbffff3d0) at tokenizer.c:1466 #3 0x080561b1 in parsetok (tok=0x81ca7b0, g=0x8167980, start=257, err_ret=0xbffff440, flags=0) at parsetok.c:125 #4 0x0805613c in PyParser_ParseFileFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", g=0x8167980, start=257, ps1=0x0, ps2=0x0, err_ret=0xbffff440, flags=0) at parsetok.c:90 #5 0x080f3926 in PyParser_SimpleParseFileFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", start=257, flags=0) at pythonrun.c:1345 #6 0x080f352b in PyRun_FileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", start=257, globals=0xb7d62e94, locals=0xb7d62e94, closeit=1, flags=0xbffff544) at pythonrun.c:1239 #7 0x080f22f2 in PyRun_SimpleFileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", closeit=1, flags=0xbffff544) at pythonrun.c:860 #8 0x080f1b16 in PyRun_AnyFileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", closeit=1, flags=0xbffff544) at pythonrun.c:664 #9 0x08055e45 in Py_Main (argc=2, argv=0xbffff5f4) at main.c:484 #10 0x08055366 in main (argc=2, argv=0xbffff5f4) at python.c:23 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-07 16:28 Message: Logged In: YES user_id=89016 The reason for this is the new codec buffering code in 2.4: The codec might read and decode more data from the byte stream than is neccessary for decoding one line. I.e. when reading line n, the codec might decode bytes that belong to line n+1, n+2 etc. too. If there's a decoding error in this data, line n gets reported. I don't think there's a simple fix for this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&group_id=5470 From noreply at sourceforge.net Tue May 17 23:09:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 May 2005 14:09:07 -0700 Subject: [ python-Bugs-1071094 ] some latex reject the pdfinfo macro while generating html Message-ID: Bugs item #1071094, was opened at 2004-11-22 17:15 Message generated for change (Comment added) made by stroeder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071094&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Marc-Antoine Parent (maparent) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: some latex reject the pdfinfo macro while generating html Initial Comment: I was building the documentation on OSX. I use the latest LaTeX 2004 from Wierda's teTeX. There is a pdfinfo command in Doc/ texinputs/manual.cls and Doc/texinputs/howto.cls which chokes my version of latex. edited log follows: TEXINPUTS=/.../Python-2.4c1/Doc/commontex: python /.../Python -2.4c1/Doc/tools/mkhowto --html --about html/stdabout.dat -- iconserver ../icons --favicon ../icons/pyfav.png --address "See About this document... for information on suggesting changes." --up-link ../index.html --up- title "Python Documentation Index" --global-module-index "../ modindex.html" --dvips-safe --dir html/api api/api.tex +++ TEXINPUTS=/.../Python-2.4c1/ Doc/api:/.../Python-2.4c1/Doc/ commontex:/.../Python-2.4c1/Doc/ paper-letter:/.../Python-2.4c1/Doc/ texinputs: +++ latex api *** Session transcript and error messages are in /.../Python -2.4c1/Doc/html/api/api.how. *** Exited with status 1. The relevant lines from the transcript are: ------------------------------------------------------------------------ +++ latex api This is pdfeTeX, Version 3.141592-1.20a-2.2 (Web2C 7.5.3) output format initialized to DVI entering extended mode (/.../Python-2.4c1/Doc/api/api.tex LaTeX2e <2003/12/01> Babel and hyphenation patterns for american, french, german, ngerman, nohyphenation, loaded. (/.../Python-2.4c1/Doc/texinputs/manual.cls Document Class: manual 1998/03/03 Document class (Python manual) (/.../Python-2.4c1/Doc/texinputs/pypaper.sty (/usr/local/teTeX/share/texmf.tetex/tex/latex/psnfss/times.sty) Using Times instead of Computer Modern. ) (/usr/local/teTeX/share/texmf.tetex/tex/latex/fancybox/ fancybox.sty Style option: `fancybox' v1.3 <2000/09/19> (tvz) ) (/usr/local/teTeX/share/texmf.tetex/tex/latex/base/report.cls Document Class: report 2004/02/16 v1.4f Standard LaTeX document class (/usr/local/teTeX/share/texmf.tetex/tex/latex/base/size10.clo)) (/.../Python-2.4c1/Doc/texinputs/fancyhdr.sty) Using fancier footers than usual. (/.../Python-2.4c1/Doc/texinputs/fncychap.sty) Using fancy chapter headings. (/.../Python-2.4c1/Doc/texinputs/python.sty (/usr/local/teTeX/share/texmf.tetex/tex/latex/tools/longtable.sty) (/usr/local/teTeX/share/texmf.tetex/tex/latex/tools/verbatim.sty) (/usr/local/teTeX/share/texmf.tetex/tex/latex/base/alltt.sty))) (/.../Python-2.4c1/Doc/commontex/boilerplate.tex (/.../Python-2.4c1/Doc/commontex/patchlevel.tex)) Writing index file api.idx No file api.aux. (/usr/local/teTeX/share/texmf.tetex/tex/latex/psnfss/ot1ptm.fd) pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set. { \def \{, } \pdfinfo { /Author (\@author ) /Title (\@title ) } } l.12 \maketitle No pages of output. Transcript written on api.log. *** Session transcript and error messages are in /.../Python -2.4c1/Doc/html/api/api.how. *** Exited with status 1. make: *** [html/api/api.html] Error 1 ---------------------------------------------------------------------- Comment By: Michael Str?der (stroeder) Date: 2005-05-17 23:09 Message: Logged In: YES user_id=64920 I also have this problem when trying to build python-ldap's docs on SuSE Linux 9.3 which ships with tetex-3.0-13 and te_latex-3.0-13. You might wanna take note of this: http://www.latex-project.org/cgi-bin/ltxbugs2html?pr=latex/3640&state=open It refers to this module: http://www.tex.ac.uk/tex-archive/macros/latex/contrib/oberdiek/ifpdf.sty ---------------------------------------------------------------------- Comment By: S?bastien Maret (bmaret) Date: 2005-04-18 21:53 Message: Logged In: YES user_id=842097 I get the exact same error. I am running MacOSX with teTeX 3.0 installed with Fink. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071094&group_id=5470 From noreply at sourceforge.net Wed May 18 11:31:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 May 2005 02:31:58 -0700 Subject: [ python-Bugs-1178484 ] Erroneous line number error in Py2.4.1 Message-ID: Bugs item #1178484, was opened at 2005-04-07 14:33 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Timo Linna (tilinna) Assigned to: Martin v. L?wis (loewis) Summary: Erroneous line number error in Py2.4.1 Initial Comment: For some reason Python 2.3.5 reports the error in the following program correctly: File "C:\Temp\problem.py", line 7 SyntaxError: unknown decode error ..whereas Python 2.4.1 reports an invalid line number: File "C:\Temp\problem.py", line 2 SyntaxError: unknown decode error ----- problem.py starts ----- # -*- coding: ascii -*- """ Foo bar """ # ? is not allowed in ascii coding ----- problem.py ends ----- Without the encoding declaration both Python versions report the usual deprecation warning (just like they should be doing). My environment: Windows 2000 + SP3. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-05-18 11:31 Message: Logged In: YES user_id=38388 Walter, as I've said before: I know that you need buffering for the UTF-x readline support, but I don't see a requirement for it in most of the other codecs. E.g. an ascii codec or latin-1 codec will only ever see standard line ends (not Unicode ones), so the streams .readline() method can be used directly - just like we did before the buffering code was added. Your argument about applications making implications on the file position after having used .readline() is true, but still many applications rely on this behavior which is not as far fetched as it may seem given that they normally only expect 8-bit data. Wouldn't it make things a lot safer if we only use buffering per default in the UTF-x codecs and revert back to the old non-buffered behavior for the other codecs which has worked well in the past ?! About your patch: * Please explain what firstline is supposed to do (preferably in the doc-string). * Why is firstline always set in .readline() ? * Please remove the print repr() * You cannot always be sure that exc has a .start attribute, so you need to accomocate for this situation as well ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-05-17 18:50 Message: Logged In: YES user_id=89016 It isn't the buffering support per se that breaks the tokenizer. This problem exists even in Python 2.3.x (Simply try the test scripts from http://www.python.org/sf/1089395 with Python 2.3.5 and you'll get a segfault). Applications that rely on len(readline(x)) == x or anything similar are broken anyway. Supporting buffered and unbuffered reading would mean keeping the 2.3 mode of doing things around indefinitely, and we'd loose readline() support for UTF-16 again. BTW, applying Greg Chapman's patch (http://www.python.org/sf/1101726, which fixes the tokenizer) together with this one seems to fix the problem from my previous post. So if you could give http://www.python.org/sf/1101726 a third look, so we can get it into 2.4.2, this would be great. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-05-17 11:13 Message: Logged In: YES user_id=38388 Walter, I think that instead of trying to get the tokenizer to work with the buffer support in the codecs, you should add a flag that allows to switch off the buffer support in the codecs altogether and then use the unbuffered mode codecs in the tokenizer. I expect that other applications will run into the same kind of problem, so it should be possible to switch off buffering if needed (maybe we should make this the default ?!). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-05-16 10:35 Message: Logged In: YES user_id=89016 OK, here is a patch. It adds an additional argument firstline to read(). If this argument is true (i.e. if called from readline()) and a decoding error happens, this error will only be reported if it is in the first line. Otherwise read() will decode up to the error position and put the rest in the bytebuffer. Unfortunately with this patch, I get a segfault with the following stacktrace if I run the test. I don't know if this is related to bug #1089395/patch #1101726. Martin, can you take a look? #0 0x08057ad1 in tok_nextc (tok=0x81ca7b0) at tokenizer.c:719 #1 0x08058558 in tok_get (tok=0x81ca7b0, p_start=0xbffff3d4, p_end=0xbffff3d0) at tokenizer.c:1075 #2 0x08059331 in PyTokenizer_Get (tok=0x81ca7b0, p_start=0xbffff3d4, p_end=0xbffff3d0) at tokenizer.c:1466 #3 0x080561b1 in parsetok (tok=0x81ca7b0, g=0x8167980, start=257, err_ret=0xbffff440, flags=0) at parsetok.c:125 #4 0x0805613c in PyParser_ParseFileFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", g=0x8167980, start=257, ps1=0x0, ps2=0x0, err_ret=0xbffff440, flags=0) at parsetok.c:90 #5 0x080f3926 in PyParser_SimpleParseFileFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", start=257, flags=0) at pythonrun.c:1345 #6 0x080f352b in PyRun_FileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", start=257, globals=0xb7d62e94, locals=0xb7d62e94, closeit=1, flags=0xbffff544) at pythonrun.c:1239 #7 0x080f22f2 in PyRun_SimpleFileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", closeit=1, flags=0xbffff544) at pythonrun.c:860 #8 0x080f1b16 in PyRun_AnyFileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", closeit=1, flags=0xbffff544) at pythonrun.c:664 #9 0x08055e45 in Py_Main (argc=2, argv=0xbffff5f4) at main.c:484 #10 0x08055366 in main (argc=2, argv=0xbffff5f4) at python.c:23 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-07 16:28 Message: Logged In: YES user_id=89016 The reason for this is the new codec buffering code in 2.4: The codec might read and decode more data from the byte stream than is neccessary for decoding one line. I.e. when reading line n, the codec might decode bytes that belong to line n+1, n+2 etc. too. If there's a decoding error in this data, line n gets reported. I don't think there's a simple fix for this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&group_id=5470 From noreply at sourceforge.net Wed May 18 13:53:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 May 2005 04:53:40 -0700 Subject: [ python-Bugs-1202946 ] Problem with abs function Message-ID: Bugs item #1202946, was opened at 2005-05-17 02:32 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202946&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ric-b (ric-b) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with abs function Initial Comment: On windows version I get : >>> abs(-9999999999999999999) Traceback (most recent call last): File "", line 1, in -toplevel- abs(-9999999999999999999) OverflowError: long too big to convert does not handle new longs. I am using the following work around: t = a - b # calc t = abs(a - b) if t < 0 : t *= -1 ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-18 21:53 Message: Logged In: YES user_id=1038590 I tried the OP's example in wxPython's PyShell as well as in the standard interpreter, and got the same result as Raymond. However, I was able to provoke a similar looking error by trying to convert a large long to a float (and the exception is telling the plain truth - a double precision float can't handle a number that big): Py> num = 1.0 Py> lng = -999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999 999999999999 Py> num += abs(lng) Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to float ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-17 03:33 Message: Logged In: YES user_id=80475 That's odd. It works for me: Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> abs(-9999999999999999999) 9999999999999999999L ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202946&group_id=5470 From noreply at sourceforge.net Wed May 18 14:15:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 May 2005 05:15:13 -0700 Subject: [ python-Bugs-1201456 ] Problem with recursion in dict (crash with core dump) Message-ID: Bugs item #1201456, was opened at 2005-05-14 01:43 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Vladimir Yu. Stepanov (vys) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with recursion in dict (crash with core dump) Initial Comment: Please see example code. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-18 22:15 Message: Logged In: YES user_id=1038590 What does sys.getrecursionlimit() return? Does the buggy code generate the expected exception if you use sys.setrecursionlimit() to make the value smaller (e.g. 500)? FreeBSD has a history of not playing well with CPython's ability to detect inifinite recursion. . . ---------------------------------------------------------------------- Comment By: Vladimir Yu. Stepanov (vys) Date: 2005-05-14 02:06 Message: Logged In: YES user_id=384980 This is output from `uname -a`: FreeBSD fox.renet.ru 5.3-RELEASE FreeBSD 5.3-RELEASE #1: Fri Apr 15 10:38:49 MSD 2005 root at fox.renet.ru:/M/safedir/src/sys/i386/compile/FOX i386 I get some others with this code: Python 2.4.1 (#2, Apr 26 2005, 14:16:31) [GCC 3.4.2 [FreeBSD] 20040728] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> d = {} >>> >>> class test: ... def __hash__(self): ... d[self] = None ... >>> d[test()] = None Bus error (core dumped) fox:vys!~ > gdb python python.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Core was generated by `python'. Program terminated with signal 10, Bus error. (gdb) where #0 0x2828b3b1 in ldexp () from /lib/libc.so.5 #1 0x2828b618 in malloc () from /lib/libc.so.5 #2 0x080bdca1 in _PyObject_GC_Malloc () #3 0x080bdd4a in _PyObject_GC_New () #4 0x0805f556 in PyMethod_New () #5 0x0805c1a6 in PyInstance_NewRaw () #6 0x0805c66a in PyInstance_New () #7 0x0805cca1 in _PyInstance_Lookup () #8 0x080703e6 in PyDict_SetItem () #9 0x0809bb0e in PyEval_EvalFrame () #10 0x0809fc20 in PyEval_EvalCodeEx () #11 0x080d4d66 in PyFunction_SetClosure () #12 0x0805a38c in PyObject_Call () #13 0x0805fbe2 in PyMethod_New () #14 0x0805a38c in PyObject_Call () #15 0x08099f1b in PyEval_CallObjectWithKeywords () #16 0x0805ccb9 in _PyInstance_Lookup () #17 0x080703e6 in PyDict_SetItem () #18 0x0809bb0e in PyEval_EvalFrame () #19 0x0809fc20 in PyEval_EvalCodeEx () #20 0x080d4d66 in PyFunction_SetClosure () #21 0x0805a38c in PyObject_Call () #22 0x0805fbe2 in PyMethod_New () ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-14 01:55 Message: Logged In: YES user_id=80475 I get the expected behavior: RuntimeError: maximum recursion depth exceeded ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-14 01:55 Message: Logged In: YES user_id=6656 I get an infinite recursion runtime error. What platform are you on? ---------------------------------------------------------------------- Comment By: Vladimir Yu. Stepanov (vys) Date: 2005-05-14 01:46 Message: Logged In: YES user_id=384980 d = {} class test: def __hash__(self): d[self] = None d[test()] = None ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-14 01:46 Message: Logged In: YES user_id=6656 I see no code. SF can be a pain with this... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&group_id=5470 From noreply at sourceforge.net Wed May 18 15:05:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 May 2005 06:05:56 -0700 Subject: [ python-Bugs-1201456 ] Problem with recursion in dict (crash with core dump) Message-ID: Bugs item #1201456, was opened at 2005-05-13 19:43 Message generated for change (Comment added) made by vys You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Vladimir Yu. Stepanov (vys) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with recursion in dict (crash with core dump) Initial Comment: Please see example code. ---------------------------------------------------------------------- >Comment By: Vladimir Yu. Stepanov (vys) Date: 2005-05-18 17:05 Message: Logged In: YES user_id=384980 sys.getrecursionlimit() returns 1000. I set sys.setrecursionlimit() to 500 and problem was resolved :) Thank you very much ! PS. Is it possible to add some checks in Py_SetRecursionLimit to reject overflow values ? ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-18 16:15 Message: Logged In: YES user_id=1038590 What does sys.getrecursionlimit() return? Does the buggy code generate the expected exception if you use sys.setrecursionlimit() to make the value smaller (e.g. 500)? FreeBSD has a history of not playing well with CPython's ability to detect inifinite recursion. . . ---------------------------------------------------------------------- Comment By: Vladimir Yu. Stepanov (vys) Date: 2005-05-13 20:06 Message: Logged In: YES user_id=384980 This is output from `uname -a`: FreeBSD fox.renet.ru 5.3-RELEASE FreeBSD 5.3-RELEASE #1: Fri Apr 15 10:38:49 MSD 2005 root at fox.renet.ru:/M/safedir/src/sys/i386/compile/FOX i386 I get some others with this code: Python 2.4.1 (#2, Apr 26 2005, 14:16:31) [GCC 3.4.2 [FreeBSD] 20040728] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> d = {} >>> >>> class test: ... def __hash__(self): ... d[self] = None ... >>> d[test()] = None Bus error (core dumped) fox:vys!~ > gdb python python.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Core was generated by `python'. Program terminated with signal 10, Bus error. (gdb) where #0 0x2828b3b1 in ldexp () from /lib/libc.so.5 #1 0x2828b618 in malloc () from /lib/libc.so.5 #2 0x080bdca1 in _PyObject_GC_Malloc () #3 0x080bdd4a in _PyObject_GC_New () #4 0x0805f556 in PyMethod_New () #5 0x0805c1a6 in PyInstance_NewRaw () #6 0x0805c66a in PyInstance_New () #7 0x0805cca1 in _PyInstance_Lookup () #8 0x080703e6 in PyDict_SetItem () #9 0x0809bb0e in PyEval_EvalFrame () #10 0x0809fc20 in PyEval_EvalCodeEx () #11 0x080d4d66 in PyFunction_SetClosure () #12 0x0805a38c in PyObject_Call () #13 0x0805fbe2 in PyMethod_New () #14 0x0805a38c in PyObject_Call () #15 0x08099f1b in PyEval_CallObjectWithKeywords () #16 0x0805ccb9 in _PyInstance_Lookup () #17 0x080703e6 in PyDict_SetItem () #18 0x0809bb0e in PyEval_EvalFrame () #19 0x0809fc20 in PyEval_EvalCodeEx () #20 0x080d4d66 in PyFunction_SetClosure () #21 0x0805a38c in PyObject_Call () #22 0x0805fbe2 in PyMethod_New () ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-13 19:55 Message: Logged In: YES user_id=80475 I get the expected behavior: RuntimeError: maximum recursion depth exceeded ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-13 19:55 Message: Logged In: YES user_id=6656 I get an infinite recursion runtime error. What platform are you on? ---------------------------------------------------------------------- Comment By: Vladimir Yu. Stepanov (vys) Date: 2005-05-13 19:46 Message: Logged In: YES user_id=384980 d = {} class test: def __hash__(self): d[self] = None d[test()] = None ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-13 19:46 Message: Logged In: YES user_id=6656 I see no code. SF can be a pain with this... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&group_id=5470 From noreply at sourceforge.net Wed May 18 16:15:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 May 2005 07:15:07 -0700 Subject: [ python-Bugs-1200686 ] SyntaxError raised on win32 for correct files Message-ID: Bugs item #1200686, was opened at 2005-05-12 06:19 Message generated for change (Comment added) made by glchapman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200686&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Federico Di Gregorio (fog) Assigned to: Nobody/Anonymous (nobody) Summary: SyntaxError raised on win32 for correct files Initial Comment: Try to import the attached file (dt.py) on Windows with Python 2.4 or 2.4.1 and you'll get a SyntaxError (the file was written a long time ago, and worked perfectly well on Python 2.1, 2.2 and 2.3.) The same does not happen when importing the same module on Linux (tested with 2.4 and 2.4.1). When the module imports fine you'll get an ImportError (don't want to attach all dependencies here) but the SyntaxError comes before that. Also note that compiling the file with compiler.compileFile("dt.py") generates a perfectly good .pyc file that can be later imported just fine (tested with 2.4 and 2.4.1 on Windows). ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-05-18 06:15 Message: Logged In: YES user_id=86307 I'm fairly sure this is caused by the bug described here: www.python.org/sf/1175396 The module imports without syntax error on my Windows system (with a patched codecs.py to work around the above bug). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200686&group_id=5470 From noreply at sourceforge.net Thu May 19 00:49:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 May 2005 15:49:10 -0700 Subject: [ python-Feature Requests-1200804 ] enhancing os.chown functionality Message-ID: Feature Requests item #1200804, was opened at 2005-05-12 11:26 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1200804&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: gyrof (gyrof) Assigned to: Nobody/Anonymous (nobody) Summary: enhancing os.chown functionality Initial Comment: Hi, I don't think it is currently possible (with os.chown or any other Python library function) to change the groupId of a file without specifying the userId (like posix 'chgrp' does), or to change the userId without specifying the groupId. I would suggest adding the option of having os.chown accept None as either the userId or groupId, and having the function change only the 'non-None' portion of the file ownership. Thanks for your consideration. -g ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-05-18 17:49 Message: Logged In: YES user_id=2772 the posix (os) module is intended as a thin wrapper around operating system services. The chown(2) syscall requires that owner and group both be specified. Possibly an enhanced chownonly/chgrp would find a home in the 'shutil' module. Possibly translating a parameter of None into -1 (which means 'no change') would be accepted as a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1200804&group_id=5470 From noreply at sourceforge.net Thu May 19 02:48:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 May 2005 17:48:58 -0700 Subject: [ python-Bugs-1199808 ] installation problem with python 2.4.1 on Win2k system Message-ID: Bugs item #1199808, was opened at 2005-05-11 08:50 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199808&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: mmkobayashi (mmkobayashi) Assigned to: Nobody/Anonymous (nobody) Summary: installation problem with python 2.4.1 on Win2k system Initial Comment: After several attempts to install python2.4.1 on a win2k systems with doing all windows updates, we have been unable to install python2.4.1 on this system. We have attached an error logfile. The main thing that happens is that the install proceeds as normal but at some point the install decides that something has gone wrong and uninstalls itself. Any help in this matter would be greatly appreciated. ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 20:48 Message: Logged In: YES user_id=593130 Help questions should better be directed to comp.lang.python == python mailing list == gmane.comp.python.general. The answers you get should help determine whether there is a bug in the install file distributed by PSF that should be reported here. Given that the install appeared to go ok until it tried to remove the existing files, I wonder whether there is a process running in the background that is using the existing install. That issue has been discussed on the python group recently. ---------------------------------------------------------------------- Comment By: mmkobayashi (mmkobayashi) Date: 2005-05-12 01:53 Message: Logged In: YES user_id=1273313 add file ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199808&group_id=5470 From noreply at sourceforge.net Thu May 19 03:01:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 May 2005 18:01:24 -0700 Subject: [ python-Bugs-1199808 ] installation problem with python 2.4.1 on Win2k system Message-ID: Bugs item #1199808, was opened at 2005-05-11 08:50 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199808&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: mmkobayashi (mmkobayashi) Assigned to: Nobody/Anonymous (nobody) Summary: installation problem with python 2.4.1 on Win2k system Initial Comment: After several attempts to install python2.4.1 on a win2k systems with doing all windows updates, we have been unable to install python2.4.1 on this system. We have attached an error logfile. The main thing that happens is that the install proceeds as normal but at some point the install decides that something has gone wrong and uninstalls itself. Any help in this matter would be greatly appreciated. ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 21:01 Message: Logged In: YES user_id=593130 You might also check out http://python.org/sf/1199947 ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 20:48 Message: Logged In: YES user_id=593130 Help questions should better be directed to comp.lang.python == python mailing list == gmane.comp.python.general. The answers you get should help determine whether there is a bug in the install file distributed by PSF that should be reported here. Given that the install appeared to go ok until it tried to remove the existing files, I wonder whether there is a process running in the background that is using the existing install. That issue has been discussed on the python group recently. ---------------------------------------------------------------------- Comment By: mmkobayashi (mmkobayashi) Date: 2005-05-12 01:53 Message: Logged In: YES user_id=1273313 add file ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199808&group_id=5470 From noreply at sourceforge.net Thu May 19 03:03:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 May 2005 18:03:56 -0700 Subject: [ python-Bugs-1200287 ] Windows msi installer fails on virtual drives Message-ID: Bugs item #1200287, was opened at 2005-05-11 20:55 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200287&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: bartgrantham (bartgrantham) Assigned to: Nobody/Anonymous (nobody) Summary: Windows msi installer fails on virtual drives Initial Comment: The MSI installer for 2.4.1 failed to install from a virtual drive under windows (ie. a drive created with subst). It would error out without an error code, immediately after package selection and before "thinking...". Not sure if this also applies to network mapped drives. Moving installer to genuine C: drive and running from there fixed the problem. ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 21:03 Message: Logged In: YES user_id=593130 This is almost certainly not a Python bug. See http://python.org/sf/1199947 Please close unless you see a particular bug with Python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200287&group_id=5470 From noreply at sourceforge.net Thu May 19 03:18:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 May 2005 18:18:43 -0700 Subject: [ python-Bugs-1202395 ] Description of string.lstrip() needs improvement Message-ID: Bugs item #1202395, was opened at 2005-05-15 13:50 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202395&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Roy Smith (roysmith) Assigned to: Nobody/Anonymous (nobody) Summary: Description of string.lstrip() needs improvement Initial Comment: In http://docs.python.org/lib/string-methods.html, under lstrip(), it says, "chars must be a string; the characters in the string will be stripped from the beginning of the string this method is called on". It would be clearer if it said: "chars must be a string; the characters in the string constitute a set of characters to be stripped from the beginning of the string this method is called on". Similarly for rstrip() and strip(). There was a recent posting to comp.lang.python where it appears that the poster thought the argument to lstrip() was a leading string to be removed, not a set of characters. ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 21:18 Message: Logged In: YES user_id=593130 Over the years, several people have tripped over this and posted to c.l.p., so I think the existing text is unclear enough to arguably qualify as a buglet. In response to the same posting, I had the same thought of clarifying that the 'string' defines a set, so I support this suggestion or something similar ;-) and thank you for submitting it. ---------------------------------------------------------------------- Comment By: Roy Smith (roysmith) Date: 2005-05-15 13:55 Message: Logged In: YES user_id=390499 I notice bug #1196824 (recently submitted and closed as "not a bug") relates to the same issue. It seems more than one person has gotten confused by this :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202395&group_id=5470 From noreply at sourceforge.net Thu May 19 04:02:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 May 2005 19:02:26 -0700 Subject: [ python-Bugs-1202533 ] a bunch of infinite C recursions Message-ID: Bugs item #1202533, was opened at 2005-05-15 19:43 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 Category: Python Interpreter Core Group: None Status: Open >Resolution: Works For Me Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 22:02 Message: Logged In: YES user_id=593130 On Windows, this caused the interactive window to just disappear.so I suspect something similar occurred. New is a known dangerous, use at your own risk, implementation specific module whose use, like byte code hacking, is outside the language proper. Both bypass normal object creation syntax and its checks and both can create invalid objects. A hold-your- hand inplementation would not give such access to internals. Lib Ref 3.28 says "This module provides a low-level interface to the interpreter, so care must be exercised when using this module. It is possible to supply non-sensical arguments which crash the interpreter when the object is used." Should more or different be said? If not, I suspect this should be closed as 'won't fix', as in 'won't remove the inherently dangerous new module'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 From noreply at sourceforge.net Thu May 19 04:10:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 May 2005 19:10:37 -0700 Subject: [ python-Bugs-1202946 ] Problem with abs function Message-ID: Bugs item #1202946, was opened at 2005-05-16 12:32 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202946&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ric-b (ric-b) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with abs function Initial Comment: On windows version I get : >>> abs(-9999999999999999999) Traceback (most recent call last): File "", line 1, in -toplevel- abs(-9999999999999999999) OverflowError: long too big to convert does not handle new longs. I am using the following work around: t = a - b # calc t = abs(a - b) if t < 0 : t *= -1 ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 22:10 Message: Logged In: YES user_id=593130 Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> abs(-9999999999999999999) 9999999999999999999L Ric-b: what windows version? Even older? If the problem is not with current or future (cvs) Python, please close this. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-18 07:53 Message: Logged In: YES user_id=1038590 I tried the OP's example in wxPython's PyShell as well as in the standard interpreter, and got the same result as Raymond. However, I was able to provoke a similar looking error by trying to convert a large long to a float (and the exception is telling the plain truth - a double precision float can't handle a number that big): Py> num = 1.0 Py> lng = -999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999 999999999999 Py> num += abs(lng) Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to float ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-16 13:33 Message: Logged In: YES user_id=80475 That's odd. It works for me: Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> abs(-9999999999999999999) 9999999999999999999L ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202946&group_id=5470 From noreply at sourceforge.net Thu May 19 04:15:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 May 2005 19:15:00 -0700 Subject: [ python-Bugs-1201456 ] Problem with recursion in dict (crash with core dump) Message-ID: Bugs item #1201456, was opened at 2005-05-13 11:43 Message generated for change (Settings changed) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Vladimir Yu. Stepanov (vys) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with recursion in dict (crash with core dump) Initial Comment: Please see example code. ---------------------------------------------------------------------- Comment By: Vladimir Yu. Stepanov (vys) Date: 2005-05-18 09:05 Message: Logged In: YES user_id=384980 sys.getrecursionlimit() returns 1000. I set sys.setrecursionlimit() to 500 and problem was resolved :) Thank you very much ! PS. Is it possible to add some checks in Py_SetRecursionLimit to reject overflow values ? ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-18 08:15 Message: Logged In: YES user_id=1038590 What does sys.getrecursionlimit() return? Does the buggy code generate the expected exception if you use sys.setrecursionlimit() to make the value smaller (e.g. 500)? FreeBSD has a history of not playing well with CPython's ability to detect inifinite recursion. . . ---------------------------------------------------------------------- Comment By: Vladimir Yu. Stepanov (vys) Date: 2005-05-13 12:06 Message: Logged In: YES user_id=384980 This is output from `uname -a`: FreeBSD fox.renet.ru 5.3-RELEASE FreeBSD 5.3-RELEASE #1: Fri Apr 15 10:38:49 MSD 2005 root at fox.renet.ru:/M/safedir/src/sys/i386/compile/FOX i386 I get some others with this code: Python 2.4.1 (#2, Apr 26 2005, 14:16:31) [GCC 3.4.2 [FreeBSD] 20040728] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> d = {} >>> >>> class test: ... def __hash__(self): ... d[self] = None ... >>> d[test()] = None Bus error (core dumped) fox:vys!~ > gdb python python.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Core was generated by `python'. Program terminated with signal 10, Bus error. (gdb) where #0 0x2828b3b1 in ldexp () from /lib/libc.so.5 #1 0x2828b618 in malloc () from /lib/libc.so.5 #2 0x080bdca1 in _PyObject_GC_Malloc () #3 0x080bdd4a in _PyObject_GC_New () #4 0x0805f556 in PyMethod_New () #5 0x0805c1a6 in PyInstance_NewRaw () #6 0x0805c66a in PyInstance_New () #7 0x0805cca1 in _PyInstance_Lookup () #8 0x080703e6 in PyDict_SetItem () #9 0x0809bb0e in PyEval_EvalFrame () #10 0x0809fc20 in PyEval_EvalCodeEx () #11 0x080d4d66 in PyFunction_SetClosure () #12 0x0805a38c in PyObject_Call () #13 0x0805fbe2 in PyMethod_New () #14 0x0805a38c in PyObject_Call () #15 0x08099f1b in PyEval_CallObjectWithKeywords () #16 0x0805ccb9 in _PyInstance_Lookup () #17 0x080703e6 in PyDict_SetItem () #18 0x0809bb0e in PyEval_EvalFrame () #19 0x0809fc20 in PyEval_EvalCodeEx () #20 0x080d4d66 in PyFunction_SetClosure () #21 0x0805a38c in PyObject_Call () #22 0x0805fbe2 in PyMethod_New () ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-13 11:55 Message: Logged In: YES user_id=80475 I get the expected behavior: RuntimeError: maximum recursion depth exceeded ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-13 11:55 Message: Logged In: YES user_id=6656 I get an infinite recursion runtime error. What platform are you on? ---------------------------------------------------------------------- Comment By: Vladimir Yu. Stepanov (vys) Date: 2005-05-13 11:46 Message: Logged In: YES user_id=384980 d = {} class test: def __hash__(self): d[self] = None d[test()] = None ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-13 11:46 Message: Logged In: YES user_id=6656 I see no code. SF can be a pain with this... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&group_id=5470 From noreply at sourceforge.net Thu May 19 07:21:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 May 2005 22:21:30 -0700 Subject: [ python-Bugs-1204734 ] Documentation error? Message-ID: Bugs item #1204734, was opened at 2005-05-18 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=105470&aid=1204734&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Eikenberry (zhar) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation error? Initial Comment: >From http://www.python.org/dev/doc/devel/ref/new-style-attribute-access.html "Called unconditionally to implement attribute accesses for instances of the class. If the class also defines __getattr__, it will never be called (unless called explicitly)." But I'm not seeing this behaviour in python-2.3.5 and python-2.4.1 on Linux. class A(object): def __getattr__(self,key): print '__getattr__',key raise AttributeError,key def __getattribute__(self,key): print '__getattribute__',key raise AttributeError,key a = A() a.foo $ python test.py __getattribute__ foo __getattr__ foo Traceback (most recent call last): File "test.py", line 14, in ? a.foo File "test.py", line 7, in __getattr__ raise AttributeError(key) AttributeError: foo It seems to be calling __getattribute__ as it should, but then it falls back on __getattr__ even though the docs specifically say it shouldn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&group_id=5470 From noreply at sourceforge.net Thu May 19 13:00:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 04:00:03 -0700 Subject: [ python-Bugs-998998 ] pickle bug - recursively memoizing class? Message-ID: Bugs item #998998, was opened at 2004-07-27 22:55 Message generated for change (Comment added) made by grubert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998998&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: pickle bug - recursively memoizing class? Initial Comment: The attached script (picklecycle.py) gives me an assertion error in Pickler.memoize(). Maybe I'm just doing something dumb. I have very little experience with pickle and even less experience pickling new-style class instances. I'm just trying to adapt an existing messy object graph to allow it to be pickled. I realize the two instances refer to each other, but I thought pickle was supposed to gracefully handle cyclic object graphs. I can worm around the problem a couple ways. First, getting rid of new-style classes does the trick. Also modifying B.__reduce__ to not return self.__dict__ seems to do the trick. Output (cycle.out) and a modified version of Pickler.memoize (memoize.py) will be attached momentarily. ---------------------------------------------------------------------- Comment By: engelbert gruber (grubert) Date: 2005-05-19 13:00 Message: Logged In: YES user_id=147070 it does memoize recursively, but "asserts" not to get stuck in cycles. that's how i understand the code if :: assert id(obj) not in self.memo is replaced by :: if id(obj) in self.memo: return it works (better). and test_pickle.py still passes. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-07-27 22:57 Message: Logged In: YES user_id=44345 Attaching the output I see when running picklecycle.py w/ the modified memoize() method (cycle.out). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-07-27 22:56 Message: Logged In: YES user_id=44345 Attaching chatty version of Pickler.memoize() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998998&group_id=5470 From noreply at sourceforge.net Thu May 19 15:53:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 06:53:11 -0700 Subject: [ python-Bugs-1153016 ] Setting socket timeout crashes SSL Message-ID: Bugs item #1153016, was opened at 2005-02-27 19:41 Message generated for change (Comment added) made by tarek-ziade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153016&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: pristine777 (pristine777) Assigned to: Nobody/Anonymous (nobody) Summary: Setting socket timeout crashes SSL Initial Comment: This bug was fixed in Python 2.3 but has resurfaced in Python 2.4 The original bug report can be found at: https://sourceforge.net/tracker/? func=detail&atid=105470&aid=673797&group_id=5470 The method urlopen both in urllib and in urllib2 crashes if socket.setdefaulttimeout has been called. Below is a cut and paste when using the function in urllib. >>> import socket >>> socket.setdefaulttimeout(30.0) >>> import urllib >>> urllib.urlopen('https://members.tufts- health.com/memindex.html') Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\urllib.py", line 77, in urlopen return opener.open(url) File "C:\Python24\lib\urllib.py", line 180, in open return getattr(self, name)(url) File "C:\Python24\lib\urllib.py", line 374, in open_https h.endheaders() File "C:\Python24\lib\httplib.py", line 794, in endheaders self._send_output() File "C:\Python24\lib\httplib.py", line 675, in _send_output self.send(msg) File "C:\Python24\lib\httplib.py", line 642, in send self.connect() File "C:\Python24\lib\httplib.py", line 1069, in connect ssl = socket.ssl(sock, self.key_file, self.cert_file) File "C:\Python24\lib\socket.py", line 74, in ssl return _realssl(sock, keyfile, certfile) IOError: [Errno socket error] (2, 'The operation did not complete (read)') Thanks a ton! ---------------------------------------------------------------------- Comment By: Tarek Ziad? (tarek-ziade) Date: 2005-05-19 13:53 Message: Logged In: YES user_id=1163510 having same issue here, using imaplib thru ssl :/ >>> import socket >>> socket.setdefaulttimeout(10) >>> i = imaplib.IMAP4_SSL('mail.xxxx.com') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/imaplib.py", line 1101, in __init__ IMAP4.__init__(self, host, port) File "/usr/lib/python2.4/imaplib.py", line 181, in __init__ self.welcome = self._get_response() File "/usr/lib/python2.4/imaplib.py", line 876, in _get_response resp = self._get_line() File "/usr/lib/python2.4/imaplib.py", line 969, in _get_line line = self.readline() File "/usr/lib/python2.4/imaplib.py", line 1136, in readline char = self.sslobj.read(1) socket.sslerror: The read operation timed out so i can't get timeouts with ssl in imap :/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153016&group_id=5470 From noreply at sourceforge.net Thu May 19 17:05:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 08:05:57 -0700 Subject: [ python-Bugs-1202533 ] a bunch of infinite C recursions Message-ID: Bugs item #1202533, was opened at 2005-05-15 23:43 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 Category: Python Interpreter Core Group: None Status: Open >Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-05-19 15:05 Message: Logged In: YES user_id=4771 This is not about the new module. The same example can be written as: import types class A: pass A.__mul__ = types.MethodType(operator.mul, None, A) If this still looks essentially like an indirect way of using the new module, here is another example: class A(str): __get__ = getattr a = A('a') A.a = a a.a Or, as I just found out, new-style classes are again vulnerable to the older example based __call__, which was fixed for old-style classes: class A(object): pass A.__call__ = A() A()() I'm not denying that these examples look convoluted :-) My point here is that we can basically build a lot of examples based only on core (if not necessarily widely understood) language features. It appears to go against the basic hope that CPython cannot be crashed as long as you don't use features explicitely marked as dangerous. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-19 02:02 Message: Logged In: YES user_id=593130 On Windows, this caused the interactive window to just disappear.so I suspect something similar occurred. New is a known dangerous, use at your own risk, implementation specific module whose use, like byte code hacking, is outside the language proper. Both bypass normal object creation syntax and its checks and both can create invalid objects. A hold-your- hand inplementation would not give such access to internals. Lib Ref 3.28 says "This module provides a low-level interface to the interpreter, so care must be exercised when using this module. It is possible to supply non-sensical arguments which crash the interpreter when the object is used." Should more or different be said? If not, I suspect this should be closed as 'won't fix', as in 'won't remove the inherently dangerous new module'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 From noreply at sourceforge.net Thu May 19 21:06:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 12:06:31 -0700 Subject: [ python-Bugs-1178484 ] Erroneous line number error in Py2.4.1 Message-ID: Bugs item #1178484, was opened at 2005-04-07 14:33 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&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: Open Resolution: Accepted Priority: 5 Submitted By: Timo Linna (tilinna) Assigned to: Martin v. L?wis (loewis) Summary: Erroneous line number error in Py2.4.1 Initial Comment: For some reason Python 2.3.5 reports the error in the following program correctly: File "C:\Temp\problem.py", line 7 SyntaxError: unknown decode error ..whereas Python 2.4.1 reports an invalid line number: File "C:\Temp\problem.py", line 2 SyntaxError: unknown decode error ----- problem.py starts ----- # -*- coding: ascii -*- """ Foo bar """ # ? is not allowed in ascii coding ----- problem.py ends ----- Without the encoding declaration both Python versions report the usual deprecation warning (just like they should be doing). My environment: Windows 2000 + SP3. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-05-19 21:06 Message: Logged In: YES user_id=89016 > Walter, as I've said before: I know that you need buffering > for the UTF-x readline support, but I don't see a > requirement for it in most of the other codecs The *charbuffer* is required for readline support, but the *bytebuffer* is required for any non-charmap codec. To have different buffering modes we'd either need a flag in the StreamReader or use different classes, i.e. a class hierarchy like the following: StreamReader UnbufferedStreamReader CharmapStreamReader ascii.StreamReader iso_8859_1.StreamReader BufferedStreamReader utf_8.StreamReader I don't think that we should introduce such a big change in 2.4.x. Furthermore there is another problem: The 2.4 buffering code automatically gives us universal newline support. If you have a file foo.txt containing "a\rb", with Python 2.4 you get: >>> list(codecs.open("foo.txt", "rb", "latin-1")) [u'a\r', u'b'] But with Python 2.3 you get: >>> list(codecs.open("foo.txt", "rb", "latin-1")) [u'a\rb'] If we would switch to the old StreamReader for the charmap codecs, suddenly the stream reader for e.g. latin-1 and UTF-8 would behave differently. Of course we could change the buffering stream reader to only split lines on "\n", but this would change functionality again. > Your argument about applications making implications on the > file position after having used .readline() is true, but > still many applications rely on this behavior which is not > as far fetched as it may seem given that they normally only > expect 8-bit data. If an application doesn't mix calls to read() with calls to readline() (or different size values in these calls), the change in behaviour from 2.3 to 2.4 shouldn't be this big. No matter what we decide for the codecs, the tokenizer is broken and should be fixed. > Wouldn't it make things a lot safer if we only use buffering > per default in the UTF-x codecs and revert back to the old > non-buffered behavior for the other codecs which has worked > well in the past ?! Only if we'd drop the additional functionality added in 2.4. (universal newline support, the chars argument for read() and the keepends argument for readline().), which I think could only be done for 2.5. > About your patch: > > * Please explain what firstline is supposed to do > (preferably in the doc-string). OK, I've added an explanation in the docstring. > * Why is firstline always set in .readline() ? firstline is only supposed to be used by readline(). We could rename the argument to _firstline to make it clear that this is a private parameter, or introduce a new method _read() that has a firstline parameter. Then read() calls _read() with firstline==False and readline() calls _read() with firstline==True. The purpose of firstline is to make sure that if an input stream has its first decoding error in line n, that the UnicodeDecodeError will only be raised by the n'th call to readline(). > * Please remove the print repr() OK, done. > * You cannot always be sure that exc has a .start attribute, > so you need to accomocate for this situation as well I don't understand that. A UnicodeDecodeError is created by PyUnicodeDecodeError_Create() in exceptions.c, so any UnicodeDecodeError instance without a start attribute would be severely broken. Thanks for reviewing the patch. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-05-18 11:31 Message: Logged In: YES user_id=38388 Walter, as I've said before: I know that you need buffering for the UTF-x readline support, but I don't see a requirement for it in most of the other codecs. E.g. an ascii codec or latin-1 codec will only ever see standard line ends (not Unicode ones), so the streams .readline() method can be used directly - just like we did before the buffering code was added. Your argument about applications making implications on the file position after having used .readline() is true, but still many applications rely on this behavior which is not as far fetched as it may seem given that they normally only expect 8-bit data. Wouldn't it make things a lot safer if we only use buffering per default in the UTF-x codecs and revert back to the old non-buffered behavior for the other codecs which has worked well in the past ?! About your patch: * Please explain what firstline is supposed to do (preferably in the doc-string). * Why is firstline always set in .readline() ? * Please remove the print repr() * You cannot always be sure that exc has a .start attribute, so you need to accomocate for this situation as well ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-05-17 18:50 Message: Logged In: YES user_id=89016 It isn't the buffering support per se that breaks the tokenizer. This problem exists even in Python 2.3.x (Simply try the test scripts from http://www.python.org/sf/1089395 with Python 2.3.5 and you'll get a segfault). Applications that rely on len(readline(x)) == x or anything similar are broken anyway. Supporting buffered and unbuffered reading would mean keeping the 2.3 mode of doing things around indefinitely, and we'd loose readline() support for UTF-16 again. BTW, applying Greg Chapman's patch (http://www.python.org/sf/1101726, which fixes the tokenizer) together with this one seems to fix the problem from my previous post. So if you could give http://www.python.org/sf/1101726 a third look, so we can get it into 2.4.2, this would be great. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-05-17 11:13 Message: Logged In: YES user_id=38388 Walter, I think that instead of trying to get the tokenizer to work with the buffer support in the codecs, you should add a flag that allows to switch off the buffer support in the codecs altogether and then use the unbuffered mode codecs in the tokenizer. I expect that other applications will run into the same kind of problem, so it should be possible to switch off buffering if needed (maybe we should make this the default ?!). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-05-16 10:35 Message: Logged In: YES user_id=89016 OK, here is a patch. It adds an additional argument firstline to read(). If this argument is true (i.e. if called from readline()) and a decoding error happens, this error will only be reported if it is in the first line. Otherwise read() will decode up to the error position and put the rest in the bytebuffer. Unfortunately with this patch, I get a segfault with the following stacktrace if I run the test. I don't know if this is related to bug #1089395/patch #1101726. Martin, can you take a look? #0 0x08057ad1 in tok_nextc (tok=0x81ca7b0) at tokenizer.c:719 #1 0x08058558 in tok_get (tok=0x81ca7b0, p_start=0xbffff3d4, p_end=0xbffff3d0) at tokenizer.c:1075 #2 0x08059331 in PyTokenizer_Get (tok=0x81ca7b0, p_start=0xbffff3d4, p_end=0xbffff3d0) at tokenizer.c:1466 #3 0x080561b1 in parsetok (tok=0x81ca7b0, g=0x8167980, start=257, err_ret=0xbffff440, flags=0) at parsetok.c:125 #4 0x0805613c in PyParser_ParseFileFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", g=0x8167980, start=257, ps1=0x0, ps2=0x0, err_ret=0xbffff440, flags=0) at parsetok.c:90 #5 0x080f3926 in PyParser_SimpleParseFileFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", start=257, flags=0) at pythonrun.c:1345 #6 0x080f352b in PyRun_FileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", start=257, globals=0xb7d62e94, locals=0xb7d62e94, closeit=1, flags=0xbffff544) at pythonrun.c:1239 #7 0x080f22f2 in PyRun_SimpleFileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", closeit=1, flags=0xbffff544) at pythonrun.c:860 #8 0x080f1b16 in PyRun_AnyFileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", closeit=1, flags=0xbffff544) at pythonrun.c:664 #9 0x08055e45 in Py_Main (argc=2, argv=0xbffff5f4) at main.c:484 #10 0x08055366 in main (argc=2, argv=0xbffff5f4) at python.c:23 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-07 16:28 Message: Logged In: YES user_id=89016 The reason for this is the new codec buffering code in 2.4: The codec might read and decode more data from the byte stream than is neccessary for decoding one line. I.e. when reading line n, the codec might decode bytes that belong to line n+1, n+2 etc. too. If there's a decoding error in this data, line n gets reported. I don't think there's a simple fix for this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&group_id=5470 From noreply at sourceforge.net Thu May 19 21:07:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 12:07:45 -0700 Subject: [ python-Bugs-1178145 ] urllib2.py assumes 206 is an error Message-ID: Bugs item #1178145, was opened at 2005-04-06 23:52 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178145&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: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Barry Alan Scott (barry-scott) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2.py assumes 206 is an error Initial Comment: I'm writting code that uses the Range header. The correct response is 206, but the urllib2.py is coded to treat any code that is not 200 as error. The correct code needs to treat 200 to 299 as success. The attached patch fixes the problem. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-05-19 20:07 Message: Logged In: YES user_id=261020 Please close: this is already fixed in 2.4. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-04-08 17:17 Message: Logged In: YES user_id=764593 Please re-attach. SF didn't get the file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178145&group_id=5470 From noreply at sourceforge.net Thu May 19 21:10:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 12:10:09 -0700 Subject: [ python-Bugs-1175848 ] poorly named variable in urllib2.py Message-ID: Bugs item #1175848, was opened at 2005-04-03 16:26 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175848&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: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Roy Smith (roysmith) Assigned to: Nobody/Anonymous (nobody) Summary: poorly named variable in urllib2.py Initial Comment: This is kind of trivial, but in urllib2.OpenerDirector.__init__, the local variable "server_version" is poorly named. The name makes it sound like it's the version of the HTTP (or whatever) server we're talking to. How about client_version or library_version or module_version? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-05-19 20:10 Message: Logged In: YES user_id=261020 My, you're picky. ;-) Yes, that does seem a poor name, +1 on changing it to client_version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175848&group_id=5470 From noreply at sourceforge.net Thu May 19 21:18:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 12:18:19 -0700 Subject: [ python-Bugs-1167397 ] Python 2.4 causes BitTorrent 3.4.2 failure Message-ID: Bugs item #1167397, was opened at 2005-03-21 09:37 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167397&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew P. Lentvorski, Jr. (bsder) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4 causes BitTorrent 3.4.2 failure Initial Comment: The following failure messages gets dumped out of BitTorrent 3.4.2 when run against Python 2.4: Traceback (most recent call last): File "/usr/local/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "/usr/local/lib/python2.4/threading.py", line 422, in run self.__target(*self.__args, **self.__kwargs) File "/home/andrewl/python/lib/python2.4/site-packages/BitTorrent/Rerequester.py", line 84, in rerequest h = urlopen(url) File "/usr/local/lib/python2.4/urllib2.py", line 130, in urlopen return _opener.open(url, data) File "/usr/local/lib/python2.4/urllib2.py", line 364, in open response = meth(req, response) File "/usr/local/lib/python2.4/urllib2.py", line 468, in http_response code, msg, hdrs = response.code, response.msg, response.info() AttributeError: addinfourldecompress instance has no attribute 'code' ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-05-19 20:18 Message: Logged In: YES user_id=261020 This is indeed http://python.org/sf/852995 again (the yum package manager bug). I don't think this is a Python bug, though it's possible a patch could insulate users from this change (even though the change was not to a public API). My detailed comments on the corresponding yum bug are here: https://bugzilla.redhat.com/beta/show_bug.cgi?id=138535#c44 Unless it's very new, addinfourldecompress is from BitTorrent, not Python. ---------------------------------------------------------------------- Comment By: Andrew P. Lentvorski, Jr. (bsder) Date: 2005-03-21 20:44 Message: Logged In: YES user_id=752864 The same BitTorrent version works just fine under 2.3.5. addinfourldecompress is a BitTorrent object which inherits from Python's addinfourl in urllib.py. The following comment was found in a patch that attempted to work around the issue: # As of Python 2.4 http_open response also has 'code' and 'msg' # members, and HTTPErrorProcessor breaks if they don't exist. This problem has been cited in a couple of different contexts. I saw it in a bug report for bittornado on FreeBSD. I also saw it in a RedHat list concerning breakage in the yum utility. Annoyingly, nobody seems to have filed it upstream with the Python folks. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-03-21 14:55 Message: Logged In: YES user_id=357491 Does this happen if the exact same files are run in 2.3? I can't find addinfourldecompress in Python; is it a BitTorrent class? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167397&group_id=5470 From noreply at sourceforge.net Thu May 19 21:30:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 12:30:35 -0700 Subject: [ python-Bugs-1153027 ] http_error_302() crashes with 'HTTP/1.1 400 Bad Request Message-ID: Bugs item #1153027, was opened at 2005-02-27 20:16 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153027&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: pristine777 (pristine777) Assigned to: Nobody/Anonymous (nobody) Summary: http_error_302() crashes with 'HTTP/1.1 400 Bad Request Initial Comment: I was able to get to a website by using both IE and FireFox but my Python code kept giving HTTP 400 Bad request error. To debug, I set set_http_debuglevel(1) as in the following code: hh = urllib2.HTTPHandler() hh.set_http_debuglevel(1) opener = urllib2.build_opener (hh,urllib2.HTTPCookieProcessor(self.cj)) The printed debug messages show that this crash happens when there is a space in the redirected location. Here's a cut-and-paste of the relevant debug messages (note the line starting with send that http_error_302 is sending): reply: 'HTTP/1.1 302 Moved Temporarily\r\n' header: Connection: close header: Date: Sun, 27 Feb 2005 19:52:51 GMT header: Server: Microsoft-IIS/6.0 <---other header data--> send: 'GET /myEmail/User?asOf=02/26/2005 11:38:12 PM& ddn=87cb51501730 <---remaining header data--> reply: 'HTTP/1.1 400 Bad Request\r\n' header: Content-Type: text/html header: Date: Sun, 27 Feb 2005 19:56:45 GMT header: Connection: close header: Content-Length: 20 To fix this, I first tried to encode the redirected location in the function http_error_302() in urllib2 using the methods urllib.quote and urllib.urlencode but to no avail (they encode other data as well). A temporary solution that works is to replace any space in the redirected URL by'%20'. Below is a snippet of the function http_error_302 in urllib2 with this suggested fix: def http_error_302(self, req, fp, code, msg, headers): # Some servers (incorrectly) return multiple Location headers # (so probably same goes for URI). Use first header. if 'location' in headers: newurl = headers.getheaders('location')[0] elif 'uri' in headers: newurl = headers.getheaders('uri')[0] else: return newurl=newurl.replace(' ','%20') # <<< TEMP FIX - inserting this line temporarily fixes this problem newurl = urlparse.urljoin(req.get_full_url(), newurl) <--- remainder of this function --> Thanks! ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-05-19 20:30 Message: Logged In: YES user_id=261020 Sure, but if Firefox and IE do it, probably we should do the same. I think cookielib.escape_path(), or something similar (perhaps without the case normalisation) is probably the right thing to do. That's not part of any documented API; I suppose that function or a similar one should be added to module urlparse, and used by urllib2 and urllib when redirecting. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-03-01 17:41 Message: Logged In: YES user_id=2772 When the server sends the 302 response with 'Location: http://example.com/url%20with%20whitespace', urllib2 seems to work just fine. I believe based on reading rfc2396 that a URL that contains spaces must contain quoted spaces (%20) not literal spaces, because space is not an "unreserved character" [2.3] and "[d]ata must be escaped if it does not have a representation using an unreserved character" [2.4]. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153027&group_id=5470 From noreply at sourceforge.net Thu May 19 21:40:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 12:40:07 -0700 Subject: [ python-Bugs-1152723 ] urllib2 dont respect debuglevel in httplib Message-ID: Bugs item #1152723, was opened at 2005-02-27 02:49 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1152723&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: abbatini (abbatini) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 dont respect debuglevel in httplib Initial Comment: It is common habit to see http headers: >>> import httplib >>> httplib.HTTPConnection.debuglevel = 1 >>> import urllib >>> feeddata = urllib.urlopen('http://diveintomark.org/xml/atom.xml').read() but this dont work with import urllib2 with python 2.4 In rev 1.57 was intoduced code to AbstractHTTPHandler class that prevent above mentioned construction. Init method always set debuglevel=0 then do_open method always do: h.set_debuglevel(self._debuglevel) after instantiating HTTPConnection class. Regards ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-05-19 20:40 Message: Logged In: YES user_id=261020 The .set_debuglevel() method allows debugging per-HTTPConnection when using urllib2 (instead of turning on debug prints for *all* HTTPConnection instances). Since this is just turns on some debug prints, I don't see any great need to contort the code and/or confuse people further by attempting to "fix" this. ---------------------------------------------------------------------- Comment By: abbatini (abbatini) Date: 2005-02-27 02:57 Message: Logged In: YES user_id=1227778 of course: # h.set_debuglevel(self._debuglevel) work very well, but i dont know reason this code was introduced, maybe forgotten code since development ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1152723&group_id=5470 From noreply at sourceforge.net Thu May 19 21:48:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 12:48:50 -0700 Subject: [ python-Bugs-1070735 ] urllib2 authentication redirection error(?) Message-ID: Bugs item #1070735, was opened at 2004-11-22 02:01 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1070735&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: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Allan B. Wilson (allanbwilson) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 authentication redirection error(?) Initial Comment: I am trying to use urllib2 to retrieve a page from a site requiring authentication. I supply the authentication parameters, which succeed, and *a* page is returned -- but not the page I originally requested. As it turns out, the authentication is handled at a completely different URL (actually a different domain); I can confirm this by not supplying authentication data, because I see a 302 earlier in the traceback when authentication fails. What I think is happening is that the redirect happens to the authentication site, but the original URL that I wanted has been forgotten. The page I get back is the default page for the original (now authenticated) site, not the page itself, which is deeper down in the site hierarchy. Sorry, I can't supply a patch! Thanks ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-05-19 20:48 Message: Logged In: YES user_id=261020 Allan, unfortunately there's no way of investigating this without a running script that demonstrates the problem. Please supply one, or close the bug. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1070735&group_id=5470 From noreply at sourceforge.net Thu May 19 21:54:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 12:54:36 -0700 Subject: [ python-Feature Requests-1205239 ] Let shift operators take any integer value Message-ID: Feature Requests item #1205239, was opened at 2005-05-19 19:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&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: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Albert Torpey (dtorp) Assigned to: Nobody/Anonymous (nobody) Summary: Let shift operators take any integer value Initial Comment: Let: 1 >> -4 be interpreted as: 1 << 4 This should be easy to do. It would be somewhat helpful for bit manipulations and multiplying by powers of two. Without the change, my code is laced with sections like: if y > 0: z = x << y else: z = x >> -y This is ugly and slow compared to a straight: z = x << y There is a precedent. See what is done with negative list indices for comparison. It saves even less code with x[len (x)-i] becoming x[i]. The reason for doing it is code simplication and clarity. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&group_id=5470 From noreply at sourceforge.net Thu May 19 22:05:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 13:05:07 -0700 Subject: [ python-Bugs-971965 ] urllib2 raises exception with non-200 success codes. Message-ID: Bugs item #971965, was opened at 2004-06-13 05:00 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=971965&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: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ed Watkeys (edw) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 raises exception with non-200 success codes. Initial Comment: If a server returns a code other than 200, specifically 201 (Created), urllib2.urlopen will raise an HTTPError exception. I ran into this while implementing an Atom API client, which solicits 201 responses from the server when submitting a blog post. File "/usr/local/lib/python2.3/urllib2.py", line 129, in urlopen return _opener.open(url, data) File "/usr/local/lib/python2.3/urllib2.py", line 326, in open '_open', req) File "/usr/local/lib/python2.3/urllib2.py", line 306, in _call_chain result = func(*args) File "/usr/local/lib/python2.3/urllib2.py", line 901, in http_open return self.do_open(httplib.HTTP, req) File "/usr/local/lib/python2.3/urllib2.py", line 895, in do_open return self.parent.error('http', req, fp, code, msg, hdrs) File "/usr/local/lib/python2.3/urllib2.py", line 352, in error return self._call_chain(*args) File "/usr/local/lib/python2.3/urllib2.py", line 306, in _call_chain result = func(*args) File "/usr/local/lib/python2.3/urllib2.py", line 412, in http_error_default raise HTTPError(req.get_full_url(), code, msg, hdrs, fp) urllib2.HTTPError: HTTP Error 201: Created ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-05-19 21:05 Message: Logged In: YES user_id=261020 Before bug 912845 (CVS rev 1.69) added 206 to the list of response codes considered "successful" by urllib2, I'd assumed this would never be altered, for backwards-compatibility reasons. Note that this behaviour can be configured by module users, since HTTPError exceptions support the urllib2 response interface. This can be done by replacing HTTPErrorProcessor, or by replacing HTTPDefaultErrorHandler, or catching the exception "manually". But maybe since the 206 issue was considered a valid bug fix, this is OK too. If so, it would be best if the other 20x responses were also considered at the same time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=971965&group_id=5470 From noreply at sourceforge.net Thu May 19 22:12:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 13:12:09 -0700 Subject: [ python-Bugs-944407 ] No documentation for urllib2 exception classes Message-ID: Bugs item #944407, was opened at 2004-04-29 12:38 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944407&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: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: No documentation for urllib2 exception classes Initial Comment: There's not even reference documentation for the exceptions used by urllib2. Documentation of what these are, how you're supposed to handle them and what attributes you're supposed to play with would be very handy. I guess I'll just have to try and glean something from the source :-S ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-05-19 21:12 Message: Logged In: YES user_id=261020 This is not correct, these exceptions are documented. (from http://docs.python.org/lib/module-urllib2.html) The following exceptions are raised as appropriate: exception URLError The handlers raise this exception (or derived exceptions) when they run into a problem. It is a subclass of IOError. exception HTTPError A subclass of URLError, it can also function as a non-exceptional file-like return value (the same thing that urlopen() returns). This is useful when handling exotic HTTP errors, such as requests for authentication. exception GopherError A subclass of URLError, this is the error raised by the Gopher handler. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944407&group_id=5470 From noreply at sourceforge.net Thu May 19 22:22:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 13:22:03 -0700 Subject: [ python-Bugs-844336 ] urllib2 fails its builtin test Message-ID: Bugs item #844336, was opened at 2003-11-18 12:32 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844336&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: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 fails its builtin test Initial Comment: >python -u "ftplib.py" Traceback (most recent call last): File "ftplib.py", line 803, in ? test() File "ftplib.py", line 762, in test while sys.argv[1] == '-d': IndexError: list index out of range >Exit code: 1 >python -u "urllib2.py" gopher://gopher.lib.ncsu.edu/11/library/stacks/Alex socket.error: (7, 'getaddrinfo failed') gopher://gopher.vt.edu:10010/10/33 socket.error: (7, 'getaddrinfo failed') file:/etc/passwd Traceback (most recent call last): File "urllib2.py", line 1154, in ? f = urlopen(url, req) File "urllib2.py", line 136, in urlopen return _opener.open(url, data) File "urllib2.py", line 333, in open '_open', req) File "urllib2.py", line 313, in _call_chain result = func(*args) File "urllib2.py", line 928, in file_open return self.open_local_file(req) File "urllib2.py", line 943, in open_local_file stats = os.stat(localfile) OSError: [Errno 2] No such file or directory: '\etc\passwd' >Exit code: 1 ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-05-19 21:22 Message: Logged In: YES user_id=261020 This should be closed: this issue was resolved by patch 852995. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-08 00:17 Message: Logged In: YES user_id=261020 Sorry, last comment not very useful. I think this should be closed. Two real problems: 1. urllib2.urlopen incorrectly raises OSError instead of URLError. This is already detected by my unit tests (852995), and I'll file a separate bug for this later (when/if 852995 is resolved). 2. Would be nice if urllib2's functional tests used PyUnit (so it is clear which tests are passing or failing), and worked on Windows. Again, I'll submit a separate patch. To the bug poster: 0. ftplib is not urllib2, please report bugs separately. 1. You're not invoking ftplib's test program correctly. It seems to work, at least partially: python ftplib.py ftp.python.org /pub/www.python.org/index.html 2. It seems you're using Windows, so you shouldn't expect opening /etc/password to work (though the test shouldn't crash as it does, of course, and it should work on Windows, and it should give an indication of pass/fail). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-03 19:40 Message: Logged In: YES user_id=261020 It is broken. I'd like to know where functional tests officially live before fixing it. I'll ask on python-dev... ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2003-11-18 22:04 Message: Logged In: YES user_id=285587 This is a response to quiver. Thanks for pointing out the correct usage of ftlib, I am slowly sorting out how to use ftplib from a script. Unfortunately my report did not make it clear that there is a problem with the operation of the test function. Usually, a test function gives some assurance that the main code of the module is functional. In this case, the test fails. That, I suggest, indicates a bug. The bug could be in test function or the module being exercised. You are probably right that a host needs to be specified. I suggest that the test function should be responsible for this. Incidentally, it would be very helpful to the potential user if the documentation made the names and roles of the various cmds's clearer. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-11-18 15:48 Message: Logged In: YES user_id=671362 For the first one, you need to specify a host to run the test. For expample, >python ftplib.py ftp.python.org -l This gives drwxrwxr-x 5 webmaster webmaster 512 Jan 25 2003 pub There is a usage on the test in the script: '''Test program. Usage: ftp [-d] [-r[file]] host [-l[dir]] [-d[dir]] [-p] [file] ...''' I think this is not a bug. For the second one, catching OSError along with IOError might be needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844336&group_id=5470 From noreply at sourceforge.net Thu May 19 22:24:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 13:24:34 -0700 Subject: [ python-Bugs-745097 ] urllib2 doesn't handle urls without scheme Message-ID: Bugs item #745097, was opened at 2003-05-28 19:54 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745097&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: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 doesn't handle urls without scheme Initial Comment: urllib2.urlopen does not handle URLs without a scheme, so the following code will not work: url = urllib.pathname2url('/etc/passwd') urllib2.urlopen(url) The same code does work with urllib.urlopen. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-05-19 21:24 Message: Logged In: YES user_id=261020 Could somebody close this? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-11-30 23:24 Message: Logged In: YES user_id=261020 Is it wise to allow this? Maybe it's unlikely to cause bugs, but "/etc/passwd" could refer to any URI scheme, not only file:. Since it seems reasonable to only allow absolute URLs, I think it's a bad idea to guess the scheme is file: when given a relative URL. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745097&group_id=5470 From noreply at sourceforge.net Thu May 19 22:38:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 13:38:38 -0700 Subject: [ python-Bugs-1046077 ] urllib2: better import ftplib and gopherlib etc late Message-ID: Bugs item #1046077, was opened at 2004-10-13 10:41 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1046077&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: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robert Kiendl (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2: better import ftplib and gopherlib etc late Initial Comment: I've always trouble shrinking a py2exe'd package, because of this. its also a speed issue. urllib2 is most time used only with http(s) ...? *** urllib2_old.py Tue May 11 16:14:34 2004 --- urllib2.py Wed Oct 13 11:32:44 2004 *************** f = urllib2.urlopen('http://www.python.o *** 88,95 **** # check digest against correct (i.e. non-apache) implementation import base64 - import ftplib - import gopherlib import httplib import inspect import md5 --- 88,93 ---- *************** class FileHandler(BaseHandler): *** 1009,1014 **** --- 1007,1013 ---- class FTPHandler(BaseHandler): def ftp_open(self, req): + import ftplib host = req.get_host() if not host: raise IOError, ('ftp error', 'no host given') *************** class CacheFTPHandler(FTPHandler): *** 1110,1115 **** --- 1109,1115 ---- class GopherHandler(BaseHandler): def gopher_open(self, req): + import gopherlib host = req.get_host() if not host: raise GopherError('no host given') ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-05-19 21:38 Message: Logged In: YES user_id=261020 Since Jeremy doesn't like the idea, this should probably be closed, but: Robert re-submitted this as patch 1053150. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2004-11-07 14:42 Message: Logged In: YES user_id=31392 I'd rather not move imports from their typical place for a small performance chance in an unusual use case. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-10-15 23:55 Message: Logged In: YES user_id=593130 Since you have a patch, this should have been submitted as a patch rather than a bug. In any case, the patch needs to be submitted as separate file ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1046077&group_id=5470 From noreply at sourceforge.net Thu May 19 23:42:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 14:42:13 -0700 Subject: [ python-Bugs-1072623 ] FeedParser problem on end boundaries w/o newline Message-ID: Bugs item #1072623, was opened at 2004-11-24 09:27 Message generated for change (Comment added) made by binaryfeed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072623&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: Python Library Group: Python 2.4 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Tessa Lau (tlau) Assigned to: Barry A. Warsaw (bwarsaw) Summary: FeedParser problem on end boundaries w/o newline Initial Comment: (Python 2.3.4, Linux Debian unstable) The email module's as_string() method generates messages that do not include a trailing CRLF on the last line. This causes problems when Python-created messages are piped to procmail and delivered to an mbox. The attached test script illustrates this behavior. You must have a working procmail configured to deliver mail to an mbox (the default configuration will work). If you then read the resulting mailbox with /bin/mail, it appears as if there is only one message in the mailbox, instead of two. The second is concatenated on to the end of the first. The mbox does not contain a blank line between the first message and the second. Pop servers require this blank line delimiter between messages. You could argue that this is procmail's responsibility, but as far as I can tell from reading RFC 2822, each line in an email message must terminate in CRLF, and Python's email module is violating that spec. ---------------------------------------------------------------------- Comment By: Jeffrey Wescott (binaryfeed) Date: 2005-05-19 14:42 Message: Logged In: YES user_id=189789 Well, idempotency is completely borked. If I do: f = file('somemessage') import email m = email.message_from_file(f) f2 = file('newmsg', 'w') f2.write(m.as_string()) somemessage and newmsg will be *different*. This is hardly "what goes in equals what goes out". ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-11-30 14:21 Message: Logged In: YES user_id=12800 Yep, it was someone else's posting, sorry about that. As for the trailing newline on non-MIME messages, you will need to make sure that your payload is terminated with a newline. Generator won't do that on the basis that maintaining idempotency (what goes in equals what goes out) is more important. ---------------------------------------------------------------------- Comment By: Tessa Lau (tlau) Date: 2004-11-29 05:23 Message: Logged In: YES user_id=112896 It must have been someone else on the email sig; I haven't posted there recently. Thanks for the workaround. However, it only fixes the problem for MIME messages, but not for non-MIME messages. The second message constructed in my test script still lacks a trailing newline. I can work around it after the message is generated by checking for a final newline on the string and adding it if it's missing, but that seems clunky. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-11-28 17:10 Message: Logged In: YES user_id=12800 I must have been thinking about the message you posted to the email sig, which uncovered the bug I commented on, and fixed. In the case of the original bug report, I don't believe this is fixable. There is, however a simple workaround for you. In your sample code, set the outer message's epilogue to the empty string, e.g.: msg1.epilogue = '' ... msg2.epilogue = '' This will cause the Generator to add a newline at the end of the outer message. We can't make that change in the Message class because doing so would break inner message flattening. However, if someone were to come up with a patch that fixes this problem yet doesn't break any of the 217 tests in the current test suite, I'd be happy to look at it. As it is, nothing will be changed for Python 2.4. final. ---------------------------------------------------------------------- Comment By: Tessa Lau (tlau) Date: 2004-11-27 16:45 Message: Logged In: YES user_id=112896 My original bugreport had to do with email generation, not parsing. Python seems to be generating email that is not compliant with the RFC spec. In my situation, parsing is done by 3rd party programs (procmail and /bin/mail) which also fail to deal gracefully with the lack of trailing newline. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-11-27 16:03 Message: Logged In: YES user_id=12800 Changing the summary of this issue to reflect the real problem. The attachment 1072623.py illustrates that if the end boundary of a string being parsed by the FeedParser does not have a trailing newline, the parser doesn't recognize this as an end boundary. It just so happens that your example produces a message string with that property (which isn't a bug). The fix is about as trivial as you can get: one character. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072623&group_id=5470 From noreply at sourceforge.net Fri May 20 01:53:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 16:53:01 -0700 Subject: [ python-Bugs-745097 ] urllib2 doesn't handle urls without scheme Message-ID: Bugs item #745097, was opened at 2003-05-28 20:54 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745097&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: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 doesn't handle urls without scheme Initial Comment: urllib2.urlopen does not handle URLs without a scheme, so the following code will not work: url = urllib.pathname2url('/etc/passwd') urllib2.urlopen(url) The same code does work with urllib.urlopen. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2005-05-20 01:53 Message: Logged In: YES user_id=45365 I'm not convinced it isn't a bug. I agree that the URL '/etc/passwd' isn't always a file: url, but I think that in that case urllib2 should get its own pathname2url() method that returns urls with the file: prefix. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-05-19 22:24 Message: Logged In: YES user_id=261020 Could somebody close this? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-01 00:24 Message: Logged In: YES user_id=261020 Is it wise to allow this? Maybe it's unlikely to cause bugs, but "/etc/passwd" could refer to any URI scheme, not only file:. Since it seems reasonable to only allow absolute URLs, I think it's a bad idea to guess the scheme is file: when given a relative URL. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745097&group_id=5470 From noreply at sourceforge.net Fri May 20 04:45:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 19:45:52 -0700 Subject: [ python-Bugs-1082487 ] font lock keyword regular expressions Message-ID: Bugs item #1082487, was opened at 2004-12-09 15:43 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082487&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: Fixed Priority: 5 Submitted By: Robert Brown (robert-brown) Assigned to: Skip Montanaro (montanaro) Summary: font lock keyword regular expressions Initial Comment: I've noticed that when I use Python mode (alpha 1) with font lock mode, "self" is highlighted in the following line: his_self() The problem appears to be a combination of using "\b" in the Python font lock regular expressions and my .emacs file, which does: (modify-syntax-entry ?\_ "_" py-mode-syntax-table) I do not experience similar problems with highlighting in C mode, but there "\<" and "\>" are used in the font lock regular expressions. Using these word delimiters instead of "\b" appears to fix the problem for me in Python mode. Please wrap keywords with "\<" and "\>" instead of with "\b" in the font lock regular expression. Thanks very much. Bob ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-05-19 21:45 Message: Logged In: YES user_id=44345 python-mode.el 4.71. Raymond, sorry for taking so long with this. Please give it a try and let me know how it works. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 21:36 Message: Logged In: YES user_id=80475 Skip, can you field this one? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082487&group_id=5470 From noreply at sourceforge.net Fri May 20 05:08:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 20:08:01 -0700 Subject: [ python-Bugs-967182 ] file("foo", "wU") is silently accepted Message-ID: Bugs item #967182, was opened at 2004-06-05 12:15 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=967182&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: Python Interpreter Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: file("foo", "wU") is silently accepted Initial Comment: PEP 278 says at opening a file with "wU" is illegal, yet file("foo", "wU") passes without complaint. There may be other flags which the PEP disallows with "U" that need to be checked. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-05-19 22:08 Message: Logged In: YES user_id=44345 This has been idle for nearly a year with no further response. Looks good to me. ;-) Objects/fileobject.c 2.194 Lib/test/test_file.py 1.16 ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-06-11 00:44 Message: Logged In: YES user_id=44345 So this means I can't be explicit about what to accept, only about what to reject. Simpler patch attached... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-07 22:01 Message: Logged In: YES user_id=31435 The C standard is open-ended about what a mode string can contain, and Python has historically allowed users to exploit platform-specific extensions here. On Windows, at least 't' and 'c' mean something in mode strings, and 'c' is actually useful (it forces writes to get committed to disk immediately). Most platforms ignore characters in mode strings that they don't understand. This is an exhaustive list of the mode strings a conforming C implementation must support (from C99): """ r open text file for reading w truncate to zero length or create text file for writing a append; open or create text file for writing at end-of-file rb open binary file for reading wb truncate to zero length or create binary file for writing ab append; open or create binary file for writing at end-of-file r+ open text file for update (reading and writing) w+ truncate to zero length or create text file for update a+ append; open or create text file for update, writing at end- of-file r+b or rb+ open binary file for update (reading and writing) w+b or wb+ truncate to zero length or create binary file for update a+b or ab+ append; open or create binary file for update, writing at end-of-file """ Implementations are free to support as many more as they care to. Guido may be in favor of restricting Python (in 2.4 or 2.5) to the set of mode strings required by C99, plus those that make sense with Python's U extension. I think he said something to that effect in person once. But 'c' is in fact useful on Windows, and code will break if it's outlawed. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-06-07 21:10 Message: Logged In: YES user_id=44345 Turned out not to be obvious at all (and not related to my changes). Here's another patch which is cleaner I think. Would someone take a look at this? My intent is to not let invalid modes pass silently (as "wU" currently does). Have I accounted for all the valid mode strings? It has some semantic changes, so this is not a backport candidate. I'm not sure about how 't' is handled. It's only of use on Windows as I understand it, but I don't see it sucked out of the mode string on non-Windows platforms, so it must be silently accepted on Unix and Mac. (Can someone confirm this?) ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-06-05 14:51 Message: Logged In: YES user_id=44345 Here's a first cut patch - test suite fails though - must be something obvious... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=967182&group_id=5470 From noreply at sourceforge.net Fri May 20 05:26:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 20:26:46 -0700 Subject: [ python-Bugs-861340 ] UnboundLocalError in cgitb.py Message-ID: Bugs item #861340, was opened at 2003-12-16 17:09 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=861340&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: Python Library Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Skip Montanaro (montanaro) Summary: UnboundLocalError in cgitb.py Initial Comment: Here's the exception: Exception return cgitb.text((E, e, tb)).rstrip('\r\n') File "/usr/lib/python2.3/cgitb.py", line 197, in text vars = scanvars(reader, frame, locals) File "/usr/lib/python2.3/cgitb.py", line 76, in scanvars parent = value UnboundLocalError: local variable 'value' referenced before assignment And here's the code: if lasttoken == '.': if parent is not __UNDEF__: value = getattr(parent, token, __UNDEF__) vars.append((prefix + token, prefix, value)) else: where, value = lookup(token, frame, locals) vars.append((token, where, value)) elif token == '.': prefix += lasttoken + '.' parent = value If lasttoken is '.' and parent is __UNDEF__, value doesn't get set. I'd offer a patch, but I really have no idea what this code is doing and so don't know what to set value to. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-05-19 22:26 Message: Logged In: YES user_id=44345 Looks like this was fixed at some point. The local variable value is clearly initialized in scanvars() at this point. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-18 17:32 Message: Logged In: YES user_id=33168 Jeremy, that's still not enough to reproduce the bug. What exception was thrown by the code below and from where? What were the values of bugs, searchstr, and keywords? What are the definitions for utils.pluralize() and utils.commaAndify()? ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-12-18 17:02 Message: Logged In: YES user_id=99508 The code that caused the raised exception (which subsequently triggered the exception in cgitb) was this: outputstr = '%d %s match \'%s\' (%s):' % (len(bugs), \ utils.pluralize(len(bugs), 'bug'), searchstr, utils.commaAndify(keywords, And='AND')) That's actually from the diff where I changed it to be a bit more idiomatic :) It wasn't my code, I promise! ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-12-18 16:56 Message: Logged In: YES user_id=99508 To be honest, it's just something I ran into in my own test suite when my exception-handling logging code caught an exception I didn't expect to get raised. Since I have no idea what the code in cgitb that's raising the exception is actually doing, I really don't know how to begin to try and narrow it down to a test case. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-12-18 11:31 Message: Logged In: YES user_id=44345 I pulled scanvars() and lookup() out into a separate file and instrumented things a little. From staring at the code I thought that perhaps it didn't handle the case where the line starts with a dot separating an object and its attribute. I can't provoke a failure in that situation though. See attached lookup.py. Jeremy, can you fiddle it to make it fail? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-12-18 10:13 Message: Logged In: YES user_id=44345 Sorry, I have no idea what it does either. I'll look into it a bit, but don't expect a miracle. :-( ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-18 09:02 Message: Logged In: YES user_id=33168 Jeremy, can you attach a complete test case? Skip, I realize you didn't write the scanvars code (Ping did), but you did add text. So maybe you have an idea. >From a brief scan, it looks like if value is initialized to None, the code might work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=861340&group_id=5470 From noreply at sourceforge.net Fri May 20 07:54:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 22:54:26 -0700 Subject: [ python-Bugs-944407 ] No documentation for urllib2 exception classes Message-ID: Bugs item #944407, was opened at 2004-04-29 11:38 Message generated for change (Settings changed) made by fresh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944407&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: 5 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: No documentation for urllib2 exception classes Initial Comment: There's not even reference documentation for the exceptions used by urllib2. Documentation of what these are, how you're supposed to handle them and what attributes you're supposed to play with would be very handy. I guess I'll just have to try and glean something from the source :-S ---------------------------------------------------------------------- >Comment By: Chris Withers (fresh) Date: 2005-05-20 05:54 Message: Logged In: YES user_id=24723 True enough, I guess that some time in the last year this got updated ;-) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-05-19 20:12 Message: Logged In: YES user_id=261020 This is not correct, these exceptions are documented. (from http://docs.python.org/lib/module-urllib2.html) The following exceptions are raised as appropriate: exception URLError The handlers raise this exception (or derived exceptions) when they run into a problem. It is a subclass of IOError. exception HTTPError A subclass of URLError, it can also function as a non-exceptional file-like return value (the same thing that urlopen() returns). This is useful when handling exotic HTTP errors, such as requests for authentication. exception GopherError A subclass of URLError, this is the error raised by the Gopher handler. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944407&group_id=5470 From noreply at sourceforge.net Fri May 20 12:26:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 May 2005 03:26:28 -0700 Subject: [ python-Bugs-1205544 ] urllib has spurious print statement Message-ID: Bugs item #1205544, was opened at 2005-05-20 10:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205544&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Wray (drcw) Assigned to: Nobody/Anonymous (nobody) Summary: urllib has spurious print statement Initial Comment: In Python 2.4.1, the procedure getproxies_environment() in urllib.py has a spurious print statement on line 1188: print proxies This was presumably used for testing, but not commented out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205544&group_id=5470 From noreply at sourceforge.net Fri May 20 13:05:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 May 2005 04:05:22 -0700 Subject: [ python-Bugs-1205568 ] Compile fails on Darwin8 with --with-cxx=g++ Message-ID: Bugs item #1205568, was opened at 2005-05-20 07:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205568&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: Robert M. Zigweid (rzigweid) Assigned to: Nobody/Anonymous (nobody) Summary: Compile fails on Darwin8 with --with-cxx=g++ Initial Comment: As has been previously reported and fixed in some portions of the build process, building on Darwin 8 with gcc-4.0 requires some extra libraries to be passed. When --with-cxx=g++ is specified to configure, and possibly for other flags that make the build process be conscious of C++. Tail of error: gcc -u _PyMac_Error -o python.exe Modules/ccpython.o libpython2.4.a -ldl /usr/bin/ld: Undefined symbols: ___gxx_personality_v0 collect2: ld returned 1 exit status make: *** [python.exe] Error 1 Fix: Add -lSystem and -lSystemStubs for Darwin 8 to the linker where appropriate. I haven't identified all these spots though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205568&group_id=5470 From noreply at sourceforge.net Fri May 20 17:21:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 May 2005 08:21:34 -0700 Subject: [ python-Bugs-1205736 ] wrong location for math lib with --prefix Message-ID: Bugs item #1205736, was opened at 2005-05-20 17:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205736&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: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Richter (thorfdbg) Assigned to: Nobody/Anonymous (nobody) Summary: wrong location for math lib with --prefix Initial Comment: If python2.3 or 2.4 get configured with --prefix, the math libraries (and other binary libraries) are check for in the wrong location. Specifically, the prefix will be will be used twice, giving the wrong path for the binary object. How to reproduce: Configure python with ./configure --prefix=/foo ;or whatever, make make install This will place libraries etc. correctly in /foo/lib/python2.4. Afterwards, setup pythonpath accordingly export PYTHONPATH="/foo/lib/python2.4:/foo/lib/python2.4/site-packages" If you start then python, try >> import math The result will be that pyhon will not find the math module. Debugging with strace reveals that python checks for binary libraries now in /foo/lib/python2.4/lib/python2.4 instead of /foo/lib/python2.4 Setting a softlink in the lib directory works around this and brings python back to working. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205736&group_id=5470 From noreply at sourceforge.net Fri May 20 23:13:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 May 2005 14:13:18 -0700 Subject: [ python-Bugs-1205568 ] Compile fails on Darwin8 with --with-cxx=g++ Message-ID: Bugs item #1205568, was opened at 2005-05-20 13:05 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205568&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: Robert M. Zigweid (rzigweid) Assigned to: Nobody/Anonymous (nobody) Summary: Compile fails on Darwin8 with --with-cxx=g++ Initial Comment: As has been previously reported and fixed in some portions of the build process, building on Darwin 8 with gcc-4.0 requires some extra libraries to be passed. When --with-cxx=g++ is specified to configure, and possibly for other flags that make the build process be conscious of C++. Tail of error: gcc -u _PyMac_Error -o python.exe Modules/ccpython.o libpython2.4.a -ldl /usr/bin/ld: Undefined symbols: ___gxx_personality_v0 collect2: ld returned 1 exit status make: *** [python.exe] Error 1 Fix: Add -lSystem and -lSystemStubs for Darwin 8 to the linker where appropriate. I haven't identified all these spots though. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-05-20 23:13 Message: Logged In: YES user_id=21627 Can you check whether just linking with g++ (instead of linking with gcc, and still not adding -lSystem) also solves the problem? configure is supposed to detect that g++ is needed for linking; if linking with g++ solves the problem, then configure.in must be enhanced to properly auto-detect this case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205568&group_id=5470 From noreply at sourceforge.net Fri May 20 23:22:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 May 2005 14:22:30 -0700 Subject: [ python-Bugs-1202533 ] a bunch of infinite C recursions Message-ID: Bugs item #1202533, was opened at 2005-05-16 01:43 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-05-20 23:22 Message: Logged In: YES user_id=21627 Wouldn't adding Py_EnterRecursiveCall into many places solve the problem? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-19 17:05 Message: Logged In: YES user_id=4771 This is not about the new module. The same example can be written as: import types class A: pass A.__mul__ = types.MethodType(operator.mul, None, A) If this still looks essentially like an indirect way of using the new module, here is another example: class A(str): __get__ = getattr a = A('a') A.a = a a.a Or, as I just found out, new-style classes are again vulnerable to the older example based __call__, which was fixed for old-style classes: class A(object): pass A.__call__ = A() A()() I'm not denying that these examples look convoluted :-) My point here is that we can basically build a lot of examples based only on core (if not necessarily widely understood) language features. It appears to go against the basic hope that CPython cannot be crashed as long as you don't use features explicitely marked as dangerous. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-19 04:02 Message: Logged In: YES user_id=593130 On Windows, this caused the interactive window to just disappear.so I suspect something similar occurred. New is a known dangerous, use at your own risk, implementation specific module whose use, like byte code hacking, is outside the language proper. Both bypass normal object creation syntax and its checks and both can create invalid objects. A hold-your- hand inplementation would not give such access to internals. Lib Ref 3.28 says "This module provides a low-level interface to the interpreter, so care must be exercised when using this module. It is possible to supply non-sensical arguments which crash the interpreter when the object is used." Should more or different be said? If not, I suspect this should be closed as 'won't fix', as in 'won't remove the inherently dangerous new module'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 From noreply at sourceforge.net Fri May 20 23:23:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 May 2005 14:23:37 -0700 Subject: [ python-Bugs-1200287 ] Windows msi installer fails on virtual drives Message-ID: Bugs item #1200287, was opened at 2005-05-12 02:55 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200287&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: Installation >Group: 3rd Party >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: bartgrantham (bartgrantham) Assigned to: Nobody/Anonymous (nobody) Summary: Windows msi installer fails on virtual drives Initial Comment: The MSI installer for 2.4.1 failed to install from a virtual drive under windows (ie. a drive created with subst). It would error out without an error code, immediately after package selection and before "thinking...". Not sure if this also applies to network mapped drives. Moving installer to genuine C: drive and running from there fixed the problem. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-05-20 23:23 Message: Logged In: YES user_id=21627 It is not a bug in Python, but an MSI limitation; closing as third-party. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-19 03:03 Message: Logged In: YES user_id=593130 This is almost certainly not a Python bug. See http://python.org/sf/1199947 Please close unless you see a particular bug with Python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200287&group_id=5470 From noreply at sourceforge.net Fri May 20 23:25:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 May 2005 14:25:55 -0700 Subject: [ python-Bugs-1199947 ] Python 2.4.1 Installer ended prematurely Message-ID: Bugs item #1199947, was opened at 2005-05-11 18:01 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199947&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: Installation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Wai Yip Tung (tungwaiyip) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.1 Installer ended prematurely Initial Comment: Similar symptom to bug 105470 http://sourceforge.net/tracker/index.php? func=detail&aid=1085208&group_id=5470&atid=105470 Running python-2.4.1.msi with all default setting. It ends quickly with a dialogbox titled "Python 2.4.1 Installer ended prematurely". Same problem running the 2.4 msi. Machine information: Windows XP Professional V2002 SP2 Dell Latitude D600 640MB RAM Symantec Antivirus 9.0.1.1000 (disable it does not help) cscript.exe version 5.6.0.8825 (upgraded from 8820?) The workaround mentioned in 105470 does not help. Running x.vbs gives me 0. Doing regsvr32 c:\windows\system32\scrrun.dll makes no difference. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-05-20 23:25 Message: Logged In: YES user_id=21627 Closing the problem as fixed. ---------------------------------------------------------------------- Comment By: Wai Yip Tung (tungwaiyip) Date: 2005-05-16 22:32 Message: Logged In: YES user_id=561546 Problem solved: I copied the msi file to the root directory (e.g. c:\) and launch from there. it works prefectly. I found that not only Python installer gave me problem, any msi installer gave me problem on this machine. Then I found the clue from Ultramon's FAQ: http://www.realtimesoft.com/ultramon/support.asp#2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199947&group_id=5470 From noreply at sourceforge.net Fri May 20 23:35:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 May 2005 14:35:52 -0700 Subject: [ python-Bugs-1199808 ] installation problem with python 2.4.1 on Win2k system Message-ID: Bugs item #1199808, was opened at 2005-05-11 14:50 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199808&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: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: mmkobayashi (mmkobayashi) Assigned to: Nobody/Anonymous (nobody) Summary: installation problem with python 2.4.1 on Win2k system Initial Comment: After several attempts to install python2.4.1 on a win2k systems with doing all windows updates, we have been unable to install python2.4.1 on this system. We have attached an error logfile. The main thing that happens is that the install proceeds as normal but at some point the install decides that something has gone wrong and uninstalls itself. Any help in this matter would be greatly appreciated. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-05-20 23:35 Message: Logged In: YES user_id=21627 The log file appears to be manually truncated. Can you please provide the full log file? Are you by any chance running the MSI file from a SUBSTed drive? ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-19 03:01 Message: Logged In: YES user_id=593130 You might also check out http://python.org/sf/1199947 ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-19 02:48 Message: Logged In: YES user_id=593130 Help questions should better be directed to comp.lang.python == python mailing list == gmane.comp.python.general. The answers you get should help determine whether there is a bug in the install file distributed by PSF that should be reported here. Given that the install appeared to go ok until it tried to remove the existing files, I wonder whether there is a process running in the background that is using the existing install. That issue has been discussed on the python group recently. ---------------------------------------------------------------------- Comment By: mmkobayashi (mmkobayashi) Date: 2005-05-12 07:53 Message: Logged In: YES user_id=1273313 add file ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199808&group_id=5470 From noreply at sourceforge.net Fri May 20 23:41:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 May 2005 14:41:25 -0700 Subject: [ python-Feature Requests-1200804 ] enhancing os.chown functionality Message-ID: Feature Requests item #1200804, was opened at 2005-05-12 18:26 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1200804&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: Extension Modules Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: gyrof (gyrof) Assigned to: Nobody/Anonymous (nobody) Summary: enhancing os.chown functionality Initial Comment: Hi, I don't think it is currently possible (with os.chown or any other Python library function) to change the groupId of a file without specifying the userId (like posix 'chgrp' does), or to change the userId without specifying the groupId. I would suggest adding the option of having os.chown accept None as either the userId or groupId, and having the function change only the 'non-None' portion of the file ownership. Thanks for your consideration. -g ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-05-20 23:41 Message: Logged In: YES user_id=21627 Jeff already provided the right analysis: It *is* currently possibly with os.chown to only change the groupid without specifying the userid: just pass -1 as the userid. The requested feature is already there, so I'm rejecting this request. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-05-19 00:49 Message: Logged In: YES user_id=2772 the posix (os) module is intended as a thin wrapper around operating system services. The chown(2) syscall requires that owner and group both be specified. Possibly an enhanced chownonly/chgrp would find a home in the 'shutil' module. Possibly translating a parameter of None into -1 (which means 'no change') would be accepted as a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1200804&group_id=5470 From noreply at sourceforge.net Fri May 20 23:44:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 May 2005 14:44:02 -0700 Subject: [ python-Bugs-1157901 ] xml.dom.minidom.Node.removeChild() doesn't remove Message-ID: Bugs item #1157901, was opened at 2005-03-06 22:17 Message generated for change (Comment added) made by mkempka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157901&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Matthias Kempka (mkempka) Assigned to: Nobody/Anonymous (nobody) Summary: xml.dom.minidom.Node.removeChild() doesn't remove Initial Comment: There seems to be a constellation where xml.dom.minidom.Node.removeChild() doesn't remove childs properly. I found this bug in 2.3.4 and it is still in: Python 2.3.5 (#2, Feb 9 2005, 00:38:15) [GCC 3.3.5 (Debian 1:3.3.5-8)] on linux2 I attached 3 files, the dombug.py demonstrates the problem: First, I iterate over all children of a specific element, check their tag name and remove them using removeChild() and then child.unlink(). After the elements are removed I iterate again, do the same check for a tag and find there are still elements in there. That is, there are still elements in there when I parse the file errorintroducer.xml. When I parse the file errorfree.xml the elements are all removed. The difference between the xml files is the carriage return after each closing tag. Since to my knowledge both xml files are well-formed I would expect in both cases that all elements are removed. ---------------------------------------------------------------------- >Comment By: Matthias Kempka (mkempka) Date: 2005-05-20 23:44 Message: Logged In: YES user_id=736381 well then, invalid. ---------------------------------------------------------------------- Comment By: Andrew Clover (bobince) Date: 2005-03-11 09:25 Message: Logged In: YES user_id=311085 Bug should be marked INVALID. childNodes lists are 'live'. You are iterating over a list you are destroying at the same time. The code is equivalent to the more obviously broken: foo= [1, 2, 3, 4] i= 0 while i>> [2, 4] The 'working' example only works because it has extra whitespace nodes in, so when you delete child number i, the child i+1 that is skipped over is a Text node containing only whitespace. BTW, there's a separate bug tracker for the PyXML project from which minidom is taken. You may get better results by submitting there (and discussing on the XML-SIG list). ---------------------------------------------------------------------- Comment By: Matthias Kempka (mkempka) Date: 2005-03-06 22:24 Message: Logged In: YES user_id=736381 so.. this form posts the error report with uploading files...interesting... Anyway, the output I get when running the program with errorintroducer.xml is: > python dombug.py found element 1 .. removed found element 3 .. removed found element 5 .. removed -----------everything removed from timerList[0]--------------- found Element 2 found Element 4 found Element 6 imho it should be, as it is with errorfree.xml: found element 1 .. removed found element 2 .. removed found element 3 .. removed found element 4 .. removed found element 5 .. removed found element 6 .. removed -----------everything removed from timerList[0]--------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157901&group_id=5470 From noreply at sourceforge.net Fri May 20 23:46:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 May 2005 14:46:44 -0700 Subject: [ python-Bugs-1202533 ] a bunch of infinite C recursions Message-ID: Bugs item #1202533, was opened at 2005-05-15 23:43 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-05-20 21:46 Message: Logged In: YES user_id=4771 Yes, but I'm concerned that we would need to add it really really many places, and probably forget some even then. E.g. I just thought about: lst = [apply] lst.append(lst) apply(*lst) It seems a bit hopeless, honestly... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-20 21:22 Message: Logged In: YES user_id=21627 Wouldn't adding Py_EnterRecursiveCall into many places solve the problem? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-19 15:05 Message: Logged In: YES user_id=4771 This is not about the new module. The same example can be written as: import types class A: pass A.__mul__ = types.MethodType(operator.mul, None, A) If this still looks essentially like an indirect way of using the new module, here is another example: class A(str): __get__ = getattr a = A('a') A.a = a a.a Or, as I just found out, new-style classes are again vulnerable to the older example based __call__, which was fixed for old-style classes: class A(object): pass A.__call__ = A() A()() I'm not denying that these examples look convoluted :-) My point here is that we can basically build a lot of examples based only on core (if not necessarily widely understood) language features. It appears to go against the basic hope that CPython cannot be crashed as long as you don't use features explicitely marked as dangerous. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-19 02:02 Message: Logged In: YES user_id=593130 On Windows, this caused the interactive window to just disappear.so I suspect something similar occurred. New is a known dangerous, use at your own risk, implementation specific module whose use, like byte code hacking, is outside the language proper. Both bypass normal object creation syntax and its checks and both can create invalid objects. A hold-your- hand inplementation would not give such access to internals. Lib Ref 3.28 says "This module provides a low-level interface to the interpreter, so care must be exercised when using this module. It is possible to supply non-sensical arguments which crash the interpreter when the object is used." Should more or different be said? If not, I suspect this should be closed as 'won't fix', as in 'won't remove the inherently dangerous new module'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 From noreply at sourceforge.net Fri May 20 23:48:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 May 2005 14:48:03 -0700 Subject: [ python-Feature Requests-1184678 ] "replace" function should accept lists. Message-ID: Feature Requests item #1184678, was opened at 2005-04-17 18:05 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1184678&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: Rejected Priority: 5 Submitted By: Poromenos (poromenos) Assigned to: Nobody/Anonymous (nobody) Summary: "replace" function should accept lists. Initial Comment: It would be nice if the "replace" function accepted lists/ tuples and replaced each item in the "old" list with the corresponding item in the "new" list. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-05-20 23:48 Message: Logged In: YES user_id=21627 I'm rejecting this request, noticing that even the *specification* of the requested feature is tricky: Would "foobarfoo".replace([("foo","baz"), ("barf", "")] produce "bazbarbaz" or "bazfoo" IOW, would it first replace all occurrences of the first pair, then all occurrences of the second pair, or would it iterate over the list, replacing everything it can replace, and then start all over until nothing needs to be done? In the face of doubt, refuse the temptation to guess. ---------------------------------------------------------------------- Comment By: Poromenos (poromenos) Date: 2005-05-01 11:55 Message: Logged In: YES user_id=267121 Ah, okay. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-30 14:30 Message: Logged In: YES user_id=80475 Sorry, am not going to gum up the API for this. It doesn't come up much and when it does it is an easy problem. Each additional option on a function makes it harder to learn, use, and remember. Likewise, it complicates maintenance. Also, this one has its own complexities that make it worth avoiding (examples can be contrived when the for-loop version produces a different result than replacing each match as found). A good implementation would take time. It would involve regexps and have to be done for unicode objects. ---------------------------------------------------------------------- Comment By: Poromenos (poromenos) Date: 2005-04-30 11:48 Message: Logged In: YES user_id=267121 That is true, the alternative loop is quite usable, but the API change would be backwards-compatible, and the implementation is not very difficult... I just see this as a nice feature of replace, it's not really necessary if it'll break other stuff. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-29 16:10 Message: Logged In: YES user_id=80475 Given the multiple alternative input matches, this is a job for regular expressions. See the string.substitute() source code for an approach to making the transformation you outlined. I do not think multi-replace is sufficiently common to warrant a change to the API. If needed and if the regexp solution is too hard, then a regular for-loop is a reasonable alternative: for old, new in zip(oldlist, newlist): s = s.replace(old, new) ---------------------------------------------------------------------- Comment By: Poromenos (poromenos) Date: 2005-04-29 15:03 Message: Logged In: YES user_id=267121 There was an oversight on my part... Translate can only be used to change individual characters, what I am proposing could replace strings of multiple characters, essentially concatenating multiple replace()s in one: >>> "h.w".replace(["h", ".", "w"], ["Hello", " ", "World!"]) 'Hello, World!' ---------------------------------------------------------------------- Comment By: Poromenos (poromenos) Date: 2005-04-19 00:23 Message: Logged In: YES user_id=267121 Ah, I did not know that... The docs are a bit complicated on . translate, but since it can do that, yes, it would be unwise to implement my suggestion. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-19 00:20 Message: Logged In: YES user_id=80475 I'm -1 on complicating str.replace()'s API for functionality that substantially duplicates that offered by str.translate(): >>> "Hello world".translate(string.maketrans('ed', 'ae')) 'Hallo worle' ---------------------------------------------------------------------- Comment By: Poromenos (poromenos) Date: 2005-04-18 23:15 Message: Logged In: YES user_id=267121 Hmm, actually I was requesting that string.replace() accepted lists of substitutions, like so: >>> "Hello world".replace(["e", "d"], ["a", "e"]) 'Hallo worle' But your suggestion would also be very useful. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-18 23:11 Message: Logged In: YES user_id=80475 Are you requesting that lists be given a replace() method that parallels the replace() method for strings? def replace(self, old, new): result = [] for elem in self: if elem == old: result.append(new) else: result.append(elem) self[:] = result ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1184678&group_id=5470 From noreply at sourceforge.net Fri May 20 23:52:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 May 2005 14:52:20 -0700 Subject: [ python-Feature Requests-1184678 ] "replace" function should accept lists. Message-ID: Feature Requests item #1184678, was opened at 2005-04-17 19:05 Message generated for change (Comment added) made by poromenos You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1184678&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: Rejected Priority: 5 Submitted By: Poromenos (poromenos) Assigned to: Nobody/Anonymous (nobody) Summary: "replace" function should accept lists. Initial Comment: It would be nice if the "replace" function accepted lists/ tuples and replaced each item in the "old" list with the corresponding item in the "new" list. ---------------------------------------------------------------------- >Comment By: Poromenos (poromenos) Date: 2005-05-21 00:52 Message: Logged In: YES user_id=267121 Actually it would accept two lists, and replace item n in the first list with item n in the second list, in that order (so that you can condense multiple replace lines into one), but this feature is not that important anyway. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-21 00:48 Message: Logged In: YES user_id=21627 I'm rejecting this request, noticing that even the *specification* of the requested feature is tricky: Would "foobarfoo".replace([("foo","baz"), ("barf", "")] produce "bazbarbaz" or "bazfoo" IOW, would it first replace all occurrences of the first pair, then all occurrences of the second pair, or would it iterate over the list, replacing everything it can replace, and then start all over until nothing needs to be done? In the face of doubt, refuse the temptation to guess. ---------------------------------------------------------------------- Comment By: Poromenos (poromenos) Date: 2005-05-01 12:55 Message: Logged In: YES user_id=267121 Ah, okay. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-30 15:30 Message: Logged In: YES user_id=80475 Sorry, am not going to gum up the API for this. It doesn't come up much and when it does it is an easy problem. Each additional option on a function makes it harder to learn, use, and remember. Likewise, it complicates maintenance. Also, this one has its own complexities that make it worth avoiding (examples can be contrived when the for-loop version produces a different result than replacing each match as found). A good implementation would take time. It would involve regexps and have to be done for unicode objects. ---------------------------------------------------------------------- Comment By: Poromenos (poromenos) Date: 2005-04-30 12:48 Message: Logged In: YES user_id=267121 That is true, the alternative loop is quite usable, but the API change would be backwards-compatible, and the implementation is not very difficult... I just see this as a nice feature of replace, it's not really necessary if it'll break other stuff. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-29 17:10 Message: Logged In: YES user_id=80475 Given the multiple alternative input matches, this is a job for regular expressions. See the string.substitute() source code for an approach to making the transformation you outlined. I do not think multi-replace is sufficiently common to warrant a change to the API. If needed and if the regexp solution is too hard, then a regular for-loop is a reasonable alternative: for old, new in zip(oldlist, newlist): s = s.replace(old, new) ---------------------------------------------------------------------- Comment By: Poromenos (poromenos) Date: 2005-04-29 16:03 Message: Logged In: YES user_id=267121 There was an oversight on my part... Translate can only be used to change individual characters, what I am proposing could replace strings of multiple characters, essentially concatenating multiple replace()s in one: >>> "h.w".replace(["h", ".", "w"], ["Hello", " ", "World!"]) 'Hello, World!' ---------------------------------------------------------------------- Comment By: Poromenos (poromenos) Date: 2005-04-19 01:23 Message: Logged In: YES user_id=267121 Ah, I did not know that... The docs are a bit complicated on . translate, but since it can do that, yes, it would be unwise to implement my suggestion. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-19 01:20 Message: Logged In: YES user_id=80475 I'm -1 on complicating str.replace()'s API for functionality that substantially duplicates that offered by str.translate(): >>> "Hello world".translate(string.maketrans('ed', 'ae')) 'Hallo worle' ---------------------------------------------------------------------- Comment By: Poromenos (poromenos) Date: 2005-04-19 00:15 Message: Logged In: YES user_id=267121 Hmm, actually I was requesting that string.replace() accepted lists of substitutions, like so: >>> "Hello world".replace(["e", "d"], ["a", "e"]) 'Hallo worle' But your suggestion would also be very useful. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-19 00:11 Message: Logged In: YES user_id=80475 Are you requesting that lists be given a replace() method that parallels the replace() method for strings? def replace(self, old, new): result = [] for elem in self: if elem == old: result.append(new) else: result.append(elem) self[:] = result ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1184678&group_id=5470 From noreply at sourceforge.net Sat May 21 19:46:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 21 May 2005 10:46:12 -0700 Subject: [ python-Bugs-1206232 ] IDLE 1.0.5 (Python 2.3.5) crashes under Windows Message-ID: Bugs item #1206232, was opened at 2005-05-21 19:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1206232&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Torsten Bronger (bronger) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE 1.0.5 (Python 2.3.5) crashes under Windows Initial Comment: Using Win2k or XP, IDLE 1.0.5 and Python 2.3.5, the attached source produces a fatal error and IDLE and the Python Shell are closed. In order to reproduce the issue, start IDLE, open the attached file and press "F5". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1206232&group_id=5470 From noreply at sourceforge.net Sun May 22 14:25:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 May 2005 05:25:18 -0700 Subject: [ python-Bugs-745097 ] urllib2 doesn't handle urls without scheme Message-ID: Bugs item #745097, was opened at 2003-05-28 19:54 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745097&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: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 doesn't handle urls without scheme Initial Comment: urllib2.urlopen does not handle URLs without a scheme, so the following code will not work: url = urllib.pathname2url('/etc/passwd') urllib2.urlopen(url) The same code does work with urllib.urlopen. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-05-22 13:25 Message: Logged In: YES user_id=261020 That sounds like a feature request to me, not a bug. I agree it's desirable to have a better pathname2url (I haven't submitted one partly because I'm scared of getting it wrong!). I disagree that it should be a method, since OpenerDirector has no knowledge of base URL (and urllib2.Request or the response class also seem like the wrong places for that method: the URLs they have aren't always the URL you want to use as the base URL). It would be nice to have a couple of functions urlparse.urlfrompathname(pathname) and urlparse.absurlfrompathname(pathname, baseurl) (better names / places for those, anyone?). Or you could resubmit this as a bug in urllib for allowing relative URLs without knowing the base URL ;-) ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2005-05-20 00:53 Message: Logged In: YES user_id=45365 I'm not convinced it isn't a bug. I agree that the URL '/etc/passwd' isn't always a file: url, but I think that in that case urllib2 should get its own pathname2url() method that returns urls with the file: prefix. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-05-19 21:24 Message: Logged In: YES user_id=261020 Could somebody close this? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-11-30 23:24 Message: Logged In: YES user_id=261020 Is it wise to allow this? Maybe it's unlikely to cause bugs, but "/etc/passwd" could refer to any URI scheme, not only file:. Since it seems reasonable to only allow absolute URLs, I think it's a bad idea to guess the scheme is file: when given a relative URL. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745097&group_id=5470 From noreply at sourceforge.net Sun May 22 16:37:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 May 2005 07:37:10 -0700 Subject: [ python-Bugs-1206537 ] weakref cannot handle bound methods (in contrast to docu) Message-ID: Bugs item #1206537, was opened at 2005-05-22 14:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1206537&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: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raik Gruenberg (graik) Assigned to: Nobody/Anonymous (nobody) Summary: weakref cannot handle bound methods (in contrast to docu) Initial Comment: According to the documentation of the weakref module, weakreferences can be applied to "...class instances, functions written in Python (but not in C), methods (both bound and unbound)..." In reality, bound methods cannot be referenced (see bug 813299): import weakref ## this works: def testF( event ): pass r = weakref.ref( testF ) ## this doesnt: class EventListener: def handleEventA( self, event ): pass t = EventListener() ## gives a "dead" ref r = weakref.ref( t.handleEventA ) This behaviour is unexpected for anyone not aquainted to the inner clockwork of python and unfortunate because it, for example, prevents to keep weak references to callback methods in event handling patterns. A workaround is proposed at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/81253 Discussion: (minimal) Solution 1: Change the weakref documentation (preferred) Solution 2: Adapt weakref to allow references to bound methods Perhaps this bug should be converted into a documentation bug and a feature request. Python version 2.3 and 2.4 OS: Linux 2.6 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1206537&group_id=5470 From noreply at sourceforge.net Sun May 22 20:39:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 May 2005 11:39:27 -0700 Subject: [ python-Bugs-1070735 ] urllib2 authentication redirection error(?) Message-ID: Bugs item #1070735, was opened at 2004-11-21 18:01 Message generated for change (Comment added) made by allanbwilson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1070735&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: Python Library Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Allan B. Wilson (allanbwilson) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 authentication redirection error(?) Initial Comment: I am trying to use urllib2 to retrieve a page from a site requiring authentication. I supply the authentication parameters, which succeed, and *a* page is returned -- but not the page I originally requested. As it turns out, the authentication is handled at a completely different URL (actually a different domain); I can confirm this by not supplying authentication data, because I see a 302 earlier in the traceback when authentication fails. What I think is happening is that the redirect happens to the authentication site, but the original URL that I wanted has been forgotten. The page I get back is the default page for the original (now authenticated) site, not the page itself, which is deeper down in the site hierarchy. Sorry, I can't supply a patch! Thanks ---------------------------------------------------------------------- >Comment By: Allan B. Wilson (allanbwilson) Date: 2005-05-22 11:39 Message: Logged In: YES user_id=725330 Yes, that makes sense. Unfortunately the site is a financial site so I won't be able to supply a demo script. Let's do close it out on that basis. Thanks ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-05-19 12:48 Message: Logged In: YES user_id=261020 Allan, unfortunately there's no way of investigating this without a running script that demonstrates the problem. Please supply one, or close the bug. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1070735&group_id=5470 From noreply at sourceforge.net Mon May 23 03:32:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 May 2005 18:32:04 -0700 Subject: [ python-Bugs-944890 ] csv writer bug on windows Message-ID: Bugs item #944890, was opened at 2004-04-29 16:06 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944890&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: Fixed Priority: 5 Submitted By: Brian Kelley (wc2so1) Assigned to: Skip Montanaro (montanaro) Summary: csv writer bug on windows Initial Comment: The excel dialect is set up to be class excel(Dialect): delimiter = ',' quotechar = '"' doublequote = True skipinitialspace = False lineterminator = '\r\n' quoting = QUOTE_MINIMAL register_dialect("excel", excel) However, on the windows platform, the lineterminator should be simply "\n" My suggested fix is: class excel(Dialect): delimiter = ',' quotechar = '"' doublequote = True skipinitialspace = False if sys.platform == "win32": lineterminator = '\n' else: lineterminator = '\r\n' quoting = QUOTE_MINIMAL Which seems to work. It could be that I'm missing something, but the universal readlines doesn't appear to work for writing files. If this is a usage issue, it probably should be a documentation fix. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-05-22 20:32 Message: Logged In: YES user_id=44345 This should have been closed long ago. The documentation states that files need to be opened in binary mode. ---------------------------------------------------------------------- Comment By: Brian Kelley (wc2so1) Date: 2004-06-05 15:22 Message: Logged In: YES user_id=424987 The example in the documentation fails... import csv writer = csv.writer(file("some.csv", "w")) for row in someiterable: writer.writerow(row) As I suspected, the fix is a documentation issue. I will make a documentation patch next week. It will be my first one :) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-05 11:14 Message: Logged In: YES user_id=31435 Excel on Windows puts \r\n line ends in .csv files it creates (I just tried it). Since the OP mentioned "universal readlines", I bet he's opening the file with "U" (but it needs to be "rb"). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-06-05 11:04 Message: Logged In: YES user_id=44345 Can you attach an example that fails? I don't have access to Windows. Note that you must open the file with binary mode ("wb" or "rb"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944890&group_id=5470 From noreply at sourceforge.net Mon May 23 03:35:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 May 2005 18:35:48 -0700 Subject: [ python-Bugs-813198 ] Migrate PEP material to docs Message-ID: Bugs item #813198, was opened at 2003-09-26 12:58 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813198&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: David Abrahams (david_abrahams) >Assigned to: Nobody/Anonymous (nobody) Summary: Migrate PEP material to docs Initial Comment: Much of the basic information is still missing. MRO, descriptors, most of PEPs 252 and 253 are ones I can think of off the top of my head, but I'm certain there's more. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-05-22 20:35 Message: Logged In: YES user_id=44345 I'm passing this back for someone to take who's better versed in PEPs 252 and 253. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813198&group_id=5470 From noreply at sourceforge.net Mon May 23 03:38:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 May 2005 18:38:02 -0700 Subject: [ python-Bugs-731501 ] Importing anydbm generates exception if _bsddb unavailable Message-ID: Bugs item #731501, was opened at 2003-05-02 12:56 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731501&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: Python Library Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Nick Vargish (vargish) Assigned to: Skip Montanaro (montanaro) Summary: Importing anydbm generates exception if _bsddb unavailable Initial Comment: The anydbm module attempts to import the dbhash module, which fails if there is no BSD DB module available. Relevant portion of backtrace: File "/diska/netsite-docs/cgi-bin/waisdb2.py", line 124, in _getsystemsdbm dbsrc = anydbm.open(self.dbfile) File "/usr/local/python-2.3b1/lib/python2.3/anydbm.py", line 82, in open mod = __import__(result) File "/usr/local/python-2.3b1/lib/python2.3/dbhash.py", line 5, in ? import bsddb File "/usr/local/python-2.3b1/lib/python2.3/bsddb/__init__.py", line 40, in ? import _bsddb ImportError: No module named _bsddb Tests that explicitly use "import dbm" rather than anydbm are successful on this system. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-05-22 20:38 Message: Logged In: YES user_id=44345 ancient history i just never closed ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-06-24 01:09 Message: Logged In: YES user_id=3066 The doc changes look mostly fine to me (and I've changed what didn't; a small cosmetic nit). I'm just amazed we're still spending time tweaking BSD DB; I don't think that's ever "just worked" for me without digging around for a version of the underlying library that worked with Python. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-05-06 15:54 Message: Logged In: YES user_id=44345 Assigned to Fred for doc review - I added a couple notes to libbsddb.tex and libundoc.tex in lieu of actually creating a separate bsddb185 section which I felt would have given people the mistaken idea that the module is available for general use. Still, I thought there should be some mention in the docs. Library detection probably needs a little tweakage as well. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-05 16:55 Message: Logged In: YES user_id=21627 Actually, you probably need to check whether /usr/lib/libdb.* is present, and link with that as well if it is. If you are uncertain whether this is the right library, I see no way except to run a test program, at configure time, that creates a database and determines whether this really is a DB 1.85 database. Alternatively, the test program might try to invoke db_version. If the function is available, it is DB x, x>=2 (DB1 apparently has no version indication function). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-05 15:34 Message: Logged In: YES user_id=21627 I can't actually test the patch, but it looks good to me. Please apply! ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-05-05 09:27 Message: Logged In: YES user_id=44345 I believe the attached patch does what's necessary to get this to work again. It does a few things: * setup.py builds the bsddb185 under the right (restrictive) circumstances. /usr/include/db.h must exist and HASHVERSION must be 2. In this case the bsddb185 module will be built without any extra includes, libraries or #defines, forcing whatever is present in /usr/include/db.h and libc to be used to build the module. * whichdb.py detects the older hash file format and returns "bsddb185". * bsddbmodule.c grows an extra undocumented attribute, "open". The last two changes avoid having to change dbhash.py in complicated ways to distinguish between new and old file versions. The format- detecting mess remains isolated to whichdb.py. Using this setup I was successfully able to open /etc/pwd.db on my system using anydbm.open(), which I was unable to do previously. I can also still open a more recent hash file created with anydbm.open. Finally, new files created with anydbm.open are in the later format. Please give it a try. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-03 04:02 Message: Logged In: YES user_id=21627 I think this is not a bug. open() has determined that this is a bsddb file, but bsddb is not supported on the system. Or did you mean to suggest that opening the very same file with dbm would be successful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731501&group_id=5470 From noreply at sourceforge.net Mon May 23 03:41:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 May 2005 18:41:50 -0700 Subject: [ python-Bugs-1082487 ] font lock keyword regular expressions Message-ID: Bugs item #1082487, was opened at 2004-12-09 15:43 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082487&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: Fixed Priority: 5 Submitted By: Robert Brown (robert-brown) >Assigned to: Raymond Hettinger (rhettinger) Summary: font lock keyword regular expressions Initial Comment: I've noticed that when I use Python mode (alpha 1) with font lock mode, "self" is highlighted in the following line: his_self() The problem appears to be a combination of using "\b" in the Python font lock regular expressions and my .emacs file, which does: (modify-syntax-entry ?\_ "_" py-mode-syntax-table) I do not experience similar problems with highlighting in C mode, but there "\<" and "\>" are used in the font lock regular expressions. Using these word delimiters instead of "\b" appears to fix the problem for me in Python mode. Please wrap keywords with "\<" and "\>" instead of with "\b" in the font lock regular expression. Thanks very much. Bob ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-05-22 20:41 Message: Logged In: YES user_id=44345 Passing along to Raymond. If it works for you, please close. If not, pass it back to me. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-05-19 21:45 Message: Logged In: YES user_id=44345 python-mode.el 4.71. Raymond, sorry for taking so long with this. Please give it a try and let me know how it works. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 21:36 Message: Logged In: YES user_id=80475 Skip, can you field this one? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082487&group_id=5470 From noreply at sourceforge.net Mon May 23 03:44:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 May 2005 18:44:25 -0700 Subject: [ python-Bugs-768068 ] Explicit interp reference during build fails Message-ID: Bugs item #768068, was opened at 2003-07-08 16:44 Message generated for change (Settings changed) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768068&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: Explicit interp reference during build fails Initial Comment: I think this is MacPython-specific and not just a general Python build issue. If I explicitly reference the Python executable when building an out-of-tree extension module I get an error building the .so file because it stripped the dirname() of the python.exe file. Here's a simple example. I have a directory with a single extension module and simple setup.py. I want to build it with ~/src/python/head/dist/src/build.pg/python.exe Compilation works fine. Linkage bombs. % pwd /Users/skip/src/PyExtensions1.5/python2.2 montanaro:python2.2% ls -l total 8 -rw-r--r-- 1 skip staff 1318 Jan 21 2002 llopmodule.c -rw-rw-r-- 1 skip staff 114 Jan 21 2002 setup.py montanaro:python2.2% cat setup.py from distutils.core import setup, Extension setup(name="llop", ext_modules=[Extension("llop", ["llopmodule.c"])]) montanaro:python2.2% ~/src/python/head/dist/src/ build.pg/python.exe setup.py build running build running build_ext building 'llop' extension creating build creating build/temp.darwin-6.6-Power_Macintosh-2.3 gcc -pg -fno-strict-aliasing -Wno-long-double -no-cpp- precomp -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I/ Users/skip/src/python/head/dist/src/Include -I/Users/skip/ src/python/head/dist/src/build.pg -c llopmodule.c -o build/ temp.darwin-6.6-Power_Macintosh-2.3/llopmodule.o creating build/lib.darwin-6.6-Power_Macintosh-2.3 gcc -pg -bundle -bundle_loader python.exe build/ temp.darwin-6.6-Power_Macintosh-2.3/llopmodule.o -o build/lib.darwin-6.6-Power_Macintosh-2.3/llop.so ld: can't open: python.exe (No such file or directory, errno = 2) error: command 'gcc' failed with exit status 1 ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2004-07-16 09:53 Message: Logged In: YES user_id=45365 Skip, I think this problem has gone away as a side-effect of the new way to create extension modules, at least if you make sure you have MACOSX_TARGET_PLATFORM=10.3 in your environment when configuring and building python. Could you try, please, and close the report if this appears to work for you? Otherwise please reassign back to me. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-21 16:00 Message: Logged In: YES user_id=45365 This won't be fixed for 2.3, after discussion on python-dev it seems the situation is not so common, so it can wait for 2.3.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768068&group_id=5470 From noreply at sourceforge.net Mon May 23 06:29:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 May 2005 21:29:45 -0700 Subject: [ python-Bugs-1201456 ] Problem with recursion in dict (crash with core dump) Message-ID: Bugs item #1201456, was opened at 2005-05-13 08:43 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&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: Python Interpreter Core Group: Python 2.4 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Vladimir Yu. Stepanov (vys) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with recursion in dict (crash with core dump) Initial Comment: Please see example code. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-22 21:29 Message: Logged In: YES user_id=341410 If your system has sufficient stack space (and/or a reasonably sane malloc), a recursion limit of 1000 should be fine. My windows systems print tracebacks properly for up to a recursion limit of around 5750 levels (after which I get MemoryErrors with tracebacks, not cores). Place a sys.setrecursionlimit() call in your site.py. ---------------------------------------------------------------------- Comment By: Vladimir Yu. Stepanov (vys) Date: 2005-05-18 06:05 Message: Logged In: YES user_id=384980 sys.getrecursionlimit() returns 1000. I set sys.setrecursionlimit() to 500 and problem was resolved :) Thank you very much ! PS. Is it possible to add some checks in Py_SetRecursionLimit to reject overflow values ? ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-18 05:15 Message: Logged In: YES user_id=1038590 What does sys.getrecursionlimit() return? Does the buggy code generate the expected exception if you use sys.setrecursionlimit() to make the value smaller (e.g. 500)? FreeBSD has a history of not playing well with CPython's ability to detect inifinite recursion. . . ---------------------------------------------------------------------- Comment By: Vladimir Yu. Stepanov (vys) Date: 2005-05-13 09:06 Message: Logged In: YES user_id=384980 This is output from `uname -a`: FreeBSD fox.renet.ru 5.3-RELEASE FreeBSD 5.3-RELEASE #1: Fri Apr 15 10:38:49 MSD 2005 root at fox.renet.ru:/M/safedir/src/sys/i386/compile/FOX i386 I get some others with this code: Python 2.4.1 (#2, Apr 26 2005, 14:16:31) [GCC 3.4.2 [FreeBSD] 20040728] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> d = {} >>> >>> class test: ... def __hash__(self): ... d[self] = None ... >>> d[test()] = None Bus error (core dumped) fox:vys!~ > gdb python python.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Core was generated by `python'. Program terminated with signal 10, Bus error. (gdb) where #0 0x2828b3b1 in ldexp () from /lib/libc.so.5 #1 0x2828b618 in malloc () from /lib/libc.so.5 #2 0x080bdca1 in _PyObject_GC_Malloc () #3 0x080bdd4a in _PyObject_GC_New () #4 0x0805f556 in PyMethod_New () #5 0x0805c1a6 in PyInstance_NewRaw () #6 0x0805c66a in PyInstance_New () #7 0x0805cca1 in _PyInstance_Lookup () #8 0x080703e6 in PyDict_SetItem () #9 0x0809bb0e in PyEval_EvalFrame () #10 0x0809fc20 in PyEval_EvalCodeEx () #11 0x080d4d66 in PyFunction_SetClosure () #12 0x0805a38c in PyObject_Call () #13 0x0805fbe2 in PyMethod_New () #14 0x0805a38c in PyObject_Call () #15 0x08099f1b in PyEval_CallObjectWithKeywords () #16 0x0805ccb9 in _PyInstance_Lookup () #17 0x080703e6 in PyDict_SetItem () #18 0x0809bb0e in PyEval_EvalFrame () #19 0x0809fc20 in PyEval_EvalCodeEx () #20 0x080d4d66 in PyFunction_SetClosure () #21 0x0805a38c in PyObject_Call () #22 0x0805fbe2 in PyMethod_New () ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-13 08:55 Message: Logged In: YES user_id=80475 I get the expected behavior: RuntimeError: maximum recursion depth exceeded ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-13 08:55 Message: Logged In: YES user_id=6656 I get an infinite recursion runtime error. What platform are you on? ---------------------------------------------------------------------- Comment By: Vladimir Yu. Stepanov (vys) Date: 2005-05-13 08:46 Message: Logged In: YES user_id=384980 d = {} class test: def __hash__(self): d[self] = None d[test()] = None ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-13 08:46 Message: Logged In: YES user_id=6656 I see no code. SF can be a pain with this... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&group_id=5470 From noreply at sourceforge.net Mon May 23 06:46:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 May 2005 21:46:32 -0700 Subject: [ python-Bugs-1201456 ] Problem with recursion in dict (crash with core dump) Message-ID: Bugs item #1201456, was opened at 2005-05-13 10:43 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&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: Python Interpreter Core Group: Python 2.4 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Vladimir Yu. Stepanov (vys) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with recursion in dict (crash with core dump) Initial Comment: Please see example code. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-22 23:46 Message: Logged In: YES user_id=80475 FWIW, the OP's original situation may have tickled a genuine bug where one of the recursed into routines makes a malloc request but fails to check for, report, or gracefully exit from a memory error. His gdb trace may show the way, but I didn't see the bug. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-22 23:29 Message: Logged In: YES user_id=341410 If your system has sufficient stack space (and/or a reasonably sane malloc), a recursion limit of 1000 should be fine. My windows systems print tracebacks properly for up to a recursion limit of around 5750 levels (after which I get MemoryErrors with tracebacks, not cores). Place a sys.setrecursionlimit() call in your site.py. ---------------------------------------------------------------------- Comment By: Vladimir Yu. Stepanov (vys) Date: 2005-05-18 08:05 Message: Logged In: YES user_id=384980 sys.getrecursionlimit() returns 1000. I set sys.setrecursionlimit() to 500 and problem was resolved :) Thank you very much ! PS. Is it possible to add some checks in Py_SetRecursionLimit to reject overflow values ? ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-18 07:15 Message: Logged In: YES user_id=1038590 What does sys.getrecursionlimit() return? Does the buggy code generate the expected exception if you use sys.setrecursionlimit() to make the value smaller (e.g. 500)? FreeBSD has a history of not playing well with CPython's ability to detect inifinite recursion. . . ---------------------------------------------------------------------- Comment By: Vladimir Yu. Stepanov (vys) Date: 2005-05-13 11:06 Message: Logged In: YES user_id=384980 This is output from `uname -a`: FreeBSD fox.renet.ru 5.3-RELEASE FreeBSD 5.3-RELEASE #1: Fri Apr 15 10:38:49 MSD 2005 root at fox.renet.ru:/M/safedir/src/sys/i386/compile/FOX i386 I get some others with this code: Python 2.4.1 (#2, Apr 26 2005, 14:16:31) [GCC 3.4.2 [FreeBSD] 20040728] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> d = {} >>> >>> class test: ... def __hash__(self): ... d[self] = None ... >>> d[test()] = None Bus error (core dumped) fox:vys!~ > gdb python python.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Core was generated by `python'. Program terminated with signal 10, Bus error. (gdb) where #0 0x2828b3b1 in ldexp () from /lib/libc.so.5 #1 0x2828b618 in malloc () from /lib/libc.so.5 #2 0x080bdca1 in _PyObject_GC_Malloc () #3 0x080bdd4a in _PyObject_GC_New () #4 0x0805f556 in PyMethod_New () #5 0x0805c1a6 in PyInstance_NewRaw () #6 0x0805c66a in PyInstance_New () #7 0x0805cca1 in _PyInstance_Lookup () #8 0x080703e6 in PyDict_SetItem () #9 0x0809bb0e in PyEval_EvalFrame () #10 0x0809fc20 in PyEval_EvalCodeEx () #11 0x080d4d66 in PyFunction_SetClosure () #12 0x0805a38c in PyObject_Call () #13 0x0805fbe2 in PyMethod_New () #14 0x0805a38c in PyObject_Call () #15 0x08099f1b in PyEval_CallObjectWithKeywords () #16 0x0805ccb9 in _PyInstance_Lookup () #17 0x080703e6 in PyDict_SetItem () #18 0x0809bb0e in PyEval_EvalFrame () #19 0x0809fc20 in PyEval_EvalCodeEx () #20 0x080d4d66 in PyFunction_SetClosure () #21 0x0805a38c in PyObject_Call () #22 0x0805fbe2 in PyMethod_New () ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-13 10:55 Message: Logged In: YES user_id=80475 I get the expected behavior: RuntimeError: maximum recursion depth exceeded ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-13 10:55 Message: Logged In: YES user_id=6656 I get an infinite recursion runtime error. What platform are you on? ---------------------------------------------------------------------- Comment By: Vladimir Yu. Stepanov (vys) Date: 2005-05-13 10:46 Message: Logged In: YES user_id=384980 d = {} class test: def __hash__(self): d[self] = None d[test()] = None ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-13 10:46 Message: Logged In: YES user_id=6656 I see no code. SF can be a pain with this... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&group_id=5470 From noreply at sourceforge.net Mon May 23 06:49:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 May 2005 21:49:51 -0700 Subject: [ python-Bugs-1206537 ] weakref cannot handle bound methods (in contrast to docu) Message-ID: Bugs item #1206537, was opened at 2005-05-22 09:37 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1206537&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: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raik Gruenberg (graik) >Assigned to: Raymond Hettinger (rhettinger) Summary: weakref cannot handle bound methods (in contrast to docu) Initial Comment: According to the documentation of the weakref module, weakreferences can be applied to "...class instances, functions written in Python (but not in C), methods (both bound and unbound)..." In reality, bound methods cannot be referenced (see bug 813299): import weakref ## this works: def testF( event ): pass r = weakref.ref( testF ) ## this doesnt: class EventListener: def handleEventA( self, event ): pass t = EventListener() ## gives a "dead" ref r = weakref.ref( t.handleEventA ) This behaviour is unexpected for anyone not aquainted to the inner clockwork of python and unfortunate because it, for example, prevents to keep weak references to callback methods in event handling patterns. A workaround is proposed at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/81253 Discussion: (minimal) Solution 1: Change the weakref documentation (preferred) Solution 2: Adapt weakref to allow references to bound methods Perhaps this bug should be converted into a documentation bug and a feature request. Python version 2.3 and 2.4 OS: Linux 2.6 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1206537&group_id=5470 From noreply at sourceforge.net Mon May 23 08:52:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 May 2005 23:52:02 -0700 Subject: [ python-Bugs-1193180 ] Strange os.path.exists() results with invalid chars Message-ID: Bugs item #1193180, was opened at 2005-05-01 01:13 Message generated for change (Comment added) made by grubert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193180&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Daniele Varrazzo (dvarrazzo) Assigned to: Nobody/Anonymous (nobody) Summary: Strange os.path.exists() results with invalid chars Initial Comment: Hi, when there are invalid chars in a filename, os.path.exists () behaves oddly, returning True. The bug appears on win32 system, not on unix ones. Thus is probably related to some weird windows api call and doesn't maybe worth fixing. Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> f = file("a_b", "w") >>> f.close() >>> os.listdir(".") ['a_b'] >>> os.path.exists("a>> os.path.exists("a>b") True And, even more strange... >>> os.path.exists("a<") True >>> os.path.exists("a>") False Better answers would have been: * False * raise ValueError ---------------------------------------------------------------------- Comment By: engelbert gruber (grubert) Date: 2005-05-23 08:52 Message: Logged In: YES user_id=147070 testing with perl: print -e "a<"; returns True/1 too ---------------------------------------------------------------------- Comment By: Jarek Zgoda (zgoda) Date: 2005-05-02 14:04 Message: Logged In: YES user_id=92222 Same for Python 2.3.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193180&group_id=5470 From noreply at sourceforge.net Mon May 23 09:41:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 May 2005 00:41:02 -0700 Subject: [ python-Bugs-1202533 ] a bunch of infinite C recursions Message-ID: Bugs item #1202533, was opened at 2005-05-15 16:43 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-23 00:41 Message: Logged In: YES user_id=341410 I personally think that the CPython runtime should make a best-effort to not crash when running code that makes sense. But when CPython is running on input that is nonsensical (in each of the examples that Armin provides, no return value could make sense), I think that as long as the behavior is stated clearly, it is sufficient. Certainly it would be nice if CPython did not crash in such cases, but I don't know if the performance penalty and code maintenance outweigh the cases where users write bad code. Perhaps a compile-time option, enabled by default based on whether or not we want a safer or faster CPython. Of course maintenance is still a chore, and it is one additional set of calls that C extension writers may need to be aware of (if their code can be recursively called, and they want to participate in the infinite recursion detection). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-20 14:46 Message: Logged In: YES user_id=4771 Yes, but I'm concerned that we would need to add it really really many places, and probably forget some even then. E.g. I just thought about: lst = [apply] lst.append(lst) apply(*lst) It seems a bit hopeless, honestly... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-20 14:22 Message: Logged In: YES user_id=21627 Wouldn't adding Py_EnterRecursiveCall into many places solve the problem? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-19 08:05 Message: Logged In: YES user_id=4771 This is not about the new module. The same example can be written as: import types class A: pass A.__mul__ = types.MethodType(operator.mul, None, A) If this still looks essentially like an indirect way of using the new module, here is another example: class A(str): __get__ = getattr a = A('a') A.a = a a.a Or, as I just found out, new-style classes are again vulnerable to the older example based __call__, which was fixed for old-style classes: class A(object): pass A.__call__ = A() A()() I'm not denying that these examples look convoluted :-) My point here is that we can basically build a lot of examples based only on core (if not necessarily widely understood) language features. It appears to go against the basic hope that CPython cannot be crashed as long as you don't use features explicitely marked as dangerous. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 19:02 Message: Logged In: YES user_id=593130 On Windows, this caused the interactive window to just disappear.so I suspect something similar occurred. New is a known dangerous, use at your own risk, implementation specific module whose use, like byte code hacking, is outside the language proper. Both bypass normal object creation syntax and its checks and both can create invalid objects. A hold-your- hand inplementation would not give such access to internals. Lib Ref 3.28 says "This module provides a low-level interface to the interpreter, so care must be exercised when using this module. It is possible to supply non-sensical arguments which crash the interpreter when the object is used." Should more or different be said? If not, I suspect this should be closed as 'won't fix', as in 'won't remove the inherently dangerous new module'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 From noreply at sourceforge.net Mon May 23 15:06:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 May 2005 06:06:22 -0700 Subject: [ python-Bugs-1202533 ] a bunch of infinite C recursions Message-ID: Bugs item #1202533, was opened at 2005-05-16 01:43 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-05-23 15:06 Message: Logged In: YES user_id=21627 It has been a long-time policy that you should not be able to crash the Python interpreter even with malicious code. I think this is a good policy, because it provides people always with a back-trace, which is much easier to analyse than a core dump. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-23 09:41 Message: Logged In: YES user_id=341410 I personally think that the CPython runtime should make a best-effort to not crash when running code that makes sense. But when CPython is running on input that is nonsensical (in each of the examples that Armin provides, no return value could make sense), I think that as long as the behavior is stated clearly, it is sufficient. Certainly it would be nice if CPython did not crash in such cases, but I don't know if the performance penalty and code maintenance outweigh the cases where users write bad code. Perhaps a compile-time option, enabled by default based on whether or not we want a safer or faster CPython. Of course maintenance is still a chore, and it is one additional set of calls that C extension writers may need to be aware of (if their code can be recursively called, and they want to participate in the infinite recursion detection). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-20 23:46 Message: Logged In: YES user_id=4771 Yes, but I'm concerned that we would need to add it really really many places, and probably forget some even then. E.g. I just thought about: lst = [apply] lst.append(lst) apply(*lst) It seems a bit hopeless, honestly... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-20 23:22 Message: Logged In: YES user_id=21627 Wouldn't adding Py_EnterRecursiveCall into many places solve the problem? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-19 17:05 Message: Logged In: YES user_id=4771 This is not about the new module. The same example can be written as: import types class A: pass A.__mul__ = types.MethodType(operator.mul, None, A) If this still looks essentially like an indirect way of using the new module, here is another example: class A(str): __get__ = getattr a = A('a') A.a = a a.a Or, as I just found out, new-style classes are again vulnerable to the older example based __call__, which was fixed for old-style classes: class A(object): pass A.__call__ = A() A()() I'm not denying that these examples look convoluted :-) My point here is that we can basically build a lot of examples based only on core (if not necessarily widely understood) language features. It appears to go against the basic hope that CPython cannot be crashed as long as you don't use features explicitely marked as dangerous. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-19 04:02 Message: Logged In: YES user_id=593130 On Windows, this caused the interactive window to just disappear.so I suspect something similar occurred. New is a known dangerous, use at your own risk, implementation specific module whose use, like byte code hacking, is outside the language proper. Both bypass normal object creation syntax and its checks and both can create invalid objects. A hold-your- hand inplementation would not give such access to internals. Lib Ref 3.28 says "This module provides a low-level interface to the interpreter, so care must be exercised when using this module. It is possible to supply non-sensical arguments which crash the interpreter when the object is used." Should more or different be said? If not, I suspect this should be closed as 'won't fix', as in 'won't remove the inherently dangerous new module'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 From noreply at sourceforge.net Mon May 23 15:16:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 May 2005 06:16:32 -0700 Subject: [ python-Bugs-1202533 ] a bunch of infinite C recursions Message-ID: Bugs item #1202533, was opened at 2005-05-16 00:43 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-05-23 14:16 Message: Logged In: YES user_id=6656 I agree with Armin that this could easily be a never ending story. Perhaps it would suffice to sprinkle Py_EnterRecursiveCall around as we find holes. It might have to, because I can't really think of a better way of doing this. The only other approach I know is that of SBCL (a Common Lisp implementation): it mprotects a page at the end of the stack and installs a SIGSEGV handler (and uses sigaltstack) that knows how to abort the current lisp operation. Somehow, I don't think we want to go down this line. Anybody have any other ideas? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-23 14:06 Message: Logged In: YES user_id=21627 It has been a long-time policy that you should not be able to crash the Python interpreter even with malicious code. I think this is a good policy, because it provides people always with a back-trace, which is much easier to analyse than a core dump. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-23 08:41 Message: Logged In: YES user_id=341410 I personally think that the CPython runtime should make a best-effort to not crash when running code that makes sense. But when CPython is running on input that is nonsensical (in each of the examples that Armin provides, no return value could make sense), I think that as long as the behavior is stated clearly, it is sufficient. Certainly it would be nice if CPython did not crash in such cases, but I don't know if the performance penalty and code maintenance outweigh the cases where users write bad code. Perhaps a compile-time option, enabled by default based on whether or not we want a safer or faster CPython. Of course maintenance is still a chore, and it is one additional set of calls that C extension writers may need to be aware of (if their code can be recursively called, and they want to participate in the infinite recursion detection). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-20 22:46 Message: Logged In: YES user_id=4771 Yes, but I'm concerned that we would need to add it really really many places, and probably forget some even then. E.g. I just thought about: lst = [apply] lst.append(lst) apply(*lst) It seems a bit hopeless, honestly... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-20 22:22 Message: Logged In: YES user_id=21627 Wouldn't adding Py_EnterRecursiveCall into many places solve the problem? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-19 16:05 Message: Logged In: YES user_id=4771 This is not about the new module. The same example can be written as: import types class A: pass A.__mul__ = types.MethodType(operator.mul, None, A) If this still looks essentially like an indirect way of using the new module, here is another example: class A(str): __get__ = getattr a = A('a') A.a = a a.a Or, as I just found out, new-style classes are again vulnerable to the older example based __call__, which was fixed for old-style classes: class A(object): pass A.__call__ = A() A()() I'm not denying that these examples look convoluted :-) My point here is that we can basically build a lot of examples based only on core (if not necessarily widely understood) language features. It appears to go against the basic hope that CPython cannot be crashed as long as you don't use features explicitely marked as dangerous. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-19 03:02 Message: Logged In: YES user_id=593130 On Windows, this caused the interactive window to just disappear.so I suspect something similar occurred. New is a known dangerous, use at your own risk, implementation specific module whose use, like byte code hacking, is outside the language proper. Both bypass normal object creation syntax and its checks and both can create invalid objects. A hold-your- hand inplementation would not give such access to internals. Lib Ref 3.28 says "This module provides a low-level interface to the interpreter, so care must be exercised when using this module. It is possible to supply non-sensical arguments which crash the interpreter when the object is used." Should more or different be said? If not, I suspect this should be closed as 'won't fix', as in 'won't remove the inherently dangerous new module'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 From noreply at sourceforge.net Mon May 23 15:52:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 May 2005 06:52:45 -0700 Subject: [ python-Bugs-1202533 ] a bunch of infinite C recursions Message-ID: Bugs item #1202533, was opened at 2005-05-15 23:43 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-05-23 13:52 Message: Logged In: YES user_id=4771 When I thought about the same problem for PyPy, I imagined that it would be easy to use the call graph computed by the type inferencer ("annotator"). We would find an algorithm that figures out the minimal number of places that need a Py_EnterRecursiveCall so that every cycle goes through at least one of them. For CPython it might be possible to go down the same path if someone can find a C code analyzer smart enough to provide the required information -- a call graph including indirect calls through function pointers. Not sure it's sane, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-23 13:16 Message: Logged In: YES user_id=6656 I agree with Armin that this could easily be a never ending story. Perhaps it would suffice to sprinkle Py_EnterRecursiveCall around as we find holes. It might have to, because I can't really think of a better way of doing this. The only other approach I know is that of SBCL (a Common Lisp implementation): it mprotects a page at the end of the stack and installs a SIGSEGV handler (and uses sigaltstack) that knows how to abort the current lisp operation. Somehow, I don't think we want to go down this line. Anybody have any other ideas? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-23 13:06 Message: Logged In: YES user_id=21627 It has been a long-time policy that you should not be able to crash the Python interpreter even with malicious code. I think this is a good policy, because it provides people always with a back-trace, which is much easier to analyse than a core dump. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-23 07:41 Message: Logged In: YES user_id=341410 I personally think that the CPython runtime should make a best-effort to not crash when running code that makes sense. But when CPython is running on input that is nonsensical (in each of the examples that Armin provides, no return value could make sense), I think that as long as the behavior is stated clearly, it is sufficient. Certainly it would be nice if CPython did not crash in such cases, but I don't know if the performance penalty and code maintenance outweigh the cases where users write bad code. Perhaps a compile-time option, enabled by default based on whether or not we want a safer or faster CPython. Of course maintenance is still a chore, and it is one additional set of calls that C extension writers may need to be aware of (if their code can be recursively called, and they want to participate in the infinite recursion detection). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-20 21:46 Message: Logged In: YES user_id=4771 Yes, but I'm concerned that we would need to add it really really many places, and probably forget some even then. E.g. I just thought about: lst = [apply] lst.append(lst) apply(*lst) It seems a bit hopeless, honestly... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-20 21:22 Message: Logged In: YES user_id=21627 Wouldn't adding Py_EnterRecursiveCall into many places solve the problem? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-19 15:05 Message: Logged In: YES user_id=4771 This is not about the new module. The same example can be written as: import types class A: pass A.__mul__ = types.MethodType(operator.mul, None, A) If this still looks essentially like an indirect way of using the new module, here is another example: class A(str): __get__ = getattr a = A('a') A.a = a a.a Or, as I just found out, new-style classes are again vulnerable to the older example based __call__, which was fixed for old-style classes: class A(object): pass A.__call__ = A() A()() I'm not denying that these examples look convoluted :-) My point here is that we can basically build a lot of examples based only on core (if not necessarily widely understood) language features. It appears to go against the basic hope that CPython cannot be crashed as long as you don't use features explicitely marked as dangerous. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-19 02:02 Message: Logged In: YES user_id=593130 On Windows, this caused the interactive window to just disappear.so I suspect something similar occurred. New is a known dangerous, use at your own risk, implementation specific module whose use, like byte code hacking, is outside the language proper. Both bypass normal object creation syntax and its checks and both can create invalid objects. A hold-your- hand inplementation would not give such access to internals. Lib Ref 3.28 says "This module provides a low-level interface to the interpreter, so care must be exercised when using this module. It is possible to supply non-sensical arguments which crash the interpreter when the object is used." Should more or different be said? If not, I suspect this should be closed as 'won't fix', as in 'won't remove the inherently dangerous new module'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 From noreply at sourceforge.net Mon May 23 16:08:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 May 2005 07:08:14 -0700 Subject: [ python-Bugs-1206537 ] weakref cannot handle bound methods (in contrast to docu) Message-ID: Bugs item #1206537, was opened at 2005-05-22 14:37 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1206537&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: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raik Gruenberg (graik) Assigned to: Raymond Hettinger (rhettinger) Summary: weakref cannot handle bound methods (in contrast to docu) Initial Comment: According to the documentation of the weakref module, weakreferences can be applied to "...class instances, functions written in Python (but not in C), methods (both bound and unbound)..." In reality, bound methods cannot be referenced (see bug 813299): import weakref ## this works: def testF( event ): pass r = weakref.ref( testF ) ## this doesnt: class EventListener: def handleEventA( self, event ): pass t = EventListener() ## gives a "dead" ref r = weakref.ref( t.handleEventA ) This behaviour is unexpected for anyone not aquainted to the inner clockwork of python and unfortunate because it, for example, prevents to keep weak references to callback methods in event handling patterns. A workaround is proposed at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/81253 Discussion: (minimal) Solution 1: Change the weakref documentation (preferred) Solution 2: Adapt weakref to allow references to bound methods Perhaps this bug should be converted into a documentation bug and a feature request. Python version 2.3 and 2.4 OS: Linux 2.6 ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-05-23 14:08 Message: Logged In: YES user_id=4771 Of course, the weakref documentation is ultimately right, and the problem, unrelated to bound methods, is that you always get a dead weakref if you do weakref.ref() But I'm not being particularly helpful here. A trick simpler than the cookbook proposals is to force the method object to be alive as long as the instance itself by storing it on the instance: obj = MyClass() obj.m = obj.m ref = weakref.ref(obj.m) This works because the last "obj.m" returns an existing object, as opposed to one created just-in-time. This might be mentioned in the weakref documentation with the comment that it's a general rule to be careful not to take weakrefs to short-lived object; the same problem would occur e.g. when taking a weakref to "obj.a" where "a" is a computed property. Storing the result back on "obj" -- under the same or another name -- is a workaround. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1206537&group_id=5470 From noreply at sourceforge.net Mon May 23 16:28:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 May 2005 07:28:46 -0700 Subject: [ python-Bugs-1204734 ] Documentation error? Message-ID: Bugs item #1204734, was opened at 2005-05-19 05:21 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&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: John Eikenberry (zhar) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation error? Initial Comment: >From http://www.python.org/dev/doc/devel/ref/new-style-attribute-access.html "Called unconditionally to implement attribute accesses for instances of the class. If the class also defines __getattr__, it will never be called (unless called explicitly)." But I'm not seeing this behaviour in python-2.3.5 and python-2.4.1 on Linux. class A(object): def __getattr__(self,key): print '__getattr__',key raise AttributeError,key def __getattribute__(self,key): print '__getattribute__',key raise AttributeError,key a = A() a.foo $ python test.py __getattribute__ foo __getattr__ foo Traceback (most recent call last): File "test.py", line 14, in ? a.foo File "test.py", line 7, in __getattr__ raise AttributeError(key) AttributeError: foo It seems to be calling __getattribute__ as it should, but then it falls back on __getattr__ even though the docs specifically say it shouldn't. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-05-23 14:28 Message: Logged In: YES user_id=4771 Indeed, the logic in typeobject.c is to call __getattribute__ and fall back on __getattr__ if the former raised an AttributeError. This is necessary because all objects have a __getattribute__, actually, as there is one in the 'object' base class. This let me think that the error is really in the documentation, which should mention this logic. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&group_id=5470 From noreply at sourceforge.net Mon May 23 18:03:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 May 2005 09:03:59 -0700 Subject: [ python-Bugs-1202395 ] Description of string.lstrip() needs improvement Message-ID: Bugs item #1202395, was opened at 2005-05-15 12:50 Message generated for change (Comment added) made by liturgist You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202395&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: Roy Smith (roysmith) Assigned to: Nobody/Anonymous (nobody) Summary: Description of string.lstrip() needs improvement Initial Comment: In http://docs.python.org/lib/string-methods.html, under lstrip(), it says, "chars must be a string; the characters in the string will be stripped from the beginning of the string this method is called on". It would be clearer if it said: "chars must be a string; the characters in the string constitute a set of characters to be stripped from the beginning of the string this method is called on". Similarly for rstrip() and strip(). There was a recent posting to comp.lang.python where it appears that the poster thought the argument to lstrip() was a leading string to be removed, not a set of characters. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-05-23 11:03 Message: Logged In: YES user_id=197677 It would also be helpful to note the definition of "whitespace" in each of the strip() methods. It appears to be defined in strip() as being identical to string.whitespace. However, I do not see a built-in whitespace for strings. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 20:18 Message: Logged In: YES user_id=593130 Over the years, several people have tripped over this and posted to c.l.p., so I think the existing text is unclear enough to arguably qualify as a buglet. In response to the same posting, I had the same thought of clarifying that the 'string' defines a set, so I support this suggestion or something similar ;-) and thank you for submitting it. ---------------------------------------------------------------------- Comment By: Roy Smith (roysmith) Date: 2005-05-15 12:55 Message: Logged In: YES user_id=390499 I notice bug #1196824 (recently submitted and closed as "not a bug") relates to the same issue. It seems more than one person has gotten confused by this :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202395&group_id=5470 From noreply at sourceforge.net Mon May 23 20:43:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 May 2005 11:43:27 -0700 Subject: [ python-Bugs-1204734 ] Documentation error? Message-ID: Bugs item #1204734, was opened at 2005-05-18 22:21 Message generated for change (Comment added) made by zhar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&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: John Eikenberry (zhar) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation error? Initial Comment: >From http://www.python.org/dev/doc/devel/ref/new-style-attribute-access.html "Called unconditionally to implement attribute accesses for instances of the class. If the class also defines __getattr__, it will never be called (unless called explicitly)." But I'm not seeing this behaviour in python-2.3.5 and python-2.4.1 on Linux. class A(object): def __getattr__(self,key): print '__getattr__',key raise AttributeError,key def __getattribute__(self,key): print '__getattribute__',key raise AttributeError,key a = A() a.foo $ python test.py __getattribute__ foo __getattr__ foo Traceback (most recent call last): File "test.py", line 14, in ? a.foo File "test.py", line 7, in __getattr__ raise AttributeError(key) AttributeError: foo It seems to be calling __getattribute__ as it should, but then it falls back on __getattr__ even though the docs specifically say it shouldn't. ---------------------------------------------------------------------- >Comment By: John Eikenberry (zhar) Date: 2005-05-23 11:43 Message: Logged In: YES user_id=322022 Please specify in the documentation whether this is how it is supposed to work or whether this is a side-effect of the implementation. To make explicit if you can write code relying on this 'feature' and not have it break at some point. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-23 07:28 Message: Logged In: YES user_id=4771 Indeed, the logic in typeobject.c is to call __getattribute__ and fall back on __getattr__ if the former raised an AttributeError. This is necessary because all objects have a __getattribute__, actually, as there is one in the 'object' base class. This let me think that the error is really in the documentation, which should mention this logic. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&group_id=5470 From noreply at sourceforge.net Tue May 24 00:02:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 May 2005 15:02:04 -0700 Subject: [ python-Bugs-1207379 ] class property fset not working Message-ID: Bugs item #1207379, was opened at 2005-05-24 00:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&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: Master_Jaf (master_jaf) Assigned to: Nobody/Anonymous (nobody) Summary: class property fset not working Initial Comment: Classes which are not instantiated from 'object', containing properties, are not working as expected. The GET method is working but not the SET method. Tested with python 2.4.1 und 2.3.5. See sample code file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&group_id=5470 From noreply at sourceforge.net Tue May 24 04:21:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 May 2005 19:21:58 -0700 Subject: [ python-Bugs-1207466 ] installer ignores changed installation directory Message-ID: Bugs item #1207466, was opened at 2005-05-24 04:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207466&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: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Blubb Fallo (blubbfallo) Assigned to: Nobody/Anonymous (nobody) Summary: installer ignores changed installation directory Initial Comment: concerning python-2.4.1.msi at win2000 sp4 After having spent quite some time at python.org to find out if I had to remove 2.4 before installing 2.4.1 (without any success, btw) I dared to start overinstalling. 1. Unfortunately, I didn't recognize that the suggested directory was different from where I wanted Python to stay in. Now, there seems to be no way back except completele un- and reinstalling: 2. I run the installer again and selected "change Python 2.4.1", then clicked "back", choosing the right directory, then went on to "next" and on, but my directory choice was ignored. 3. Finally, I run the installer at commandline, specifying TARGETDIR, chose the "change Python 2.4.1" radiobutton ... and again, Python was reinstalled as if TARGETDIR wasn't given. Paths containing spaces are not involved. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207466&group_id=5470 From noreply at sourceforge.net Tue May 24 06:29:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 May 2005 21:29:50 -0700 Subject: [ python-Bugs-1207501 ] Issue in grammar Message-ID: Bugs item #1207501, was opened at 2005-05-24 09:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207501&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: venkat manian (annacoder) Assigned to: Nobody/Anonymous (nobody) Summary: Issue in grammar Initial Comment: decorator ::= "@" dotted_name ["(" [argument_list [","]] ")"] NEWLINE ---------------------------------- the above line appears in the grammar for function definition and dotted_name seems to be a non-terminal. But, i was not able to find any instance of it again in the grammer. It does not appear on the left-hand side. Even in the documentation, the "dotted_name" link does not take me anywhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207501&group_id=5470 From noreply at sourceforge.net Tue May 24 07:06:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 May 2005 22:06:12 -0700 Subject: [ python-Bugs-1207509 ] Issue in grammar Message-ID: Bugs item #1207509, was opened at 2005-05-24 10:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207509&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: venkat manian (annacoder) Assigned to: Nobody/Anonymous (nobody) Summary: Issue in grammar Initial Comment: decorator ::= "@" dotted_name ["(" [argument_list [","]] ")"] NEWLINE ---------------------------------- the above line appears in the grammar for function definition and dotted_name seems to be a non-terminal. But, i was not able to find any instance of it again in the grammer. It does not appear on the left-hand side. Even in the documentation, the "dotted_name" link does not take me anywhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207509&group_id=5470 From noreply at sourceforge.net Tue May 24 09:31:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 May 2005 00:31:49 -0700 Subject: [ python-Bugs-868571 ] HTTPResponse.read(amt) fails when response length is UNKNOWN Message-ID: Bugs item #868571, was opened at 2003-12-31 19:18 Message generated for change (Comment added) made by cropr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868571&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: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Grant Monroe (gmonroe) Assigned to: Nobody/Anonymous (nobody) Summary: HTTPResponse.read(amt) fails when response length is UNKNOWN Initial Comment: If the length of the reponse from an HTTPConnection is unknown, then a read with a specified amount fails. File "/home/grant/local/lib/python2.3/httplib.py", line 404, in read self.length -= amt TypeError: unsupported operand type(s) for -=: 'str' and 'int' ---------------------------------------------------------------------- Comment By: ruben decrop (cropr) Date: 2005-05-24 07:31 Message: Logged In: YES user_id=17539 I can reproduce the same error. This happens when the server answers using the HTTP 0.9 protocol. Apparently the _read_status() is getting confused for some HTTP 0.9 messages. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868571&group_id=5470 From noreply at sourceforge.net Tue May 24 09:58:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 May 2005 00:58:55 -0700 Subject: [ python-Bugs-1207379 ] class property fset not working Message-ID: Bugs item #1207379, was opened at 2005-05-23 23:02 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&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: Master_Jaf (master_jaf) Assigned to: Nobody/Anonymous (nobody) Summary: class property fset not working Initial Comment: Classes which are not instantiated from 'object', containing properties, are not working as expected. The GET method is working but not the SET method. Tested with python 2.4.1 und 2.3.5. See sample code file. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-05-24 08:58 Message: Logged In: YES user_id=6656 At the very limit, this is a documentation bug. Why did you think properties could be attached to old-style classes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&group_id=5470 From noreply at sourceforge.net Tue May 24 09:59:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 May 2005 00:59:38 -0700 Subject: [ python-Bugs-1207509 ] Issue in grammar Message-ID: Bugs item #1207509, was opened at 2005-05-24 06:06 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207509&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: Duplicate Priority: 5 Submitted By: venkat manian (annacoder) Assigned to: Nobody/Anonymous (nobody) Summary: Issue in grammar Initial Comment: decorator ::= "@" dotted_name ["(" [argument_list [","]] ")"] NEWLINE ---------------------------------- the above line appears in the grammar for function definition and dotted_name seems to be a non-terminal. But, i was not able to find any instance of it again in the grammer. It does not appear on the left-hand side. Even in the documentation, the "dotted_name" link does not take me anywhere. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-05-24 08:59 Message: Logged In: YES user_id=6656 Dup of #1207501. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207509&group_id=5470 From noreply at sourceforge.net Tue May 24 10:31:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 May 2005 01:31:45 -0700 Subject: [ python-Feature Requests-1207589 ] Right Click Context Menu Message-ID: Feature Requests item #1207589, was opened at 2005-05-24 08:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1207589&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: Mike Foord (mjfoord) Assigned to: Nobody/Anonymous (nobody) Summary: Right Click Context Menu Initial Comment: It would be useful if the right click context menu had the usual 'cut/paste/copy' options - as in most other IDEs. I regularly lose my selection because IDLE doesn't behave the same way as most other editors in this regard. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1207589&group_id=5470 From noreply at sourceforge.net Tue May 24 10:34:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 May 2005 01:34:14 -0700 Subject: [ python-Feature Requests-1207592 ] Clipboard Cleared on Close Message-ID: Feature Requests item #1207592, was opened at 2005-05-24 08:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1207592&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: Mike Foord (mjfoord) Assigned to: Nobody/Anonymous (nobody) Summary: Clipboard Cleared on Close Initial Comment: When you close IDLE (under windows at least) any clipboard selection is cleared. This is non-standard behaviour. I often open a script with IDLE in order to copy something, select and copy it and close IDLE. When I come to paste it in another window - the clipboard has been cleared. Most other programs leave the clipboard contents intact even after closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1207592&group_id=5470 From noreply at sourceforge.net Tue May 24 11:08:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 May 2005 02:08:16 -0700 Subject: [ python-Bugs-1204734 ] Documentation error? Message-ID: Bugs item #1204734, was opened at 2005-05-19 05:21 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&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: John Eikenberry (zhar) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation error? Initial Comment: >From http://www.python.org/dev/doc/devel/ref/new-style-attribute-access.html "Called unconditionally to implement attribute accesses for instances of the class. If the class also defines __getattr__, it will never be called (unless called explicitly)." But I'm not seeing this behaviour in python-2.3.5 and python-2.4.1 on Linux. class A(object): def __getattr__(self,key): print '__getattr__',key raise AttributeError,key def __getattribute__(self,key): print '__getattribute__',key raise AttributeError,key a = A() a.foo $ python test.py __getattribute__ foo __getattr__ foo Traceback (most recent call last): File "test.py", line 14, in ? a.foo File "test.py", line 7, in __getattr__ raise AttributeError(key) AttributeError: foo It seems to be calling __getattribute__ as it should, but then it falls back on __getattr__ even though the docs specifically say it shouldn't. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-05-24 09:08 Message: Logged In: YES user_id=4771 I'll wait for an "authorized" confirmation, but so far I think that the current implementation is really how it is supposed to work. The method 'object.__getattribute__' must be there, given that it is a common technique to use it directly in overridden __getattribute__ implementations. As a consequence, __getattribute__ cannot completely shadow __getattr__, or __getattr__ would never be called. ---------------------------------------------------------------------- Comment By: John Eikenberry (zhar) Date: 2005-05-23 18:43 Message: Logged In: YES user_id=322022 Please specify in the documentation whether this is how it is supposed to work or whether this is a side-effect of the implementation. To make explicit if you can write code relying on this 'feature' and not have it break at some point. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-23 14:28 Message: Logged In: YES user_id=4771 Indeed, the logic in typeobject.c is to call __getattribute__ and fall back on __getattr__ if the former raised an AttributeError. This is necessary because all objects have a __getattribute__, actually, as there is one in the 'object' base class. This let me think that the error is really in the documentation, which should mention this logic. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&group_id=5470 From noreply at sourceforge.net Tue May 24 11:08:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 May 2005 02:08:33 -0700 Subject: [ python-Feature Requests-1207613 ] Bottom Scroll Bar Message-ID: Feature Requests item #1207613, was opened at 2005-05-24 09:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1207613&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: Mike Foord (mjfoord) Assigned to: Nobody/Anonymous (nobody) Summary: Bottom Scroll Bar Initial Comment: IDLE comes without a horizontal (bottom) scroll bar. In general this is preferable, but there are times when it's a nuisance. It would be nice to have an option (easily accessible) to switch this on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1207613&group_id=5470 From noreply at sourceforge.net Tue May 24 14:27:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 May 2005 05:27:48 -0700 Subject: [ python-Bugs-1207379 ] class property fset not working Message-ID: Bugs item #1207379, was opened at 2005-05-24 00:02 Message generated for change (Comment added) made by master_jaf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&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: Master_Jaf (master_jaf) Assigned to: Nobody/Anonymous (nobody) Summary: class property fset not working Initial Comment: Classes which are not instantiated from 'object', containing properties, are not working as expected. The GET method is working but not the SET method. Tested with python 2.4.1 und 2.3.5. See sample code file. ---------------------------------------------------------------------- >Comment By: Master_Jaf (master_jaf) Date: 2005-05-24 14:27 Message: Logged In: YES user_id=1140154 After reading some more documentation I've found at Python Tutorial "D. Glossary" more hints. <cite> Any class that inherits from object. This includes all built-in types like list and dict. Only new-style classes can use Python's newer, versatile features like __slots__, descriptors, properties, __getattribute__(), class methods, and static methods. </cite> Fine. OK, understood.. I'm tending to agree with mwh's opinion, that this is a documentation bug, although I don't fully understand why the GET descriptor is working but unlikly not the SET descriptor. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-24 09:58 Message: Logged In: YES user_id=6656 At the very limit, this is a documentation bug. Why did you think properties could be attached to old-style classes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&group_id=5470 From noreply at sourceforge.net Tue May 24 14:27:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 May 2005 05:27:48 -0700 Subject: [ python-Bugs-1207379 ] class property fset not working Message-ID: Bugs item #1207379, was opened at 2005-05-24 00:02 Message generated for change (Comment added) made by master_jaf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&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: Master_Jaf (master_jaf) Assigned to: Nobody/Anonymous (nobody) Summary: class property fset not working Initial Comment: Classes which are not instantiated from 'object', containing properties, are not working as expected. The GET method is working but not the SET method. Tested with python 2.4.1 und 2.3.5. See sample code file. ---------------------------------------------------------------------- >Comment By: Master_Jaf (master_jaf) Date: 2005-05-24 14:27 Message: Logged In: YES user_id=1140154 After reading some more documentation I've found at Python Tutorial "D. Glossary" more hints. <cite> Any class that inherits from object. This includes all built-in types like list and dict. Only new-style classes can use Python's newer, versatile features like __slots__, descriptors, properties, __getattribute__(), class methods, and static methods. </cite> Fine. OK, understood.. I'm tending to agree with mwh's opinion, that this is a documentation bug, although I don't fully understand why the GET descriptor is working but unlikly not the SET descriptor. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-24 09:58 Message: Logged In: YES user_id=6656 At the very limit, this is a documentation bug. Why did you think properties could be attached to old-style classes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&group_id=5470 From noreply at sourceforge.net Wed May 25 07:43:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 May 2005 22:43:35 -0700 Subject: [ python-Bugs-1120777 ] bug in unichr() documentation Message-ID: Bugs item #1120777, was opened at 2005-02-11 08:54 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120777&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: Marko Kreen (mkz) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: bug in unichr() documentation Initial Comment: http://www.python.org/doc/2.4/lib/built-in-funcs.html: > Return the Unicode string of one character whose Unicode > code is the integer i. > [...] > The argument must be in the range [0..65535], inclusive. unichr.__doc_ says: > Return a Unicode string of one character with ordinal i; 0 <= i <= 0x10ffff. Which is correct? ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-05-25 01:43 Message: Logged In: YES user_id=3066 Fixed in Doc/lib/libfuncs.tex revisions 1.182, 1.175.2.3 ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-19 22:57 Message: Logged In: YES user_id=81797 Fred: The attached patch looks good to me. ---------------------------------------------------------------------- Comment By: Marko Kreen (mkz) Date: 2005-02-11 09:38 Message: Logged In: YES user_id=894541 Main problem for me was that the 65535 hints that unichr() may want UTF-16 values not Unicode. That was rather confusing. Ok, attached path clarifies unichr() range. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-02-11 09:03 Message: Logged In: YES user_id=38388 Whether unichr() handles the UCS2 or the UCS4 range depends on the configuration option you set at Python compile time. Perhaps we should extend the documentation to mention this difference ?! Doc patches are welcome :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120777&group_id=5470 From noreply at sourceforge.net Wed May 25 07:46:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 May 2005 22:46:58 -0700 Subject: [ python-Bugs-1167922 ] Line ending documentation is misleading Message-ID: Bugs item #1167922, was opened at 2005-03-21 17:06 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167922&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: Paul Moore (pmoore) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Line ending documentation is misleading Initial Comment: The documentation of line ending conventions is misleading when embedding Python. The only documentation I can find on line endings is in the language reference - section 2.1.2 "Physical Lines". This describes a physical line as being terminated with the platform line terminator. When referring to source files, this is wrong, as universal newline support now means that any of CR, LF, or CRLF is a valid line terminator on all platforms. When embedding (via something like PyRun_SimpleString) a C-level newline terminator (ie, "\n") is the line terminator. I attach a suggested patch to the ref\ref2.tex documentation file (patch against CVS HEAD as at 29th Jan). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-05-25 01:46 Message: Logged In: YES user_id=3066 Fixed in Doc/ref/ref2.tex revisions 1.57, 1.56.2.1, using the attached patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167922&group_id=5470 From noreply at sourceforge.net Wed May 25 11:20:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 25 May 2005 02:20:22 -0700 Subject: [ python-Bugs-1208304 ] urllib2's urlopen() method causes a memory leak Message-ID: Bugs item #1208304, was opened at 2005-05-25 09:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1208304&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: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Petr Toman (manekcz) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2's urlopen() method causes a memory leak Initial Comment: It seems that the urlopen(url) methd of the urllib2 module leaves some undestroyable objects in memory. Please try the following code: ========================== if __name__ == '__main__': import urllib2 a = urllib2.urlopen('http://www.google.com') del a # or a = None or del(a) # check memory on memory leaks import gc gc.set_debug(gc.DEBUG_SAVEALL) gc.collect() for it in gc.garbage: print it ========================== In our code, we're using lots of urlopens in a loop and the number of unreachable objects grows beyond all limits :) We also tried a.close() but it didn't help. You can also try the following: ========================== def print_unreachable_len(): # check memory on memory leaks import gc gc.set_debug(gc.DEBUG_SAVEALL) gc.collect() unreachableL = [] for it in gc.garbage: unreachableL.append(it) return len(str(unreachableL)) if __name__ == '__main__': print "at the beginning", print_unreachable_len() import urllib2 print "after import of urllib2", print_unreachable_len() a = urllib2.urlopen('http://www.google.com') print 'after urllib2.urlopen', print_unreachable_len() del a print 'after del', print_unreachable_len() ========================== We're using WindowsXP with latest patches, Python 2.4 (ActivePython 2.4 Build 243 (ActiveState Corp.) based on Python 2.4 (#60, Nov 30 2004, 09:34:21) [MSC v.1310 32 bit (Intel)] on win32). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1208304&group_id=5470 From noreply at sourceforge.net Wed May 25 16:05:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 25 May 2005 07:05:19 -0700 Subject: [ python-Bugs-1208468 ] no CoreGraphics library under Python 2.4 Message-ID: Bugs item #1208468, was opened at 2005-05-25 14:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1208468&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: Jurjen N.E. Bos (jneb) Assigned to: Jack Jansen (jackjansen) Summary: no CoreGraphics library under Python 2.4 Initial Comment: It is very simple: Under Python 2.3: >>> import CoreGraphics >>> Under Python 2.4: >>> import CoreGraphics Traceback (most recent call last): File "", line 1, in ? ImportError: No module named CoreGraphics >>> That's all there is to it. I get the impression that Apple made the CoreGraphics library themselves, but maybe there is a trick to get it in. PS do not confuse this with Carbon.CoreGraphics: this is not more than a bunch of constants. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1208468&group_id=5470 From noreply at sourceforge.net Wed May 25 18:42:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 25 May 2005 09:42:40 -0700 Subject: [ python-Bugs-1208468 ] no CoreGraphics library under Python 2.4 Message-ID: Bugs item #1208468, was opened at 2005-05-25 15:05 Message generated for change (Settings changed) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1208468&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: Closed >Resolution: Rejected Priority: 5 Submitted By: Jurjen N.E. Bos (jneb) Assigned to: Jack Jansen (jackjansen) Summary: no CoreGraphics library under Python 2.4 Initial Comment: It is very simple: Under Python 2.3: >>> import CoreGraphics >>> Under Python 2.4: >>> import CoreGraphics Traceback (most recent call last): File "", line 1, in ? ImportError: No module named CoreGraphics >>> That's all there is to it. I get the impression that Apple made the CoreGraphics library themselves, but maybe there is a trick to get it in. PS do not confuse this with Carbon.CoreGraphics: this is not more than a bunch of constants. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-05-25 17:42 Message: Logged In: YES user_id=6656 > I get the impression that Apple made the > CoreGraphics library themselves. Indeed, if you want it for Python 2.4 you'll have to ask them for it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1208468&group_id=5470 From noreply at sourceforge.net Wed May 25 22:37:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 25 May 2005 13:37:55 -0700 Subject: [ python-Feature Requests-1208730 ] expat binding for XML_ParserReset Message-ID: Feature Requests item #1208730, was opened at 2005-05-25 13:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1208730&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: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Eikenberry (zhar) Assigned to: Nobody/Anonymous (nobody) Summary: expat binding for XML_ParserReset Initial Comment: XML_ParserReset is an expat parser method for resetting the parser to handle a new document. This keeps you from having to create a new parser for each document. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1208730&group_id=5470 From noreply at sourceforge.net Thu May 26 09:02:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 00:02:54 -0700 Subject: [ python-Feature Requests-1207592 ] Clipboard Cleared on Close Message-ID: Feature Requests item #1207592, was opened at 2005-05-24 03:34 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1207592&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: Mike Foord (mjfoord) >Assigned to: Kurt B. Kaiser (kbk) Summary: Clipboard Cleared on Close Initial Comment: When you close IDLE (under windows at least) any clipboard selection is cleared. This is non-standard behaviour. I often open a script with IDLE in order to copy something, select and copy it and close IDLE. When I come to paste it in another window - the clipboard has been cleared. Most other programs leave the clipboard contents intact even after closing. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-26 02:02 Message: Logged In: YES user_id=80475 I've also bumped into this. It's annoying. Am not sure whether it is a Python issue, IDLE issue, or Tkinter issue. If the latter, there is likely nothing that can be done about it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1207592&group_id=5470 From noreply at sourceforge.net Thu May 26 09:03:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 00:03:26 -0700 Subject: [ python-Feature Requests-1207613 ] Bottom Scroll Bar Message-ID: Feature Requests item #1207613, was opened at 2005-05-24 04:08 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1207613&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: Mike Foord (mjfoord) >Assigned to: Kurt B. Kaiser (kbk) Summary: Bottom Scroll Bar Initial Comment: IDLE comes without a horizontal (bottom) scroll bar. In general this is preferable, but there are times when it's a nuisance. It would be nice to have an option (easily accessible) to switch this on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1207613&group_id=5470 From noreply at sourceforge.net Thu May 26 09:06:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 00:06:44 -0700 Subject: [ python-Feature Requests-1207589 ] Right Click Context Menu Message-ID: Feature Requests item #1207589, was opened at 2005-05-24 03:31 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1207589&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: Mike Foord (mjfoord) >Assigned to: Kurt B. Kaiser (kbk) Summary: Right Click Context Menu Initial Comment: It would be useful if the right click context menu had the usual 'cut/paste/copy' options - as in most other IDEs. I regularly lose my selection because IDLE doesn't behave the same way as most other editors in this regard. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-26 02:06 Message: Logged In: YES user_id=80475 +0 Control-X, Control-C, and Control-V work fine for me. Still, the OP's suggestion is a standard way of doing things. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1207589&group_id=5470 From noreply at sourceforge.net Thu May 26 09:09:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 00:09:34 -0700 Subject: [ python-Bugs-1207501 ] Issue in grammar Message-ID: Bugs item #1207501, was opened at 2005-05-23 23:29 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207501&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: venkat manian (annacoder) >Assigned to: Michael Hudson (mwh) Summary: Issue in grammar Initial Comment: decorator ::= "@" dotted_name ["(" [argument_list [","]] ")"] NEWLINE ---------------------------------- the above line appears in the grammar for function definition and dotted_name seems to be a non-terminal. But, i was not able to find any instance of it again in the grammer. It does not appear on the left-hand side. Even in the documentation, the "dotted_name" link does not take me anywhere. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-26 02:09 Message: Logged In: YES user_id=80475 Michael, this was your change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207501&group_id=5470 From noreply at sourceforge.net Thu May 26 09:12:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 00:12:13 -0700 Subject: [ python-Bugs-1202946 ] Problem with abs function Message-ID: Bugs item #1202946, was opened at 2005-05-16 11:32 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202946&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: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: ric-b (ric-b) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with abs function Initial Comment: On windows version I get : >>> abs(-9999999999999999999) Traceback (most recent call last): File "", line 1, in -toplevel- abs(-9999999999999999999) OverflowError: long too big to convert does not handle new longs. I am using the following work around: t = a - b # calc t = abs(a - b) if t < 0 : t *= -1 ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-26 02:12 Message: Logged In: YES user_id=80475 No response from the OP. Presuming that Terry's explanation is correct. Please re-open if presented with evidence to the contrary. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 21:10 Message: Logged In: YES user_id=593130 Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> abs(-9999999999999999999) 9999999999999999999L Ric-b: what windows version? Even older? If the problem is not with current or future (cvs) Python, please close this. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-18 06:53 Message: Logged In: YES user_id=1038590 I tried the OP's example in wxPython's PyShell as well as in the standard interpreter, and got the same result as Raymond. However, I was able to provoke a similar looking error by trying to convert a large long to a float (and the exception is telling the plain truth - a double precision float can't handle a number that big): Py> num = 1.0 Py> lng = -999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999 999999999999 Py> num += abs(lng) Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to float ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-16 12:33 Message: Logged In: YES user_id=80475 That's odd. It works for me: Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> abs(-9999999999999999999) 9999999999999999999L ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202946&group_id=5470 From noreply at sourceforge.net Thu May 26 09:17:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 00:17:15 -0700 Subject: [ python-Bugs-1199808 ] installation problem with python 2.4.1 on Win2k system Message-ID: Bugs item #1199808, was opened at 2005-05-11 05:50 Message generated for change (Comment added) made by mmkobayashi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199808&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: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: mmkobayashi (mmkobayashi) Assigned to: Nobody/Anonymous (nobody) Summary: installation problem with python 2.4.1 on Win2k system Initial Comment: After several attempts to install python2.4.1 on a win2k systems with doing all windows updates, we have been unable to install python2.4.1 on this system. We have attached an error logfile. The main thing that happens is that the install proceeds as normal but at some point the install decides that something has gone wrong and uninstalls itself. Any help in this matter would be greatly appreciated. ---------------------------------------------------------------------- >Comment By: mmkobayashi (mmkobayashi) Date: 2005-05-26 00:17 Message: Logged In: YES user_id=1273313 Yes, the logfile is indeed manually truncated. I could not upload the unmodified file which is greater than 2 Mbytes Any suggestions how I can get the log file to you. I was not using a SUBSTed drive. Python 2.4.1 installed fine on a similarly configured machine but can not get past this bug. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-20 14:35 Message: Logged In: YES user_id=21627 The log file appears to be manually truncated. Can you please provide the full log file? Are you by any chance running the MSI file from a SUBSTed drive? ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 18:01 Message: Logged In: YES user_id=593130 You might also check out http://python.org/sf/1199947 ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 17:48 Message: Logged In: YES user_id=593130 Help questions should better be directed to comp.lang.python == python mailing list == gmane.comp.python.general. The answers you get should help determine whether there is a bug in the install file distributed by PSF that should be reported here. Given that the install appeared to go ok until it tried to remove the existing files, I wonder whether there is a process running in the background that is using the existing install. That issue has been discussed on the python group recently. ---------------------------------------------------------------------- Comment By: mmkobayashi (mmkobayashi) Date: 2005-05-11 22:53 Message: Logged In: YES user_id=1273313 add file ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199808&group_id=5470 From noreply at sourceforge.net Thu May 26 09:46:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 00:46:02 -0700 Subject: [ python-Feature Requests-1207589 ] Right Click Context Menu Message-ID: Feature Requests item #1207589, was opened at 2005-05-24 08:31 Message generated for change (Comment added) made by mjfoord You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1207589&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: Mike Foord (mjfoord) Assigned to: Kurt B. Kaiser (kbk) Summary: Right Click Context Menu Initial Comment: It would be useful if the right click context menu had the usual 'cut/paste/copy' options - as in most other IDEs. I regularly lose my selection because IDLE doesn't behave the same way as most other editors in this regard. ---------------------------------------------------------------------- >Comment By: Mike Foord (mjfoord) Date: 2005-05-26 07:46 Message: Logged In: YES user_id=1123892 It's a standard way of doing things (and so an ingrained habit for at least windoze users) - and also if you're using the mouse to make a selection and then change focus to another window to paste into it; it's easier to be able to do the whole operation with the mouse than change to the keyboard and back again. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-26 07:06 Message: Logged In: YES user_id=80475 +0 Control-X, Control-C, and Control-V work fine for me. Still, the OP's suggestion is a standard way of doing things. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1207589&group_id=5470 From noreply at sourceforge.net Thu May 26 10:00:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 01:00:00 -0700 Subject: [ python-Bugs-1207501 ] Issue in grammar Message-ID: Bugs item #1207501, was opened at 2005-05-24 05:29 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207501&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: venkat manian (annacoder) Assigned to: Michael Hudson (mwh) Summary: Issue in grammar Initial Comment: decorator ::= "@" dotted_name ["(" [argument_list [","]] ")"] NEWLINE ---------------------------------- the above line appears in the grammar for function definition and dotted_name seems to be a non-terminal. But, i was not able to find any instance of it again in the grammer. It does not appear on the left-hand side. Even in the documentation, the "dotted_name" link does not take me anywhere. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-05-26 09:00 Message: Logged In: YES user_id=6656 Well, IIRC I only checked this patch in because SF CVS wasn't talking to Anthony that day... but I fixed it anyway: Revision 1.45 of Doc/ref/ref7.tex ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-26 08:09 Message: Logged In: YES user_id=80475 Michael, this was your change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207501&group_id=5470 From noreply at sourceforge.net Thu May 26 10:01:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 01:01:39 -0700 Subject: [ python-Feature Requests-1205239 ] Let shift operators take any integer value Message-ID: Feature Requests item #1205239, was opened at 2005-05-19 12:54 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&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: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Albert Torpey (dtorp) Assigned to: Nobody/Anonymous (nobody) Summary: Let shift operators take any integer value Initial Comment: Let: 1 >> -4 be interpreted as: 1 << 4 This should be easy to do. It would be somewhat helpful for bit manipulations and multiplying by powers of two. Without the change, my code is laced with sections like: if y > 0: z = x << y else: z = x >> -y This is ugly and slow compared to a straight: z = x << y There is a precedent. See what is done with negative list indices for comparison. It saves even less code with x[len (x)-i] becoming x[i]. The reason for doing it is code simplication and clarity. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-26 01:01 Message: Logged In: YES user_id=341410 Is your code time critical? Do your numbers have more than 53 bits of precision? Do your numbers vary beyond 2**1024 or 1/2**1024? If not, then the following should be sufficient for your uses: int(x * 2**y) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&group_id=5470 From noreply at sourceforge.net Thu May 26 17:33:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 08:33:03 -0700 Subject: [ python-Bugs-1204734 ] Documentation error? Message-ID: Bugs item #1204734, was opened at 2005-05-19 01:21 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&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: John Eikenberry (zhar) >Assigned to: Guido van Rossum (gvanrossum) Summary: Documentation error? Initial Comment: >From http://www.python.org/dev/doc/devel/ref/new-style-attribute-access.html "Called unconditionally to implement attribute accesses for instances of the class. If the class also defines __getattr__, it will never be called (unless called explicitly)." But I'm not seeing this behaviour in python-2.3.5 and python-2.4.1 on Linux. class A(object): def __getattr__(self,key): print '__getattr__',key raise AttributeError,key def __getattribute__(self,key): print '__getattribute__',key raise AttributeError,key a = A() a.foo $ python test.py __getattribute__ foo __getattr__ foo Traceback (most recent call last): File "test.py", line 14, in ? a.foo File "test.py", line 7, in __getattr__ raise AttributeError(key) AttributeError: foo It seems to be calling __getattribute__ as it should, but then it falls back on __getattr__ even though the docs specifically say it shouldn't. ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 11:33 Message: Logged In: YES user_id=593130 If the default __getattribute__ explicitly calls __getattr__ (but I don't know which source file to check), then the second sentence above *would* make some sense. Guido (or deputy): what is your design intention? Note: if the second sentence is kept, replacing 'it' with 'the latter' would make it clearer. I first read 'it' as referring to __getattribute__. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-24 05:08 Message: Logged In: YES user_id=4771 I'll wait for an "authorized" confirmation, but so far I think that the current implementation is really how it is supposed to work. The method 'object.__getattribute__' must be there, given that it is a common technique to use it directly in overridden __getattribute__ implementations. As a consequence, __getattribute__ cannot completely shadow __getattr__, or __getattr__ would never be called. ---------------------------------------------------------------------- Comment By: John Eikenberry (zhar) Date: 2005-05-23 14:43 Message: Logged In: YES user_id=322022 Please specify in the documentation whether this is how it is supposed to work or whether this is a side-effect of the implementation. To make explicit if you can write code relying on this 'feature' and not have it break at some point. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-23 10:28 Message: Logged In: YES user_id=4771 Indeed, the logic in typeobject.c is to call __getattribute__ and fall back on __getattr__ if the former raised an AttributeError. This is necessary because all objects have a __getattribute__, actually, as there is one in the 'object' base class. This let me think that the error is really in the documentation, which should mention this logic. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&group_id=5470 From noreply at sourceforge.net Thu May 26 17:38:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 08:38:04 -0700 Subject: [ python-Feature Requests-1207589 ] Right Click Context Menu Message-ID: Feature Requests item #1207589, was opened at 2005-05-24 03:31 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1207589&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Mike Foord (mjfoord) >Assigned to: Nobody/Anonymous (nobody) Summary: Right Click Context Menu Initial Comment: It would be useful if the right click context menu had the usual 'cut/paste/copy' options - as in most other IDEs. I regularly lose my selection because IDLE doesn't behave the same way as most other editors in this regard. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-05-26 10:38 Message: Logged In: YES user_id=149084 This came up on idle-dev, as I remember. Seems like a reasonable suggestion to me. Maybe OP could write a patch? All the pertinent code should be in EditorWindow.py. ---------------------------------------------------------------------- Comment By: Mike Foord (mjfoord) Date: 2005-05-26 02:46 Message: Logged In: YES user_id=1123892 It's a standard way of doing things (and so an ingrained habit for at least windoze users) - and also if you're using the mouse to make a selection and then change focus to another window to paste into it; it's easier to be able to do the whole operation with the mouse than change to the keyboard and back again. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-26 02:06 Message: Logged In: YES user_id=80475 +0 Control-X, Control-C, and Control-V work fine for me. Still, the OP's suggestion is a standard way of doing things. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1207589&group_id=5470 From noreply at sourceforge.net Thu May 26 17:43:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 08:43:13 -0700 Subject: [ python-Bugs-1204734 ] __getattribute__ documentation error? Message-ID: Bugs item #1204734, was opened at 2005-05-19 01:21 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&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: John Eikenberry (zhar) Assigned to: Guido van Rossum (gvanrossum) >Summary: __getattribute__ documentation error? Initial Comment: >From http://www.python.org/dev/doc/devel/ref/new-style-attribute-access.html "Called unconditionally to implement attribute accesses for instances of the class. If the class also defines __getattr__, it will never be called (unless called explicitly)." But I'm not seeing this behaviour in python-2.3.5 and python-2.4.1 on Linux. class A(object): def __getattr__(self,key): print '__getattr__',key raise AttributeError,key def __getattribute__(self,key): print '__getattribute__',key raise AttributeError,key a = A() a.foo $ python test.py __getattribute__ foo __getattr__ foo Traceback (most recent call last): File "test.py", line 14, in ? a.foo File "test.py", line 7, in __getattr__ raise AttributeError(key) AttributeError: foo It seems to be calling __getattribute__ as it should, but then it falls back on __getattr__ even though the docs specifically say it shouldn't. ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 11:43 Message: Logged In: YES user_id=593130 John E: A general title like 'Documentation Error?' discourages attention from people with the specialized knowledge needed to answer such a question. I have taken the liberty of trying to add '__getattribute__'. We'll see if the edit works when I, not the OP, submits it. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 11:33 Message: Logged In: YES user_id=593130 If the default __getattribute__ explicitly calls __getattr__ (but I don't know which source file to check), then the second sentence above *would* make some sense. Guido (or deputy): what is your design intention? Note: if the second sentence is kept, replacing 'it' with 'the latter' would make it clearer. I first read 'it' as referring to __getattribute__. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-24 05:08 Message: Logged In: YES user_id=4771 I'll wait for an "authorized" confirmation, but so far I think that the current implementation is really how it is supposed to work. The method 'object.__getattribute__' must be there, given that it is a common technique to use it directly in overridden __getattribute__ implementations. As a consequence, __getattribute__ cannot completely shadow __getattr__, or __getattr__ would never be called. ---------------------------------------------------------------------- Comment By: John Eikenberry (zhar) Date: 2005-05-23 14:43 Message: Logged In: YES user_id=322022 Please specify in the documentation whether this is how it is supposed to work or whether this is a side-effect of the implementation. To make explicit if you can write code relying on this 'feature' and not have it break at some point. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-23 10:28 Message: Logged In: YES user_id=4771 Indeed, the logic in typeobject.c is to call __getattribute__ and fall back on __getattr__ if the former raised an AttributeError. This is necessary because all objects have a __getattribute__, actually, as there is one in the 'object' base class. This let me think that the error is really in the documentation, which should mention this logic. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&group_id=5470 From noreply at sourceforge.net Thu May 26 17:48:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 08:48:19 -0700 Subject: [ python-Feature Requests-1207613 ] Bottom Scroll Bar Message-ID: Feature Requests item #1207613, was opened at 2005-05-24 04:08 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1207613&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Mike Foord (mjfoord) Assigned to: Kurt B. Kaiser (kbk) Summary: Bottom Scroll Bar Initial Comment: IDLE comes without a horizontal (bottom) scroll bar. In general this is preferable, but there are times when it's a nuisance. It would be nice to have an option (easily accessible) to switch this on. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-05-26 10:48 Message: Logged In: YES user_id=149084 IDLE is intended to present a simple interface to beginners and to encourage good style. I believe that GvR made a deliberate decision not to have a horiz scroll bar to discourage lines longer that 80 char. If you want to code a patch, I'd accept it. However, the config switch should be in config-main.def only, and the selection should not appear on the Options dialog. That way an experienced user could set it in .idlerc/config-main.cfg ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1207613&group_id=5470 From noreply at sourceforge.net Thu May 26 17:52:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 08:52:09 -0700 Subject: [ python-Bugs-1204734 ] __getattribute__ documentation error? Message-ID: Bugs item #1204734, was opened at 2005-05-18 22:21 Message generated for change (Comment added) made by zhar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&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: John Eikenberry (zhar) Assigned to: Guido van Rossum (gvanrossum) Summary: __getattribute__ documentation error? Initial Comment: >From http://www.python.org/dev/doc/devel/ref/new-style-attribute-access.html "Called unconditionally to implement attribute accesses for instances of the class. If the class also defines __getattr__, it will never be called (unless called explicitly)." But I'm not seeing this behaviour in python-2.3.5 and python-2.4.1 on Linux. class A(object): def __getattr__(self,key): print '__getattr__',key raise AttributeError,key def __getattribute__(self,key): print '__getattribute__',key raise AttributeError,key a = A() a.foo $ python test.py __getattribute__ foo __getattr__ foo Traceback (most recent call last): File "test.py", line 14, in ? a.foo File "test.py", line 7, in __getattr__ raise AttributeError(key) AttributeError: foo It seems to be calling __getattribute__ as it should, but then it falls back on __getattr__ even though the docs specifically say it shouldn't. ---------------------------------------------------------------------- >Comment By: John Eikenberry (zhar) Date: 2005-05-26 08:52 Message: Logged In: YES user_id=322022 Terry, I started with a much longer subject but decided I didn't want to overload it to much. Guess I went to far the other way. I'll try to strike a better balance next time. Thanks. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 08:43 Message: Logged In: YES user_id=593130 John E: A general title like 'Documentation Error?' discourages attention from people with the specialized knowledge needed to answer such a question. I have taken the liberty of trying to add '__getattribute__'. We'll see if the edit works when I, not the OP, submits it. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 08:33 Message: Logged In: YES user_id=593130 If the default __getattribute__ explicitly calls __getattr__ (but I don't know which source file to check), then the second sentence above *would* make some sense. Guido (or deputy): what is your design intention? Note: if the second sentence is kept, replacing 'it' with 'the latter' would make it clearer. I first read 'it' as referring to __getattribute__. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-24 02:08 Message: Logged In: YES user_id=4771 I'll wait for an "authorized" confirmation, but so far I think that the current implementation is really how it is supposed to work. The method 'object.__getattribute__' must be there, given that it is a common technique to use it directly in overridden __getattribute__ implementations. As a consequence, __getattribute__ cannot completely shadow __getattr__, or __getattr__ would never be called. ---------------------------------------------------------------------- Comment By: John Eikenberry (zhar) Date: 2005-05-23 11:43 Message: Logged In: YES user_id=322022 Please specify in the documentation whether this is how it is supposed to work or whether this is a side-effect of the implementation. To make explicit if you can write code relying on this 'feature' and not have it break at some point. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-23 07:28 Message: Logged In: YES user_id=4771 Indeed, the logic in typeobject.c is to call __getattribute__ and fall back on __getattr__ if the former raised an AttributeError. This is necessary because all objects have a __getattribute__, actually, as there is one in the 'object' base class. This let me think that the error is really in the documentation, which should mention this logic. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&group_id=5470 From noreply at sourceforge.net Thu May 26 17:59:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 08:59:02 -0700 Subject: [ python-Feature Requests-1207592 ] Clipboard Cleared on Close Message-ID: Feature Requests item #1207592, was opened at 2005-05-24 03:34 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1207592&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Mike Foord (mjfoord) Assigned to: Kurt B. Kaiser (kbk) Summary: Clipboard Cleared on Close Initial Comment: When you close IDLE (under windows at least) any clipboard selection is cleared. This is non-standard behaviour. I often open a script with IDLE in order to copy something, select and copy it and close IDLE. When I come to paste it in another window - the clipboard has been cleared. Most other programs leave the clipboard contents intact even after closing. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-05-26 10:59 Message: Logged In: YES user_id=149084 I believe this is a Tcl/Tk issue, outside of Python. Sorry. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-26 02:02 Message: Logged In: YES user_id=80475 I've also bumped into this. It's annoying. Am not sure whether it is a Python issue, IDLE issue, or Tkinter issue. If the latter, there is likely nothing that can be done about it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1207592&group_id=5470 From noreply at sourceforge.net Thu May 26 17:59:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 08:59:16 -0700 Subject: [ python-Bugs-1205736 ] wrong location for math lib with --prefix Message-ID: Bugs item #1205736, was opened at 2005-05-20 11:21 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205736&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: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Richter (thorfdbg) Assigned to: Nobody/Anonymous (nobody) Summary: wrong location for math lib with --prefix Initial Comment: If python2.3 or 2.4 get configured with --prefix, the math libraries (and other binary libraries) are check for in the wrong location. Specifically, the prefix will be will be used twice, giving the wrong path for the binary object. How to reproduce: Configure python with ./configure --prefix=/foo ;or whatever, make make install This will place libraries etc. correctly in /foo/lib/python2.4. Afterwards, setup pythonpath accordingly export PYTHONPATH="/foo/lib/python2.4:/foo/lib/python2.4/site-packages" If you start then python, try >> import math The result will be that pyhon will not find the math module. Debugging with strace reveals that python checks for binary libraries now in /foo/lib/python2.4/lib/python2.4 instead of /foo/lib/python2.4 Setting a softlink in the lib directory works around this and brings python back to working. ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 11:59 Message: Logged In: YES user_id=593130 What *specific* system or systems did this occur with? If this were general to all *nix type systems, I would expect it to have already been caught and fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205736&group_id=5470 From noreply at sourceforge.net Thu May 26 18:18:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 09:18:09 -0700 Subject: [ python-Bugs-1204734 ] __getattribute__ documentation error? Message-ID: Bugs item #1204734, was opened at 2005-05-19 01:21 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&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: John Eikenberry (zhar) >Assigned to: Nobody/Anonymous (nobody) Summary: __getattribute__ documentation error? Initial Comment: >From http://www.python.org/dev/doc/devel/ref/new-style-attribute-access.html "Called unconditionally to implement attribute accesses for instances of the class. If the class also defines __getattr__, it will never be called (unless called explicitly)." But I'm not seeing this behaviour in python-2.3.5 and python-2.4.1 on Linux. class A(object): def __getattr__(self,key): print '__getattr__',key raise AttributeError,key def __getattribute__(self,key): print '__getattribute__',key raise AttributeError,key a = A() a.foo $ python test.py __getattribute__ foo __getattr__ foo Traceback (most recent call last): File "test.py", line 14, in ? a.foo File "test.py", line 7, in __getattr__ raise AttributeError(key) AttributeError: foo It seems to be calling __getattribute__ as it should, but then it falls back on __getattr__ even though the docs specifically say it shouldn't. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-05-26 12:18 Message: Logged In: YES user_id=6380 The implementation works as expected. The documentation is flawed. ---------------------------------------------------------------------- Comment By: John Eikenberry (zhar) Date: 2005-05-26 11:52 Message: Logged In: YES user_id=322022 Terry, I started with a much longer subject but decided I didn't want to overload it to much. Guess I went to far the other way. I'll try to strike a better balance next time. Thanks. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 11:43 Message: Logged In: YES user_id=593130 John E: A general title like 'Documentation Error?' discourages attention from people with the specialized knowledge needed to answer such a question. I have taken the liberty of trying to add '__getattribute__'. We'll see if the edit works when I, not the OP, submits it. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 11:33 Message: Logged In: YES user_id=593130 If the default __getattribute__ explicitly calls __getattr__ (but I don't know which source file to check), then the second sentence above *would* make some sense. Guido (or deputy): what is your design intention? Note: if the second sentence is kept, replacing 'it' with 'the latter' would make it clearer. I first read 'it' as referring to __getattribute__. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-24 05:08 Message: Logged In: YES user_id=4771 I'll wait for an "authorized" confirmation, but so far I think that the current implementation is really how it is supposed to work. The method 'object.__getattribute__' must be there, given that it is a common technique to use it directly in overridden __getattribute__ implementations. As a consequence, __getattribute__ cannot completely shadow __getattr__, or __getattr__ would never be called. ---------------------------------------------------------------------- Comment By: John Eikenberry (zhar) Date: 2005-05-23 14:43 Message: Logged In: YES user_id=322022 Please specify in the documentation whether this is how it is supposed to work or whether this is a side-effect of the implementation. To make explicit if you can write code relying on this 'feature' and not have it break at some point. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-23 10:28 Message: Logged In: YES user_id=4771 Indeed, the logic in typeobject.c is to call __getattribute__ and fall back on __getattr__ if the former raised an AttributeError. This is necessary because all objects have a __getattribute__, actually, as there is one in the 'object' base class. This let me think that the error is really in the documentation, which should mention this logic. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&group_id=5470 From noreply at sourceforge.net Thu May 26 18:20:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 09:20:04 -0700 Subject: [ python-Feature Requests-1175686 ] add "reload" function Message-ID: Feature Requests item #1175686, was opened at 2005-04-03 03:48 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1175686&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: 3 Submitted By: paul rubin (phr) >Assigned to: Nobody/Anonymous (nobody) Summary: add "reload" function Initial Comment: The file menu in Editor windows could benefit from a "reload" function that re-reads the file from disc and loads it into the editor, replacing what's currently in the editor. That's useful for those of us who like to edit with Emacs in another window while running the code under Idle. To get really fancy, it might be cool to optionally display a diff between the in-editor version and the on-disk version allowing merging changes, but that's maybe over the top. Other editors usually do have commands like this, e.g.M-x Revert-file in Emacs or ":e!" in vi. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-05-26 11:20 Message: Logged In: YES user_id=149084 I like the Revert idea better. It probably should be above "Close" in the File menu. Otherwise, if it's next to "Recent Files", someday someone is going to select it by mistake and be really ticked. I think the suggestion violates KISS. Over time, it's ideas like this that cause creeping features and a boated interface. But again, why not use IDLE instead of emacs to edit Python code? One button Save/Run! What is the killer feature that's missing from IDLE? That would be the real thing to work on. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-04-18 21:55 Message: Logged In: YES user_id=149084 Why do you use Emacs instead of IDLE? (I use emacs myself sometimes, but I'm curious what your reasons are these days.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-18 17:48 Message: Logged In: YES user_id=80475 If added, it should definitely be called "revert" instead of "reload". The latter already has a specific meaning in Python that relates to imports. The former seems to be standard terminology across a number of editing tools from emacs to photoshop. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1175686&group_id=5470 From noreply at sourceforge.net Thu May 26 18:23:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 09:23:40 -0700 Subject: [ python-Bugs-1206232 ] IDLE 1.0.5 (Python 2.3.5) crashes under Windows Message-ID: Bugs item #1206232, was opened at 2005-05-21 13:46 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1206232&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Torsten Bronger (bronger) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE 1.0.5 (Python 2.3.5) crashes under Windows Initial Comment: Using Win2k or XP, IDLE 1.0.5 and Python 2.3.5, the attached source produces a fatal error and IDLE and the Python Shell are closed. In order to reproduce the issue, start IDLE, open the attached file and press "F5". ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 12:23 Message: Logged In: YES user_id=593130 Does this still happen with 2.4.1 and the corresponding IDLE? Besides numerous bug fixes, I believe 2.4 changed the interpretation of unsigned hex constants from sometimes negative to always positive. From a glance at your file, this seems likely relevant. If you also find a bug with current Python/IDLE, please reduce your file to the minimum necessary to produce the bug. Also include the error message and traceback you get. (As far as I know, there is currently no prospect of a 2.3.6, but there should at least be a 2.4.2) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1206232&group_id=5470 From noreply at sourceforge.net Thu May 26 18:37:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 09:37:17 -0700 Subject: [ python-Bugs-1207379 ] class property fset not working Message-ID: Bugs item #1207379, was opened at 2005-05-23 18:02 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&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: Master_Jaf (master_jaf) Assigned to: Nobody/Anonymous (nobody) Summary: class property fset not working Initial Comment: Classes which are not instantiated from 'object', containing properties, are not working as expected. The GET method is working but not the SET method. Tested with python 2.4.1 und 2.3.5. See sample code file. ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 12:37 Message: Logged In: YES user_id=593130 For people who learned Python with old-style classes, it is 'obvious' that properties are a new addition that came with and work with new-style classes. Can you suggest specific places in the docs where clarification could be made? Or should be close this? (I suspect that setting is more complicated than getting but would not have expected even the get method to work.) ---------------------------------------------------------------------- Comment By: Master_Jaf (master_jaf) Date: 2005-05-24 08:27 Message: Logged In: YES user_id=1140154 After reading some more documentation I've found at Python Tutorial "D. Glossary" more hints. <cite> Any class that inherits from object. This includes all built-in types like list and dict. Only new-style classes can use Python's newer, versatile features like __slots__, descriptors, properties, __getattribute__(), class methods, and static methods. </cite> Fine. OK, understood.. I'm tending to agree with mwh's opinion, that this is a documentation bug, although I don't fully understand why the GET descriptor is working but unlikly not the SET descriptor. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-24 03:58 Message: Logged In: YES user_id=6656 At the very limit, this is a documentation bug. Why did you think properties could be attached to old-style classes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&group_id=5470 From noreply at sourceforge.net Thu May 26 19:42:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 10:42:00 -0700 Subject: [ python-Bugs-1204734 ] __getattribute__ documentation error? Message-ID: Bugs item #1204734, was opened at 2005-05-19 01:21 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&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: John Eikenberry (zhar) Assigned to: Nobody/Anonymous (nobody) Summary: __getattribute__ documentation error? Initial Comment: >From http://www.python.org/dev/doc/devel/ref/new-style-attribute-access.html "Called unconditionally to implement attribute accesses for instances of the class. If the class also defines __getattr__, it will never be called (unless called explicitly)." But I'm not seeing this behaviour in python-2.3.5 and python-2.4.1 on Linux. class A(object): def __getattr__(self,key): print '__getattr__',key raise AttributeError,key def __getattribute__(self,key): print '__getattribute__',key raise AttributeError,key a = A() a.foo $ python test.py __getattribute__ foo __getattr__ foo Traceback (most recent call last): File "test.py", line 14, in ? a.foo File "test.py", line 7, in __getattr__ raise AttributeError(key) AttributeError: foo It seems to be calling __getattribute__ as it should, but then it falls back on __getattr__ even though the docs specifically say it shouldn't. ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 13:42 Message: Logged In: YES user_id=593130 If I understand correctly, this revision of the consequent of the second sentence (after ',') matches the implementation. [If the class also defines __getattr__, ] the latter will not be called unless __getattribute__ either calls it explicitly or raises an AttributeError. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-05-26 12:18 Message: Logged In: YES user_id=6380 The implementation works as expected. The documentation is flawed. ---------------------------------------------------------------------- Comment By: John Eikenberry (zhar) Date: 2005-05-26 11:52 Message: Logged In: YES user_id=322022 Terry, I started with a much longer subject but decided I didn't want to overload it to much. Guess I went to far the other way. I'll try to strike a better balance next time. Thanks. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 11:43 Message: Logged In: YES user_id=593130 John E: A general title like 'Documentation Error?' discourages attention from people with the specialized knowledge needed to answer such a question. I have taken the liberty of trying to add '__getattribute__'. We'll see if the edit works when I, not the OP, submits it. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 11:33 Message: Logged In: YES user_id=593130 If the default __getattribute__ explicitly calls __getattr__ (but I don't know which source file to check), then the second sentence above *would* make some sense. Guido (or deputy): what is your design intention? Note: if the second sentence is kept, replacing 'it' with 'the latter' would make it clearer. I first read 'it' as referring to __getattribute__. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-24 05:08 Message: Logged In: YES user_id=4771 I'll wait for an "authorized" confirmation, but so far I think that the current implementation is really how it is supposed to work. The method 'object.__getattribute__' must be there, given that it is a common technique to use it directly in overridden __getattribute__ implementations. As a consequence, __getattribute__ cannot completely shadow __getattr__, or __getattr__ would never be called. ---------------------------------------------------------------------- Comment By: John Eikenberry (zhar) Date: 2005-05-23 14:43 Message: Logged In: YES user_id=322022 Please specify in the documentation whether this is how it is supposed to work or whether this is a side-effect of the implementation. To make explicit if you can write code relying on this 'feature' and not have it break at some point. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-23 10:28 Message: Logged In: YES user_id=4771 Indeed, the logic in typeobject.c is to call __getattribute__ and fall back on __getattr__ if the former raised an AttributeError. This is necessary because all objects have a __getattribute__, actually, as there is one in the 'object' base class. This let me think that the error is really in the documentation, which should mention this logic. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&group_id=5470 From noreply at sourceforge.net Thu May 26 19:58:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 10:58:34 -0700 Subject: [ python-Bugs-1209324 ] longs should be pickled in hexadecimal Message-ID: Bugs item #1209324, was opened at 2005-05-26 17:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209324&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: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Johansson (fredrik_j) Assigned to: Nobody/Anonymous (nobody) Summary: longs should be pickled in hexadecimal Initial Comment: Longs are currently pickled to their decimal representation. However, converting a very large number represented in a binary base (used by Python longs) to decimal is inefficient. For example, the operation pickle.dumps(123**100001) takes 50 seconds on my computer. The hexadecimal representation of the same number, via hex(), can be computed in an instant. The hexadecimal representation also has the benefit of being more concise. I therefore suggest that the pickle format is changed so that pickled longs are represented in hexadecimal. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209324&group_id=5470 From noreply at sourceforge.net Thu May 26 20:09:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 11:09:27 -0700 Subject: [ python-Bugs-1199808 ] installation problem with python 2.4.1 on Win2k system Message-ID: Bugs item #1199808, was opened at 2005-05-11 14:50 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199808&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: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: mmkobayashi (mmkobayashi) Assigned to: Nobody/Anonymous (nobody) Summary: installation problem with python 2.4.1 on Win2k system Initial Comment: After several attempts to install python2.4.1 on a win2k systems with doing all windows updates, we have been unable to install python2.4.1 on this system. We have attached an error logfile. The main thing that happens is that the install proceeds as normal but at some point the install decides that something has gone wrong and uninstalls itself. Any help in this matter would be greatly appreciated. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-05-26 20:09 Message: Logged In: YES user_id=21627 Please try to zip the logfile. If it is then still too large, please put it on some webserver under your control, and post the URL here. If you have no access to a webserver, please mail it to martin.vonloewis at hpi.uni-potsdam.de ---------------------------------------------------------------------- Comment By: mmkobayashi (mmkobayashi) Date: 2005-05-26 09:17 Message: Logged In: YES user_id=1273313 Yes, the logfile is indeed manually truncated. I could not upload the unmodified file which is greater than 2 Mbytes Any suggestions how I can get the log file to you. I was not using a SUBSTed drive. Python 2.4.1 installed fine on a similarly configured machine but can not get past this bug. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-20 23:35 Message: Logged In: YES user_id=21627 The log file appears to be manually truncated. Can you please provide the full log file? Are you by any chance running the MSI file from a SUBSTed drive? ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-19 03:01 Message: Logged In: YES user_id=593130 You might also check out http://python.org/sf/1199947 ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-19 02:48 Message: Logged In: YES user_id=593130 Help questions should better be directed to comp.lang.python == python mailing list == gmane.comp.python.general. The answers you get should help determine whether there is a bug in the install file distributed by PSF that should be reported here. Given that the install appeared to go ok until it tried to remove the existing files, I wonder whether there is a process running in the background that is using the existing install. That issue has been discussed on the python group recently. ---------------------------------------------------------------------- Comment By: mmkobayashi (mmkobayashi) Date: 2005-05-12 07:53 Message: Logged In: YES user_id=1273313 add file ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199808&group_id=5470 From noreply at sourceforge.net Thu May 26 20:17:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 11:17:54 -0700 Subject: [ python-Bugs-1209324 ] longs should be pickled in hexadecimal Message-ID: Bugs item #1209324, was opened at 2005-05-26 12:58 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209324&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: Python Library Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Fredrik Johansson (fredrik_j) Assigned to: Nobody/Anonymous (nobody) Summary: longs should be pickled in hexadecimal Initial Comment: Longs are currently pickled to their decimal representation. However, converting a very large number represented in a binary base (used by Python longs) to decimal is inefficient. For example, the operation pickle.dumps(123**100001) takes 50 seconds on my computer. The hexadecimal representation of the same number, via hex(), can be computed in an instant. The hexadecimal representation also has the benefit of being more concise. I therefore suggest that the pickle format is changed so that pickled longs are represented in hexadecimal. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-26 13:17 Message: Logged In: YES user_id=80475 Rather than introduce a backwards incompatible change, just use binary pickles: pickle.dumps(123**100001, 2). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209324&group_id=5470 From noreply at sourceforge.net Thu May 26 20:57:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 11:57:05 -0700 Subject: [ python-Bugs-1209324 ] longs should be pickled in hexadecimal Message-ID: Bugs item #1209324, was opened at 2005-05-26 13:58 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209324&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: Python Library Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Fredrik Johansson (fredrik_j) Assigned to: Nobody/Anonymous (nobody) Summary: longs should be pickled in hexadecimal Initial Comment: Longs are currently pickled to their decimal representation. However, converting a very large number represented in a binary base (used by Python longs) to decimal is inefficient. For example, the operation pickle.dumps(123**100001) takes 50 seconds on my computer. The hexadecimal representation of the same number, via hex(), can be computed in an instant. The hexadecimal representation also has the benefit of being more concise. I therefore suggest that the pickle format is changed so that pickled longs are represented in hexadecimal. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-05-26 14:57 Message: Logged In: YES user_id=31435 More precisely, use pickle protocol 2 (or higher, although 2 is as high is it goes so far). In pickle protocol 1 (which used to be called "binary"), and in protocol 0 (which used to be called "text") pickling and unpickling longs were still quadratic-time operations. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-26 14:17 Message: Logged In: YES user_id=80475 Rather than introduce a backwards incompatible change, just use binary pickles: pickle.dumps(123**100001, 2). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209324&group_id=5470 From noreply at sourceforge.net Thu May 26 20:59:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 11:59:28 -0700 Subject: [ python-Bugs-1207379 ] class property fset not working Message-ID: Bugs item #1207379, was opened at 2005-05-24 00:02 Message generated for change (Comment added) made by master_jaf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&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: Master_Jaf (master_jaf) Assigned to: Nobody/Anonymous (nobody) Summary: class property fset not working Initial Comment: Classes which are not instantiated from 'object', containing properties, are not working as expected. The GET method is working but not the SET method. Tested with python 2.4.1 und 2.3.5. See sample code file. ---------------------------------------------------------------------- >Comment By: Master_Jaf (master_jaf) Date: 2005-05-26 20:59 Message: Logged In: YES user_id=1140154 >From my point of view (I'm just learning Python) there is only a simple difference between old and new style classes, just the (object) while defining a class. For sure, we can close this. My questions were answered :-) So my suggestions for adding info to the documentation: "Python Tutorial": Chap. 9.3., ex. With Python 2.2 new style classes were introduced. These new style classes are inherited from 'object' base class and supporting newer features like properties, slots etc.. It is recommended to use new style classes. "Python Library Reference": Chap. 2.1 Built-in Functions, ex. property([fget[, fset[, fdel[, doc]]]]) [....] New in Python 2.2. Properties only can applied to new style classes. See also "D. Glossary" -> new style classes for more details. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 18:37 Message: Logged In: YES user_id=593130 For people who learned Python with old-style classes, it is 'obvious' that properties are a new addition that came with and work with new-style classes. Can you suggest specific places in the docs where clarification could be made? Or should be close this? (I suspect that setting is more complicated than getting but would not have expected even the get method to work.) ---------------------------------------------------------------------- Comment By: Master_Jaf (master_jaf) Date: 2005-05-24 14:27 Message: Logged In: YES user_id=1140154 After reading some more documentation I've found at Python Tutorial "D. Glossary" more hints. <cite> Any class that inherits from object. This includes all built-in types like list and dict. Only new-style classes can use Python's newer, versatile features like __slots__, descriptors, properties, __getattribute__(), class methods, and static methods. </cite> Fine. OK, understood.. I'm tending to agree with mwh's opinion, that this is a documentation bug, although I don't fully understand why the GET descriptor is working but unlikly not the SET descriptor. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-24 09:58 Message: Logged In: YES user_id=6656 At the very limit, this is a documentation bug. Why did you think properties could be attached to old-style classes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&group_id=5470 From noreply at sourceforge.net Thu May 26 21:47:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 12:47:26 -0700 Subject: [ python-Bugs-1209411 ] divmod documentation shd reference // not / Message-ID: Bugs item #1209411, was opened at 2005-05-26 14:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209411&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: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: divmod documentation shd reference // not / Initial Comment: At http://docs.python.org/lib/typesnumeric.html we find: divmod(x, y) the pair (x / y, x % y) (3)(4) This should be: divmod(x, y) the pair (x // y, x % y) (3)(4) At http://docs.python.org/lib/built-in-funcs.html#built-in-funcs we find: divmod( a, b) .... For plain and long integers, the result is the same as (a / b, a % b). This should be: .... For plain and long integers, the result is the same as (a // b, a % b). Alternatively there could be a reference to "from __future__ import division" but the proposed change is cleaner and will last. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209411&group_id=5470 From noreply at sourceforge.net Thu May 26 22:20:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 13:20:46 -0700 Subject: [ python-Bugs-1206232 ] IDLE 1.0.5 (Python 2.3.5) crashes under Windows Message-ID: Bugs item #1206232, was opened at 2005-05-21 19:46 Message generated for change (Comment added) made by bronger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1206232&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Torsten Bronger (bronger) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE 1.0.5 (Python 2.3.5) crashes under Windows Initial Comment: Using Win2k or XP, IDLE 1.0.5 and Python 2.3.5, the attached source produces a fatal error and IDLE and the Python Shell are closed. In order to reproduce the issue, start IDLE, open the attached file and press "F5". ---------------------------------------------------------------------- >Comment By: Torsten Bronger (bronger) Date: 2005-05-26 22:20 Message: Logged In: YES user_id=442234 No, I had tested it also with 2.4.x and had no problem. I didn't know whether there would be another 2.3.x, so I submitted it. In case the 2.3 branch is closed, do the same with this bug. ;) ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 18:23 Message: Logged In: YES user_id=593130 Does this still happen with 2.4.1 and the corresponding IDLE? Besides numerous bug fixes, I believe 2.4 changed the interpretation of unsigned hex constants from sometimes negative to always positive. From a glance at your file, this seems likely relevant. If you also find a bug with current Python/IDLE, please reduce your file to the minimum necessary to produce the bug. Also include the error message and traceback you get. (As far as I know, there is currently no prospect of a 2.3.6, but there should at least be a 2.4.2) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1206232&group_id=5470 From noreply at sourceforge.net Thu May 26 22:26:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 13:26:04 -0700 Subject: [ python-Bugs-1206232 ] IDLE 1.0.5 (Python 2.3.5) crashes under Windows Message-ID: Bugs item #1206232, was opened at 2005-05-21 19:46 Message generated for change (Comment added) made by bronger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1206232&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Torsten Bronger (bronger) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE 1.0.5 (Python 2.3.5) crashes under Windows Initial Comment: Using Win2k or XP, IDLE 1.0.5 and Python 2.3.5, the attached source produces a fatal error and IDLE and the Python Shell are closed. In order to reproduce the issue, start IDLE, open the attached file and press "F5". ---------------------------------------------------------------------- >Comment By: Torsten Bronger (bronger) Date: 2005-05-26 22:26 Message: Logged In: YES user_id=442234 Oops, I think I should add my further findings nevertheless: It was indeed the hex constants and their implicit conversion to signed values. An attached "L" solved the problem. Could it be that the warning messages cause possible errors with IDLE on Windows? With Linux, I see those "future warnings" on the console when I try to import my file. With IDLE, these things are supressed, of course. 2.4 doesn't show warnings, too. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2005-05-26 22:20 Message: Logged In: YES user_id=442234 No, I had tested it also with 2.4.x and had no problem. I didn't know whether there would be another 2.3.x, so I submitted it. In case the 2.3 branch is closed, do the same with this bug. ;) ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 18:23 Message: Logged In: YES user_id=593130 Does this still happen with 2.4.1 and the corresponding IDLE? Besides numerous bug fixes, I believe 2.4 changed the interpretation of unsigned hex constants from sometimes negative to always positive. From a glance at your file, this seems likely relevant. If you also find a bug with current Python/IDLE, please reduce your file to the minimum necessary to produce the bug. Also include the error message and traceback you get. (As far as I know, there is currently no prospect of a 2.3.6, but there should at least be a 2.4.2) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1206232&group_id=5470 From noreply at sourceforge.net Thu May 26 22:45:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 13:45:11 -0700 Subject: [ python-Bugs-1209447 ] os.path.join() fails if 2nd arg is a UNC path Message-ID: Bugs item #1209447, was opened at 2005-05-26 20:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209447&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.join() fails if 2nd arg is a UNC path Initial Comment: os.path.join('c:', r'\server\share') returns c:\server\share rather than \server\share. Interestingly os.path.join('c:a', r'\server\share') returns r'\server\share'. IMHO, r'\server\share' should be returned in all cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209447&group_id=5470 From noreply at sourceforge.net Fri May 27 02:33:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 17:33:25 -0700 Subject: [ python-Bugs-1209560 ] spurious blank page in dist.pdf Message-ID: Bugs item #1209560, was opened at 2005-05-27 00:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209560&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: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: spurious blank page in dist.pdf Initial Comment: In the US Letter sized version of dist.pdf in the current download zip (Python 2.4.1), the third page of the file (the one immediately preceding the table of contents, which starts with roman numeral "i") is blank. That means that page "i" of the table of contents, and page "1" of the actual document, begin on even-numbered pages in the file. This is bad because if you print on a duplex printer, page 1 comes out on the back of page ii, page 3 comes out on the back of page 2, etc. You want odd numbered pages to be on the front and even numbered pages to be on the back, so page 2 should be on the back of page 1, etc. This is probably a problem with the latex extension that made the pdf file and so it probably affects the other pdfs as well as dist.pdf, but that's the only one I printed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209560&group_id=5470 From noreply at sourceforge.net Fri May 27 02:37:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 17:37:13 -0700 Subject: [ python-Feature Requests-1209562 ] add single html files Message-ID: Feature Requests item #1209562, was opened at 2005-05-27 00:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1209562&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: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: add single html files Initial Comment: It would be good if the docs directory on python.org included a "view entire document as one big html page" for each document. If I want to read through a document from beginning to end, it's a big pain to have to keep clicking around at the end of each page, especially if I'm looking at most pages for just a second or so. For the biggest documents (Python library) maybe there could be several sections. Right now the only way to see everything at once is with the PDF, which is much more hassle than browsing html. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1209562&group_id=5470 From noreply at sourceforge.net Fri May 27 02:39:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 17:39:30 -0700 Subject: [ python-Feature Requests-1207592 ] Clipboard Cleared on Close Message-ID: Feature Requests item #1207592, was opened at 2005-05-24 03:34 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1207592&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Mike Foord (mjfoord) Assigned to: Kurt B. Kaiser (kbk) Summary: Clipboard Cleared on Close Initial Comment: When you close IDLE (under windows at least) any clipboard selection is cleared. This is non-standard behaviour. I often open a script with IDLE in order to copy something, select and copy it and close IDLE. When I come to paste it in another window - the clipboard has been cleared. Most other programs leave the clipboard contents intact even after closing. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-05-26 19:39 Message: Logged In: YES user_id=2772 Yes, this is a Tcl/Tk issue. I believe that it will be fixed with the release of Tk 8.5, though I don't know when this release will take place. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-05-26 10:59 Message: Logged In: YES user_id=149084 I believe this is a Tcl/Tk issue, outside of Python. Sorry. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-26 02:02 Message: Logged In: YES user_id=80475 I've also bumped into this. It's annoying. Am not sure whether it is a Python issue, IDLE issue, or Tkinter issue. If the latter, there is likely nothing that can be done about it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1207592&group_id=5470 From noreply at sourceforge.net Fri May 27 09:36:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 May 2005 00:36:11 -0700 Subject: [ python-Feature Requests-1209664 ] calling it revert is fine with me Message-ID: Feature Requests item #1209664, was opened at 2005-05-27 07:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1209664&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: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: calling it revert is fine with me Initial Comment: Calling it revert is fine with me. I don't want to get into an editor war thing, let's just say emacs is what I've always used; it's not a matter of any single "killer feature", it's a highly integrated system and I do everything in it (shell, news reader, email, syntax driven editing for N different languages, etc). I do use IDLE sometimes but comparing IDLE to Emacs is almost like comparing it to Eclipse. They're just light years apart. Btw re editor wars, I'm reminded of the T-shirt with a kid asking "Why are we running from the police, daddy?". The dad answers "Because we use emacs, son. They use vi". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1209664&group_id=5470 From noreply at sourceforge.net Fri May 27 09:49:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 May 2005 00:49:04 -0700 Subject: [ python-Bugs-1209671 ] dict.popitem documentation should mention empty dict case Message-ID: Bugs item #1209671, was opened at 2005-05-27 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=105470&aid=1209671&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: William Chang (misterwilliam) Assigned to: Nobody/Anonymous (nobody) Summary: dict.popitem documentation should mention empty dict case Initial Comment: Currently the documentation in the Python Library Reference entry for Mapping Types does not mention what happens when dict.popitem() is called on an empty mapping. I think that the documentation should mention that a KeyError exception is raised. (At least this is what happens when I try it in the official Python 2.4 release with a dictionary.) If this omission was intentional to give room for future implementors of python/mappings I feel that this should at least be mentioned in the documentation to remind programmers this behavior is not specified. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209671&group_id=5470 From noreply at sourceforge.net Fri May 27 09:51:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 May 2005 00:51:05 -0700 Subject: [ python-Bugs-1209671 ] dict.popitem documentation should mention empty dict case Message-ID: Bugs item #1209671, was opened at 2005-05-27 00:49 Message generated for change (Comment added) made by misterwilliam You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209671&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: William Chang (misterwilliam) Assigned to: Nobody/Anonymous (nobody) Summary: dict.popitem documentation should mention empty dict case Initial Comment: Currently the documentation in the Python Library Reference entry for Mapping Types does not mention what happens when dict.popitem() is called on an empty mapping. I think that the documentation should mention that a KeyError exception is raised. (At least this is what happens when I try it in the official Python 2.4 release with a dictionary.) If this omission was intentional to give room for future implementors of python/mappings I feel that this should at least be mentioned in the documentation to remind programmers this behavior is not specified. ---------------------------------------------------------------------- >Comment By: William Chang (misterwilliam) Date: 2005-05-27 00:51 Message: Logged In: YES user_id=1286263 I wasn't being very precise when I substituted dict for mapping types in the summary. I'm so used to thinking of them interchangeablely. I suppose it might matter though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209671&group_id=5470 From noreply at sourceforge.net Fri May 27 11:35:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 May 2005 02:35:58 -0700 Subject: [ python-Bugs-1185883 ] PyObject_Realloc bug in obmalloc.c Message-ID: Bugs item #1185883, was opened at 2005-04-19 13:07 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1185883&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: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kristj?n Valur (krisvale) Assigned to: Tim Peters (tim_one) Summary: PyObject_Realloc bug in obmalloc.c Initial Comment: obmalloc.c:835 If the previous block was not handled by obmalloc, and the realloc is for growing the block, this memcpy may cross a page boundary and cause a segmentation fault. This scenario can happen if a previous allocation failed to successfully allocate from the obmalloc pools, due to memory starvation or other reasons, but was successfully allocated by the c runtime. The solution is to query the actual size of the allocated block, and copy only so much memory. Most modern platforms provide size query functions complementing the malloc()/free() calls. on Windows, this is the _msize () function. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-05-27 10:35 Message: Logged In: YES user_id=6656 Ping! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-04-19 16:34 Message: Logged In: YES user_id=31435 krisvale: Thank you for the very clear explanation. Even I understand this now . We won't use _msize here -- Python has to run under dozens of compilers and C libraries, and it's saner to give up on this "optimization" completely than to introduce a rat's nest of #ifdefs here. IOW, I expect the entire "if (nbytes <= SMALL_REQUEST_THRESHOLD)" block will go away, so that the platform realloc() gets called in every case obmalloc doesn't control the incoming block. BTW, note that there's no plan to do another release in the Python 2.3 line. ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2005-04-19 16:22 Message: Logged In: YES user_id=1262199 The platform is windows 2000/2003 server, single threaded C runtime. I have only had the chance to do postmortem debugging on this but it would appear to be as you describe: The following page is not mapped in. Windows doesn?t use the setbrk() method of heap management and doesn?t automatically move the break. Rather they (the multiple heaps) requests pages as required. A malloc may have succeeded from a different page and copying to much from the old block close to the boundary caused an exception _at_ the page boundary. Fyi, old block was 68 bytes at 0x6d85efb8. This block ends at -effc. The new size requested was 108 bytes. Reading 108 bytes from this address caused an exception at address 0x6d85f000. As you know, reading past a malloc block results in undefined behaviour and sometimes this can mean a crash. I have patched python locally to use MIN(nbytes, _msize(p)) in stead and we are about to run the modified version on our server cluster. Nodes were dying quite regularly because of this. I'll let you know if this changes anyting in that aspect. Btw, I work for ccp games, and we are running the MMORPG eve online (www.eveonline.com) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-04-19 16:00 Message: Logged In: YES user_id=31435 mwh: Umm ... I don't understand what the claim is. For example, what HW does Python run on where memcpy segfaults just because the address range crosses a page boundary? If that's what's happening, sounds more like a bug in the platform memcpy. I can memcpy blocks spanning thousands of pages on my box -- and so can you . krisvale: which OS and which C are you using? It is true that this code may try to access a bit of memory that wasn't allocated. If that's at the end of the address space, then I could see a segfault happening. If it is, I doubt there's any portable way to fix it short of PyObject_Realloc never trying to take over small blocks it didn't control to begin with. Then the platform realloc() will segfault instead . ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2005-04-19 15:39 Message: Logged In: YES user_id=1262199 I can only say that I?ve been seeing this happeing with our software. Admittedly it's because we are eating up all memory due to other reasons, but we would like to deal with that with a MemoryError rather than a crash. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-19 15:30 Message: Logged In: YES user_id=6656 Tim, what do you think? This is a pretty unlikely scenario, it seems to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1185883&group_id=5470 From noreply at sourceforge.net Fri May 27 11:36:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 May 2005 02:36:24 -0700 Subject: [ python-Bugs-1122301 ] marshal may crash on truncated input Message-ID: Bugs item #1122301, was opened at 2005-02-14 11:14 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1122301&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Fredrik Lundh (effbot) Summary: marshal may crash on truncated input Initial Comment: marshal doesn't behave well on truncated or otherwise malformed input. here's a short demo script, from a recent comp.lang.python thread: ::: the problem is that the following may or may not reach the "done!" statement, somewhat depending on python version, memory allocator, and what data you pass to dumps. import marshal data = marshal.dumps((1, 2, 3, "hello", 4, 5, 6)) for i in range(len(data), -1, -1): try: print marshal.loads(data[:i]) except EOFError: print "EOFError" except ValueError: print "ValueError" print "done!" (try different data combinations, to see how far you get on your platform...) fixing this should be relatively easy, and should result in a safe unmarshaller (your application will still have to limit the amount of data fed into load/loads, of course). ::: (also note that marshal may raise either EOFError or ValueError exceptions, again somewhat depending on how the file is damaged. a little consistency wouldn't hurt, but I'm not sure if/how this can be fixed...) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-05-27 10:36 Message: Logged In: YES user_id=6656 Ping! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-19 15:58 Message: Logged In: YES user_id=6656 I think the attached fixes this example, and another involving marshalled sets. I spent a while feeding random data to marshal a few days ago and found that the commonest problem was attempting to allocate really huge sequences. Also, the TYPE_STRINGREF is horribly fragile, but I'm hoping Martin's going to fix that (he has a bug filed against him, anyway). Can you test/check it in? My marshal.c has rather a lot of local changes. Also, a test suite entry would be nice... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1122301&group_id=5470 From noreply at sourceforge.net Fri May 27 12:46:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 May 2005 03:46:02 -0700 Subject: [ python-Bugs-1209671 ] dict.popitem documentation should mention empty dict case Message-ID: Bugs item #1209671, was opened at 2005-05-27 02:49 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209671&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: Fixed Priority: 5 Submitted By: William Chang (misterwilliam) Assigned to: Nobody/Anonymous (nobody) Summary: dict.popitem documentation should mention empty dict case Initial Comment: Currently the documentation in the Python Library Reference entry for Mapping Types does not mention what happens when dict.popitem() is called on an empty mapping. I think that the documentation should mention that a KeyError exception is raised. (At least this is what happens when I try it in the official Python 2.4 release with a dictionary.) If this omission was intentional to give room for future implementors of python/mappings I feel that this should at least be mentioned in the documentation to remind programmers this behavior is not specified. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-27 05:46 Message: Logged In: YES user_id=80475 Okay, fixed. Thanks for the report. ---------------------------------------------------------------------- Comment By: William Chang (misterwilliam) Date: 2005-05-27 02:51 Message: Logged In: YES user_id=1286263 I wasn't being very precise when I substituted dict for mapping types in the summary. I'm so used to thinking of them interchangeablely. I suppose it might matter though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209671&group_id=5470 From noreply at sourceforge.net Fri May 27 16:04:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 May 2005 07:04:30 -0700 Subject: [ python-Bugs-1209880 ] doc bug in Lock.acquire Message-ID: Bugs item #1209880, was opened at 2005-05-27 10:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209880&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: Chris Perkins (cperkins) Assigned to: Nobody/Anonymous (nobody) Summary: doc bug in Lock.acquire Initial Comment: The docs for the acquire method in both the thread and threading modules are incorrect. They describe an old (insane) version that returned None when called with no argument. It appears that acquire is now sane, and always returns True or False. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209880&group_id=5470 From noreply at sourceforge.net Fri May 27 18:26:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 May 2005 09:26:46 -0700 Subject: [ python-Bugs-1210001 ] Typo in "Differences from mimelib" Message-ID: Bugs item #1210001, was opened at 2005-05-27 18:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210001&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: Zumi (zumi001) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in "Differences from mimelib" Initial Comment: In the online manual: http://www.python.org/doc/2.4/lib/node577.html "12.2.12 Differences from mimelib" there's a typo: "The methodgetmaintype() was renamed to get_main_type()." Suggestion: a space after the word "method". So something like this: "The method getmaintype() was renamed to get_main_type()." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210001&group_id=5470 From noreply at sourceforge.net Fri May 27 18:32:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 May 2005 09:32:55 -0700 Subject: [ python-Bugs-1210001 ] Typo in "Differences from mimelib" Message-ID: Bugs item #1210001, was opened at 2005-05-27 12:26 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210001&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: Zumi (zumi001) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Typo in "Differences from mimelib" Initial Comment: In the online manual: http://www.python.org/doc/2.4/lib/node577.html "12.2.12 Differences from mimelib" there's a typo: "The methodgetmaintype() was renamed to get_main_type()." Suggestion: a space after the word "method". So something like this: "The method getmaintype() was renamed to get_main_type()." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210001&group_id=5470 From noreply at sourceforge.net Fri May 27 19:05:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 May 2005 10:05:00 -0700 Subject: [ python-Feature Requests-1205239 ] Let shift operators take any integer value Message-ID: Feature Requests item #1205239, was opened at 2005-05-19 19:54 Message generated for change (Comment added) made by dtorp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&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: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Albert Torpey (dtorp) Assigned to: Nobody/Anonymous (nobody) Summary: Let shift operators take any integer value Initial Comment: Let: 1 >> -4 be interpreted as: 1 << 4 This should be easy to do. It would be somewhat helpful for bit manipulations and multiplying by powers of two. Without the change, my code is laced with sections like: if y > 0: z = x << y else: z = x >> -y This is ugly and slow compared to a straight: z = x << y There is a precedent. See what is done with negative list indices for comparison. It saves even less code with x[len (x)-i] becoming x[i]. The reason for doing it is code simplication and clarity. ---------------------------------------------------------------------- >Comment By: David Albert Torpey (dtorp) Date: 2005-05-27 17:05 Message: Logged In: YES user_id=681258 Yes, I use this on long integers. And, the whole point of doing shifts is to avoid the costs of computing and multiplying by powers of two. Besides the math equivalents do not express the algorithms as well or as directly as shifts. Other than coming up with cumbersome workarounds (which I already had), do you have an objection to letting the shift operators use negative indices (in much the same way as with array indices)? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-26 08:01 Message: Logged In: YES user_id=341410 Is your code time critical? Do your numbers have more than 53 bits of precision? Do your numbers vary beyond 2**1024 or 1/2**1024? If not, then the following should be sufficient for your uses: int(x * 2**y) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&group_id=5470 From noreply at sourceforge.net Fri May 27 20:06:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 May 2005 11:06:35 -0700 Subject: [ python-Feature Requests-1205239 ] Let shift operators take any integer value Message-ID: Feature Requests item #1205239, was opened at 2005-05-19 12:54 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&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: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Albert Torpey (dtorp) Assigned to: Nobody/Anonymous (nobody) Summary: Let shift operators take any integer value Initial Comment: Let: 1 >> -4 be interpreted as: 1 << 4 This should be easy to do. It would be somewhat helpful for bit manipulations and multiplying by powers of two. Without the change, my code is laced with sections like: if y > 0: z = x << y else: z = x >> -y This is ugly and slow compared to a straight: z = x << y There is a precedent. See what is done with negative list indices for comparison. It saves even less code with x[len (x)-i] becoming x[i]. The reason for doing it is code simplication and clarity. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-27 11:06 Message: Logged In: YES user_id=341410 Yes, I do have an objection. On execution, either: 1. The interpreter would necessarily have to ask the question "is this shift value positive or negative" in order to possibly change which operation is to be executed. 2. Every shift operator would need to be rewritten to support negative shift values. Both of these solutions add compexity to what has been historically (in all languages) a very simple operation, and as the zen says "Simple is better than complex." -1 ---------------------------------------------------------------------- Comment By: David Albert Torpey (dtorp) Date: 2005-05-27 10:05 Message: Logged In: YES user_id=681258 Yes, I use this on long integers. And, the whole point of doing shifts is to avoid the costs of computing and multiplying by powers of two. Besides the math equivalents do not express the algorithms as well or as directly as shifts. Other than coming up with cumbersome workarounds (which I already had), do you have an objection to letting the shift operators use negative indices (in much the same way as with array indices)? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-26 01:01 Message: Logged In: YES user_id=341410 Is your code time critical? Do your numbers have more than 53 bits of precision? Do your numbers vary beyond 2**1024 or 1/2**1024? If not, then the following should be sufficient for your uses: int(x * 2**y) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&group_id=5470 From noreply at sourceforge.net Fri May 27 20:49:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 May 2005 11:49:09 -0700 Subject: [ python-Feature Requests-1205239 ] Let shift operators take any integer value Message-ID: Feature Requests item #1205239, was opened at 2005-05-19 19:54 Message generated for change (Comment added) made by dtorp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&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: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Albert Torpey (dtorp) Assigned to: Nobody/Anonymous (nobody) Summary: Let shift operators take any integer value Initial Comment: Let: 1 >> -4 be interpreted as: 1 << 4 This should be easy to do. It would be somewhat helpful for bit manipulations and multiplying by powers of two. Without the change, my code is laced with sections like: if y > 0: z = x << y else: z = x >> -y This is ugly and slow compared to a straight: z = x << y There is a precedent. See what is done with negative list indices for comparison. It saves even less code with x[len (x)-i] becoming x[i]. The reason for doing it is code simplication and clarity. ---------------------------------------------------------------------- >Comment By: David Albert Torpey (dtorp) Date: 2005-05-27 18:49 Message: Logged In: YES user_id=681258 Forgive my directness, but the last post doesn't show the slightest clue about how Python works. The existing test for a negative shift count takes place downstream from the interpreter in the int_lshift function in intobject.c (and the same for longobject.c). The RFE is to replace the line that raises a Value Error exception with a line that does something useful like flipping the sign of the argument and delegating to int_rshift. That is a zero net change in code complexity. The runtime of non-negative cases is likewise unchanged. Is there someone else reading this who has an informed opinion? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-27 18:06 Message: Logged In: YES user_id=341410 Yes, I do have an objection. On execution, either: 1. The interpreter would necessarily have to ask the question "is this shift value positive or negative" in order to possibly change which operation is to be executed. 2. Every shift operator would need to be rewritten to support negative shift values. Both of these solutions add compexity to what has been historically (in all languages) a very simple operation, and as the zen says "Simple is better than complex." -1 ---------------------------------------------------------------------- Comment By: David Albert Torpey (dtorp) Date: 2005-05-27 17:05 Message: Logged In: YES user_id=681258 Yes, I use this on long integers. And, the whole point of doing shifts is to avoid the costs of computing and multiplying by powers of two. Besides the math equivalents do not express the algorithms as well or as directly as shifts. Other than coming up with cumbersome workarounds (which I already had), do you have an objection to letting the shift operators use negative indices (in much the same way as with array indices)? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-26 08:01 Message: Logged In: YES user_id=341410 Is your code time critical? Do your numbers have more than 53 bits of precision? Do your numbers vary beyond 2**1024 or 1/2**1024? If not, then the following should be sufficient for your uses: int(x * 2**y) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&group_id=5470 From noreply at sourceforge.net Fri May 27 21:22:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 May 2005 12:22:45 -0700 Subject: [ python-Feature Requests-1205239 ] Let shift operators take any integer value Message-ID: Feature Requests item #1205239, was opened at 2005-05-19 12:54 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&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: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Albert Torpey (dtorp) Assigned to: Nobody/Anonymous (nobody) Summary: Let shift operators take any integer value Initial Comment: Let: 1 >> -4 be interpreted as: 1 << 4 This should be easy to do. It would be somewhat helpful for bit manipulations and multiplying by powers of two. Without the change, my code is laced with sections like: if y > 0: z = x << y else: z = x >> -y This is ugly and slow compared to a straight: z = x << y There is a precedent. See what is done with negative list indices for comparison. It saves even less code with x[len (x)-i] becoming x[i]. The reason for doing it is code simplication and clarity. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-27 12:22 Message: Logged In: YES user_id=341410 Pardon me for believing that your RFE was applicable to any object with an __lshift__ method. Being that you did not explicitly state that it was for integers only, merely that you did use it with integers. Regardless, changing integers to support negative shifts would imply that floats should also support negative shifts, and that all objects supporting __(l|r)shift__ methods also support negative shifts. One of Python's strengths is about consistancy, my rude friend, not merely about your particular use case for negative shifts. You should also realize that because this would be a new feature, it would have to wait until Python 2.5, which has at least a year before it is to be released. Are you willing to wait a year to use this? If not, you should get the source for 2.4, modify it as you see fit, and run your own version. If waiting a year for 2.5 and for your change to maybe be included or running your own version of 2.4 is not sufficient, then you have a serious problem on your hands, and no one here can help you. ---------------------------------------------------------------------- Comment By: David Albert Torpey (dtorp) Date: 2005-05-27 11:49 Message: Logged In: YES user_id=681258 Forgive my directness, but the last post doesn't show the slightest clue about how Python works. The existing test for a negative shift count takes place downstream from the interpreter in the int_lshift function in intobject.c (and the same for longobject.c). The RFE is to replace the line that raises a Value Error exception with a line that does something useful like flipping the sign of the argument and delegating to int_rshift. That is a zero net change in code complexity. The runtime of non-negative cases is likewise unchanged. Is there someone else reading this who has an informed opinion? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-27 11:06 Message: Logged In: YES user_id=341410 Yes, I do have an objection. On execution, either: 1. The interpreter would necessarily have to ask the question "is this shift value positive or negative" in order to possibly change which operation is to be executed. 2. Every shift operator would need to be rewritten to support negative shift values. Both of these solutions add compexity to what has been historically (in all languages) a very simple operation, and as the zen says "Simple is better than complex." -1 ---------------------------------------------------------------------- Comment By: David Albert Torpey (dtorp) Date: 2005-05-27 10:05 Message: Logged In: YES user_id=681258 Yes, I use this on long integers. And, the whole point of doing shifts is to avoid the costs of computing and multiplying by powers of two. Besides the math equivalents do not express the algorithms as well or as directly as shifts. Other than coming up with cumbersome workarounds (which I already had), do you have an objection to letting the shift operators use negative indices (in much the same way as with array indices)? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-26 01:01 Message: Logged In: YES user_id=341410 Is your code time critical? Do your numbers have more than 53 bits of precision? Do your numbers vary beyond 2**1024 or 1/2**1024? If not, then the following should be sufficient for your uses: int(x * 2**y) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&group_id=5470 From noreply at sourceforge.net Fri May 27 21:50:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 May 2005 12:50:03 -0700 Subject: [ python-Feature Requests-1205239 ] Let shift operators take any integer value Message-ID: Feature Requests item #1205239, was opened at 2005-05-19 15:54 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&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: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Albert Torpey (dtorp) Assigned to: Nobody/Anonymous (nobody) Summary: Let shift operators take any integer value Initial Comment: Let: 1 >> -4 be interpreted as: 1 << 4 This should be easy to do. It would be somewhat helpful for bit manipulations and multiplying by powers of two. Without the change, my code is laced with sections like: if y > 0: z = x << y else: z = x >> -y This is ugly and slow compared to a straight: z = x << y There is a precedent. See what is done with negative list indices for comparison. It saves even less code with x[len (x)-i] becoming x[i]. The reason for doing it is code simplication and clarity. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-05-27 15:50 Message: Logged In: YES user_id=31435 -0. I could live with this change, but would rather not. In my experience complaints about using a negative shift count has correctly pointed out logic errors in my code, and I wouldn't want to lose that. Note that floats don't support __[lr]shift__ regardless; neither do complex numbers nor Decimals; the benefit/damage among the builtin types would be confined to int & long. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-27 15:22 Message: Logged In: YES user_id=341410 Pardon me for believing that your RFE was applicable to any object with an __lshift__ method. Being that you did not explicitly state that it was for integers only, merely that you did use it with integers. Regardless, changing integers to support negative shifts would imply that floats should also support negative shifts, and that all objects supporting __(l|r)shift__ methods also support negative shifts. One of Python's strengths is about consistancy, my rude friend, not merely about your particular use case for negative shifts. You should also realize that because this would be a new feature, it would have to wait until Python 2.5, which has at least a year before it is to be released. Are you willing to wait a year to use this? If not, you should get the source for 2.4, modify it as you see fit, and run your own version. If waiting a year for 2.5 and for your change to maybe be included or running your own version of 2.4 is not sufficient, then you have a serious problem on your hands, and no one here can help you. ---------------------------------------------------------------------- Comment By: David Albert Torpey (dtorp) Date: 2005-05-27 14:49 Message: Logged In: YES user_id=681258 Forgive my directness, but the last post doesn't show the slightest clue about how Python works. The existing test for a negative shift count takes place downstream from the interpreter in the int_lshift function in intobject.c (and the same for longobject.c). The RFE is to replace the line that raises a Value Error exception with a line that does something useful like flipping the sign of the argument and delegating to int_rshift. That is a zero net change in code complexity. The runtime of non-negative cases is likewise unchanged. Is there someone else reading this who has an informed opinion? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-27 14:06 Message: Logged In: YES user_id=341410 Yes, I do have an objection. On execution, either: 1. The interpreter would necessarily have to ask the question "is this shift value positive or negative" in order to possibly change which operation is to be executed. 2. Every shift operator would need to be rewritten to support negative shift values. Both of these solutions add compexity to what has been historically (in all languages) a very simple operation, and as the zen says "Simple is better than complex." -1 ---------------------------------------------------------------------- Comment By: David Albert Torpey (dtorp) Date: 2005-05-27 13:05 Message: Logged In: YES user_id=681258 Yes, I use this on long integers. And, the whole point of doing shifts is to avoid the costs of computing and multiplying by powers of two. Besides the math equivalents do not express the algorithms as well or as directly as shifts. Other than coming up with cumbersome workarounds (which I already had), do you have an objection to letting the shift operators use negative indices (in much the same way as with array indices)? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-26 04:01 Message: Logged In: YES user_id=341410 Is your code time critical? Do your numbers have more than 53 bits of precision? Do your numbers vary beyond 2**1024 or 1/2**1024? If not, then the following should be sufficient for your uses: int(x * 2**y) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&group_id=5470 From noreply at sourceforge.net Fri May 27 22:08:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 May 2005 13:08:07 -0700 Subject: [ python-Feature Requests-1205239 ] Let shift operators take any integer value Message-ID: Feature Requests item #1205239, was opened at 2005-05-19 19:54 Message generated for change (Comment added) made by dtorp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&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: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Albert Torpey (dtorp) Assigned to: Nobody/Anonymous (nobody) Summary: Let shift operators take any integer value Initial Comment: Let: 1 >> -4 be interpreted as: 1 << 4 This should be easy to do. It would be somewhat helpful for bit manipulations and multiplying by powers of two. Without the change, my code is laced with sections like: if y > 0: z = x << y else: z = x >> -y This is ugly and slow compared to a straight: z = x << y There is a precedent. See what is done with negative list indices for comparison. It saves even less code with x[len (x)-i] becoming x[i]. The reason for doing it is code simplication and clarity. ---------------------------------------------------------------------- >Comment By: David Albert Torpey (dtorp) Date: 2005-05-27 20:08 Message: Logged In: YES user_id=681258 When balancing expressiveness against error checking, do you know what tipped the scales in favor of negative list indices? I imagine the issues were similar (although shifting isn't nearly as common as shifting). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-05-27 19:50 Message: Logged In: YES user_id=31435 -0. I could live with this change, but would rather not. In my experience complaints about using a negative shift count has correctly pointed out logic errors in my code, and I wouldn't want to lose that. Note that floats don't support __[lr]shift__ regardless; neither do complex numbers nor Decimals; the benefit/damage among the builtin types would be confined to int & long. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-27 19:22 Message: Logged In: YES user_id=341410 Pardon me for believing that your RFE was applicable to any object with an __lshift__ method. Being that you did not explicitly state that it was for integers only, merely that you did use it with integers. Regardless, changing integers to support negative shifts would imply that floats should also support negative shifts, and that all objects supporting __(l|r)shift__ methods also support negative shifts. One of Python's strengths is about consistancy, my rude friend, not merely about your particular use case for negative shifts. You should also realize that because this would be a new feature, it would have to wait until Python 2.5, which has at least a year before it is to be released. Are you willing to wait a year to use this? If not, you should get the source for 2.4, modify it as you see fit, and run your own version. If waiting a year for 2.5 and for your change to maybe be included or running your own version of 2.4 is not sufficient, then you have a serious problem on your hands, and no one here can help you. ---------------------------------------------------------------------- Comment By: David Albert Torpey (dtorp) Date: 2005-05-27 18:49 Message: Logged In: YES user_id=681258 Forgive my directness, but the last post doesn't show the slightest clue about how Python works. The existing test for a negative shift count takes place downstream from the interpreter in the int_lshift function in intobject.c (and the same for longobject.c). The RFE is to replace the line that raises a Value Error exception with a line that does something useful like flipping the sign of the argument and delegating to int_rshift. That is a zero net change in code complexity. The runtime of non-negative cases is likewise unchanged. Is there someone else reading this who has an informed opinion? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-27 18:06 Message: Logged In: YES user_id=341410 Yes, I do have an objection. On execution, either: 1. The interpreter would necessarily have to ask the question "is this shift value positive or negative" in order to possibly change which operation is to be executed. 2. Every shift operator would need to be rewritten to support negative shift values. Both of these solutions add compexity to what has been historically (in all languages) a very simple operation, and as the zen says "Simple is better than complex." -1 ---------------------------------------------------------------------- Comment By: David Albert Torpey (dtorp) Date: 2005-05-27 17:05 Message: Logged In: YES user_id=681258 Yes, I use this on long integers. And, the whole point of doing shifts is to avoid the costs of computing and multiplying by powers of two. Besides the math equivalents do not express the algorithms as well or as directly as shifts. Other than coming up with cumbersome workarounds (which I already had), do you have an objection to letting the shift operators use negative indices (in much the same way as with array indices)? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-26 08:01 Message: Logged In: YES user_id=341410 Is your code time critical? Do your numbers have more than 53 bits of precision? Do your numbers vary beyond 2**1024 or 1/2**1024? If not, then the following should be sufficient for your uses: int(x * 2**y) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&group_id=5470 From noreply at sourceforge.net Sat May 28 09:32:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 May 2005 00:32:31 -0700 Subject: [ python-Bugs-1186195 ] [AST] genexps get scoping wrong Message-ID: Bugs item #1186195, was opened at 2005-04-20 05:02 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186195&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: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nick Coghlan (ncoghlan) Summary: [AST] genexps get scoping wrong Initial Comment: test_genexps is failing because it is unable to find a global defined in a genexp that is returned. Here is the problem simplified: def f(n): return (i for i in xrange(n)) list(f(10)) Leads to ``SystemError: no locals when loading 'xrange'``. Comparing Python 2.4 bytecode: 1 0 LOAD_CONST 1 ( at 0x3931e0, file "", line 1>) 3 MAKE_FUNCTION 0 6 LOAD_GLOBAL 0 (xrange) 9 LOAD_FAST 0 (n) 12 CALL_FUNCTION 1 15 GET_ITER 16 CALL_FUNCTION 1 19 RETURN_VALUE 20 LOAD_CONST 0 (None) 23 RETURN_VALUE to AST bytecode: 1 0 LOAD_CLOSURE 0 (n) 3 BUILD_TUPLE 1 6 LOAD_CONST 1 ( at 0x5212e8, file "", line 1>) 9 MAKE_CLOSURE 0 12 LOAD_NAME 0 (xrange) 15 LOAD_DEREF 0 (n) 18 CALL_FUNCTION 1 21 GET_ITER 22 CALL_FUNCTION 1 25 RETURN_VALUE 26 LOAD_CONST 0 (None) 29 RETURN_VALUE makes it obvious something is off (no peepholer; turned it off in my build of 2.4). Looks like extraneous work is being done in making a closure. Seems like it will still work, though. Plus the usage of LOAD_NAME is wrong in the AST; LOAD_NAME gets an object from the local namespace based on its name instead of offset. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 17:32 Message: Logged In: YES user_id=1038590 Patch attached that means test_genexps mostly passes for me. The two which still fail are actually problems with assignment statements (the AST branch does not yet intercept attempts to assign to genexps and produce a nice error message). I'm also much happier with the implementation technique I used this time around - something similar should work for the compiler implementation, hopefully permitting it to be simplified (I'm going to look at that now, and will post a separate patch if it works out). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-21 16:13 Message: Logged In: YES user_id=357491 OK, so basically what I figured out earlier today. I noticed that both genexps in 2.4 and the AST branch generated the same bytecode, so the only difference was how it was handling passing in arguments to the generator for its initial creation. I figured there was some jiggering in the compiler to note that the scoping in the genexp should not affect how variables were handled for its arguments. And as you said, the AST branch just doesn't take this into consideration as it should. I will see if I get to it, but I doubt I will (leaving town Friday for the weekend). I think this has justified fleshing out Python/compile.txt with a more thorough discussion of how the symbol table is generated. If you have any specific points you think should go in there, Nick (or anyone for that matter), please email them to me. Even explaining how the whole thing works would be a help. =) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-04-21 08:13 Message: Logged In: YES user_id=1038590 The compiler stage does some fancy footwork so that the outermost iterable is evaluated immediately, and passed as an argument to the genexp block. The symbol table generation needs similar footwork, but it doesn't have it. That is, the symbol table for the outermost iterable is being created in the genexp scope, instead of in the containing function's scope, but the actual execution is happening in the function scope. Hilarity ensues. . . My original testing didn't pick this up because I was using (1, 2, 3) as the outermost iterable - no name lookups in the outermost iterable to be affected! If you haven't figured out a fix for this part of the problem before Sunday, I should be able to get to it then. The location of the enter_scope and exit_scope in the symbol table pass for genexps needs adjusting so that the outermost iterable is NOT part of the new scope. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-20 10:30 Message: Logged In: YES user_id=357491 OK, figured out why the closure thing is happening. 'n' is being detected as a free variable. This leads to PyCode_GetNumFree() to return a non-0 value. In compiler_make_closure() this automatically triggers the LOAD_CLOSURE/.../MAKE_CLOSURE chunk of bytecode instead of LOAD_CONST/MAKE_FUNCTION. So, how to make 'n' be detected as a local instead a free variable ... ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-20 10:09 Message: Logged In: YES user_id=357491 Some playing with gdb has turned up some clues. So LOAD_NAME is emitted by compiler_nameop(). How this partially works is that it gets the scope for an argument and then based on that emits the proper load, store, or delete. So why is xrange() coming out at the NAME scope? Well, turns out it is not being found in a particular scope by PyST_GetScope() and is thus returning 0 by default. This means that NAME becomes the scope for xrange(). So it looks like the symtable creation is screwing up and not making xrange() a global like it should. This might be a side-effect of the while closure thing above. Not sure, though. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-20 05:03 Message: Logged In: YES user_id=357491 Initially assigned to Nick since he did the genexp patch and in hopes he might know what is going on off the top of his head. Otherwise assign to me. I have a sneaking suspicion that the symtable code overall is slightly busted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186195&group_id=5470 From noreply at sourceforge.net Sat May 28 09:33:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 May 2005 00:33:42 -0700 Subject: [ python-Bugs-1186195 ] [AST] genexps get scoping wrong Message-ID: Bugs item #1186195, was opened at 2005-04-20 05:02 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186195&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: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) >Assigned to: Brett Cannon (bcannon) Summary: [AST] genexps get scoping wrong Initial Comment: test_genexps is failing because it is unable to find a global defined in a genexp that is returned. Here is the problem simplified: def f(n): return (i for i in xrange(n)) list(f(10)) Leads to ``SystemError: no locals when loading 'xrange'``. Comparing Python 2.4 bytecode: 1 0 LOAD_CONST 1 ( at 0x3931e0, file "", line 1>) 3 MAKE_FUNCTION 0 6 LOAD_GLOBAL 0 (xrange) 9 LOAD_FAST 0 (n) 12 CALL_FUNCTION 1 15 GET_ITER 16 CALL_FUNCTION 1 19 RETURN_VALUE 20 LOAD_CONST 0 (None) 23 RETURN_VALUE to AST bytecode: 1 0 LOAD_CLOSURE 0 (n) 3 BUILD_TUPLE 1 6 LOAD_CONST 1 ( at 0x5212e8, file "", line 1>) 9 MAKE_CLOSURE 0 12 LOAD_NAME 0 (xrange) 15 LOAD_DEREF 0 (n) 18 CALL_FUNCTION 1 21 GET_ITER 22 CALL_FUNCTION 1 25 RETURN_VALUE 26 LOAD_CONST 0 (None) 29 RETURN_VALUE makes it obvious something is off (no peepholer; turned it off in my build of 2.4). Looks like extraneous work is being done in making a closure. Seems like it will still work, though. Plus the usage of LOAD_NAME is wrong in the AST; LOAD_NAME gets an object from the local namespace based on its name instead of offset. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 17:33 Message: Logged In: YES user_id=1038590 Tag, you're it :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 17:32 Message: Logged In: YES user_id=1038590 Patch attached that means test_genexps mostly passes for me. The two which still fail are actually problems with assignment statements (the AST branch does not yet intercept attempts to assign to genexps and produce a nice error message). I'm also much happier with the implementation technique I used this time around - something similar should work for the compiler implementation, hopefully permitting it to be simplified (I'm going to look at that now, and will post a separate patch if it works out). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-21 16:13 Message: Logged In: YES user_id=357491 OK, so basically what I figured out earlier today. I noticed that both genexps in 2.4 and the AST branch generated the same bytecode, so the only difference was how it was handling passing in arguments to the generator for its initial creation. I figured there was some jiggering in the compiler to note that the scoping in the genexp should not affect how variables were handled for its arguments. And as you said, the AST branch just doesn't take this into consideration as it should. I will see if I get to it, but I doubt I will (leaving town Friday for the weekend). I think this has justified fleshing out Python/compile.txt with a more thorough discussion of how the symbol table is generated. If you have any specific points you think should go in there, Nick (or anyone for that matter), please email them to me. Even explaining how the whole thing works would be a help. =) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-04-21 08:13 Message: Logged In: YES user_id=1038590 The compiler stage does some fancy footwork so that the outermost iterable is evaluated immediately, and passed as an argument to the genexp block. The symbol table generation needs similar footwork, but it doesn't have it. That is, the symbol table for the outermost iterable is being created in the genexp scope, instead of in the containing function's scope, but the actual execution is happening in the function scope. Hilarity ensues. . . My original testing didn't pick this up because I was using (1, 2, 3) as the outermost iterable - no name lookups in the outermost iterable to be affected! If you haven't figured out a fix for this part of the problem before Sunday, I should be able to get to it then. The location of the enter_scope and exit_scope in the symbol table pass for genexps needs adjusting so that the outermost iterable is NOT part of the new scope. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-20 10:30 Message: Logged In: YES user_id=357491 OK, figured out why the closure thing is happening. 'n' is being detected as a free variable. This leads to PyCode_GetNumFree() to return a non-0 value. In compiler_make_closure() this automatically triggers the LOAD_CLOSURE/.../MAKE_CLOSURE chunk of bytecode instead of LOAD_CONST/MAKE_FUNCTION. So, how to make 'n' be detected as a local instead a free variable ... ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-20 10:09 Message: Logged In: YES user_id=357491 Some playing with gdb has turned up some clues. So LOAD_NAME is emitted by compiler_nameop(). How this partially works is that it gets the scope for an argument and then based on that emits the proper load, store, or delete. So why is xrange() coming out at the NAME scope? Well, turns out it is not being found in a particular scope by PyST_GetScope() and is thus returning 0 by default. This means that NAME becomes the scope for xrange(). So it looks like the symtable creation is screwing up and not making xrange() a global like it should. This might be a side-effect of the while closure thing above. Not sure, though. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-20 05:03 Message: Logged In: YES user_id=357491 Initially assigned to Nick since he did the genexp patch and in hopes he might know what is going on off the top of his head. Otherwise assign to me. I have a sneaking suspicion that the symtable code overall is slightly busted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186195&group_id=5470 From noreply at sourceforge.net Sat May 28 09:49:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 May 2005 00:49:37 -0700 Subject: [ python-Bugs-1186195 ] [AST] genexps get scoping wrong Message-ID: Bugs item #1186195, was opened at 2005-04-20 05:02 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186195&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: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: [AST] genexps get scoping wrong Initial Comment: test_genexps is failing because it is unable to find a global defined in a genexp that is returned. Here is the problem simplified: def f(n): return (i for i in xrange(n)) list(f(10)) Leads to ``SystemError: no locals when loading 'xrange'``. Comparing Python 2.4 bytecode: 1 0 LOAD_CONST 1 ( at 0x3931e0, file "", line 1>) 3 MAKE_FUNCTION 0 6 LOAD_GLOBAL 0 (xrange) 9 LOAD_FAST 0 (n) 12 CALL_FUNCTION 1 15 GET_ITER 16 CALL_FUNCTION 1 19 RETURN_VALUE 20 LOAD_CONST 0 (None) 23 RETURN_VALUE to AST bytecode: 1 0 LOAD_CLOSURE 0 (n) 3 BUILD_TUPLE 1 6 LOAD_CONST 1 ( at 0x5212e8, file "", line 1>) 9 MAKE_CLOSURE 0 12 LOAD_NAME 0 (xrange) 15 LOAD_DEREF 0 (n) 18 CALL_FUNCTION 1 21 GET_ITER 22 CALL_FUNCTION 1 25 RETURN_VALUE 26 LOAD_CONST 0 (None) 29 RETURN_VALUE makes it obvious something is off (no peepholer; turned it off in my build of 2.4). Looks like extraneous work is being done in making a closure. Seems like it will still work, though. Plus the usage of LOAD_NAME is wrong in the AST; LOAD_NAME gets an object from the local namespace based on its name instead of offset. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 17:49 Message: Logged In: YES user_id=1038590 Scratch that comment about applying a similar methodology to the compiler stage - the need to correctly structure the generate bytecode makes things a lot uglier, so the simple trick I used to get the symbol table scoping right doesn't apply (the outer loops need to do things before *and after* the inner loops in the compiler stage). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 17:33 Message: Logged In: YES user_id=1038590 Tag, you're it :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 17:32 Message: Logged In: YES user_id=1038590 Patch attached that means test_genexps mostly passes for me. The two which still fail are actually problems with assignment statements (the AST branch does not yet intercept attempts to assign to genexps and produce a nice error message). I'm also much happier with the implementation technique I used this time around - something similar should work for the compiler implementation, hopefully permitting it to be simplified (I'm going to look at that now, and will post a separate patch if it works out). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-21 16:13 Message: Logged In: YES user_id=357491 OK, so basically what I figured out earlier today. I noticed that both genexps in 2.4 and the AST branch generated the same bytecode, so the only difference was how it was handling passing in arguments to the generator for its initial creation. I figured there was some jiggering in the compiler to note that the scoping in the genexp should not affect how variables were handled for its arguments. And as you said, the AST branch just doesn't take this into consideration as it should. I will see if I get to it, but I doubt I will (leaving town Friday for the weekend). I think this has justified fleshing out Python/compile.txt with a more thorough discussion of how the symbol table is generated. If you have any specific points you think should go in there, Nick (or anyone for that matter), please email them to me. Even explaining how the whole thing works would be a help. =) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-04-21 08:13 Message: Logged In: YES user_id=1038590 The compiler stage does some fancy footwork so that the outermost iterable is evaluated immediately, and passed as an argument to the genexp block. The symbol table generation needs similar footwork, but it doesn't have it. That is, the symbol table for the outermost iterable is being created in the genexp scope, instead of in the containing function's scope, but the actual execution is happening in the function scope. Hilarity ensues. . . My original testing didn't pick this up because I was using (1, 2, 3) as the outermost iterable - no name lookups in the outermost iterable to be affected! If you haven't figured out a fix for this part of the problem before Sunday, I should be able to get to it then. The location of the enter_scope and exit_scope in the symbol table pass for genexps needs adjusting so that the outermost iterable is NOT part of the new scope. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-20 10:30 Message: Logged In: YES user_id=357491 OK, figured out why the closure thing is happening. 'n' is being detected as a free variable. This leads to PyCode_GetNumFree() to return a non-0 value. In compiler_make_closure() this automatically triggers the LOAD_CLOSURE/.../MAKE_CLOSURE chunk of bytecode instead of LOAD_CONST/MAKE_FUNCTION. So, how to make 'n' be detected as a local instead a free variable ... ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-20 10:09 Message: Logged In: YES user_id=357491 Some playing with gdb has turned up some clues. So LOAD_NAME is emitted by compiler_nameop(). How this partially works is that it gets the scope for an argument and then based on that emits the proper load, store, or delete. So why is xrange() coming out at the NAME scope? Well, turns out it is not being found in a particular scope by PyST_GetScope() and is thus returning 0 by default. This means that NAME becomes the scope for xrange(). So it looks like the symtable creation is screwing up and not making xrange() a global like it should. This might be a side-effect of the while closure thing above. Not sure, though. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-20 05:03 Message: Logged In: YES user_id=357491 Initially assigned to Nick since he did the genexp patch and in hopes he might know what is going on off the top of his head. Otherwise assign to me. I have a sneaking suspicion that the symtable code overall is slightly busted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186195&group_id=5470 From noreply at sourceforge.net Sat May 28 10:26:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 May 2005 01:26:09 -0700 Subject: [ python-Bugs-1190011 ] [AST] distinct code objects not created Message-ID: Bugs item #1190011, was opened at 2005-04-26 16:10 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190011&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: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) >Assigned to: Nick Coghlan (ncoghlan) Summary: [AST] distinct code objects not created Initial Comment: >> def f(): return ((lambda x=1: x), (lambda x=2: x)) >> f1, f2 = f() >> id(f1.func_code) != id(f2.func_code) The above does not hold true. It should according to test_compile (reported in HEAD as bug #1048870). ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 18:26 Message: Logged In: YES user_id=1038590 This seems to be the least of lambda's problems. A number of regression tests currently fail with UnboundLocalErrors, after an argument of the form "lambda (x, y): x" is passed to a function for invocation. Assigning to myself, since I'm about to take a look at the current misbehaviour of lambdas (they must be simpler than genexps, right?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190011&group_id=5470 From noreply at sourceforge.net Sat May 28 10:33:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 May 2005 01:33:11 -0700 Subject: [ python-Bugs-1191458 ] [AST] Failing tests Message-ID: Bugs item #1191458, was opened at 2005-04-28 13:30 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&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: Open Resolution: None >Priority: 9 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: [AST] Failing tests Initial Comment: This tracker item is to be used to keep track of what tests are currently failing on the AST branch. This is somewhat important sinced there are so many failures it can be hard to detect if a change fixed what it was supposed to or actually managed to break more code. When posting follow-ups of fixed tests, please re-list the currently failing tests so as to make it simple to reference the current state of things. So, the current offenders are (from a straight ``regrtest.py`` run on my OS X box, which always has test__locale fail so I removed it):: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_peepholer test_scope test_socket test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings test_zipfile ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 18:33 Message: Logged In: YES user_id=1038590 Bumped bug priority to 9 so it stays on top of the SF tracker. Also, we can't merge the AST branch until this bug is closed, so it is fairly important to close out these issues :) Running "./python Lib/test/regrtest.py -uall" Suse Linux 9.1: 20 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_ossaudiodev test_peepholer test_scope test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings test_zipfile WIth the patch for 1186195 (genexp scoping) applied I get: 19 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_ossaudiodev test_peepholer test_scope test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings The remaining test_genexps failures are due to assignment statements not checking for genexps as illegal targets. Running test_zipfile in verbose mode indicated genexp problems, so it makes sense that fixing the scoping eliminated those failures. I'm going to look at lambdas next, since they seem to be the culprits with respect to a few different test failures. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&group_id=5470 From noreply at sourceforge.net Sat May 28 11:41:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 May 2005 02:41:02 -0700 Subject: [ python-Bugs-1186353 ] [AST] automatic unpacking of arguments broken Message-ID: Bugs item #1186353, was opened at 2005-04-20 09:37 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186353&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: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) >Assigned to: Nick Coghlan (ncoghlan) Summary: [AST] automatic unpacking of arguments broken Initial Comment: The code ``(lambda (x, y): x)((3, 5))`` fails because the passed-in tuple is not unpacked into the arguments. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 19:41 Message: Logged In: YES user_id=1038590 Investigating lambda behaviour, as per comment on 1190011 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186353&group_id=5470 From noreply at sourceforge.net Sat May 28 12:13:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 May 2005 03:13:30 -0700 Subject: [ python-Bugs-1210326 ] comma separated cookie values Message-ID: Bugs item #1210326, was opened at 2005-05-28 10:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210326&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: tvogt (tovo) Assigned to: Nobody/Anonymous (nobody) Summary: comma separated cookie values Initial Comment: According to RFC 2109 "For backward compatibility, the separator in the Cookie header is semi-colon (;) everywhere. A server should also accept comma (,) as the separator between cookie-values for future compatibility." The Cookie standard module does not support this as it should. >>> import Cookie >>> c=Cookie.SimpleCookie() >>> c.load('foo=2, bar=3') >>> print c['foo'].value 2, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210326&group_id=5470 From noreply at sourceforge.net Sat May 28 12:34:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 May 2005 03:34:34 -0700 Subject: [ python-Bugs-1186353 ] [AST] automatic unpacking of arguments broken Message-ID: Bugs item #1186353, was opened at 2005-04-20 09:37 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186353&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: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) >Assigned to: Brett Cannon (bcannon) Summary: [AST] automatic unpacking of arguments broken Initial Comment: The code ``(lambda (x, y): x)((3, 5))`` fails because the passed-in tuple is not unpacked into the arguments. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 20:34 Message: Logged In: YES user_id=1038590 After looking in all the wrong places, it turned out to be something simple in the compiler. I factored out the relevant code from the function compilation, so that lambda compilation can use it too. Assigning to Brett for review. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 19:41 Message: Logged In: YES user_id=1038590 Investigating lambda behaviour, as per comment on 1190011 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186353&group_id=5470 From noreply at sourceforge.net Sat May 28 13:02:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 May 2005 04:02:35 -0700 Subject: [ python-Bugs-1190011 ] [AST] distinct code objects not created Message-ID: Bugs item #1190011, was opened at 2005-04-26 16:10 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190011&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: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nick Coghlan (ncoghlan) Summary: [AST] distinct code objects not created Initial Comment: >> def f(): return ((lambda x=1: x), (lambda x=2: x)) >> f1, f2 = f() >> id(f1.func_code) != id(f2.func_code) The above does not hold true. It should according to test_compile (reported in HEAD as bug #1048870). ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 21:02 Message: Logged In: YES user_id=1038590 For the code above, Python 2.4.1 actually generates a single code object (that is, the comparison returns False). Looking closer at 1048870, this is expected, as the two lambdas are created on the same line. I'll look into this on the AST branch - I suspect the culprit may be our problems with getting the line numbering right. (FWIW, I worked out the UnboundLocal problem, and followed it up in the relevant bug, 1186353) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 18:26 Message: Logged In: YES user_id=1038590 This seems to be the least of lambda's problems. A number of regression tests currently fail with UnboundLocalErrors, after an argument of the form "lambda (x, y): x" is passed to a function for invocation. Assigning to myself, since I'm about to take a look at the current misbehaviour of lambdas (they must be simpler than genexps, right?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190011&group_id=5470 From noreply at sourceforge.net Sat May 28 13:40:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 May 2005 04:40:16 -0700 Subject: [ python-Bugs-1191458 ] [AST] Failing tests Message-ID: Bugs item #1191458, was opened at 2005-04-28 13:30 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&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: Open Resolution: None Priority: 9 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: [AST] Failing tests Initial Comment: This tracker item is to be used to keep track of what tests are currently failing on the AST branch. This is somewhat important sinced there are so many failures it can be hard to detect if a change fixed what it was supposed to or actually managed to break more code. When posting follow-ups of fixed tests, please re-list the currently failing tests so as to make it simple to reference the current state of things. So, the current offenders are (from a straight ``regrtest.py`` run on my OS X box, which always has test__locale fail so I removed it):: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_peepholer test_scope test_socket test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings test_zipfile ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 21:40 Message: Logged In: YES user_id=1038590 Fixing #1186353 (lambda argument unpacking) fixes test_sort and test_itertools: 17 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_new test_ossaudiodev test_peepholer test_scope test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 18:33 Message: Logged In: YES user_id=1038590 Bumped bug priority to 9 so it stays on top of the SF tracker. Also, we can't merge the AST branch until this bug is closed, so it is fairly important to close out these issues :) Running "./python Lib/test/regrtest.py -uall" Suse Linux 9.1: 20 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_ossaudiodev test_peepholer test_scope test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings test_zipfile WIth the patch for 1186195 (genexp scoping) applied I get: 19 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_ossaudiodev test_peepholer test_scope test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings The remaining test_genexps failures are due to assignment statements not checking for genexps as illegal targets. Running test_zipfile in verbose mode indicated genexp problems, so it makes sense that fixing the scoping eliminated those failures. I'm going to look at lambdas next, since they seem to be the culprits with respect to a few different test failures. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&group_id=5470 From noreply at sourceforge.net Sat May 28 14:11:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 May 2005 05:11:26 -0700 Subject: [ python-Bugs-1190011 ] [AST] distinct code objects not created Message-ID: Bugs item #1190011, was opened at 2005-04-26 16:10 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190011&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: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nick Coghlan (ncoghlan) Summary: [AST] distinct code objects not created Initial Comment: >> def f(): return ((lambda x=1: x), (lambda x=2: x)) >> f1, f2 = f() >> id(f1.func_code) != id(f2.func_code) The above does not hold true. It should according to test_compile (reported in HEAD as bug #1048870). ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 22:11 Message: Logged In: YES user_id=1038590 The same fix mwh used for HEAD appears to work for the AST branch, too (it's just in a different source file). Patch attached, and kicking in Brett's direction for review. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 21:02 Message: Logged In: YES user_id=1038590 For the code above, Python 2.4.1 actually generates a single code object (that is, the comparison returns False). Looking closer at 1048870, this is expected, as the two lambdas are created on the same line. I'll look into this on the AST branch - I suspect the culprit may be our problems with getting the line numbering right. (FWIW, I worked out the UnboundLocal problem, and followed it up in the relevant bug, 1186353) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 18:26 Message: Logged In: YES user_id=1038590 This seems to be the least of lambda's problems. A number of regression tests currently fail with UnboundLocalErrors, after an argument of the form "lambda (x, y): x" is passed to a function for invocation. Assigning to myself, since I'm about to take a look at the current misbehaviour of lambdas (they must be simpler than genexps, right?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190011&group_id=5470 From noreply at sourceforge.net Sat May 28 14:11:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 May 2005 05:11:54 -0700 Subject: [ python-Bugs-1190011 ] [AST] distinct code objects not created Message-ID: Bugs item #1190011, was opened at 2005-04-26 16:10 Message generated for change (Settings changed) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190011&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: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) >Assigned to: Brett Cannon (bcannon) Summary: [AST] distinct code objects not created Initial Comment: >> def f(): return ((lambda x=1: x), (lambda x=2: x)) >> f1, f2 = f() >> id(f1.func_code) != id(f2.func_code) The above does not hold true. It should according to test_compile (reported in HEAD as bug #1048870). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 22:11 Message: Logged In: YES user_id=1038590 The same fix mwh used for HEAD appears to work for the AST branch, too (it's just in a different source file). Patch attached, and kicking in Brett's direction for review. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 21:02 Message: Logged In: YES user_id=1038590 For the code above, Python 2.4.1 actually generates a single code object (that is, the comparison returns False). Looking closer at 1048870, this is expected, as the two lambdas are created on the same line. I'll look into this on the AST branch - I suspect the culprit may be our problems with getting the line numbering right. (FWIW, I worked out the UnboundLocal problem, and followed it up in the relevant bug, 1186353) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 18:26 Message: Logged In: YES user_id=1038590 This seems to be the least of lambda's problems. A number of regression tests currently fail with UnboundLocalErrors, after an argument of the form "lambda (x, y): x" is passed to a function for invocation. Assigning to myself, since I'm about to take a look at the current misbehaviour of lambdas (they must be simpler than genexps, right?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190011&group_id=5470 From noreply at sourceforge.net Sat May 28 14:48:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 May 2005 05:48:42 -0700 Subject: [ python-Bugs-1210377 ] Cursors not correctly closed after exception. Message-ID: Bugs item #1210377, was opened at 2005-05-28 14:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210377&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ragnar Ouchterlony (ragnar) Assigned to: Nobody/Anonymous (nobody) Summary: Cursors not correctly closed after exception. Initial Comment: If an exception occurs when going through a database, the cursors will not be correctly reset. If I manually set the cursor to None (by doing db.dbc = None) it will work fine. >>> db = bsddb.btopen('/tmp/test.db', 'c') >>> db.first() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/bsddb/__init__.py", line 264, in first rv = self.dbc.first() _bsddb.DBNotFoundError: (-30990, 'DB_NOTFOUND: No matching key/data pair found') >>> db['foo'] = 'bar' Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/bsddb/__init__.py", line 217, in __setitem__ self._closeCursors() File "/usr/lib/python2.4/bsddb/__init__.py", line 192, in _closeCursors self.saved_dbc_key = c.current(0,0,0)[0] bsddb._db.DBInvalidArgError: (22, 'Invalid argument -- Cursor position must be set before performing this operation') Here, I first open a new database. Since it is empty, db.first() will fail. When I after that try to add a key/value pair to the database it fails, since it tries to close an invalid cursor. >>> db = bsddb.btopen('/tmp/test.db', 'c') >>> db.first() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/bsddb/__init__.py", line 264, in first rv = self.dbc.first() _bsddb.DBNotFoundError: (-30990, 'DB_NOTFOUND: No matching key/data pair found') >>> db.dbc = None >>> db['foo'] = 'bar' >>> db {'foo': 'bar'} Here I do "db.dbc = None" after the exception and now it works just fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210377&group_id=5470 From noreply at sourceforge.net Sun May 29 01:22:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 May 2005 16:22:06 -0700 Subject: [ python-Feature Requests-1191964 ] asynchronous Subprocess Message-ID: Feature Requests item #1191964, was opened at 2005-04-28 13:40 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191964&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: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: asynchronous Subprocess Initial Comment: It would be terribly nice if the Popen class in the subprocess module would allow a programmer to easily say "send some data right now (if I have some to send) and receive whatever information is available right now". Essentially the equivalent of asyncore.loop(count=1), only that it returns the data received, instead of placing it in a buffer. Why would this functionality be useful? Currently, when using the subprocess module with pipes, the interaction with a pipe is limited to "send data if desired, close the subprocess' stdin, read all output from the subprocess' stdout, ...". Certainly one can pull the pipes out of the Popen instance, and perform the necessary functions on posix systems (with select or poll), but the additional magic on WIndows is a little less obvious (but still possible). There is a post by Paul Du Bois with an example using win32pipe.PeekNamedPipe: http://groups-beta.google.com/group/comp.lang.python/msg/115e9332cc1ca09d?hl=en And a message from Neil Hodgeson stating that PeekNamedPipe works on anonymous pipes: http://mail.python.org/pipermail/python-dev/2000-May/004200.html With this modification, creating Expect-like modules for any platform, as well as embedded shells inside any GUI with a text input widget, becomes easy. Heck, even Idle could use it rather than a socket for its interactive interpreter. ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-28 16:22 Message: Logged In: YES user_id=341410 I've got a version of subprocess that has this functionality with pywin32. Making it work on *nix systems with usable select is trivial. About the only question is whether the functionality is desireable, and if so, what kind of API is reasonable. Perhaps adding an optional argument 'wait_for_completion' to the communicate method, which defaults to True for executing what is currently in the body of communicate. If the 'wait_for_completion' argument is untrue, then it does non-waiting asynchronous IO, returning either a 2 or 3-tuple on completion. If input is None, it is a 2-tuple of (stdout, stderr). If input is a string, it is a 3-tuple of (bytes_sent, stdout, stderr). How does that sound? ---------------------------------------------------------------------- Comment By: Dave Schuyler (parameter) Date: 2005-04-28 16:38 Message: Logged In: YES user_id=473331 More control of sub-processes would be great. Several times in the past few years I've done stuff with os.system, popenN, or spawn* and it would be useful to have even more cross-platform consistency and support in this area. Anyway, this is just a vote to encurage other developers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191964&group_id=5470 From noreply at sourceforge.net Sun May 29 01:38:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 May 2005 16:38:40 -0700 Subject: [ python-Feature Requests-1191964 ] asynchronous Subprocess Message-ID: Feature Requests item #1191964, was opened at 2005-04-28 15:40 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191964&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: Josiah Carlson (josiahcarlson) >Assigned to: Peter ?strand (astrand) Summary: asynchronous Subprocess Initial Comment: It would be terribly nice if the Popen class in the subprocess module would allow a programmer to easily say "send some data right now (if I have some to send) and receive whatever information is available right now". Essentially the equivalent of asyncore.loop(count=1), only that it returns the data received, instead of placing it in a buffer. Why would this functionality be useful? Currently, when using the subprocess module with pipes, the interaction with a pipe is limited to "send data if desired, close the subprocess' stdin, read all output from the subprocess' stdout, ...". Certainly one can pull the pipes out of the Popen instance, and perform the necessary functions on posix systems (with select or poll), but the additional magic on WIndows is a little less obvious (but still possible). There is a post by Paul Du Bois with an example using win32pipe.PeekNamedPipe: http://groups-beta.google.com/group/comp.lang.python/msg/115e9332cc1ca09d?hl=en And a message from Neil Hodgeson stating that PeekNamedPipe works on anonymous pipes: http://mail.python.org/pipermail/python-dev/2000-May/004200.html With this modification, creating Expect-like modules for any platform, as well as embedded shells inside any GUI with a text input widget, becomes easy. Heck, even Idle could use it rather than a socket for its interactive interpreter. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-28 18:22 Message: Logged In: YES user_id=341410 I've got a version of subprocess that has this functionality with pywin32. Making it work on *nix systems with usable select is trivial. About the only question is whether the functionality is desireable, and if so, what kind of API is reasonable. Perhaps adding an optional argument 'wait_for_completion' to the communicate method, which defaults to True for executing what is currently in the body of communicate. If the 'wait_for_completion' argument is untrue, then it does non-waiting asynchronous IO, returning either a 2 or 3-tuple on completion. If input is None, it is a 2-tuple of (stdout, stderr). If input is a string, it is a 3-tuple of (bytes_sent, stdout, stderr). How does that sound? ---------------------------------------------------------------------- Comment By: Dave Schuyler (parameter) Date: 2005-04-28 18:38 Message: Logged In: YES user_id=473331 More control of sub-processes would be great. Several times in the past few years I've done stuff with os.system, popenN, or spawn* and it would be useful to have even more cross-platform consistency and support in this area. Anyway, this is just a vote to encurage other developers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191964&group_id=5470 From noreply at sourceforge.net Sun May 29 02:15:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 May 2005 17:15:17 -0700 Subject: [ python-Feature Requests-1191964 ] asynchronous Subprocess Message-ID: Feature Requests item #1191964, was opened at 2005-04-28 13:40 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191964&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: Josiah Carlson (josiahcarlson) Assigned to: Peter ?strand (astrand) Summary: asynchronous Subprocess Initial Comment: It would be terribly nice if the Popen class in the subprocess module would allow a programmer to easily say "send some data right now (if I have some to send) and receive whatever information is available right now". Essentially the equivalent of asyncore.loop(count=1), only that it returns the data received, instead of placing it in a buffer. Why would this functionality be useful? Currently, when using the subprocess module with pipes, the interaction with a pipe is limited to "send data if desired, close the subprocess' stdin, read all output from the subprocess' stdout, ...". Certainly one can pull the pipes out of the Popen instance, and perform the necessary functions on posix systems (with select or poll), but the additional magic on WIndows is a little less obvious (but still possible). There is a post by Paul Du Bois with an example using win32pipe.PeekNamedPipe: http://groups-beta.google.com/group/comp.lang.python/msg/115e9332cc1ca09d?hl=en And a message from Neil Hodgeson stating that PeekNamedPipe works on anonymous pipes: http://mail.python.org/pipermail/python-dev/2000-May/004200.html With this modification, creating Expect-like modules for any platform, as well as embedded shells inside any GUI with a text input widget, becomes easy. Heck, even Idle could use it rather than a socket for its interactive interpreter. ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-28 17:15 Message: Logged In: YES user_id=341410 I suppose I should mention one side-effect of all this. It requires three more functions from pywin32 be included in the _subprocess driver; win32file.ReadFile, win32file.WriteFile, and win32pipe.PeekNamedPipe . Read and Peek are for reading data from stdout and stderr, and Write is for the support for partial writes to stdin. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-28 16:22 Message: Logged In: YES user_id=341410 I've got a version of subprocess that has this functionality with pywin32. Making it work on *nix systems with usable select is trivial. About the only question is whether the functionality is desireable, and if so, what kind of API is reasonable. Perhaps adding an optional argument 'wait_for_completion' to the communicate method, which defaults to True for executing what is currently in the body of communicate. If the 'wait_for_completion' argument is untrue, then it does non-waiting asynchronous IO, returning either a 2 or 3-tuple on completion. If input is None, it is a 2-tuple of (stdout, stderr). If input is a string, it is a 3-tuple of (bytes_sent, stdout, stderr). How does that sound? ---------------------------------------------------------------------- Comment By: Dave Schuyler (parameter) Date: 2005-04-28 16:38 Message: Logged In: YES user_id=473331 More control of sub-processes would be great. Several times in the past few years I've done stuff with os.system, popenN, or spawn* and it would be useful to have even more cross-platform consistency and support in this area. Anyway, this is just a vote to encurage other developers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191964&group_id=5470 From noreply at sourceforge.net Sun May 29 14:23:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 29 May 2005 05:23:50 -0700 Subject: [ python-Bugs-1202533 ] a bunch of infinite C recursions Message-ID: Bugs item #1202533, was opened at 2005-05-15 23:43 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-05-29 12:23 Message: Logged In: YES user_id=4771 Adding a Py_EnterRecursiveCall() in PyObject_Call() seems to fix all the examples so far, with the exception of the "__get__=getattr" one, where we get a strange result instead of a RuntimeError (I suspect careless exception eating is taking place). The main loop in ceval.c doesn't call PyObject_Call() very often: it usually dispatches directly itself for performance, which is exactly what we want here, as recursion from ceval.c is already protected by a Py_EnterRecursiveCall(). So this change has a minor impact on performance. Pystone for example issues only three PyObject_Call() per loop, to call classes. This has an almost-unmeasurable impact ( < 0.4%). Of course I'll think a bit more and search for examples that don't go through PyObject_Call() :-) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-23 13:52 Message: Logged In: YES user_id=4771 When I thought about the same problem for PyPy, I imagined that it would be easy to use the call graph computed by the type inferencer ("annotator"). We would find an algorithm that figures out the minimal number of places that need a Py_EnterRecursiveCall so that every cycle goes through at least one of them. For CPython it might be possible to go down the same path if someone can find a C code analyzer smart enough to provide the required information -- a call graph including indirect calls through function pointers. Not sure it's sane, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-23 13:16 Message: Logged In: YES user_id=6656 I agree with Armin that this could easily be a never ending story. Perhaps it would suffice to sprinkle Py_EnterRecursiveCall around as we find holes. It might have to, because I can't really think of a better way of doing this. The only other approach I know is that of SBCL (a Common Lisp implementation): it mprotects a page at the end of the stack and installs a SIGSEGV handler (and uses sigaltstack) that knows how to abort the current lisp operation. Somehow, I don't think we want to go down this line. Anybody have any other ideas? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-23 13:06 Message: Logged In: YES user_id=21627 It has been a long-time policy that you should not be able to crash the Python interpreter even with malicious code. I think this is a good policy, because it provides people always with a back-trace, which is much easier to analyse than a core dump. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-23 07:41 Message: Logged In: YES user_id=341410 I personally think that the CPython runtime should make a best-effort to not crash when running code that makes sense. But when CPython is running on input that is nonsensical (in each of the examples that Armin provides, no return value could make sense), I think that as long as the behavior is stated clearly, it is sufficient. Certainly it would be nice if CPython did not crash in such cases, but I don't know if the performance penalty and code maintenance outweigh the cases where users write bad code. Perhaps a compile-time option, enabled by default based on whether or not we want a safer or faster CPython. Of course maintenance is still a chore, and it is one additional set of calls that C extension writers may need to be aware of (if their code can be recursively called, and they want to participate in the infinite recursion detection). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-20 21:46 Message: Logged In: YES user_id=4771 Yes, but I'm concerned that we would need to add it really really many places, and probably forget some even then. E.g. I just thought about: lst = [apply] lst.append(lst) apply(*lst) It seems a bit hopeless, honestly... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-20 21:22 Message: Logged In: YES user_id=21627 Wouldn't adding Py_EnterRecursiveCall into many places solve the problem? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-19 15:05 Message: Logged In: YES user_id=4771 This is not about the new module. The same example can be written as: import types class A: pass A.__mul__ = types.MethodType(operator.mul, None, A) If this still looks essentially like an indirect way of using the new module, here is another example: class A(str): __get__ = getattr a = A('a') A.a = a a.a Or, as I just found out, new-style classes are again vulnerable to the older example based __call__, which was fixed for old-style classes: class A(object): pass A.__call__ = A() A()() I'm not denying that these examples look convoluted :-) My point here is that we can basically build a lot of examples based only on core (if not necessarily widely understood) language features. It appears to go against the basic hope that CPython cannot be crashed as long as you don't use features explicitely marked as dangerous. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-19 02:02 Message: Logged In: YES user_id=593130 On Windows, this caused the interactive window to just disappear.so I suspect something similar occurred. New is a known dangerous, use at your own risk, implementation specific module whose use, like byte code hacking, is outside the language proper. Both bypass normal object creation syntax and its checks and both can create invalid objects. A hold-your- hand inplementation would not give such access to internals. Lib Ref 3.28 says "This module provides a low-level interface to the interpreter, so care must be exercised when using this module. It is possible to supply non-sensical arguments which crash the interpreter when the object is used." Should more or different be said? If not, I suspect this should be closed as 'won't fix', as in 'won't remove the inherently dangerous new module'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 From noreply at sourceforge.net Sun May 29 17:28:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 29 May 2005 08:28:44 -0700 Subject: [ python-Bugs-1210832 ] An error in Python Tutorial Message-ID: Bugs item #1210832, was opened at 2005-05-29 23:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210832&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: Gene (godhand) Assigned to: Nobody/Anonymous (nobody) Summary: An error in Python Tutorial Initial Comment: In section 4.4, the program should be written as follow to get the correct result: -------------------------------------------------------------- for n in range(2, 10): for x in range(2, n): if n % x == 0: print n, 'equals', x, '*', n/x break if x == n-1: print n, 'is a prime number' -------------------------------------------------------------- besides, the line "2 is a prime number" should not appear in the result output. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210832&group_id=5470 From noreply at sourceforge.net Mon May 30 00:59:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 29 May 2005 15:59:23 -0700 Subject: [ python-Feature Requests-1210975 ] "break" and "continue"-ing out of nested 'for' loops Message-ID: Feature Requests item #1210975, was opened at 2005-05-29 22:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1210975&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: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Geraint Luff (geraintluff) Assigned to: Nobody/Anonymous (nobody) Summary: "break" and "continue"-ing out of nested 'for' loops Initial Comment: I wasn't entirely sure whether this should go under "Interpreter Core" or "Parser/Compiler", but whatever. At the moment, "break" and "continue" can only break out of the innermost "for" loop. I would appreciate a way of breaking out of multiple 'for' or 'while' loops. This would be extremely useful for instance when you have some 'for' loops cycling through several combinations, and you are using another 'for' loop to check their validity (in my example, checking that my two values are co-prime). In this situation, the only solution I have found is to create a boolean variable that is assigned a value when the check fails, just before 'break'-ing out of a 'for' loop, and immediately after that 'for' loop, having a statement that checks the status of the boolean variable, and then 'continue's or 'breaks' again accordingly. I'm not an experienced programmer, but this strikes me as inefficient :p Sorry if the above explanation is muddled. I can send a short (15 lines) bit of code which might explain it better. BTW, PHP seems to do this with "break 2;" or "continue 2;" which is very useful. --G ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1210975&group_id=5470 From noreply at sourceforge.net Mon May 30 03:43:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 29 May 2005 18:43:03 -0700 Subject: [ python-Feature Requests-1210975 ] "break" and "continue"-ing out of nested 'for' loops Message-ID: Feature Requests item #1210975, was opened at 2005-05-29 17:59 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1210975&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: Python Interpreter Core Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Geraint Luff (geraintluff) Assigned to: Nobody/Anonymous (nobody) Summary: "break" and "continue"-ing out of nested 'for' loops Initial Comment: I wasn't entirely sure whether this should go under "Interpreter Core" or "Parser/Compiler", but whatever. At the moment, "break" and "continue" can only break out of the innermost "for" loop. I would appreciate a way of breaking out of multiple 'for' or 'while' loops. This would be extremely useful for instance when you have some 'for' loops cycling through several combinations, and you are using another 'for' loop to check their validity (in my example, checking that my two values are co-prime). In this situation, the only solution I have found is to create a boolean variable that is assigned a value when the check fails, just before 'break'-ing out of a 'for' loop, and immediately after that 'for' loop, having a statement that checks the status of the boolean variable, and then 'continue's or 'breaks' again accordingly. I'm not an experienced programmer, but this strikes me as inefficient :p Sorry if the above explanation is muddled. I can send a short (15 lines) bit of code which might explain it better. BTW, PHP seems to do this with "break 2;" or "continue 2;" which is very useful. --G ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-29 20:43 Message: Logged In: YES user_id=80475 Sorry, this was considered and rejected long ago. Most other languages have made a similar choice. In Python, the best alternatives include: * try/except which can penetrate multiple layers of looping and/or function calls. * boolean flags * enclosing the innermost loops in a function so that a return statement exits all pending loops within the function. *and try/finally statements which are not a general purpose replacement but do cover a whole class of use cases. For more reading on the subject, take a look at Knuth's Structured Programming with go to Statements. That is a rather thorough analysis of various structured constructs and their strengths and weaknesses. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1210975&group_id=5470 From noreply at sourceforge.net Mon May 30 03:49:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 29 May 2005 18:49:52 -0700 Subject: [ python-Feature Requests-1209664 ] calling it revert is fine with me Message-ID: Feature Requests item #1209664, was opened at 2005-05-27 02:36 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1209664&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: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: calling it revert is fine with me Initial Comment: Calling it revert is fine with me. I don't want to get into an editor war thing, let's just say emacs is what I've always used; it's not a matter of any single "killer feature", it's a highly integrated system and I do everything in it (shell, news reader, email, syntax driven editing for N different languages, etc). I do use IDLE sometimes but comparing IDLE to Emacs is almost like comparing it to Eclipse. They're just light years apart. Btw re editor wars, I'm reminded of the T-shirt with a kid asking "Why are we running from the police, daddy?". The dad answers "Because we use emacs, son. They use vi". ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-29 20:49 Message: Logged In: YES user_id=80475 Please clarify what you're requesting. Is there some IDLE feature you want added or renamed. If this was just an editor rant, please close the RFE. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1209664&group_id=5470 From noreply at sourceforge.net Mon May 30 03:50:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 29 May 2005 18:50:41 -0700 Subject: [ python-Feature Requests-1209562 ] add single html files Message-ID: Feature Requests item #1209562, was opened at 2005-05-26 19:37 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1209562&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: paul rubin (phr) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: add single html files Initial Comment: It would be good if the docs directory on python.org included a "view entire document as one big html page" for each document. If I want to read through a document from beginning to end, it's a big pain to have to keep clicking around at the end of each page, especially if I'm looking at most pages for just a second or so. For the biggest documents (Python library) maybe there could be several sections. Right now the only way to see everything at once is with the PDF, which is much more hassle than browsing html. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1209562&group_id=5470 From noreply at sourceforge.net Mon May 30 09:59:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 00:59:18 -0700 Subject: [ python-Bugs-1210377 ] Cursors not correctly closed after exception. Message-ID: Bugs item #1210377, was opened at 2005-05-28 14:48 Message generated for change (Comment added) made by ragnar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210377&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ragnar Ouchterlony (ragnar) Assigned to: Nobody/Anonymous (nobody) Summary: Cursors not correctly closed after exception. Initial Comment: If an exception occurs when going through a database, the cursors will not be correctly reset. If I manually set the cursor to None (by doing db.dbc = None) it will work fine. >>> db = bsddb.btopen('/tmp/test.db', 'c') >>> db.first() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/bsddb/__init__.py", line 264, in first rv = self.dbc.first() _bsddb.DBNotFoundError: (-30990, 'DB_NOTFOUND: No matching key/data pair found') >>> db['foo'] = 'bar' Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/bsddb/__init__.py", line 217, in __setitem__ self._closeCursors() File "/usr/lib/python2.4/bsddb/__init__.py", line 192, in _closeCursors self.saved_dbc_key = c.current(0,0,0)[0] bsddb._db.DBInvalidArgError: (22, 'Invalid argument -- Cursor position must be set before performing this operation') Here, I first open a new database. Since it is empty, db.first() will fail. When I after that try to add a key/value pair to the database it fails, since it tries to close an invalid cursor. >>> db = bsddb.btopen('/tmp/test.db', 'c') >>> db.first() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/bsddb/__init__.py", line 264, in first rv = self.dbc.first() _bsddb.DBNotFoundError: (-30990, 'DB_NOTFOUND: No matching key/data pair found') >>> db.dbc = None >>> db['foo'] = 'bar' >>> db {'foo': 'bar'} Here I do "db.dbc = None" after the exception and now it works just fine. ---------------------------------------------------------------------- >Comment By: Ragnar Ouchterlony (ragnar) Date: 2005-05-30 09:59 Message: Logged In: YES user_id=1394 The bugreport refers to bsddb. I did not make that entirely clear. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210377&group_id=5470 From noreply at sourceforge.net Mon May 30 10:32:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 01:32:31 -0700 Subject: [ python-Bugs-1207466 ] installer ignores changed installation directory Message-ID: Bugs item #1207466, was opened at 2005-05-24 04:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207466&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: Installation Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Blubb Fallo (blubbfallo) >Assigned to: Martin v. L?wis (loewis) Summary: installer ignores changed installation directory Initial Comment: concerning python-2.4.1.msi at win2000 sp4 After having spent quite some time at python.org to find out if I had to remove 2.4 before installing 2.4.1 (without any success, btw) I dared to start overinstalling. 1. Unfortunately, I didn't recognize that the suggested directory was different from where I wanted Python to stay in. Now, there seems to be no way back except completele un- and reinstalling: 2. I run the installer again and selected "change Python 2.4.1", then clicked "back", choosing the right directory, then went on to "next" and on, but my directory choice was ignored. 3. Finally, I run the installer at commandline, specifying TARGETDIR, chose the "change Python 2.4.1" radiobutton ... and again, Python was reinstalled as if TARGETDIR wasn't given. Paths containing spaces are not involved. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-05-30 10:32 Message: Logged In: YES user_id=21627 1. Correct, this is indeed the case. However, this sounds like an operator error, not a bug in Python. 2. Correct. It never occurred to me that somebody would try to move the installation in a "modify" installation. I will fix this by disabling the "back" button. 3. Likewise, however, this is an operator error. You shouldn't be specifying TARGETDIR in the "modify" mode. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207466&group_id=5470 From noreply at sourceforge.net Mon May 30 10:34:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 01:34:57 -0700 Subject: [ python-Bugs-1201461 ] suspected cPickle memory leak Message-ID: Bugs item #1201461, was opened at 2005-05-13 17:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201461&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: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Alan (franz2) Assigned to: Nobody/Anonymous (nobody) Summary: suspected cPickle memory leak Initial Comment: I believe there is a memory leak in cPickle. I have a parallel code which uses array() and indices() from Numeric to massage data buffers before being sent and received by Pypar. Pypar subsequently uses cPickle to pickle the data. After many hours of execution, my code crashes with one of the following error messages (depending upon the run): a = zeros(shape, typecode, savespace) MemoryError: can't allocate memory for array or: s = dumps(x, 1) MemoryError: out of memory I have since modified my code to use a different data format so cPickle is no longer used from PyPar and now the code runs fine. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-05-30 10:34 Message: Logged In: YES user_id=21627 Can you provide a test case that demonstrates how the memory is exhausted? Without a test case, it is unlikely that we will be able to find the suspected leak. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201461&group_id=5470 From noreply at sourceforge.net Mon May 30 10:37:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 01:37:06 -0700 Subject: [ python-Feature Requests-1208730 ] expat binding for XML_ParserReset Message-ID: Feature Requests item #1208730, was opened at 2005-05-25 22:37 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1208730&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: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Eikenberry (zhar) Assigned to: Nobody/Anonymous (nobody) Summary: expat binding for XML_ParserReset Initial Comment: XML_ParserReset is an expat parser method for resetting the parser to handle a new document. This keeps you from having to create a new parser for each document. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-05-30 10:37 Message: Logged In: YES user_id=21627 Would you like to work on a patch for this feature? Exposing more methods from Expat is a good idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1208730&group_id=5470 From noreply at sourceforge.net Mon May 30 10:38:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 01:38:00 -0700 Subject: [ python-Feature Requests-1193610 ] Expat Parser to supply document locator in incremental parse Message-ID: Feature Requests item #1193610, was opened at 2005-05-02 08:12 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1193610&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: None Status: Open Resolution: None >Priority: 6 Submitted By: GaryD (gazzadee) >Assigned to: Martin v. L?wis (loewis) Summary: Expat Parser to supply document locator in incremental parse Initial Comment: The standard Expat SAX Parser supplied with Python (xml.sax.expatreader.ExpatParser) does not set the document locator (using ContentHandler.setDocumentLocator) when you are doing an incremental parse (ie. using feed instead of parse), although it does supply the locator when you do a full parse. Is there a reason why this is so, or is it just an oversight? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1193610&group_id=5470 From noreply at sourceforge.net Mon May 30 11:23:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 02:23:20 -0700 Subject: [ python-Bugs-1071094 ] some latex reject the pdfinfo macro while generating html Message-ID: Bugs item #1071094, was opened at 2004-11-22 17:15 Message generated for change (Comment added) made by stroeder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071094&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: Marc-Antoine Parent (maparent) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: some latex reject the pdfinfo macro while generating html Initial Comment: I was building the documentation on OSX. I use the latest LaTeX 2004 from Wierda's teTeX. There is a pdfinfo command in Doc/ texinputs/manual.cls and Doc/texinputs/howto.cls which chokes my version of latex. edited log follows: TEXINPUTS=/.../Python-2.4c1/Doc/commontex: python /.../Python -2.4c1/Doc/tools/mkhowto --html --about html/stdabout.dat -- iconserver ../icons --favicon ../icons/pyfav.png --address "See About this document... for information on suggesting changes." --up-link ../index.html --up- title "Python Documentation Index" --global-module-index "../ modindex.html" --dvips-safe --dir html/api api/api.tex +++ TEXINPUTS=/.../Python-2.4c1/ Doc/api:/.../Python-2.4c1/Doc/ commontex:/.../Python-2.4c1/Doc/ paper-letter:/.../Python-2.4c1/Doc/ texinputs: +++ latex api *** Session transcript and error messages are in /.../Python -2.4c1/Doc/html/api/api.how. *** Exited with status 1. The relevant lines from the transcript are: ------------------------------------------------------------------------ +++ latex api This is pdfeTeX, Version 3.141592-1.20a-2.2 (Web2C 7.5.3) output format initialized to DVI entering extended mode (/.../Python-2.4c1/Doc/api/api.tex LaTeX2e <2003/12/01> Babel and hyphenation patterns for american, french, german, ngerman, nohyphenation, loaded. (/.../Python-2.4c1/Doc/texinputs/manual.cls Document Class: manual 1998/03/03 Document class (Python manual) (/.../Python-2.4c1/Doc/texinputs/pypaper.sty (/usr/local/teTeX/share/texmf.tetex/tex/latex/psnfss/times.sty) Using Times instead of Computer Modern. ) (/usr/local/teTeX/share/texmf.tetex/tex/latex/fancybox/ fancybox.sty Style option: `fancybox' v1.3 <2000/09/19> (tvz) ) (/usr/local/teTeX/share/texmf.tetex/tex/latex/base/report.cls Document Class: report 2004/02/16 v1.4f Standard LaTeX document class (/usr/local/teTeX/share/texmf.tetex/tex/latex/base/size10.clo)) (/.../Python-2.4c1/Doc/texinputs/fancyhdr.sty) Using fancier footers than usual. (/.../Python-2.4c1/Doc/texinputs/fncychap.sty) Using fancy chapter headings. (/.../Python-2.4c1/Doc/texinputs/python.sty (/usr/local/teTeX/share/texmf.tetex/tex/latex/tools/longtable.sty) (/usr/local/teTeX/share/texmf.tetex/tex/latex/tools/verbatim.sty) (/usr/local/teTeX/share/texmf.tetex/tex/latex/base/alltt.sty))) (/.../Python-2.4c1/Doc/commontex/boilerplate.tex (/.../Python-2.4c1/Doc/commontex/patchlevel.tex)) Writing index file api.idx No file api.aux. (/usr/local/teTeX/share/texmf.tetex/tex/latex/psnfss/ot1ptm.fd) pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set. { \def \{, } \pdfinfo { /Author (\@author ) /Title (\@title ) } } l.12 \maketitle No pages of output. Transcript written on api.log. *** Session transcript and error messages are in /.../Python -2.4c1/Doc/html/api/api.how. *** Exited with status 1. make: *** [html/api/api.html] Error 1 ---------------------------------------------------------------------- Comment By: Michael Str?der (stroeder) Date: 2005-05-30 11:23 Message: Logged In: YES user_id=64920 This patch I got from a tex expert seems to fix it. It should also be applied to howto.cls. --- manual.cls.orig 2005-05-30 10:02:28.000000000 +0200 +++ manual.cls 2005-05-30 11:16:58.000000000 +0200 @@ -6,9 +6,17 @@ \ProvidesClass{manual} [1998/03/03 Document class (Python manual)] +\RequirePackage{ifpdf} +\newcommand*{\@ifpdftexisnotavailable}{% + \ifpdf + \expandafter\@secondoftwo + \else + \expandafter\@firstoftwo + \fi +} + \RequirePackage{pypaper} \RequirePackage{fancybox} - % Change the options here to get a different set of basic options, but only % if you have to. Paper and font size should be adjusted in pypaper.sty. % @@ -64,7 +72,7 @@ \let\footnotesize\small \let\footnoterule\relax \py at doHorizontalRule% - \@ifundefined{pdfinfo}{}{{ + \@ifpdftexisnotavailable{}{{ % This \def is required to deal with multi-line authors; it % changes \ to ', ' (comma-space), making it pass muster for % generating document info in the PDF file. ---------------------------------------------------------------------- Comment By: Michael Str?der (stroeder) Date: 2005-05-17 23:09 Message: Logged In: YES user_id=64920 I also have this problem when trying to build python-ldap's docs on SuSE Linux 9.3 which ships with tetex-3.0-13 and te_latex-3.0-13. You might wanna take note of this: http://www.latex-project.org/cgi-bin/ltxbugs2html?pr=latex/3640&state=open It refers to this module: http://www.tex.ac.uk/tex-archive/macros/latex/contrib/oberdiek/ifpdf.sty ---------------------------------------------------------------------- Comment By: S?bastien Maret (bmaret) Date: 2005-04-18 21:53 Message: Logged In: YES user_id=842097 I get the exact same error. I am running MacOSX with teTeX 3.0 installed with Fink. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071094&group_id=5470 From noreply at sourceforge.net Mon May 30 20:00:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 11:00:09 -0700 Subject: [ python-Bugs-516232 ] Windows os.path.isdir bad if drive only Message-ID: Bugs item #516232, was opened at 2002-02-11 19:50 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=516232&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: Extension Modules Group: Python 2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Charles I. Fuller (cifuller) Assigned to: Nobody/Anonymous (nobody) Summary: Windows os.path.isdir bad if drive only Initial Comment: It seems that most os functions recognize the Windows drive letter without a directory as the current directory on the drive, but os.path.isdir still returns 0. If os.listdir('C:') returns data, os.path.isdir('C:') should return 1 for consistency. C:\folder_on_C>python Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.system('dir C:') Volume in drive C has no label. Volume Serial Number is E4C9-AD16 Directory of C:\folder_on_C 02/11/2002 05:29p <DIR> . 02/11/2002 05:29p <DIR> .. 02/11/2002 05:29p <DIR> subA 02/11/2002 05:29p <DIR> subB 0 File(s) 0 bytes 4 Dir(s) 22,126,567,424 bytes free 0 >>> os.listdir('C:') ['subA', 'subB'] >>> os.path.abspath('C:') 'C:\folder_on_C' >>> os.path.isdir('C:') 0 ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 15:00 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-03-21 16:30 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-02-12 19:33 Message: Logged In: YES user_id=31435 Well, the underlying Microsoft routines are themselves inconsistent, and in undocumented ways. We make a mild effort to hide their warts, but it's historical truth that doing so introduces other bugs. The sad fact is that MS stat() insists "C:" does not exist, but the MS FindFirstFile happily accepts "C:". If you think *you* can straigten this inherited mess out, happy to accept a patch <wink>. ---------------------------------------------------------------------- Comment By: Charles I. Fuller (cifuller) Date: 2002-02-12 18:54 Message: Logged In: YES user_id=211047 Responding to Tim's followup... In this case the 'C:' is not the root drive, it is the current dir on that drive. I noticed that os.path.abspath was updated between 2.0 and 2.2 to recognize the current dir. It's an inconsistency that tripped me up already. >>> os.path.isdir('C:') 0 >>> os.path.isdir(os.path.abspath('C:')) 1 The listdir has been working with drive specs (recognizing the current dir) for a while. The abspath code must be handling the drive-only input as a special case. The isdir function should do the same for consistency. There should at least be a warning in the docs... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-02-11 20:16 Message: Logged In: YES user_id=31435 Sorry, this is how Microsoft's implementation of the underlying stat() function works. "Root drive" paths must be given with a trailing slash or backslash, else MS stat() claims they don't exist. You'll see the same irritating behavior in C code. Attempts to worm around it in the past have introduced other bugs; see bug 513572 for a current example. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=516232&group_id=5470 From noreply at sourceforge.net Mon May 30 20:03:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 11:03:30 -0700 Subject: [ python-Bugs-549081 ] test_signal hangs -- signal broken on OpenBSD? Message-ID: Bugs item #549081, was opened at 2002-04-26 10:54 Message generated for change (Settings changed) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549081&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: Installation Group: Python 2.2.1 candidate >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Noah Spurrier (noah) Assigned to: Nobody/Anonymous (nobody) Summary: test_signal hangs -- signal broken on OpenBSD? Initial Comment: This appears to be similar to bug as PR#288, [ 210635 ] test_signal hangs when running as part of testall (PR#288) except that I have this problem on a fresh install of OpenBSD 3.0 while trying to build Python-2.2.1. I did a generic build running as root: ./configure ./make ./make test Yours, Noah ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 15:03 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 19:02 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Frallan the master Jedi (frallan) Date: 2003-12-11 09:14 Message: Logged In: YES user_id=639616 My test program now works. It both terminates and prints the 'got signal' message. Current Platform is: OpenBSD somewhere 3.3 GENERIC#44 i386 Python 2.3.2 (#1, Dec 1 2003, 11:20:01) [GCC 2.95.3 20010125 (prerelease, propolice)] on openbsd3 I should receive my OpenBSD 3.4 CDs soon. Then I'll test that too. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-31 07:49 Message: Logged In: YES user_id=6656 As far as I am aware (not very) Python signals have always been broken on OpenBSD. None of the Python core developers use OpenBSD, though, so it's always remained a mystery. frallan, does the C equivalent of your Python test work? Do you have any idea what Python (or OpenBSD, maybe) is doing wrong? signals are pain. ---------------------------------------------------------------------- Comment By: Frallan the master Jedi (frallan) Date: 2002-10-31 06:48 Message: Logged In: YES user_id=639616 I get the exact same behavior on OpenBSD 3.1 with Python- 2.2.2. Also this simple test program from the "Python Standard Library" book - fails. The program terminates but the "got signal" message is never printed. import signal import time def handler (signo, frame): print 'got signal', signo signal.signal(signal.SIGALRM, handler) # wake me up in two seconds signal.alarm(2) now = time.time() time.sleep(200) print 'slept for', time.time() - now, "seconds" ---------------------------------------------------------------------- Comment By: Noah Spurrier (noah) Date: 2002-04-27 12:40 Message: Logged In: YES user_id=59261 Below is the output of test_signal.py. I ran it manually. I modified it slightly to print out the pid; the return values from the signal calls; and to print a count of the loop iteration (starting at 1). You can see that after Count 4 it just sits there. After about a minute I hit Ctrl- Z. I have uploaded the modified version of test_signal.py. ... bash-2.05# python test_signal.py pid: 8606 signal.alarm(20): 0 signal.signal(5, handlerA): 0 signal.signal(2, handlerB): <built-in function default_int_handler> signal.signal(3, signal.SIG_IGN): 0 signal.signal(signal.SIGALRM, signal.default_int_handler): 0 starting pause() loop... + sleep 2 count: 1 call pause()... + kill -5 8606 pause() returned + sleep 2 count: 2 call pause()... + kill -2 8606 pause() returned + sleep 2 count: 3 call pause()... + kill -3 8606 pause() returned count: 4 call pause()... ^Z [1]+ Stopped python test_signal.py bash-2.05# ps -p 8606 PID TT STAT TIME COMMAND 8606 p0 T 0:00.09 python test_signal.py bash-2.05# uname -a OpenBSD nobot 3.0 GENERIC#94 i386 bash-2.05# python Python 2.2.1 (#4, Apr 26 2002, 23:06:40) [GCC 2.95.3 20010125 (prerelease)] on openbsd3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549081&group_id=5470 From noreply at sourceforge.net Mon May 30 20:26:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 11:26:27 -0700 Subject: [ python-Bugs-768649 ] popen4 doesn't close filedescriptors when in Threads Message-ID: Bugs item #768649, was opened at 2003-07-09 15:36 Message generated for change (Settings changed) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768649&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: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: martin doudoroff (mdoudoroff) Assigned to: Nobody/Anonymous (nobody) Summary: popen4 doesn't close filedescriptors when in Threads Initial Comment: Running the following code under Linux will result in a crash on the 508th thread started. The error is OSError: [Errno 24] Too many open files The nature of the bug seems to be that Python isn't closing filedescriptors cleanly when running a thread. --------------------------------------- import os from threading import Thread class Crash(Thread): def run(self): a = os.popen4('ls') b = a[1].read() # uncommenting these lines fixes the problem # but this isn't really documented as far as # we can tell... # a[0].close() # a[1].close() for i in range(1000): t = Crash() t.start() while t.isAlive(): pass print i --------------------------------------- The same code without threads (Crash as a plain class) doesn't crash, so the descriptor must be getting taken care of when the run() method is exited. import os class Crash: def run(self): a = os.popen4('ls') b = a[1].read() for i in range(1000): t = Crash() t.run() print i ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 17:48 Message: Logged In: YES user_id=752496 Works fine to me: Python 2.3.4 (#1, Oct 26 2004, 16:42:40) [GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2 with glibc-2.3.4-2 ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 17:48 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-10-01 15:51 Message: Logged In: YES user_id=139865 Duplicated with Python 2.3 on Red Hat 7.3 using glibc-2.2.5-43. Popen3.{poll,wait} are written under the incorrect assumption that waitpid can monitor any process in the same process group, when it only works for immediate children. _active.remove is never called, so Popen3 objects are never destroyed and the associated file descriptors are not returned to the operating system. A general solution for Popen[34] is not obvious to me. With patch #816059, popen2.popen[234] plugs the _active leak, which in turn returns the file descriptors to the operating system when the file objects that popen2.popen[234] return go out of scope. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-10 00:20 Message: Logged In: YES user_id=33168 I can't duplicate this on Redhat 9. What OS, what version of glibc and what kernel are you using? Does it always crash on the 508th iteration? I tested with both 2.2.3 and 2.3b2 from CVS without problems. I even used ulimit to set my open files to 10. Can you try the patch in bug #761888 to see if that helps? http://pythong.org/sf/761888 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768649&group_id=5470 From noreply at sourceforge.net Mon May 30 20:27:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 11:27:57 -0700 Subject: [ python-Bugs-763190 ] Sudden death with SIGSEGV in RtlEnterCriticalSection Message-ID: Bugs item #763190, was opened at 2003-06-30 10:34 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763190&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: Threads Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Maria Martinsdotter (dehex) Assigned to: Nobody/Anonymous (nobody) Summary: Sudden death with SIGSEGV in RtlEnterCriticalSection Initial Comment: Environment: Python 2.2.2 win32all-150 Win2000 Server Dell server 2 CPU Pentuim 4 emulating 4 CPU's. Application: Service with many (50-150) threads. Problem: The entire service exits unexepectedly with only a brief reference made by Dr.Watson indicating the Windows equivalent of SIGSEGV in RtlEnterCriticalSection. Side info: Known to have happened once, we believe it may have happened three times in total but the two extra did not leave even a Dr.Watson trace. The known occurrence can be connected to our use of a timer where the action routine restarts the timer. The two extra's occurred at a point in time that connect the problem event to the timer expiration. The application have been used for five months, runnning around the clock. The customer installation currently use five instances of the base software, only configuration differs. It is arbitrary which instance fail. We have no means to trigger the problem. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 15:27 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 16:40 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Maria Martinsdotter (dehex) Date: 2003-06-30 19:00 Message: Logged In: YES user_id=807857 Apart from what we initially reported, no extensions are used. It is all pure Python and the only part of win32all used is the support for running it as a service. We are aware of the enhancements provided by 2.3 beta but let it suffice to say that the customer is picky. We have not been able to reproduce the problem in our test environment, however the hardware is not as sophisticated. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 12:13 Message: Logged In: YES user_id=33168 Are there any other C/Extension modules used which are not from the standard python distribution? Can you make a self contained test case? I encourage you to test with 2.3 beta 2. There were some thread changes which could affect this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763190&group_id=5470 From noreply at sourceforge.net Mon May 30 20:30:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 11:30:46 -0700 Subject: [ python-Bugs-756940 ] can't CNTRL-C when running os.system in a thread Message-ID: Bugs item #756940, was opened at 2003-06-18 20:52 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756940&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: Threads Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Greg Jones (morngnstar) Assigned to: Nobody/Anonymous (nobody) Summary: can't CNTRL-C when running os.system in a thread Initial Comment: This is related to Bug #756924. When os.system is called in a thread, Control-C is ignored. Steps to reproduce: 1. Download the attached file fibonacci.py. 2. Run python2.2 fibonacci.py. 3. Hit CNTRL-C. fibonacci.py starts a thread that executes fibonacci.py again (but with a flag to prevent this from recursing infinitely). Then it computes and prints the Fibonacci sequence, the slow way. The process executed in the thread redirects this to a file to avoid conflict over stdout. All this is just to give the program something to do while you hit CNTRL-C. Expected, and Python 2.1 behavior: You get a KeyboardInterrupt exception, a stack trace, and the program exits. Actual Python 2.2 behavior: No response. You have to run kill on the process. Maybe this is not a bug, but rather a limitation of Linux, since I understand SIGINT is blocked during the C function 'system'. However, CNTRL-C worked in Python 2.1, and that was nicer. Removing the lines of code described in Bug #756924 also fix this bug. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 15:30 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 16:23 Message: Logged In: YES user_id=752496 The other bug have a very long discussion about this, and talks about patches to be applied to Py2.4, and the last patch is actually accepted. Maybe this is already fixed, please give it a try. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 16:23 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Greg Jones (morngnstar) Date: 2003-06-18 23:58 Message: Logged In: YES user_id=554883 OS is Linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756940&group_id=5470 From noreply at sourceforge.net Mon May 30 20:51:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 11:51:09 -0700 Subject: [ python-Bugs-737202 ] CGIHTTPServer does not handle scripts in sub-dirs Message-ID: Bugs item #737202, was opened at 2003-05-13 14:54 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737202&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: Python Library >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Goebel (htgoebel) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer does not handle scripts in sub-dirs Initial Comment: CGIHTTPServer does not handle scripts in sub directoreis correctly: When accessing eg. '/cgi-bin/scripts/bla', CGIHTTPServer returns 404 CGI script is not a plain file ('/cgi-bin/script') This tracked down to CGIHTTPRequestHandler.run_cgi() containing these lines: i = rest.find('/') if i >= 0: script, rest = rest[:i], rest[i:] else: script, rest = rest, '' scriptname = dir + '/' + script This will move the dir-part of the 'rest' into 'script', but leave the actual filename in 'rest'. The 'scriptname' thus does miss the filename. I assume this should become simply: script, rest = rest, '' scriptname = dir + '/' + script ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 15:51 Message: Logged In: YES user_id=752496 The example shows the problem in Py2.4.1. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2005-01-17 02:31 Message: Logged In: YES user_id=23486 Verified proper behavior does not work in 2.2, 2.3, 2.4, or current CVS. The attached patches are just a filename; you should try downloading them to be sure they're actually a patch ;). A simpe self-contained example is at http://issola.caltech.edu/~t/transfer/python-bug737202-example.tgz it works under Python 2.2 or greater & demonstrates the problem. A patch for the current CVS HEAD is at http://issola.caltech.edu/~t/transfer/python-bug737202-patch.diff and 2.4 should probably be back-patched as well. ---------------------------------------------------------------------- Comment By: Hartmut Goebel (htgoebel) Date: 2005-01-16 12:11 Message: Logged In: YES user_id=376953 Encloded please find a testcase. I've checkt it with 2.3.3. Buf should still persist in 2.3.4 and 2.4. I've checked the CVS diffs and there is no change which would solve it. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 15:42 Message: Logged In: YES user_id=752496 Both bugs are for the same problem, keeping this alive (because it has the patch), closing the other as Duplicate. Regarding the patch, the actual code has something very similar to it, so maybe the bug is already fixed... ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 15:42 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2004-12-19 03:20 Message: Logged In: YES user_id=23486 same as bug 778804, assigned to esr. ---------------------------------------------------------------------- Comment By: Hartmut Goebel (htgoebel) Date: 2003-05-23 10:21 Message: Logged In: YES user_id=376953 I rethought this: The reason for this type of split is to make it possible to pass parameters as part of the URL, like Zope does. So the snippet above should be changed to something like this: i = 0 while 1: # get the next path-element out of the url i = rest.find('/', i) if i >= 0: script, rest = rest[:i], rest[i:] else: script, rest = rest, '' scriptname = dir + '/' + script scriptfile = self.translatepath(scriptname) if os.isdir(scriptname): # if scriptname is a directory, continue "walking" the url continue # scriptname is not a directory, stop "walking" the url break Patch is included. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737202&group_id=5470 From noreply at sourceforge.net Mon May 30 20:57:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 11:57:46 -0700 Subject: [ python-Bugs-730222 ] socketmodule.c: inet_pton() expects 4-byte packed_addr Message-ID: Bugs item #730222, was opened at 2003-04-30 12:00 Message generated for change (Settings changed) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730222&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: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: John Marshall (john_marshall) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule.c: inet_pton() expects 4-byte packed_addr Initial Comment: In the Modules/socketmodule.c file, the inet_pton function implicitly treats "long packed_addr" as a 4-byte object or expects that the required 4-bytes is at &packed_addr[0]-[3]. This is not true under SUPER-UX/SX. In order to get this working right, I changed the data type from "long" to "int". This now works properly. -----Modules/socketmodule.c: #3825 /* 042303; JM; this routine really expects a 4-byte packed_addr * not a long; long on SX is 8-bytes! */ #if SX int packed_addr; #else long packed_addr; #endif ... if (packed_addr == INADDR_NONE) return 0; memcpy(dst, &packed_addr, 4); ----- ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 15:57 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. . Facundo ---------------------------------------------------------------------- Comment By: John Marshall (john_marshall) Date: 2005-01-17 12:52 Message: Logged In: YES user_id=768577 I no longer have access to SUPER-UX/SX systems, but the problem must still exist since nothing has changed in the source (I just checked that "long packed_addr" is still used -- SUPER-UX/SX systems support 8-byte longs). The more general patch supplied by nnorwitz should do the trick, though. Thanks, John ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 15:04 Message: Logged In: YES user_id=752496 This patch is no applied, the bug persists? ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 15:04 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 00:32 Message: Logged In: YES user_id=33168 Attached is a patch which should fix the problem. There was one other place that needed to be changed. This change is more generic. Let me know if it works for you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730222&group_id=5470 From noreply at sourceforge.net Mon May 30 20:59:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 11:59:31 -0700 Subject: [ python-Bugs-728515 ] mmap's resize method resizes the file in win32 but not unix Message-ID: Bugs item #728515, was opened at 2003-04-27 14:44 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&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: Extension Modules Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Myers Carpenter (myers_carpenter) Assigned to: Nobody/Anonymous (nobody) Summary: mmap's resize method resizes the file in win32 but not unix Initial Comment: In the resize method under win32 you have something like this: /* Move to the desired EOF position */ SetFilePointer (self->file_handle, new_size, NULL, FILE_BEGIN); /* Change the size of the file */ SetEndOfFile (self->file_handle); Which resizes the file Under Unix you need to call ftruncate(self->fileno, new_size) before calling remap() to make it do the same thing. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 15:59 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 14:55 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 09:36 Message: Logged In: YES user_id=21627 Would you like to contribute a patch? Please make sure to include changes to the documentation and test suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&group_id=5470 From noreply at sourceforge.net Mon May 30 21:02:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 12:02:46 -0700 Subject: [ python-Bugs-727241 ] Core Dumps : Python2.2.2 Message-ID: Bugs item #727241, was opened at 2003-04-24 19:16 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727241&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.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Eli Rosenberg (elirosenberg) Assigned to: Nobody/Anonymous (nobody) Summary: Core Dumps : Python2.2.2 Initial Comment: Hello, I am able to cause python to core dump on IRIX 6.5.18 and above with the code listed below. I have compiled with 3 versions of gcc as well as MIPSpro. Running this code with a valid host and a port that will cause a connection refused socket error produces a core dump with the the stack trace below. >>> import socket >>> x=socket.socket() >>> x.connect(('www.google.com', 1234)) > 0 realfree(0x10162e98, 0x0, 0x200000, 0x65637469, 0x17dd4, 0x1, 0x1, 0x8) ["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":527, 0xfb245fc] 1 cleanfree(0x0, 0x0, 0x200000, 0x65637469, 0x17dd4, 0x1, 0x1, 0x8) ["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":945, 0xfb24e44] 2 __malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4, 0x1, 0x1, 0x8) ["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":230, 0xfb24078] 3 _malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4, 0x1, 0x1, 0x8) ["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":186, 0xfb23ee4] 4 _PyObject_GC_Malloc(tp = 0x1013fbe0, nitems = 0) ["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":868, 0x10092244] 5 _PyObject_GC_New(tp = 0x1013fbe0) ["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":895, 0x10092368] 6 newtracebackobject(next = (nil), frame = 0x1016b670, lasti = 21, lineno = 1) ["/usr/people/eli/Python-2.2.2/Python/traceback.c":115, 0x100c6684] 7 PyTraceBack_Here(frame = 0x1016b670) ["/usr/people/eli/Python-2.2.2/Python/traceback.c":133, 0x100c67f4] 8 eval_frame(f = 0x1016b670) ["/usr/people/eli/Python-2.2.2/Python/ceval.c":2238, 0x1004e894] 9 PyEval_EvalCodeEx(co = 0x1016e990, globals = 0x1016a5d0, locals = 0x1016a5d0, args = (nil), argcount = 0, kws = (nil), kwcount = 0, defs = (nil), defcount = 0, closure = (nil)) ["/usr/people/eli/Python-2.2.2/Python/ceval.c":2595, 0x1004ffe0 10 PyEval_EvalCode(co = 0x1016e990, globals = 0x1016a5d0, locals = 0x1016a5d0) ["/usr/people/eli/Python-2.2.2/Python/ceval.c":481, 0x10047ea0] 11 run_node(n = 0x101a5b28, filename = 0x1014e978 = "<stdin>", globals = 0x1016a5d0, locals = 0x1016a5d0, flags = 0x7fff2e2c) ["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":1079, 0x1006f380] 12 PyRun_InteractiveOneFlags(fp = 0xfb53680, filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c) ["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":590, 0x1006d57c] 13 PyRun_InteractiveLoopFlags(fp = 0xfb53680, filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c) ["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":526, 0x1006d198] 14 PyRun_AnyFileExFlags(fp = 0xfb53680, filename = 0x1014e978 = "<stdin>", closeit = 0, flags = 0x7fff2e2c) ["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":489, 0x1006cf48] 15 Py_Main(argc = 1, argv = 0x7fff2f24) ["/usr/people/eli/Python-2.2.2/Modules/main.c":364, 0x1000fa44] 16 main(argc = 1, argv = 0x7fff2f24) ["/usr/people/eli/Python-2.2.2/Modules/python.c":10, 0x1000ecdc] 17 __start() ["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":177, 0x1000ec78] I compiled Python 64-bit and the code above appears not to cause a segfault but the code below will bus error after a few iterations. import socket import time def doit(): s = socket.socket() start = time.time() try: s.connect(('www.cnn.com', 80)) except socket.error,e: print repr(e),str(e) finish = time.time() time.sleep(.5) print str(finish-start),"\n" s.close() for x in xrange(10): doit() Here is the stack trace: > 0 realfree(0x10162e98, 0x0, 0x200000, 0x65637469, 0x17dd4, 0x1, 0x1, 0x8) ["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":527, 0xfb245fc] 1 cleanfree(0x0, 0x0, 0x200000, 0x65637469, 0x17dd4, 0x1, 0x1, 0x8) ["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":945, 0xfb24e44] 2 __malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4, 0x1, 0x1, 0x8) ["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":230, 0xfb24078] 3 _malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4, 0x1, 0x1, 0x8) ["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":186, 0xfb23ee4] 4 _PyObject_GC_Malloc(tp = 0x1013fbe0, nitems = 0) ["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":868, 0x10092244] 5 _PyObject_GC_New(tp = 0x1013fbe0) ["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":895, 0x10092368] 6 newtracebackobject(next = (nil), frame = 0x1016b670, lasti = 21, lineno = 1) ["/usr/people/eli/Python-2.2.2/Python/traceback.c":115, 0x100c6684] 7 PyTraceBack_Here(frame = 0x1016b670) ["/usr/people/eli/Python-2.2.2/Python/traceback.c":133, 0x100c67f4] 8 eval_frame(f = 0x1016b670) ["/usr/people/eli/Python-2.2.2/Python/ceval.c":2238, 0x1004e894] 9 PyEval_EvalCodeEx(co = 0x1016e990, globals = 0x1016a5d0, locals = 0x1016a5d0, args = (nil), argcount = 0, kws = (nil), kwcount = 0, defs = (nil), defcount = 0, closure = (nil)) ["/usr/people/eli/Python-2.2.2/Python/ceval.c":2595, 0x1004ffe0 10 PyEval_EvalCode(co = 0x1016e990, globals = 0x1016a5d0, locals = 0x1016a5d0) ["/usr/people/eli/Python-2.2.2/Python/ceval.c":481, 0x10047ea0] 11 run_node(n = 0x101a5b28, filename = 0x1014e978 = "<stdin>", globals = 0x1016a5d0, locals = 0x1016a5d0, flags = 0x7fff2e2c) ["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":1079, 0x1006f380] 12 PyRun_InteractiveOneFlags(fp = 0xfb53680, filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c) ["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":590, 0x1006d57c] 13 PyRun_InteractiveLoopFlags(fp = 0xfb53680, filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c) ["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":526, 0x1006d198] 14 PyRun_AnyFileExFlags(fp = 0xfb53680, filename = 0x1014e978 = "<stdin>", closeit = 0, flags = 0x7fff2e2c) ["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":489, 0x1006cf48] 15 Py_Main(argc = 1, argv = 0x7fff2f24) ["/usr/people/eli/Python-2.2.2/Modules/main.c":364, 0x1000fa44] 16 main(argc = 1, argv = 0x7fff2f24) ["/usr/people/eli/Python-2.2.2/Modules/python.c":10, 0x1000ecdc] 17 __start() ["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":177, 0x1000ec78] Any help would be appreciated. thanks. -Eli ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 16:02 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 14:54 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-24 22:56 Message: Logged In: YES user_id=33168 I can't reproduce this problem with 2.2.3 on Irix 6.5: % uname -a IRIX rattler 6.5 10120734 IP32 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-04-25 16:03 Message: Logged In: YES user_id=21627 No. Except for MacOS, there is are no port maintainers. There are experts for some of the Unices, but only for Linux and Solaris. For things as strange as Irix, we have to have actual users of the systems to fully understand the problem and provide patches. In general, we accept work-arounds only if it can be shown that a work-around is necessary around a true platform bug (see how the getaddrinfo emulation is used on OSX, even though the platform provides a native implementation). I'm pretty certain that Python's usage of the getaddrinfo API is correct. If this is still causing crashes, it may be that the implementation in the Irix library is buggy. Have you applied all vendor patches? ---------------------------------------------------------------------- Comment By: Eli Rosenberg (elirosenberg) Date: 2003-04-25 15:28 Message: Logged In: YES user_id=764663 Hmm, I don't know for sure, but closing might not be the best idea because anyone else building on a really recent IRIX will have problems with socketmodule. Is there an IRIX maintainer or somebody like that? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-04-25 15:06 Message: Logged In: YES user_id=6656 so... do you think the fault is with Python or IRIX? if you're happy enough with the situation as it stands, we may as well close this... ---------------------------------------------------------------------- Comment By: Eli Rosenberg (elirosenberg) Date: 2003-04-25 14:41 Message: Logged In: YES user_id=764663 Hi, I think I have fixed things...for now. Here is what I see: IRIX now includes POSIX 1003.1g draft implementations of getaddrinfo/getnameinfo in accordance with http://www.ietf.org/proceedings/01mar/I-D/ipngwg-rfc2553bis-03.txt Previously, netdb.h on IRIX did not have these definitions and Python compiled in its own implementations and things seemed to work. I changed pyconfig.h to have socketmodule use its own implementations, but I did have to make a few changes because the IRIX prototypes for these functions are for the 2001 version of the standards, whereas socketmodule seemed to have 1999 versions from RFC2553. Not knowing much about the Python C API, I did not look closely enough to see why socketmodule seems to cause memory faults when compiled with the IRIX libc versions of these functions. Hopefully this is the source of the problem. -eli ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-04-25 07:53 Message: Logged In: YES user_id=6656 This looks nasty... Could you try making a debug build of Python (pass --with-pydebug to ./configure) and/or try with current CVS? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727241&group_id=5470 From noreply at sourceforge.net Mon May 30 21:15:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 12:15:27 -0700 Subject: [ python-Bugs-718532 ] inspect, class instances and __getattr__ Message-ID: Bugs item #718532, was opened at 2003-04-09 17:01 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=718532&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Schwarzer (sschwarzer) Assigned to: Raymond Hettinger (rhettinger) Summary: inspect, class instances and __getattr__ Initial Comment: inspect.isclass(class_instance) fails if the corresponding class uses a "wildcard" implementation of __getattr__. Example: Python 2.2.2 (#1, Nov 13 2002, 22:53:57) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import inspect >>> class X: ... def __getattr__(self, name): ... if name == 'foo': ... return 1 ... if name == 'bar': ... return 2 ... else: ... return "default" ... >>> x = X() >>> inspect.isclass(x) 1 The problematic expression in inspect.isclass is hasattr(object, '__bases__') which returns a true value. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 16:15 Message: Logged In: YES user_id=752496 Don't know yet if it's a bug or not, but in Py2.4.1 inspect.isclass() is still returning True in these cases... ---------------------------------------------------------------------- Comment By: Stefan Schwarzer (sschwarzer) Date: 2005-01-28 13:44 Message: Logged In: YES user_id=383516 Hi Facundo The problem still exists in both Python 2.3.4 and 2.4. A possible test case is: import inspect import unittest class TestIsclass(unittest.TestCase): def test_instance_with_getattr(self): class Cls: def __getattr__(self, name): return "not important" obj = Cls() # obj is not a class self.failIf(inspect.isclass(obj)) ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 14:50 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-15 07:40 Message: Logged In: YES user_id=80475 Ping, if this change is made, will isclass() still be able to find extension classes? The addition of the hasattr(object, '__bases__') was made by you in ver 1.11 about two years ago. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-04-15 07:01 Message: Logged In: YES user_id=89016 type(object) in (types.TypeType, types.ClassType) won't work with custom metaclasses. isinstance(object, (type, types.ClassType)) would be better. ---------------------------------------------------------------------- Comment By: Stefan Schwarzer (sschwarzer) Date: 2003-04-15 05:01 Message: Logged In: YES user_id=383516 Hello Raymond, thanks for your reply. In fact, I'm also not sure if it counts as a bug. I also suggested a patch (handle __getattr__ requests for __bases__ with an AttributeError) for for the SF project which causes/d the problem. I think, if there's a better way to decide on "class-ness" than now, the code in inspect should be changed. Fortunately, it doesn't have to be backward-compatible, because the module is always distributed with a certain interpreter version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-14 21:36 Message: Logged In: YES user_id=80475 Hmm. I'm not sure that counts as a bug. In an OO language, it's a feature that objects can be made to look like and be substituable for other types. In this case, you've taught your object to be able to fake some classlike behavior (having a __bases__ attribute). OTOH, inspect could have a stronger test for classhood: type(object) in (types.TypeType, types.ClassType) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=718532&group_id=5470 From noreply at sourceforge.net Mon May 30 21:17:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 12:17:31 -0700 Subject: [ python-Bugs-716634 ] " build_ext" " libraries" subcommand not s Message-ID: Bugs item #716634, was opened at 2003-04-07 06:13 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=716634&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 Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Dieter Maurer (dmaurer) Assigned to: Nobody/Anonymous (nobody) Summary: "build_ext" "libraries" subcommand not s Initial Comment: The "libraries" command for "build_ext" is definitely one that should accept multiple libraries. However, this is impossible for both the command line as well as the configuration file. Patch attached. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 16:17 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 14:46 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=716634&group_id=5470 From noreply at sourceforge.net Mon May 30 21:29:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 12:29:34 -0700 Subject: [ python-Bugs-701836 ] Thread running (os.system or popen#) Message-ID: Bugs item #701836, was opened at 2003-03-11 18:46 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701836&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: Python Interpreter Core Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Johan Fredrik ?hman (johanfo) Assigned to: Nobody/Anonymous (nobody) Summary: Thread running (os.system or popen#) Initial Comment: Bottom line: Some programs may lock up when spawned from a thread. >>> import thread, os >>> thread.start_new_thread(os.system, ("/usr/sbin/ntpdate ifi.uio.no",)) This starts a program "ntpdate" from a Python thread. Usually this is no problem. Ntpdate, is a simple program to adjust the clock of the system. However, when ntpdate is started from a thread it locks up and newer exits!! With my limited debugging knowledge, it sems as it hangs in a "poll()" kernel call, however, this could be misleading. (I used stacktrace -p <pid>) ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 16:29 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 17:34 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 17:34 Message: Logged In: YES user_id=752496 Works ok for me: Python 2.3.4 (#1, Oct 26 2004, 16:42:40) [GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import thread, os >>> thread.start_new_thread(os.system,("/usr/sbin/ntpdate ifi.uio.no",)) -1210684496 >>> ---------------------------------------------------------------------- Comment By: Johan Fredrik ?hman (johanfo) Date: 2003-03-12 13:12 Message: Logged In: YES user_id=556425 I have verified this bug on both Redhat 8.0 and SuSE 8.1, linux yes. Signal is one possible path, filedescriptors another. I read somwhere that there was some issues with pthreads forking and filedescriptors. However, this is not my area (too low level).... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-03-12 09:40 Message: Logged In: YES user_id=6656 IIRC, threads other than the main thread get a signal mask that blocks everything. That could be the problem, but I don't know what to do about it... What platform are you on? Linux? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701836&group_id=5470 From noreply at sourceforge.net Mon May 30 21:31:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 12:31:15 -0700 Subject: [ python-Bugs-700650 ] Canvas origin is off-canvas in create_< item> (). Worka Message-ID: Bugs item #700650, was opened at 2003-03-10 02:17 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700650&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: Tkinter Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Roy Keir (newbieroy) Assigned to: Nobody/Anonymous (nobody) Summary: Canvas origin is off-canvas in create_<item>(). Worka Initial Comment: The origin for x,y pairs sent to the Canvas items is off-screen by the sum of borderwidth bd and highlightthickness hT. The accompanying program shows this and includes three functions which can be used in workarounds. I just hope the upload facility works this time. A canvas with exaggerated values for bd and hT is shown to illustrate the problem. On it, a full-screen open rectangle ((0-to width-1) by 0-to-(height-1)) is shown in red, and it is partly off-screen. A blue rectangle of the same coordinates is sent through UsrToCnv(), which uses .cget() to fetch up-to-date values for bd and hT (which can of course be updated on the fly) and translates the user's canvas item back where it belongs. Clicking on the canvas illustrates the use of CnvToUsr, sending a tuple (event.x, event.y) through the reverse of the above translation so that it matches the user's expectations. If these functions or their equivalents are not already available, you have my permission to offer these as workarounds while someone investigates the problem. I recommend that similar trials be performed on Tcl/Tk or PERL/Tk to see if the problem lies in Tkinter or even deeper in the mass of code. I'm a Python beginner so can't help with a project to fix it, but I'd like to be kept informed of any progress or decisions, if that's not too much trouble. Roy Keir ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 16:31 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 09:46 Message: Logged In: YES user_id=752496 There's no file attached... ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 09:46 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700650&group_id=5470 From noreply at sourceforge.net Mon May 30 21:32:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 12:32:37 -0700 Subject: [ python-Bugs-699816 ] Canvas Widget origin is off-screen Message-ID: Bugs item #699816, was opened at 2003-03-08 03:21 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699816&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: Tkinter Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Roy Keir (newbieroy) Assigned to: Nobody/Anonymous (nobody) Summary: Canvas Widget origin is off-screen Initial Comment: I'm a Python newbie, so be patient. I noticed that create-<item> didn't place the item where I expected. My help at Python.org guru Matt Cowles suggested that highlightthickness (hT hereinafter) might be the culprit. I wasn't using hT, but I was using borderwidth (bd to all), and I eventually found the problem. I believe that it is an error in Tkinter, but I'll be happy to be corrected. I wrote a program to display the canvases with the four combinations of hT and bd, and later I doubled up to see if 'relief' with bd==0 had any effect. I'll try to upload the code (oops. It invoves two modules. I may have to send two messages, one with each module). Here is what I think happens, and what I think should happen : DOES: SHOULD: Tkinter finds screen coordinates cx, cy of Canvas same (crucial step omitted) tx, ty = cx, cy Tkinter translates cx, cy = cx - bd, cy -bd tx, ty = tx- bd, ty - bd Tkinter draws the border (width is 2*bd wider than the Canvas) draws the border Tkinter translates cx, cy = cx - hT, cy - hT tx, ty = tx - hT, ty - hT Tkinter draws the highlight box (width is 2*hT wider than the border) draws the hightlight box Tkinter delivers cx, cy as the origin of the Canvas delivers cx, cy as the origin The attached program, if it arrives, demonstrates this effect. Any one doing serious graphics will need to adjust the x,y values of every Canvas item they draw. Putting a wrapper around each to .get() the values of hT and bd (and others I haven't discovered yet ?) is feasible but awful. Putting a function at the top of each event callback function to correct the event object x and y is even more awkward. To preserve backwards compatibility, I suggest that Tkinter Canvas items all be given an extra set of x and y values, with distinctive names. The user can put any old values in the current x,y positional spots and use xcorrected = NN, ycorrected=NN to override the stuff in the positional spots. To handle the variable number of x,y pairs in create_polygon(), create_line(), and perhaps other, Tkinter might require that the new values be given in a tuple of pairs or two tuples (x0,x1,x2) & (y0,y1,y2) The attached file is TkCoords03.py The next error will include algGrid03.py. Hope you can get them together. Roy Keir newbieroy rmkeir at earthlink.net ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 16:32 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 09:46 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 09:46 Message: Logged In: YES user_id=752496 There's no file attached... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699816&group_id=5470 From noreply at sourceforge.net Mon May 30 21:37:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 12:37:44 -0700 Subject: [ python-Bugs-687747 ] _iscommand() in webbrowser module Message-ID: Bugs item #687747, was opened at 2003-02-17 01:17 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687747&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: Python Library >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Cowles (mdcowles) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: _iscommand() in webbrowser module Initial Comment: [From a post to python-help] Under KDE under Mandrake Linux the BROWSER environment variable is set to kfmclient openProfile webbrowsing The problem is that _iscommand() in the webbrowser module doesn't realize that only the first thing there is the name of the executable. It looks for an executable with that whole thing as its name and doesn't find one. Since the module doesn't use any browser it has found if BROWSER is set, it raises an error rather than opening the page. The possible fixes that are obvious to me all have potential disadvantages: One solution would be to assume that the name of the executable ran only up to the first space. But executables can have spaces in their names, especially on a Macintosh, I think. Another possibility would be not to call _iscommand() on anything in BROWSER. That would have the additional advantage of not requiring that the executable specified there be in a directory that's in the user's PATH. The problem with doing things this way is that it would be impossible to tell which of the browsers specified in BROWSER should be used until the user called open(). I'm prepared to work on a fix if given some guidance about the best way to go. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 16:37 Message: Logged In: YES user_id=752496 richard seems to reproduced it on Py2.3, changing the group to it. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2005-01-16 19:01 Message: Logged In: YES user_id=6405 This is still an issue. python -c 'import webbrowser;webbrowser.open("http://www.google.com/")' on a system using KDE will exhibit the break. I posted a patch to fix the behaviour in my last message. I just noticed that I invoked diff the wrong way around (though the explanation still stands) - a correct invocation: --- /tmp/webbrowser.py 2005-01-17 08:59:50.697657208 +1100 +++ /usr/lib/python2.3/webbrowser.py 2005-01-17 08:59:58.269989095 +1100 @@ -354,7 +354,7 @@ if "BROWSER" in os.environ: # It's the user's responsibility to register handlers for any unknown # browser referenced by this value, before calling open(). - _tryorder = os.environ["BROWSER"].split(os.pathsep) + _tryorder[0:0] = os.environ["BROWSER"].split(os.pathsep) for cmd in _tryorder: if not cmd.lower() in _browsers: ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 09:26 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-08-19 21:29 Message: Logged In: YES user_id=6405 This is still an issue... has there been any movement on it outside of this bug report? I'm seeing the behaviour on Mandrake 9.1, KDE 3.1.3 that the module is finding the BROWSER env var as described above, and thus not finding a usable browser. As a fallback, the _tryorder shouldn't be *replaced* by BROWSER, but just prepended with its value. Sure, that means that the KDE BROWSER value will be ignored, but it'll still find konqueror. This approach works for me, and I'm sure it'll work for others who have "valid" BROWSER values :) Simple patch against python2.3 (sorry, sf will mangle this, but it's short): --- webbrowser.py 2003-08-20 10:28:07.000000000 +1000 +++ /usr/lib/python2.3/webbrowser.py 2003-08-04 10:18:17.000000000 +1000 @@ -354,7 +354,7 @@ if "BROWSER" in os.environ: # It's the user's responsibility to register handlers for any unknown # browser referenced by this value, before calling open(). - _tryorder[0:0] = os.environ["BROWSER"].split(os.pathsep) + _tryorder = os.environ["BROWSER"].split(os.pathsep) for cmd in _tryorder: if not cmd.lower() in _browsers: ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-02 22:19 Message: Logged In: YES user_id=6380 You know, I have no idea why all the lower() business is there. Assigning to Fred Drake, maybe he knows more. (Fred, please treat this as a hot potato -- if you don't immediately know the answer, assign it back to me.) ---------------------------------------------------------------------- Comment By: Matthew Cowles (mdcowles) Date: 2003-03-02 17:43 Message: Logged In: YES user_id=198518 A week after posting <slrnb5iu1s.t8.matt at sake.mondoinfo.com> ("webbrowser module under MacOS"), it hasn't gotten any replies. That suggests that Mac users either don't much care about the module or don't read comp.lang.python. If it's desirable merely to stop at the first space, it should be sufficient to replace: if _iscommand(cmd.lower()): with if _iscommand(cmd.lower().split(" ")[0]): There remain some things that are dubious about the handling of the values in the BROWSER environment variable. In particular, the lower() in that line, the assumption that the executables specified in BROWSER are in the user's PATH, and the lack of handling of %% and %s in those values. Still, it may be reasonable to ignore those issues until they pose a problem. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 10:53 Message: Logged In: YES user_id=6380 Please ask around on c.l.py if the macintosh problem actually exists; if it doesn't, stopping at the first space sounds like the right idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687747&group_id=5470 From noreply at sourceforge.net Mon May 30 21:47:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 12:47:28 -0700 Subject: [ python-Bugs-687297 ] Profilier hooked into SystemExit Message-ID: Bugs item #687297, was opened at 2003-02-15 22:41 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687297&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: Demos and Tools Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Dylan Shell (dshell) Assigned to: Nobody/Anonymous (nobody) Summary: Profilier hooked into SystemExit Initial Comment: I've been attempting to profile code that uses the PyOpenGL bindings. Essentially I've got a program with that calls glutMainLoop - which is said to never return. The problem is that since this really envokes some C code that calls "exit" the profiler does not catch a "SystemExit" exception, because this is never thrown. If there was a way to get the profiler to dump state on demand, I could do this in an "onExit" event handler, and then restart python with the pstats module to have a look-see. Alternatively the profiler could use some OS provided exit handler - or something simliar. Also, running the main loop in a thread does not seem to work (the video memory used by GLUT) is corrupted. So, this isn't a fair test on which to profile. I suspect that the ability to dump profile stats to disk could also be useful for other folks. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 16:47 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 01:08 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687297&group_id=5470 From noreply at sourceforge.net Mon May 30 21:55:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 12:55:37 -0700 Subject: [ python-Bugs-676346 ] String formatting operation Unicode problem. Message-ID: Bugs item #676346, was opened at 2003-01-28 17:59 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676346&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: Unicode Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 3 Submitted By: David M. Grimes (dmgrime) Assigned to: M.-A. Lemburg (lemburg) Summary: String formatting operation Unicode problem. Initial Comment: When performing a string formatting operation using %s and a unicode argument, the argument evaluation is performed more than once. In certain environments (see example) this leads to excessive calls. It seems Python-2.2.2:Objects/stringobject.c:3394 is where PyObject_GetItem is used (for dictionary-like formatting args). Later, at :3509, there is a"goto unicode" when a string argument is actually unicode. At this point, everything resets and we do it all over again in PyUnicode_Format. There is an underlying assumption that the cost of the call to PyObject_GetItem is very low (since we're going to do them all again for unicode). We've got a Python-based templating system which uses a very simple Mix-In class to facilitate flexible page generation. At the core is a simple __getitem__ implementation which maps calls to getattr(): class mixin: def __getitem__(self, name): print '%r::__getitem__(%s)' % (self, name) hook = getattr(self, name) if callable(hook): return hook() else: return hook Obviously, the print is diagnostic. So, this basic mechanism allows one to write hierarchical templates filling in content found in "%(xxxx)s" escapes with functions returning strings. It has worked extremely well for us. BUT, we recently did some XML-based work which uncovered this strange unicode behaviour. Given the following classes: class w1u(mixin): v1 = u'v1' class w2u(mixin): def v2(self): return '%(v1)s' % w1u() class w3u(mixin): def v3(self): return '%(v2)s' % w2u() class w1(mixin): v1 = 'v1' class w2(mixin): def v2(self): return '%(v1)s' % w1() class w3(mixin): def v3(self): return '%(v2)s' % w2() And test case: print 'All string:' print '%(v3)s' % w3() print print 'Unicode injected at w1u:' print '%(v3)s' % w3u() print As we can see, the only difference between the w{1,2,3} and w{1,2,3}u classes is that w1u defines v1 as unicode where w1 uses a "normal" string. What we see is the string-based one shows 3 calls, as expected: All string: <__main__.w3 instance at 0x8150524>::__getitem__(v3) <__main__.w2 instance at 0x814effc>::__getitem__(v2) <__main__.w1 instance at 0x814f024>::__getitem__(v1) v1 But the unicode causes a tree-like recursion: Unicode injected at w1u: <__main__.w3u instance at 0x8150524>::__getitem__(v3) <__main__.w2u instance at 0x814effc>::__getitem__(v2) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w2u instance at 0x814effc>::__getitem__(v2) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w3u instance at 0x8150524>::__getitem__(v3) <__main__.w2u instance at 0x814effc>::__getitem__(v2) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w2u instance at 0x814effc>::__getitem__(v2) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w1u instance at 0x814f024>::__getitem__(v1) v1 I'm sure this isn't a "common" use of the string formatting mechanism, but it seems that evaluating the arguments multiple times could be a bad thing. It certainly is for us 8^) We're running this on a RedHat 7.3/8.0 setup, not that it appears to matter (from looking in stringojbect.c). Also appears to still be a problem in 2.3a1. Any comments? Help? Questions? ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 16:55 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:54 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-28 19:23 Message: Logged In: YES user_id=38388 I don't see how you can avoid fetching the Unicode argument a second time without restructuring the formatting code altogether. If you know that your arguments can be Unicode, you should start with a Unicode formatting string to begin with. That's faster and doesn't involve a fallback solution. If you still want to see this fixed, I'd suggest to submit a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676346&group_id=5470 From noreply at sourceforge.net Mon May 30 22:03:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 13:03:07 -0700 Subject: [ python-Bugs-666700 ] os.popen+() can take string list and bypass shell. Message-ID: Bugs item #666700, was opened at 2003-01-12 13:45 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666700&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: Fixed Priority: 5 Submitted By: Dani (asqui) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen+() can take string list and bypass shell. Initial Comment: After being somewhat dumbfounded by the fact that there is no easy way to securely give user input as parameters to an external utility (because of the fact that os.popen*() runs things in the shell), I was happy to find that (os | popen2).popen[234]() will accept either a string as the command and execute it within a shell, or a string list which is executed directly. This does not apply to os.popen(), however popen2.popen[234]() all use this piece of code to execute the command in the child process: /usr/lib/python2.2/popen2.py def _run_child(self, cmd): if isinstance(cmd, types.StringTypes): cmd = ['/bin/sh', '-c', cmd] for i in range(3, MAXFD): try: os.close(i) except: pass try: os.execvp(cmd[0], cmd) finally: os._exit(1) Meaning that unless cmd is a string it will be run directly, outside of any shell. This appears to be the case for os.popen[234]() as well as popen2.popen*() ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 17:03 Message: Logged In: YES user_id=752496 Ok, fixed. ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2005-01-11 13:56 Message: Logged In: YES user_id=99508 I think I misunderstood your question. Yes, this *is* already fixed in the documentation for the subprocess module in 2.4. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 12:19 Message: Logged In: YES user_id=752496 Jeremy, could you please provide a patch for the docs? Thanks! ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2005-01-11 12:08 Message: Logged In: YES user_id=99508 Yes, I believe it should. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:34 Message: Logged In: YES user_id=752496 Should this be fixed in 2.4? Now we have the "subprocess" module. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:34 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-09-23 19:34 Message: Logged In: YES user_id=99508 Can I second that the documentation should definitely be updated to reflect this possibility, even if it's only available on *nix-like systems? This is something that many other languages in the same realm as Python (Perl, PHP, etc.) support and document, and I can't see any good reason why we *shouldn't* document a more secure way to give data to external programs. ---------------------------------------------------------------------- Comment By: Bernhard Herzog (bernhard) Date: 2003-08-05 13:04 Message: Logged In: YES user_id=2369 Given that the command as list of strings feature only works on Unix-like systems, ISTM it should perhaps only be documented for the PopenN classes. Maybe the documentation for the functions should state that on unix they accept lists of strings, though. ---------------------------------------------------------------------- Comment By: Dani (asqui) Date: 2003-01-12 13:49 Message: Logged In: YES user_id=569758 (The punch line which I omitted was that this fact is not documented anywhere.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666700&group_id=5470 From noreply at sourceforge.net Mon May 30 22:05:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 13:05:36 -0700 Subject: [ python-Bugs-654783 ] doctest and exception messages Message-ID: Bugs item #654783, was opened at 2002-12-16 16:23 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654783&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.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Aahz (aahz) Assigned to: Aahz (aahz) Summary: doctest and exception messages Initial Comment: doctest should include information something like this: doctest docstrings should not rely on the text of internal Python exceptions. Notice the way factorial() uses its own error messages with the standard Python exceptions. The internal messages can change even in bugfix releases (as in 2.2.1 to 2.2.2). ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 17:05 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:30 Message: Logged In: YES user_id=752496 What should change Aahz in the docs? Not clear to me... ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:30 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-09-23 19:01 Message: Logged In: YES user_id=3066 Tim sent this back to Aahz, so I'm assigning it to him as a reminder. ;-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-04-25 16:08 Message: Logged In: YES user_id=31435 Back to Aahz. I don't mind if you change this -- edit the docs and check it in. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-16 20:39 Message: Logged In: YES user_id=31435 It could, but it shouldn't: error msgs in docs that don't match reality are also an insult to users. doctest should grow some sort of option here, though, as its uses outgrew its original purposes. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-12-16 19:01 Message: Logged In: YES user_id=35752 Couldn't doctest be modified so that it only compares the exception name only? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654783&group_id=5470 From noreply at sourceforge.net Mon May 30 22:12:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 13:12:35 -0700 Subject: [ python-Bugs-640553 ] Misuse of /usr/local/in setup.py Message-ID: Bugs item #640553, was opened at 2002-11-19 05:04 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=640553&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.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Nick Maclaren (nmm1) Assigned to: Nobody/Anonymous (nobody) Summary: Misuse of /usr/local/in setup.py Initial Comment: I cannot guarantee that this has not been reported before, as the search facility doesn't appear sufficiently powerful to determine that, and I do not have time to read a hundred bug reports. setup.py forces the use of /usr/local, which is wrong on more counts than I can describe. Not merely need it not exist, it could easily contain the wrong versions of libraries and headers. The following change should be reversed: *** setup.py.org Mon Nov 18 19:57:09 2002 --- setup.py Mon Nov 18 19:57:23 2002 *************** *** 197,207 **** return platform def detect_modules(self): - # Ensure that /usr/local is always used - if '/usr/local/lib' not in self.compiler.library_dirs: - self.compiler.library_dirs.insert(0, '/usr/local/lib') - if '/usr/local/include' not in self.compiler.include_dirs: - self.compiler.include_dirs.insert(0, '/usr/local/include' ) try: have_unicode = unicode --- 197,202 ---- ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 17:12 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-08 02:23 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Nick Maclaren (nmm1) Date: 2002-11-19 14:44 Message: Logged In: YES user_id=652073 Well, that's an odd interpretation, but it isn't a great matter. However, I do feel that the "gotcha" should be documented. For example, the following perfectly reasonable use will fail horribly on many systems: A user version of a shareable library is in /usr/local/lib, which is a mountable filing system, and a system version in /usr/lib, which isn't - the former may be a symlink, or may be the testing version. Python is built using the standard mechanism, and is then used for system scripts. If those are then ever run when /usr/local is not mounted, they will fail horribly. Incidentally, we got caught by that one by making /usr mountable on one version of IRIX. It was actually SGI themselves who had missed the "gotcha", but we had the problem :-( Do what you will with this - I have resolved the issue here. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-11-19 14:38 Message: Logged In: YES user_id=44345 Some compilers complain if -I/usr/local/include is on the command line because it changes the compiler's notion of include file search order. The case -L/usr/local/lib may be similar. If this was an ideal world, I think we would ask the compiler if it searches /usr/local by default. If so, don't add the -I/-L flags. Maybe there's an autoconf macro floating around that can do this? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-19 14:05 Message: Logged In: YES user_id=21627 If /usr/local/lib causes a build failure, then the requirements are not absolutely standard, by (our) definition: We require /usr/local/lib to provide any libraries that are not normally on the system. Absence of /usr/local/lib is not a problem, nor are missing libraries a problem. If accessing /usr/local/lib alone causes catastrophic failures, it can't be a standard system. ---------------------------------------------------------------------- Comment By: Nick Maclaren (nmm1) Date: 2002-11-19 09:29 Message: Logged In: YES user_id=652073 No, that's not the issue. The build was absolutely out of the box, and the requirements were absolutely standard. But, for reasons that are irrelevant, -L/usr/local/lib caused failure. The point was that I had not specified it, it was not specified anywhere in the configuration or any of the Makefiles, and it wasn't even in Modules/Setup! So I could not understand where it was being set. I discovered that setup.py is invoked by default, and that did the job but didn't leave a record in any configuration or building file. GOTCHA! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-19 07:00 Message: Logged In: YES user_id=6656 It's not added if it doesn't exist in the HEAD branch. Wrt the other complaint, I think setup.py is only intended to be a convenience. If you have even vaguely complex building requirements, edit Modules/Setup instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=640553&group_id=5470 From noreply at sourceforge.net Mon May 30 22:19:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 13:19:15 -0700 Subject: [ python-Bugs-632323 ] Tkinter: BitmapImage vanishes if not stored in non-local var Message-ID: Bugs item #632323, was opened at 2002-11-01 19:39 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&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: Tkinter >Group: Python 2.3 Status: Open Resolution: Invalid Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter: BitmapImage vanishes if not stored in non-local var Initial Comment: The following program incorrectly produces a blank canvas: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """#define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """#define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) self.init2(self.init1()) #img = self.init1() #self.init2(img) self.mainloop() ---------------- However, the following program correctly draws a small red-and-green icon: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """#define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """#define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) #self.init2(self.init1()) img = self.init1() self.init2(img) self.mainloop() ---------------- The two programs are identical except that one of them assigns the BitmapImage to a variable rather than passing it directly as an argument. Python 2.2.1, OS = Linux version 2.4.18-3 (bhcompile at daffy.perf.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18 07:37:53 EDT 2002 ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 17:19 Message: Logged In: YES user_id=752496 OP says the problem persists, changing it to Py2.3. I think that or we change the resolution from "Invalid" or close the bug... ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2005-01-28 00:01 Message: Logged In: YES user_id=8861 SourceForge apparently failed to e-mail me a notification of your follow-up, so I didn't find out about it until today (exactly 1 month from your original posting), by accident. The problem is definitely still there in 2.3.3, which is what I currently have installed. I'll download and test 2.3.4 and 2.4 tomorrow. (I hope you'll give me an extra day!) lpd ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-27 23:02 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-12-11 08:59 Message: Logged In: YES user_id=21627 It's inconsistent with the rest of Tkinter. Everything in Tkinter is an object, and so are images. If you want strings, use plain _tkinter. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2002-12-11 06:33 Message: Logged In: YES user_id=38376 "..consider all common use cases -- if you don't do it this way, you either end up with leaks, code that works only by accident, or code that is a lot more convoluted than the simple assignment that is necessary to work around this problem in real life." ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-12-11 06:01 Message: Logged In: YES user_id=33229 What's wrong with simply wrapping what Tk does with an image_create method that returns a string and an image_delete method that accepts a string? It's consistent with Tk usage. You can document the proper usage of image_delete and leave the Image class for backwards compatability. Something like: def image_create(self, imgtype, cnf={}, master=None, **kw): if not master: master = Tkinter._default_root if not master: raise RuntimeError, 'Too early to create image' if kw and cnf: cnf = _cnfmerge((cnf, kw)) elif kw: cnf = kw options = () for k, v in cnf.items(): if callable(v): v = self._register(v) options = options + ('-'+k, v) return master.tk.call(('image', 'create', imgtype,) + options) def image_delete(self, imgname): try: self.tk.call('image', 'delete', imgname) except TclError: # May happen if the root was destroyed pass ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2002-12-08 10:30 Message: Logged In: YES user_id=38376 MvL wrote: As there appears to be agreement that the current behaviour cannot be changed, I'd like to propose the attached image.txt as a patch. +1 from here. I should probably write an essay some day on why the current behaviour is the only one that makes sense if you consider all common use cases -- if you don't do it this way, you either end up with leaks, code that works only by accident, or code that is a lot more convoluted than the simple assignment that is necessary to work around this problem in real life: photo = PhotoImage(...) widget = Label(master, photo=photo) widget._photo = photo # keep a reference martin has already covered most other issues. </F> ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-12-08 09:37 Message: Logged In: YES user_id=21627 As there appears to be agreement that the current behaviour cannot be changed, I'd like to propose the attached image.txt as a patch. With this patch, people who want to explicitly delete images need to pass a delete=False option to the image ctor, i.e. i = Tkinter.PhotoImage(file="fn", delete=0) Then, when they want to delete the image, they need to call i.delete() If that is an acceptable solution, I'll apply it to Python 2.3. In the case of the original report, the image would become garbage eventually, since the only reference to delete it was a local variable, which is lost. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-12-07 16:57 Message: Logged In: YES user_id=8861 Sorry, my previous comment regarding garbage collection wasn't clear. Consider the following situation: object X refers to object Y and to an image, and object Y refers to object X. The image will not be freed until the garbage collector frees objects X and Y. We worked through almost precisely this set of issues in Smalltalk systems at Xerox PARC, and later at ParcPlace Systems, starting in the early 1970s. Smalltalk, like Python, started out using only reference counting, and added garbage collection much later. However, Smalltalk wasn't trying to interact with a foreign memory management system at arm's length, as Python is with Tk: in my opinion, it's very unfortunate that Tkinter makes the existence of the two separate memory management systems visible to the Python programmer, with consequences like the ones discussed here. However, I have to agree with Martin Loewis that it's too late to change this situation, at least without extending the existing API. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-12-07 16:40 Message: Logged In: YES user_id=21627 Yes, backwards compatibility can be preserved by new classes, or by an additional constructor argument (I'd personally prefer the latter). However, I doubt the usefulness of such a new construct: nobody would use it unless they are aware of the issue, and if they are aware of the issue, they can easily solve the problem in a different way. Circular references are a red herring here; no image will ever exist in a circle, since image objects don't refer to other objects. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-12-07 15:36 Message: Logged In: YES user_id=8861 Sorry, I don't agree entirely with either of the responses. 1) I should have said no commonly used *on-screen* entity has this behavior. Backward compatibility can be handled easily by creating new subclasses of Image that have the proposed behavior. (I think I also disagree with the behavior for Variables, since unsetting a variable can also cause the screen appearance to change, but I haven't thought about it carefully enough to have a strong opinion.) 2) This is true only if the last reference to the image is the one being held by CPython. If a circular structure refers to an image, the last reference will be deleted by the garbage collector, not by CPython, so the image will not disappear until garbage collection occurs. I understand the reasoning, and it's not worth it to me to go through the PEP process; I just don't agree. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-13 09:04 Message: Logged In: YES user_id=21627 Peter, I have considered these reasons, and believe they don't apply. 1) Dropping the last reference to a Variable (IntVar, StringVar) also causes the variable to be unset. More importantly, changing the behaviour now would cause backwards incompatibilities: Existing applications rely on not having to release images explicitly. 2) While this may be true in general and for the Python language, it is not the case for CPython and Tkinter.Image specifically. If there are no references to the image anymore, it is released immediately, in CPython, withiyt waiting for garbage collection to be invoked. If you need a way to appeal this decision, you will have to write a PEP. Describe the proposed change and implementation strategy (explaining in detail how your approach solves the backwards compatibility issue), then discuss this proposed change with the Python community. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-12 18:58 Message: Logged In: YES user_id=8861 I disagree strongly with the resolution, for two reasons. 1) No other commonly used entity in the Tkinter API has this counter-intuitive behavior. Widgets do not disappear from the screen if Python holds no references to them. Text strings do not disappear from the screen if Python holds no references to the string object or the font object. (I don't know how this is accomplished.) 2) Python does not, and cannot, guarantee that an object will be finalized and freed immediately when there are no longer any references to it: if the object must be reclaimed by garbage collection, an unpredictable amount of time may elapse. Therefore, in my opinion, it is very undesirable to use object finalization in a way that directly affects the user interface. Please consider changing Tkinter so that it handles Image objects the same way that it apparently handles widgets, fonts, strings, etc. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-07 07:11 Message: Logged In: YES user_id=21627 It is now in the library section. If you think it also ought to be in the Image class, please contribute a patch. However, I think anybody looking at the Image class code could not fail to notice the image delete. I agree that the behaviour is counter-intuitive, but I disagree that automatic addition of a reference would be a solution: 1. It would break backwards-compatibility. A number of text books explicitly mention this issue, and applications make use of this property, relying on the fact that you can drop the last reference to the image and thus release the associated memory. 2. Python cannot possibly track all uses of the command. For example, you could put the image into a StrVar, and then expect to use the StrVar as the value for an image= attribute. So in short, I think educating users is the best we can do, until Tk provides better mechanisms. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-07 06:22 Message: Logged In: YES user_id=33229 > When the BitmapImage object is no longer referenced, it is > finalized; finalization causes "image delete" to be > invoked. Martin, thanks for the explanation. The behaviour is counterintuitive for a Tk wrapper, because in Tk images are eternal unless explicitly deleted. They are not GC'd when they are unreferenced, and that's their documented behaviour. IThe documentation I was refering to was the Image class documentation in Tkinter.py - it makes no mention of this, and as a rule in Python, I didn't think you had to keep a global reference to everything you pass to any function if you want it to be still alive when the function uses it. Perhaps the Label/Canvas/Button instances should keep a reference to it, which would be deleted when the instance is deleted? I know it's not in the Library Reference, as I contributed the Tkinter section, but I think it should be clear in Tkinter.py. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-05 19:13 Message: Logged In: YES user_id=21627 Mentioning "the docs" is somewhat funny when it comes to Tkinter: there was no documentation on images in the first place. I've added a new section on this in tkinter.tex 1.17. I've also added a Tk wishlist item at http://sourceforge.net/tracker/?func=detail&aid=633300&group_id=12997&atid=362997 If they ever act on this, we can improve Tkinter in this respect. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 18:23 Message: Logged In: YES user_id=6380 Let's close this as Not A Bug. Maybe it needs to be fixed in the docs? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-04 04:26 Message: Logged In: YES user_id=21627 When the BitmapImage object is no longer referenced, it is finalized; finalization causes "image delete" to be invoked. Tcl does not keep a reference to the image object; if you don't yourself, nobody does. In turn, the image object goes away right after being created. The right approach would be for Tcl to somehow keep a reference to the Python object, but I think this is unimplementable. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-03 16:42 Message: Logged In: YES user_id=8861 The bug does *not* manifest with the following definition for init(): def init(self): self.img = self.init1() self.init2(self.img) I think this is even stronger evidence that we're seeing a reference counting / garbage collection / finalization (?) problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 02:14 Message: Logged In: YES user_id=33229 This may be the same as what I'm seeing in Demo/tix/tixwidgets.py Look for image1 in tixwidgets.py: I put the following comment in the code: # This image is not showing up under Python unless it is set to a # global variable - no problem under Tcl. I assume it is being garbage # collected some how, even though the tcl command 'image names' shows # that as far as Tcl is concerned, the image exists and is called pyimage1. Can anyone explain to me what's going on? IMHO, either this is a Tkinter bug, or a documentation bug because the documentation does not explain to me why this image1 has to be global, or am I missing something here. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-02 01:32 Message: Logged In: YES user_id=8861 Comment #1: This bug is still there in Python 2.2.2. Comment #2: Using a variable isn't the whole story. The bug also manifests if I define: def init(self): img = self.init1() self.init2(img) and then have the calling program invoke self.init(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 From noreply at sourceforge.net Mon May 30 22:34:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 13:34:18 -0700 Subject: [ python-Bugs-1201461 ] suspected cPickle memory leak Message-ID: Bugs item #1201461, was opened at 2005-05-13 12:49 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201461&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: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Alan (franz2) Assigned to: Nobody/Anonymous (nobody) Summary: suspected cPickle memory leak Initial Comment: I believe there is a memory leak in cPickle. I have a parallel code which uses array() and indices() from Numeric to massage data buffers before being sent and received by Pypar. Pypar subsequently uses cPickle to pickle the data. After many hours of execution, my code crashes with one of the following error messages (depending upon the run): a = zeros(shape, typecode, savespace) MemoryError: can't allocate memory for array or: s = dumps(x, 1) MemoryError: out of memory I have since modified my code to use a different data format so cPickle is no longer used from PyPar and now the code runs fine. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 17:34 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-30 05:34 Message: Logged In: YES user_id=21627 Can you provide a test case that demonstrates how the memory is exhausted? Without a test case, it is unlikely that we will be able to find the suspected leak. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201461&group_id=5470 From noreply at sourceforge.net Tue May 31 00:36:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 15:36:25 -0700 Subject: [ python-Bugs-1211639 ] parser tells invalid syntax with correct code Message-ID: Bugs item #1211639, was opened at 2005-05-31 00:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1211639&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: Open Resolution: None Priority: 5 Submitted By: ntrunk (ntrunk) Assigned to: Nobody/Anonymous (nobody) Summary: parser tells invalid syntax with correct code Initial Comment: I work with python 2.4 on Win2000 Sp4. I wrote a simple game with 2 modules, importing one into the other. In the imported module I wrote in the first line the coding: iso-8859-15. Starting the script from the first module the parser shows 'invalid syntax'. By inserting *1* space in a comment line the script works fine! I reduced my scripts to the minimal lines, wich will reproduce the bug. (Actually the parser tells me, that the syntax error is in line 75 :-) Changing the coding to iso-8859-1 will making the bug dissapear. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1211639&group_id=5470 From noreply at sourceforge.net Tue May 31 01:32:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 16:32:27 -0700 Subject: [ python-Bugs-728515 ] mmap's resize method resizes the file in win32 but not unix Message-ID: Bugs item #728515, was opened at 2003-04-27 10:44 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&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: Extension Modules Group: Python 2.2.2 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Myers Carpenter (myers_carpenter) Assigned to: Nobody/Anonymous (nobody) Summary: mmap's resize method resizes the file in win32 but not unix Initial Comment: In the resize method under win32 you have something like this: /* Move to the desired EOF position */ SetFilePointer (self->file_handle, new_size, NULL, FILE_BEGIN); /* Change the size of the file */ SetEndOfFile (self->file_handle); Which resizes the file Under Unix you need to call ftruncate(self->fileno, new_size) before calling remap() to make it do the same thing. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-30 16:32 Message: Logged In: YES user_id=341410 The problem still persists in Python 2.3 and 2.4. A quick read of mmapmodule.c shows that ftruncate() is not being called within the non-windows portion of mmap_resize_method(). ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 11:59 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 09:55 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 05:36 Message: Logged In: YES user_id=21627 Would you like to contribute a patch? Please make sure to include changes to the documentation and test suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&group_id=5470 From noreply at sourceforge.net Tue May 31 01:51:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 16:51:32 -0700 Subject: [ python-Bugs-728515 ] mmap's resize method resizes the file in win32 but not unix Message-ID: Bugs item #728515, was opened at 2003-04-27 14:44 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&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: Extension Modules >Group: Python 2.4 >Status: Open >Resolution: None Priority: 5 Submitted By: Myers Carpenter (myers_carpenter) Assigned to: Nobody/Anonymous (nobody) Summary: mmap's resize method resizes the file in win32 but not unix Initial Comment: In the resize method under win32 you have something like this: /* Move to the desired EOF position */ SetFilePointer (self->file_handle, new_size, NULL, FILE_BEGIN); /* Change the size of the file */ SetEndOfFile (self->file_handle); Which resizes the file Under Unix you need to call ftruncate(self->fileno, new_size) before calling remap() to make it do the same thing. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 20:51 Message: Logged In: YES user_id=752496 Reopened as posted that still is a bug. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-30 20:32 Message: Logged In: YES user_id=341410 The problem still persists in Python 2.3 and 2.4. A quick read of mmapmodule.c shows that ftruncate() is not being called within the non-windows portion of mmap_resize_method(). ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 15:59 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 14:55 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 09:36 Message: Logged In: YES user_id=21627 Would you like to contribute a patch? Please make sure to include changes to the documentation and test suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&group_id=5470 From noreply at sourceforge.net Tue May 31 02:09:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 17:09:36 -0700 Subject: [ python-Bugs-856103 ] reload() fails with modules from zips Message-ID: Bugs item #856103, was opened at 2003-12-08 02:48 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856103&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: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) >Assigned to: Nobody/Anonymous (nobody) Summary: reload() fails with modules from zips Initial Comment: If you call reload() with a module that was imported from a zip, it fails with a "no such module" error. Although zips are typically read-only, it is possible that a zip could be modified during a run, and a reload be necessary. If this is considered unnecessary, then I think a more informative "can't reload from zip" error would be better than a 'no such module" one. """ >set PYTHONPATH=path/to/spambayes.zip >python >>> from spambayes import Options >>> Options <module 'spambayes.Options' from 'c:\spambayes\windows\py2exe\dist\lib\spambayes .zip\spambayes\Options.pyc'> >>> reload(Options) Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: No module named Options """ This is with Python 2.3.2 and WinXP. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-05-30 19:09 Message: Logged In: YES user_id=44345 Tossing back into the pool. ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2004-09-23 08:41 Message: Logged In: YES user_id=56214 D'oh! PyImport_AddModule() only creates a new module if it doesn't already exist in sys.modules, so there's nothing to fix on that point. Now what's needed is someone familiar with zipimport.c internals to review Stephen's patch at: http://www.chase3000.com/stephenh/patch-zipimport.txt and clean out its stderr prints. ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2004-09-23 01:21 Message: Logged In: YES user_id=56214 I've fixed bug #1029475, so reload() will now actually invoke the PEP 302 loader mechanism. However, there's another bug in zipimport: the loader implementation in zipimport.c always creates a new module, even when reloading. It needs to check sys.modules first, and reuse the existing module if present. I'm attempting to fix that issue now, and once I'm done, someone more familiar with zipimport's cache mechanism can do the rest. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-09-16 16:00 Message: Logged In: YES user_id=642545 Turns out there are two issues here: PEP 302 using the loader, and then the zip import caching the contents of zip files. At the suggestion of Phillip Eby, the PEP 302 stuff not using a loader has been put in a new bug that he is going to take care of: https://sourceforge.net/tracker/index.php?func=detail&aid=1029475&group_id=5470&atid=105470 So, now there is just the separate issue of the zip import not checking the file modification time. The attached patch makes sure when reload(aZipModule) is called that the file modification time is checked and that the contents are reloaded. More details are in my last comment. There is a test case that passes as well. The patch is at a more permanent location this time: http://www.chase3000.com/stephenh/patch-zipimport.txt ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-02 17:26 Message: Logged In: YES user_id=642545 Okay, so you talked me in to it. Besides the previous PyImport_ReloadModule patch, I modified zipimport.c to add another cache (zip_directory_cache of toc_entry's and zip_mtime_cache of modification times). On creation of a new ZipImporter or call to get_module_code, check_archive_mtime is called, which gets the new mtime and compares to the cached one. If they are different, it calls the old read_directory. read_directory was modified to, instead of creating a brand new path: [toc_entry] dictionary, clear and re-populate the same 'files' dictionary. This is so that if multiple ZipImporters are sharing an archive, and hence already sharing the same 'files' entry in zip_directory_cache, if one of them detects a new zip file and has the toc_entry's reloaded, the other ZipImporters will see the change to (as they all share the same dictionary). This was pretty much the same functionality before (sharing dictionaries), just that now read_directory clears/updates an exisitng one instead creating its own brand new one. Also, I had to add a sleep(1) call in testReload to ensure the modification time stamp would change. Again, either I don't have permissions to upload files, or I just can't figure it out, so the patch is at: http://sh5.beachead.com:8080/~stephen/patch.txt This is my first foray into Python coding, so double checking all of the reference counting inc/dec stuff would be a really good idea. I also took about 20 minutes to look at adding a reload test to test_importhooks.py, as suggested, but couldn't get it to work. I couldn't tell if it was because I was writing a flawed test (which is what I am suspecting) or if the PyImport_ReloadModule patch was not working. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-04-02 10:53 Message: Logged In: YES user_id=92689 Hm, I forgot about the caching of directory info. I don't think properly supporting reloading from zip files is worth the effort. It would be nice if it failed nicer, though. The reload patch is still cool, though, since it should fix reloading with PEP 302-style importers in general (yet zipimport may still choose not to support it). A reload test in test_importhooks.py would be a great addition. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-02 10:35 Message: Logged In: YES user_id=642545 So, upon some more investigation, it looks like the problem is that the toc_entry from the old zip file is being used, which has the old file size, not the new file size. It looks like in zipimport.c, line 126, where the zip_directory_cache is used to cache all of the toc_entry's for a zip file, a check on the zip file modification should be made, just as the modification check is done vs. .py files, I would imagine. This would require storing another a tuple in zip_directory_cache of (modification_time, list of toc_entry's). Let me know if you want me to take a shot at implementing this. Otherwise I'd prefer deferring to you guys, as I assume you can do it with much less time and much higher quality than I could. Thanks. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-02 09:38 Message: Logged In: YES user_id=642545 Actually, it doesn't seem to be working fully. I've been playing with Skip's test patch and it looks like the code it reloads uses...the same buffer size as it did with the original read? You can play with replacing 'return __name__' with different strings and it will change the error you get. E.g. with 'return __name__+"modified"', it parses fine, but get_foo() is not found (which is added after get_name()). E.g. with 'return "new"', it does not parse fine, it returns 'NameError: name 'de' is not defined'. My guess is that it got part way through reading "def get_foo(): return 1" and hit the end of a buffer. Or something. At this point, its beyond my C/Python code skills to track it down. Hopefully its just some minor error in re-loading the code from the new zip file you guys can easily find. I can't see where to upload a patch file, so you can get what I'm currently playing with at: http://sh5.beachead.com:8080/~stephen/patch.txt Note the import.c patch is the same, the new patch just adds stuff to Skip's testReload function to try loading code from a new zip file. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-04-02 06:23 Message: Logged In: YES user_id=44345 > what doesn't work for you? Sorry. Pilot error. I was adding foozip.zip to sys.path then trying from foozip import somemodule instead of just import somemodule (Obvious, not a feature I use a lot...) Seems to be working for me now. I'll try a couple more tests then check it in. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-04-02 01:00 Message: Logged In: YES user_id=92689 The import.c patch looks fine (although I didn't test it yet). Skip, what doesn't work for you? "I can't get zip imports to work" is quite broad... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-04-01 21:37 Message: Logged In: YES user_id=44345 attached is the patch to protect it from the vagaries of cut-n- paste. I also added a simple testReload test to the test_zipimport.py file. I can't get zip imports to work. Perhaps Just can test this out. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-01 18:26 Message: Logged In: YES user_id=642545 Here's a patch that fixes the problem so that modules from zip files can be reloaded. The problem was the PyImport_ReloadModulefunction not passing a loader around. Perhaps this is naive, and the PyImport_ReloadModule was purposefully not using a loader, but, again, it works for me. cvs diff -u dist\src\Python\import.c (in directory C:\cvs\python\) Index: dist/src/Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.230 diff -u -r2.230 import.c --- dist/src/Python/import.c 1 Apr 2004 02:45:22 -0000 2.230 +++ dist/src/Python/import.c 2 Apr 2004 00:18:46 -0000 @@ -2217,7 +2217,7 @@ PyImport_ReloadModule(PyObject *m) { PyObject *modules = PyImport_GetModuleDict(); - PyObject *path = NULL; + PyObject *path, *loader = NULL; char *name, *subname; char buf[MAXPATHLEN+1]; struct filedescr *fdp; @@ -2259,11 +2259,12 @@ PyErr_Clear(); } buf[0] = '\0'; - fdp = find_module(name, subname, path, buf, MAXPATHLEN+1, &fp, NULL); + fdp = find_module(name, subname, path, buf, MAXPATHLEN+1, &fp, &loader); Py_XDECREF(path); if (fdp == NULL) return NULL; - m = load_module(name, fp, buf, fdp->type, NULL); + m = load_module(name, fp, buf, fdp->type, loader); + Py_XDECREF(loader); if (fp) fclose(fp); return m; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856103&group_id=5470 From noreply at sourceforge.net Tue May 31 08:10:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 23:10:04 -0700 Subject: [ python-Feature Requests-1208730 ] expat binding for XML_ParserReset Message-ID: Feature Requests item #1208730, was opened at 2005-05-25 13:37 Message generated for change (Comment added) made by zhar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1208730&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: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Eikenberry (zhar) Assigned to: Nobody/Anonymous (nobody) Summary: expat binding for XML_ParserReset Initial Comment: XML_ParserReset is an expat parser method for resetting the parser to handle a new document. This keeps you from having to create a new parser for each document. ---------------------------------------------------------------------- >Comment By: John Eikenberry (zhar) Date: 2005-05-30 23:10 Message: Logged In: YES user_id=322022 Ok. I gave it a whirl. The patch is attached. If you have a moment, could you please look over it and let me know if I made any mistakes. Its a forward diff as recommended by the guidelines. I tried to follow them as much as possible. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-30 01:37 Message: Logged In: YES user_id=21627 Would you like to work on a patch for this feature? Exposing more methods from Expat is a good idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1208730&group_id=5470 From noreply at sourceforge.net Tue May 31 08:12:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 23:12:17 -0700 Subject: [ python-Feature Requests-1208730 ] expat binding for XML_ParserReset Message-ID: Feature Requests item #1208730, was opened at 2005-05-25 13:37 Message generated for change (Comment added) made by zhar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1208730&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: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Eikenberry (zhar) Assigned to: Nobody/Anonymous (nobody) Summary: expat binding for XML_ParserReset Initial Comment: XML_ParserReset is an expat parser method for resetting the parser to handle a new document. This keeps you from having to create a new parser for each document. ---------------------------------------------------------------------- >Comment By: John Eikenberry (zhar) Date: 2005-05-30 23:12 Message: Logged In: YES user_id=322022 Forgot to mention I made the patch against current CVS. ---------------------------------------------------------------------- Comment By: John Eikenberry (zhar) Date: 2005-05-30 23:10 Message: Logged In: YES user_id=322022 Ok. I gave it a whirl. The patch is attached. If you have a moment, could you please look over it and let me know if I made any mistakes. Its a forward diff as recommended by the guidelines. I tried to follow them as much as possible. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-30 01:37 Message: Logged In: YES user_id=21627 Would you like to work on a patch for this feature? Exposing more methods from Expat is a good idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1208730&group_id=5470 From noreply at sourceforge.net Tue May 31 08:22:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 23:22:36 -0700 Subject: [ python-Bugs-1210832 ] An error in Python Tutorial Message-ID: Bugs item #1210832, was opened at 2005-05-29 08:28 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210832&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: Gene (godhand) Assigned to: Nobody/Anonymous (nobody) Summary: An error in Python Tutorial Initial Comment: In section 4.4, the program should be written as follow to get the correct result: -------------------------------------------------------------- for n in range(2, 10): for x in range(2, n): if n % x == 0: print n, 'equals', x, '*', n/x break if x == n-1: print n, 'is a prime number' -------------------------------------------------------------- besides, the line "2 is a prime number" should not appear in the result output. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-30 23:22 Message: Logged In: YES user_id=341410 The indentation on your proposed code addition was lost during your post, re-post so that it is understandable. Further, from mathworld.com: "A prime number (or prime integer, often simply called a ''prime'' for short) is a positive integer p > 1 that has no positive integer divisors other than 1 and p itself. (More concisely, a prime number p is a positive integer having exactly one positive divisor other than 1.)" That is to say, 2 is prime, so should appear in the result output, and it seems to me that the code provided in tutorial section 4.4 is correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210832&group_id=5470 From noreply at sourceforge.net Tue May 31 09:03:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 00:03:58 -0700 Subject: [ python-Bugs-1161031 ] Neverending warnings from asyncore Message-ID: Bugs item #1161031, was opened at 2005-03-10 16:34 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: Neverending warnings from asyncore Initial Comment: Changes in asyncore from 2.3 to 2.4 mean that asyncore.poll() now passes all the sockets in the map to select.select() to be checked for errors, which is probably a good thing. If an error occurs, then handle_expt() is called, which by default logs the error. asyncore.dispatcher creates nonblocking sockets. When connect_ex() is called on a nonblocking socket, it will probably return EWOULDBLOCK (connecting takes time), which may mean the connection is successful, or may not (asyncore dispatcher keeps going assuming all is well). If the connection is not successful, and then asyncore.loop() is called, then select.select() will indicate that there is an error with the socket (can't connect) and the error will be logged. The trouble is that asyncore.loop then keeps going, and will log this error again. My not-that-fast system here gets about 10,000 logged messages per second with a single socket in the asyncore map. There are ways to avoid this: (1) if the socket is blocking when connect()ing (and then nonblocking afterwards) an error is raised if the connect fails. (2) Before calling asyncore.loop(), the caller can run through all the sockets, checking that they are ok. (3) handle_expt() can be overridden with a function that repairs or removes the socket from the map (etc) However, I'm not convinced that this is good behavior for asyncore to have, by default. On Windows, select.select() will only indicate an error when trying to connect (nonblocking) or if SO_OOBINLINE is disabled, but this may not be the case (i.e. errors can occur at other times) with other platforms, right? Unless the error is temporary, asyncore will by default start streaming (extremely fast) a lot of "warning: unhandled exception" (not very helpful an error message, either) messages. Even if the error only lasts a minute, that could easily result in 10,000 warnings being logged. Do any of the python developers agree that this is a flaw? I'm happy to work up a patch for whatever the desired solution is, if so. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 00:03 Message: Logged In: YES user_id=341410 Option 1 is not really an option in any case where a large number of connections are opened (so I don't believe should be the default). >From what I understand, certain methods are supposed to be overridden in a subclass if someone using a class wants different behavior. In this case, I believe you can perform either option 2 or 3 in your own code to avoid the thousands of logged lines; either by creating your own loop() function, or by creating a subclass of dispatcher and implementing a handle_expt() method that does as you desire. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&group_id=5470 From noreply at sourceforge.net Tue May 31 09:09:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 00:09:55 -0700 Subject: [ python-Bugs-1117601 ] os.path.exists returns false negatives in MAC environments. Message-ID: Bugs item #1117601, was opened at 2005-02-06 16:57 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117601&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: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Stephen Bennett (sbennett) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.exists returns false negatives in MAC environments. Initial Comment: In Mandatory Access Control environments (such as SELinux), it's quite possible for stat to fail with permission denied. In this case, os.path.exists will return False incorrectly. The simple(ish) fix is to check for an access denied error (which would indicate present, but not readable) when using stat to check for existence of files. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 00:09 Message: Logged In: YES user_id=341410 I believe Terry was curious about something like os.path.exists("/etc/shadow/abc123") vs `ls -l /etc/shadow/abc123`. If not, I know I am curious, and I believe it may help with a corner case. ---------------------------------------------------------------------- Comment By: Stephen Bennett (sbennett) Date: 2005-02-16 14:46 Message: Logged In: YES user_id=817465 As far as I know (at least for SELinux), permission denied on stat() always means that the file exists, but getattr isn't allowed. As for a reproducible test case, probably the simplest example is a vanilla Fedora Core 3 system with SELinux enabled and strict policy. From a regular user account, call os.path.exists("/etc/shadow"). It will return False even though the file exists. For comparison, an `ls -l /etc/shadow` from the command line will simply print 'Permission Denied'. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 12:26 Message: Logged In: YES user_id=593130 Does 'access denied' always mean 'present but not readable' in every environment that gives such messages? I ask because I have vague memories of wasting time trying to get access to something that did not exist, because access denied (or something like that) meant that I was denied access even to info about whether it existed or not. In any case, a reproducible example would help someone to verify, fix, and write a test case for this if it is deemed to be a fixable bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117601&group_id=5470 From noreply at sourceforge.net Tue May 31 09:15:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 00:15:05 -0700 Subject: [ python-Bugs-1161031 ] Neverending warnings from asyncore Message-ID: Bugs item #1161031, was opened at 2005-03-11 13:34 Message generated for change (Comment added) made by anadelonbrin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: Neverending warnings from asyncore Initial Comment: Changes in asyncore from 2.3 to 2.4 mean that asyncore.poll() now passes all the sockets in the map to select.select() to be checked for errors, which is probably a good thing. If an error occurs, then handle_expt() is called, which by default logs the error. asyncore.dispatcher creates nonblocking sockets. When connect_ex() is called on a nonblocking socket, it will probably return EWOULDBLOCK (connecting takes time), which may mean the connection is successful, or may not (asyncore dispatcher keeps going assuming all is well). If the connection is not successful, and then asyncore.loop() is called, then select.select() will indicate that there is an error with the socket (can't connect) and the error will be logged. The trouble is that asyncore.loop then keeps going, and will log this error again. My not-that-fast system here gets about 10,000 logged messages per second with a single socket in the asyncore map. There are ways to avoid this: (1) if the socket is blocking when connect()ing (and then nonblocking afterwards) an error is raised if the connect fails. (2) Before calling asyncore.loop(), the caller can run through all the sockets, checking that they are ok. (3) handle_expt() can be overridden with a function that repairs or removes the socket from the map (etc) However, I'm not convinced that this is good behavior for asyncore to have, by default. On Windows, select.select() will only indicate an error when trying to connect (nonblocking) or if SO_OOBINLINE is disabled, but this may not be the case (i.e. errors can occur at other times) with other platforms, right? Unless the error is temporary, asyncore will by default start streaming (extremely fast) a lot of "warning: unhandled exception" (not very helpful an error message, either) messages. Even if the error only lasts a minute, that could easily result in 10,000 warnings being logged. Do any of the python developers agree that this is a flaw? I'm happy to work up a patch for whatever the desired solution is, if so. ---------------------------------------------------------------------- >Comment By: Tony Meyer (anadelonbrin) Date: 2005-05-31 19:15 Message: Logged In: YES user_id=552329 Yes this problem is easily solved by subclassing. However I firmly believe that it is a terrible default behaviour, and that it's likely to hit many asyncore users. A class shouldn't have to be subclassed to be usable (ignoring virtual classes and all that), and that really is the case here. The simplest solution would be to change the handler to not log the message. Or log the message once per socket or something. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 19:03 Message: Logged In: YES user_id=341410 Option 1 is not really an option in any case where a large number of connections are opened (so I don't believe should be the default). >From what I understand, certain methods are supposed to be overridden in a subclass if someone using a class wants different behavior. In this case, I believe you can perform either option 2 or 3 in your own code to avoid the thousands of logged lines; either by creating your own loop() function, or by creating a subclass of dispatcher and implementing a handle_expt() method that does as you desire. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&group_id=5470 From noreply at sourceforge.net Tue May 31 09:31:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 00:31:52 -0700 Subject: [ python-Bugs-1161031 ] Neverending warnings from asyncore Message-ID: Bugs item #1161031, was opened at 2005-03-10 16:34 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: Neverending warnings from asyncore Initial Comment: Changes in asyncore from 2.3 to 2.4 mean that asyncore.poll() now passes all the sockets in the map to select.select() to be checked for errors, which is probably a good thing. If an error occurs, then handle_expt() is called, which by default logs the error. asyncore.dispatcher creates nonblocking sockets. When connect_ex() is called on a nonblocking socket, it will probably return EWOULDBLOCK (connecting takes time), which may mean the connection is successful, or may not (asyncore dispatcher keeps going assuming all is well). If the connection is not successful, and then asyncore.loop() is called, then select.select() will indicate that there is an error with the socket (can't connect) and the error will be logged. The trouble is that asyncore.loop then keeps going, and will log this error again. My not-that-fast system here gets about 10,000 logged messages per second with a single socket in the asyncore map. There are ways to avoid this: (1) if the socket is blocking when connect()ing (and then nonblocking afterwards) an error is raised if the connect fails. (2) Before calling asyncore.loop(), the caller can run through all the sockets, checking that they are ok. (3) handle_expt() can be overridden with a function that repairs or removes the socket from the map (etc) However, I'm not convinced that this is good behavior for asyncore to have, by default. On Windows, select.select() will only indicate an error when trying to connect (nonblocking) or if SO_OOBINLINE is disabled, but this may not be the case (i.e. errors can occur at other times) with other platforms, right? Unless the error is temporary, asyncore will by default start streaming (extremely fast) a lot of "warning: unhandled exception" (not very helpful an error message, either) messages. Even if the error only lasts a minute, that could easily result in 10,000 warnings being logged. Do any of the python developers agree that this is a flaw? I'm happy to work up a patch for whatever the desired solution is, if so. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 00:31 Message: Logged In: YES user_id=341410 I hate to point out the obvious, but dispatcher is wholly unusable without subclassing. How would you get data to/from a connection without replacing handle_read, handle_write? How do you handle the case when you want to connect to someone else or accept connections from someone else without overloading handle_connect or handle_accept? ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2005-05-31 00:15 Message: Logged In: YES user_id=552329 Yes this problem is easily solved by subclassing. However I firmly believe that it is a terrible default behaviour, and that it's likely to hit many asyncore users. A class shouldn't have to be subclassed to be usable (ignoring virtual classes and all that), and that really is the case here. The simplest solution would be to change the handler to not log the message. Or log the message once per socket or something. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 00:03 Message: Logged In: YES user_id=341410 Option 1 is not really an option in any case where a large number of connections are opened (so I don't believe should be the default). >From what I understand, certain methods are supposed to be overridden in a subclass if someone using a class wants different behavior. In this case, I believe you can perform either option 2 or 3 in your own code to avoid the thousands of logged lines; either by creating your own loop() function, or by creating a subclass of dispatcher and implementing a handle_expt() method that does as you desire. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&group_id=5470 From noreply at sourceforge.net Tue May 31 09:42:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 00:42:25 -0700 Subject: [ python-Bugs-1161031 ] Neverending warnings from asyncore Message-ID: Bugs item #1161031, was opened at 2005-03-11 13:34 Message generated for change (Comment added) made by anadelonbrin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: Neverending warnings from asyncore Initial Comment: Changes in asyncore from 2.3 to 2.4 mean that asyncore.poll() now passes all the sockets in the map to select.select() to be checked for errors, which is probably a good thing. If an error occurs, then handle_expt() is called, which by default logs the error. asyncore.dispatcher creates nonblocking sockets. When connect_ex() is called on a nonblocking socket, it will probably return EWOULDBLOCK (connecting takes time), which may mean the connection is successful, or may not (asyncore dispatcher keeps going assuming all is well). If the connection is not successful, and then asyncore.loop() is called, then select.select() will indicate that there is an error with the socket (can't connect) and the error will be logged. The trouble is that asyncore.loop then keeps going, and will log this error again. My not-that-fast system here gets about 10,000 logged messages per second with a single socket in the asyncore map. There are ways to avoid this: (1) if the socket is blocking when connect()ing (and then nonblocking afterwards) an error is raised if the connect fails. (2) Before calling asyncore.loop(), the caller can run through all the sockets, checking that they are ok. (3) handle_expt() can be overridden with a function that repairs or removes the socket from the map (etc) However, I'm not convinced that this is good behavior for asyncore to have, by default. On Windows, select.select() will only indicate an error when trying to connect (nonblocking) or if SO_OOBINLINE is disabled, but this may not be the case (i.e. errors can occur at other times) with other platforms, right? Unless the error is temporary, asyncore will by default start streaming (extremely fast) a lot of "warning: unhandled exception" (not very helpful an error message, either) messages. Even if the error only lasts a minute, that could easily result in 10,000 warnings being logged. Do any of the python developers agree that this is a flaw? I'm happy to work up a patch for whatever the desired solution is, if so. ---------------------------------------------------------------------- >Comment By: Tony Meyer (anadelonbrin) Date: 2005-05-31 19:42 Message: Logged In: YES user_id=552329 dispatcher is not at all unusable without subclassing. You can get data with recv() and send it with send() etc. It can be treated as a thin wrapper around socket objects. Yes, you will want to subclass it to get more useful behaviour than you can get from a basic socket. I don't see that this means that you should be required to override the handle_expt() function, though. As much as possible a class should provide sensible methods, so that overriding is kept to a minimum. At the very least, this is a documentation error, since the documentation states: """ handle_expt( ) Called when there is out of band (OOB) data for a socket connection. This will almost never happen, as OOB is tenuously supported and rarely used. """ "Almost never" is completely wrong. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 19:31 Message: Logged In: YES user_id=341410 I hate to point out the obvious, but dispatcher is wholly unusable without subclassing. How would you get data to/from a connection without replacing handle_read, handle_write? How do you handle the case when you want to connect to someone else or accept connections from someone else without overloading handle_connect or handle_accept? ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2005-05-31 19:15 Message: Logged In: YES user_id=552329 Yes this problem is easily solved by subclassing. However I firmly believe that it is a terrible default behaviour, and that it's likely to hit many asyncore users. A class shouldn't have to be subclassed to be usable (ignoring virtual classes and all that), and that really is the case here. The simplest solution would be to change the handler to not log the message. Or log the message once per socket or something. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 19:03 Message: Logged In: YES user_id=341410 Option 1 is not really an option in any case where a large number of connections are opened (so I don't believe should be the default). >From what I understand, certain methods are supposed to be overridden in a subclass if someone using a class wants different behavior. In this case, I believe you can perform either option 2 or 3 in your own code to avoid the thousands of logged lines; either by creating your own loop() function, or by creating a subclass of dispatcher and implementing a handle_expt() method that does as you desire. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&group_id=5470 From noreply at sourceforge.net Tue May 31 10:07:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 01:07:08 -0700 Subject: [ python-Feature Requests-1209664 ] calling it revert is fine with me Message-ID: Feature Requests item #1209664, was opened at 2005-05-27 07:36 Message generated for change (Comment added) made by phr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1209664&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: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: calling it revert is fine with me Initial Comment: Calling it revert is fine with me. I don't want to get into an editor war thing, let's just say emacs is what I've always used; it's not a matter of any single "killer feature", it's a highly integrated system and I do everything in it (shell, news reader, email, syntax driven editing for N different languages, etc). I do use IDLE sometimes but comparing IDLE to Emacs is almost like comparing it to Eclipse. They're just light years apart. Btw re editor wars, I'm reminded of the T-shirt with a kid asking "Why are we running from the police, daddy?". The dad answers "Because we use emacs, son. They use vi". ---------------------------------------------------------------------- >Comment By: paul rubin (phr) Date: 2005-05-31 08:07 Message: Logged In: YES user_id=72053 I'm not sure what happened here. This is supposed to be a reply to kbk's question on item 1175686 which was a request for a "revert" function in IDLE. Somehow it got split off to a separate item. Yes, this should be merged with 1175686 and/or closed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-30 01:49 Message: Logged In: YES user_id=80475 Please clarify what you're requesting. Is there some IDLE feature you want added or renamed. If this was just an editor rant, please close the RFE. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1209664&group_id=5470 From noreply at sourceforge.net Tue May 31 10:23:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 01:23:39 -0700 Subject: [ python-Bugs-1205544 ] urllib has spurious print statement Message-ID: Bugs item #1205544, was opened at 2005-05-20 12:26 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205544&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: Python Library Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Stuart Wray (drcw) Assigned to: Nobody/Anonymous (nobody) Summary: urllib has spurious print statement Initial Comment: In Python 2.4.1, the procedure getproxies_environment() in urllib.py has a spurious print statement on line 1188: print proxies This was presumably used for testing, but not commented out. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 10:23 Message: Logged In: YES user_id=1188172 I can't find this line of code in urllib.py in the 2.4, 2.4.1, or 2.3.5 releases. Are you sure you didn't add it for testing? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205544&group_id=5470 From noreply at sourceforge.net Tue May 31 10:51:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 01:51:04 -0700 Subject: [ python-Bugs-1211639 ] parser tells invalid syntax with correct code Message-ID: Bugs item #1211639, was opened at 2005-05-31 00:36 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1211639&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: Duplicate Priority: 5 Submitted By: ntrunk (ntrunk) Assigned to: Nobody/Anonymous (nobody) Summary: parser tells invalid syntax with correct code Initial Comment: I work with python 2.4 on Win2000 Sp4. I wrote a simple game with 2 modules, importing one into the other. In the imported module I wrote in the first line the coding: iso-8859-15. Starting the script from the first module the parser shows 'invalid syntax'. By inserting *1* space in a comment line the script works fine! I reduced my scripts to the minimal lines, wich will reproduce the bug. (Actually the parser tells me, that the syntax error is in line 75 :-) Changing the coding to iso-8859-1 will making the bug dissapear. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-05-31 10:51 Message: Logged In: YES user_id=89016 This is related to the new codec buffering code. It's a duplicate of bug #1175396 (and various others). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1211639&group_id=5470 From noreply at sourceforge.net Tue May 31 11:24:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 02:24:19 -0700 Subject: [ python-Feature Requests-1209664 ] calling it revert is fine with me Message-ID: Feature Requests item #1209664, was opened at 2005-05-27 02:36 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1209664&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: Invalid Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: calling it revert is fine with me Initial Comment: Calling it revert is fine with me. I don't want to get into an editor war thing, let's just say emacs is what I've always used; it's not a matter of any single "killer feature", it's a highly integrated system and I do everything in it (shell, news reader, email, syntax driven editing for N different languages, etc). I do use IDLE sometimes but comparing IDLE to Emacs is almost like comparing it to Eclipse. They're just light years apart. Btw re editor wars, I'm reminded of the T-shirt with a kid asking "Why are we running from the police, daddy?". The dad answers "Because we use emacs, son. They use vi". ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-05-31 03:07 Message: Logged In: YES user_id=72053 I'm not sure what happened here. This is supposed to be a reply to kbk's question on item 1175686 which was a request for a "revert" function in IDLE. Somehow it got split off to a separate item. Yes, this should be merged with 1175686 and/or closed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-29 20:49 Message: Logged In: YES user_id=80475 Please clarify what you're requesting. Is there some IDLE feature you want added or renamed. If this was just an editor rant, please close the RFE. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1209664&group_id=5470 From noreply at sourceforge.net Tue May 31 11:31:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 02:31:56 -0700 Subject: [ python-Bugs-1210832 ] An error in Python Tutorial Message-ID: Bugs item #1210832, was opened at 2005-05-29 17:28 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210832&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: Invalid Priority: 5 Submitted By: Gene (godhand) Assigned to: Nobody/Anonymous (nobody) Summary: An error in Python Tutorial Initial Comment: In section 4.4, the program should be written as follow to get the correct result: -------------------------------------------------------------- for n in range(2, 10): for x in range(2, n): if n % x == 0: print n, 'equals', x, '*', n/x break if x == n-1: print n, 'is a prime number' -------------------------------------------------------------- besides, the line "2 is a prime number" should not appear in the result output. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 11:31 Message: Logged In: YES user_id=1188172 As for 2 being prime, Josiah is right. As for your change to the code, it is equivalent to the one in the tutorial. Besides, the sample code is there to demonstrate the else clause on for/while loops, so maybe you should look into this? Closing as Invalid. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 08:22 Message: Logged In: YES user_id=341410 The indentation on your proposed code addition was lost during your post, re-post so that it is understandable. Further, from mathworld.com: "A prime number (or prime integer, often simply called a ''prime'' for short) is a positive integer p > 1 that has no positive integer divisors other than 1 and p itself. (More concisely, a prime number p is a positive integer having exactly one positive divisor other than 1.)" That is to say, 2 is prime, so should appear in the result output, and it seems to me that the code provided in tutorial section 4.4 is correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210832&group_id=5470 From noreply at sourceforge.net Tue May 31 11:33:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 02:33:38 -0700 Subject: [ python-Bugs-1209880 ] doc bug in Lock.acquire Message-ID: Bugs item #1209880, was opened at 2005-05-27 16:04 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209880&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: Chris Perkins (cperkins) Assigned to: Nobody/Anonymous (nobody) Summary: doc bug in Lock.acquire Initial Comment: The docs for the acquire method in both the thread and threading modules are incorrect. They describe an old (insane) version that returned None when called with no argument. It appears that acquire is now sane, and always returns True or False. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 11:33 Message: Logged In: YES user_id=1188172 It certainly seems that there is a code path in Lock.acquire that can return None, as the following excerpt from Modules/threadmodule.c shows: static PyObject * lock_PyThread_acquire_lock(lockobject *self, PyObject *args) { int i = 1; if (!PyArg_ParseTuple(args, "|i:acquire", &i)) return NULL; Py_BEGIN_ALLOW_THREADS i = PyThread_acquire_lock(self->lock_lock, i); Py_END_ALLOW_THREADS if (args == NULL) { Py_INCREF(Py_None); return Py_None; } else return PyBool_FromLong((long)i); } Nevertheless, a_lock.acquire() still returns true. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209880&group_id=5470 From noreply at sourceforge.net Tue May 31 11:36:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 02:36:12 -0700 Subject: [ python-Bugs-1210832 ] An error in Python Tutorial Message-ID: Bugs item #1210832, was opened at 2005-05-29 10:28 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210832&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: Rejected Priority: 5 Submitted By: Gene (godhand) Assigned to: Nobody/Anonymous (nobody) Summary: An error in Python Tutorial Initial Comment: In section 4.4, the program should be written as follow to get the correct result: -------------------------------------------------------------- for n in range(2, 10): for x in range(2, n): if n % x == 0: print n, 'equals', x, '*', n/x break if x == n-1: print n, 'is a prime number' -------------------------------------------------------------- besides, the line "2 is a prime number" should not appear in the result output. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-31 04:36 Message: Logged In: YES user_id=80475 The code and output in the tutorial is correct. Also, it fulfills its purpose as an example of "else" and "break" statements in a for-loop. The OP's code contains an error. It produces: NameError: name 'x' is not defined ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 04:31 Message: Logged In: YES user_id=1188172 As for 2 being prime, Josiah is right. As for your change to the code, it is equivalent to the one in the tutorial. Besides, the sample code is there to demonstrate the else clause on for/while loops, so maybe you should look into this? Closing as Invalid. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 01:22 Message: Logged In: YES user_id=341410 The indentation on your proposed code addition was lost during your post, re-post so that it is understandable. Further, from mathworld.com: "A prime number (or prime integer, often simply called a ''prime'' for short) is a positive integer p > 1 that has no positive integer divisors other than 1 and p itself. (More concisely, a prime number p is a positive integer having exactly one positive divisor other than 1.)" That is to say, 2 is prime, so should appear in the result output, and it seems to me that the code provided in tutorial section 4.4 is correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210832&group_id=5470 From noreply at sourceforge.net Tue May 31 11:56:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 02:56:34 -0700 Subject: [ python-Bugs-1193180 ] Strange os.path.exists() results with invalid chars Message-ID: Bugs item #1193180, was opened at 2005-05-01 01:13 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193180&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Daniele Varrazzo (dvarrazzo) Assigned to: Nobody/Anonymous (nobody) Summary: Strange os.path.exists() results with invalid chars Initial Comment: Hi, when there are invalid chars in a filename, os.path.exists () behaves oddly, returning True. The bug appears on win32 system, not on unix ones. Thus is probably related to some weird windows api call and doesn't maybe worth fixing. Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> f = file("a_b", "w") >>> f.close() >>> os.listdir(".") ['a_b'] >>> os.path.exists("a>> os.path.exists("a>b") True And, even more strange... >>> os.path.exists("a<") True >>> os.path.exists("a>") False Better answers would have been: * False * raise ValueError ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 11:56 Message: Logged In: YES user_id=1188172 I think Python just uses the Win32 system call, so there isn't much Python can do about it. ---------------------------------------------------------------------- Comment By: engelbert gruber (grubert) Date: 2005-05-23 08:52 Message: Logged In: YES user_id=147070 testing with perl: print -e "a<"; returns True/1 too ---------------------------------------------------------------------- Comment By: Jarek Zgoda (zgoda) Date: 2005-05-02 14:04 Message: Logged In: YES user_id=92222 Same for Python 2.3.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193180&group_id=5470 From noreply at sourceforge.net Tue May 31 12:25:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 03:25:44 -0700 Subject: [ python-Bugs-1209447 ] os.path.join() fails if 2nd arg is a UNC path Message-ID: Bugs item #1209447, was opened at 2005-05-26 22:45 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209447&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.join() fails if 2nd arg is a UNC path Initial Comment: os.path.join('c:', r'\server\share') returns c:\server\share rather than \server\share. Interestingly os.path.join('c:a', r'\server\share') returns r'\server\share'. IMHO, r'\server\share' should be returned in all cases. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 12:25 Message: Logged In: YES user_id=1188172 This is a difficult issue, since as far as I recall Windows allows two or more backslashes in a row in the middle of normal paths. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209447&group_id=5470 From noreply at sourceforge.net Tue May 31 12:27:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 03:27:28 -0700 Subject: [ python-Bugs-1209411 ] divmod documentation shd reference // not / Message-ID: Bugs item #1209411, was opened at 2005-05-26 21:47 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209411&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: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: divmod documentation shd reference // not / Initial Comment: At http://docs.python.org/lib/typesnumeric.html we find: divmod(x, y) the pair (x / y, x % y) (3)(4) This should be: divmod(x, y) the pair (x // y, x % y) (3)(4) At http://docs.python.org/lib/built-in-funcs.html#built-in-funcs we find: divmod( a, b) .... For plain and long integers, the result is the same as (a / b, a % b). This should be: .... For plain and long integers, the result is the same as (a // b, a % b). Alternatively there could be a reference to "from __future__ import division" but the proposed change is cleaner and will last. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 12:27 Message: Logged In: YES user_id=1188172 Agreed. This should be changed in the documentation before it becomes wrong in Py3k ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209411&group_id=5470 From noreply at sourceforge.net Tue May 31 12:27:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 03:27:28 -0700 Subject: [ python-Bugs-1202395 ] Description of string.lstrip() needs improvement Message-ID: Bugs item #1202395, was opened at 2005-05-15 12:50 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202395&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: Roy Smith (roysmith) Assigned to: Nobody/Anonymous (nobody) Summary: Description of string.lstrip() needs improvement Initial Comment: In http://docs.python.org/lib/string-methods.html, under lstrip(), it says, "chars must be a string; the characters in the string will be stripped from the beginning of the string this method is called on". It would be clearer if it said: "chars must be a string; the characters in the string constitute a set of characters to be stripped from the beginning of the string this method is called on". Similarly for rstrip() and strip(). There was a recent posting to comp.lang.python where it appears that the poster thought the argument to lstrip() was a leading string to be removed, not a set of characters. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-31 05:27 Message: Logged In: YES user_id=80475 Okay, fixed. Thanks for the report. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-05-23 11:03 Message: Logged In: YES user_id=197677 It would also be helpful to note the definition of "whitespace" in each of the strip() methods. It appears to be defined in strip() as being identical to string.whitespace. However, I do not see a built-in whitespace for strings. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 20:18 Message: Logged In: YES user_id=593130 Over the years, several people have tripped over this and posted to c.l.p., so I think the existing text is unclear enough to arguably qualify as a buglet. In response to the same posting, I had the same thought of clarifying that the 'string' defines a set, so I support this suggestion or something similar ;-) and thank you for submitting it. ---------------------------------------------------------------------- Comment By: Roy Smith (roysmith) Date: 2005-05-15 12:55 Message: Logged In: YES user_id=390499 I notice bug #1196824 (recently submitted and closed as "not a bug") relates to the same issue. It seems more than one person has gotten confused by this :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202395&group_id=5470 From noreply at sourceforge.net Tue May 31 13:04:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 04:04:11 -0700 Subject: [ python-Bugs-1209411 ] divmod documentation shd reference // not / Message-ID: Bugs item #1209411, was opened at 2005-05-26 14:47 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209411&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: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: divmod documentation shd reference // not / Initial Comment: At http://docs.python.org/lib/typesnumeric.html we find: divmod(x, y) the pair (x / y, x % y) (3)(4) This should be: divmod(x, y) the pair (x // y, x % y) (3)(4) At http://docs.python.org/lib/built-in-funcs.html#built-in-funcs we find: divmod( a, b) .... For plain and long integers, the result is the same as (a / b, a % b). This should be: .... For plain and long integers, the result is the same as (a // b, a % b). Alternatively there could be a reference to "from __future__ import division" but the proposed change is cleaner and will last. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-31 06:04 Message: Logged In: YES user_id=80475 Fixed. Thanks for the report. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 05:27 Message: Logged In: YES user_id=1188172 Agreed. This should be changed in the documentation before it becomes wrong in Py3k ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209411&group_id=5470 From noreply at sourceforge.net Tue May 31 13:23:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 04:23:10 -0700 Subject: [ python-Bugs-691733 ] Let assign to as raise SyntaxWarning as well Message-ID: Bugs item #691733, was opened at 2003-02-23 18:08 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=691733&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler >Group: Python 2.5 Status: Open Resolution: None Priority: 2 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Let assign to as raise SyntaxWarning as well Initial Comment: according to the Python Language Reference Manual: > In some future version of Python, the identifiers > as and None will both become keywords. Hence, it seems natural to me to raise a SyntaxWarning when assigning to either of these. However, the current Python implementation doesn't: 103 >>> None="foo" <stdin>:1: SyntaxWarning: assignment to None 104 >>> as="foo" 105 >>> For consistency and cleanliness, assignment to 'as' should raise a SyntaxWarning as well. Currently, it's possible to not know it'll be a keyword and use it as a variable; people shouldn't, so a SyntaxWarning would be good. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 13:23 Message: Logged In: YES user_id=1188172 This may be too late if as becomes a keyword in the new with/do/whatever-statement... ---------------------------------------------------------------------- Comment By: Gerrit Holl (gerrit) Date: 2003-02-23 18:21 Message: Logged In: YES user_id=13298 I'm not sure whether this should be considered as a feature. I'd call it a minor wart... I'm also not sure about the category, is this 'Python interpreter core' or am I right with 'parser/compiler'? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=691733&group_id=5470 From noreply at sourceforge.net Tue May 31 13:30:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 04:30:04 -0700 Subject: [ python-Bugs-757365 ] FutureWarning: %u/%o/%x/%X of negative int will return a sig Message-ID: Bugs item #757365, was opened at 2003-06-19 18:35 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757365&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.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Duncan Grant (duncangrantuk) Assigned to: Nobody/Anonymous (nobody) Summary: FutureWarning: %u/%o/%x/%X of negative int will return a sig Initial Comment: printf style formatting: "FutureWarning: %u/%o/%x/%X of negative int will return a signed string in Python 2.4 and up" The library reference clearly states that these are UNSIGNED representations, so the Futurewarning must be spurious! Please tell me you don't really intend to break this in 2.4 !!!! In 20+ yrs of low level bit-twiddling I have never ever wanted a signed hexadecimal. The idea of a signed hex or octal is just plain stupid. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 13:30 Message: Logged In: YES user_id=1188172 Now that this has already been "broken", the bug can be closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757365&group_id=5470 From noreply at sourceforge.net Tue May 31 13:34:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 04:34:27 -0700 Subject: [ python-Bugs-750328 ] Pickle fails to restore new-style class instance in a cycle Message-ID: Bugs item #750328, was opened at 2003-06-06 23:13 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=750328&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: Type/class unification Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Phillip J. Eby (pje) Assigned to: Nobody/Anonymous (nobody) Summary: Pickle fails to restore new-style class instance in a cycle Initial Comment: Here is code to demonstrate the problem. All asserts succeed except the last, showing that pickle and cPickle both handle a "classic" cycle correctly, but only cPickle handles new-style cycles correctly. It would appear that the problem is that the pure-Python pickle isn't putting the object into its 'memo' until *after* the object's state has been pickled. Thus, the identity is not preserved on unpickling. This may be true for other object types that use __reduce__, but I have not verified this. import pickle, cPickle class X: pass x = X() x.x = x x2 = cPickle.loads(cPickle.dumps(x)) assert x2.x is x2 x2 = pickle.loads(pickle.dumps(x)) assert x2.x is x2 class Y(object): pass y = Y() y.y = y y2 = cPickle.loads(cPickle.dumps(y)) assert y2.y is y2 # this fails y2 = pickle.loads(pickle.dumps(y)) assert y2.y is y2 ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 13:34 Message: Logged In: YES user_id=1188172 Runs fine in Py2.4.1 too, so should it be considered fixed? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-01 05:00 Message: Logged In: YES user_id=80475 Another datapoint: This above script runs fine in Py2.3b2. ---------------------------------------------------------------------- Comment By: Steven Taschuk (staschuk) Date: 2003-06-08 22:23 Message: Logged In: YES user_id=666873 Compare bug 702858, which observes the same behaviour for copy.deepcopy. The common parts of pickle and copy really ought to be merged. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=750328&group_id=5470 From noreply at sourceforge.net Tue May 31 13:36:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 04:36:39 -0700 Subject: [ python-Bugs-763007 ] dl module not installed with 2.2.3 Message-ID: Bugs item #763007, was opened at 2003-06-30 07:08 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763007&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.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mike Messmore (salmo) Assigned to: Nobody/Anonymous (nobody) Summary: dl module not installed with 2.2.3 Initial Comment: I'm running Redhat 7.3 on an older PII. I was attemping to try out the python bindings for gstreamer when I discovered my build of python 2.2.3 was lacking the 'dl' module. I've installed RPMS built from the SRPMS available on the python.org site (with the non-redhat9 spec file). Looking around I have not found a reason for this, nor a way to go about fixing it, so I assume it is a bug. Whenever I try to run a gst-python example I get an ImportError stating the the dl module does not exist, as well as when I try to run test_dl.py in my /usr/lib/python2.2/test/ directory. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 13:36 Message: Logged In: YES user_id=1188172 Is this still an issue? The group is Python 2.2.3, so should it be considered out of date? ---------------------------------------------------------------------- Comment By: Mike Messmore (salmo) Date: 2003-07-01 07:31 Message: Logged In: YES user_id=121084 >From the output it seems to never try to compile dlmodule.c. I ran 'rpm --rebuild python2-2.2.3-1.src.rpm 2&>1 >python_build.txt' and grepped the resulting text for dlmodule.c and only found it placing the file in the build directory. It found dlfcn.h fine. If you need me to I can attach the python_build.txt file here, but I can't find any visable errors in the building process. By the way, feel free to let me know at any point if I'm doing something retarded. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 17:22 Message: Logged In: YES user_id=33168 What is the error when building dlmodule.c? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763007&group_id=5470 From noreply at sourceforge.net Tue May 31 13:41:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 04:41:15 -0700 Subject: [ python-Bugs-772176 ] digraphs on komment lines / xlib Message-ID: Bugs item #772176, was opened at 2003-07-16 11:24 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772176&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: Python Interpreter Core >Group: 3rd Party >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Gregory Eckersley (daddio_2) Assigned to: Nobody/Anonymous (nobody) Summary: digraphs on komment lines / xlib Initial Comment: Python 2.3 falls over if it encounters non-ascii characters on comment lines. These occur with digraphs and non English names. e.g. This simple program #!/usr/bin/python print 'This program does nothing' # Aber eine Kommentarzeile l&#65533;uft nicht! # The " &#65533; " causes trouble # This causes Xlib to stop working causes the following output sys:1: DeprecationWarning: Non-ASCII character '\xe4' in file /nglob/g/bat/digraph.py on line 6, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details This program does nothing Some libraries (such as python-xlib 2.2 ) cause this problem. The line parser ought ignore all comment content whether ascii or not. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 13:41 Message: Logged In: YES user_id=1188172 This should already have been closed. As it is related to python-xlib, marking as "3rd Party". ---------------------------------------------------------------------- Comment By: Gregory Eckersley (daddio_2) Date: 2003-07-21 02:37 Message: Logged In: YES user_id=823572 I understand & agree with your comments. I did not include the exact version since it , as you say, seems to be an undesirable (in this case) consequence of the PEP. Please consider this bug report closed, and I'll follow it up in the short term with xlib, and in the longer term with the PEP after looking at whether there is a simple and systematic way of handling this. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-07-20 22:46 Message: Logged In: YES user_id=593130 1. Python 2.3 has not been released yet. Please indicate exact versions on bug reports. Including the system and OS often helps too. 2. The reported behavior is intentional and not a bug. See Reference Manual 2. Lexical analysis: "Python uses the 7-bit ASCII character set" and the referenced PEP 0263. Please close this report. 3. If a standard library module were to generate this warning, that would be a bug that should be reported here. If a third-party library does so, get a version updated for 2.3 or request that the authors make one. 4. If you want to discuss intended behavior, post to comp.lang.python. While your request about ignoring comments is superficially reasonable, the PEP seems to indicate that encoding is dealt with, and the warning issued, *before* any actual parsing, which is to say, before the parser knows what is a comment and what is not. Detecting comments is not trivial since '#' within a string does not start a comment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772176&group_id=5470 From noreply at sourceforge.net Tue May 31 13:45:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 04:45:11 -0700 Subject: [ python-Bugs-1058786 ] r'\10' as replacement pattern loops in compilation Message-ID: Bugs item #1058786, was opened at 2004-11-02 13:39 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1058786&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: Regular Expressions >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nick Maclaren (nmm1) Assigned to: Gustavo Niemeyer (niemeyer) Summary: r'\10' as replacement pattern loops in compilation Initial Comment: The following program loops under at least Solaris 9 on SPARC and Linux (kernel 2.6) in x86. From tracebacks, it seems to be in the internal compilation of the pattern r'\10'. from re import compile line = "" pat = compile(12 * r'(\d+)') ltarget = float(pat.sub(r'\10',line)) print ltarget ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 13:45 Message: Logged In: YES user_id=1188172 Setting group to Python 2.3. If there won't be a 2.3.6 in the future, it can be closed. ---------------------------------------------------------------------- Comment By: Nick Maclaren (nmm1) Date: 2004-11-02 14:28 Message: Logged In: YES user_id=652073 I have also checked, and it is fixed. From my point of view, it isn't worth backporting, as I can upgrade and don't mind using a beta version. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-02 14:07 Message: Logged In: YES user_id=6656 It does seem to be fixed in 2.4, but not in 2.3(.3, anyway). I know some of the re changes for 2.4 are fairly large, so I don't know whether the fix is a backport candidate for 2.3.5. Gustavo might know. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-11-02 14:07 Message: Logged In: YES user_id=469548 I get the following on Python 2.4/Linux 2.6.8, so it does seem to be fixed: >>> from re import compile >>> line = "" >>> pat = compile(12 * r'(\d+)') >>> ltarget = float(pat.sub(r'\10',line)) Traceback (most recent call last): File "", line 1, in ? ValueError: empty string for float() ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2004-11-02 14:00 Message: Logged In: YES user_id=38376 If you need a workaround for 2.2, use a sub callback: http://effbot.org/zone/re-sub.htm#callbacks ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2004-11-02 13:58 Message: Logged In: YES user_id=38376 Cannot check this right now, but I'm 99% sure that this has been fixed in 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1058786&group_id=5470 From noreply at sourceforge.net Tue May 31 14:56:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 05:56:58 -0700 Subject: [ python-Bugs-1117601 ] os.path.exists returns false negatives in MAC environments. Message-ID: Bugs item #1117601, was opened at 2005-02-07 00:57 Message generated for change (Comment added) made by sbennett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117601&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: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Stephen Bennett (sbennett) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.exists returns false negatives in MAC environments. Initial Comment: In Mandatory Access Control environments (such as SELinux), it's quite possible for stat to fail with permission denied. In this case, os.path.exists will return False incorrectly. The simple(ish) fix is to check for an access denied error (which would indicate present, but not readable) when using stat to check for existence of files. ---------------------------------------------------------------------- >Comment By: Stephen Bennett (sbennett) Date: 2005-05-31 12:56 Message: Logged In: YES user_id=817465 In the case of /etc/shadow/abc123, the stat will fail with "Not a directory". However, attempting to stat /root/abc123 as a limited account will return permission denied unless you have the search permission to the parent directory. However, this is an issue with regular Unix permissions too -- try to stat() a file that's inside a directory with 000 permissions. One possible way around this is to attempt to get a listing of the parent dir if the stat fails with permission denied -- if it succeeds then the file exists but can't be statted; if it fails then (at least for the purposes of the library functions) if doesn't. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 07:09 Message: Logged In: YES user_id=341410 I believe Terry was curious about something like os.path.exists("/etc/shadow/abc123") vs `ls -l /etc/shadow/abc123`. If not, I know I am curious, and I believe it may help with a corner case. ---------------------------------------------------------------------- Comment By: Stephen Bennett (sbennett) Date: 2005-02-16 22:46 Message: Logged In: YES user_id=817465 As far as I know (at least for SELinux), permission denied on stat() always means that the file exists, but getattr isn't allowed. As for a reproducible test case, probably the simplest example is a vanilla Fedora Core 3 system with SELinux enabled and strict policy. From a regular user account, call os.path.exists("/etc/shadow"). It will return False even though the file exists. For comparison, an `ls -l /etc/shadow` from the command line will simply print 'Permission Denied'. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 20:26 Message: Logged In: YES user_id=593130 Does 'access denied' always mean 'present but not readable' in every environment that gives such messages? I ask because I have vague memories of wasting time trying to get access to something that did not exist, because access denied (or something like that) meant that I was denied access even to info about whether it existed or not. In any case, a reproducible example would help someone to verify, fix, and write a test case for this if it is deemed to be a fixable bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117601&group_id=5470 From noreply at sourceforge.net Tue May 31 15:11:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 06:11:38 -0700 Subject: [ python-Bugs-834351 ] Mouse wheel crashes program Message-ID: Bugs item #834351, was opened at 2003-11-02 01:37 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834351&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: Tkinter >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gary Richardson (garyrxx) Assigned to: Martin v. L?wis (loewis) Summary: Mouse wheel crashes program Initial Comment: The following program (by Michael Peuser) crashes as soon as the mouse wheel is moved. See my post to c.l.p. on Oct 29. Gary Richardson #------------------------- from Tkinter import * def _onMouseWheel(event): print event root = Tk() root.bind('<MouseWheel>',_onMouseWheel) root.mainloop() ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 15:11 Message: Logged In: YES user_id=1188172 Bumping, as it is still the same with 2.4 on my box. ---------------------------------------------------------------------- Comment By: nikolaus heger (orthorim) Date: 2005-05-12 16:41 Message: Logged In: YES user_id=933256 sdati, thanks for this workaround. it's awesome. i am now happily mouse-wheeling :) I did make a small improvement to it so it works for all MouseWheel type events. Instead of if sequence == "": i say if type(sequence) == str and sequence.__contains__("MouseWheel"): This way, all permutations of mouse events are covered, e.g. "" ---------------------------------------------------------------------- Comment By: Steve Davis (sdati) Date: 2005-02-08 03:40 Message: Logged In: YES user_id=1214285 I have determined the root cause of this problem. It actually does lie in Tk, but is only revealed by Python Tkinter because of the way Python deals with events. >From Tk source -- tkWinX.c: case WM_MOUSEWHEEL: ... event.xany.send_event = -1 ... This line causes Tk to call TkpGetString() when ExpandPercents() is called with '%A' (which is done by Python for ALL events, including ). This, in turn, causes segmentation fault because event.xkey.trans_chars and event.xkey.nbytes are not initialized. So, the workaround from the Python side is pretty ugly, but I have tested it and verified that it works. There is probably a better way, but this was the obvious solution to me, since I have never needed to look at the Tkinter interface before: In Tkinter.py, define a new _subst_format and _subst_format_str: _subst_format_workaround = ('%#', '%b', '%f', '%h', '%k', '%s', '%t', '%w', '%x', '%y', '%D', '%E', '%K', '%N', '%W', '%T', '%X', '%Y', '%D') _subst_format_str_workaround = " ".join(_subst_format_workaround) Note that '%A' entry in _subst_format is replaced with '%D' entry in _subst_format_workaround. Now, in Misc._bind(), if sequence == "": cmd = ('%sif {"[%s %s]" == "break"} break\n' % (add and '+' or '', funcid, self._subst_format_str_workaround)) else: cmd = ('%sif {"[%s %s]" == "break"} break\n' % (add and '+' or '', funcid, self._subst_format_str)) I am submitting this bug to Tcl/Tk maintainers to request that they fix (Project: Tk Toolkit Request ID 1118340), but in the meantime (and for all older versions of Tk), it seems like a workaround in the Tkinter code might be appropriate. ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2005-01-04 16:40 Message: Logged In: YES user_id=2138 I wasn't able to reproduce this in pure Tcl/Tk (under Wish). No surprise there. In wish, I used this: toplevel .top bind .top {puts 'foo'} And mouse wheeling in the Toplevel widget made a bunch of 'foo's appear in the wish console without crashing. HTH. ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2005-01-04 16:02 Message: Logged In: YES user_id=2138 Me too. Python 2.3.4 with Tcl/Tk 8.4.9. Crash on Scroll Wheeling in WinXP SP 1. (users report it happening in SP 2 also). I'll try to make this happen in pure Tcl/Tk rather than Tkinter too. ---------------------------------------------------------------------- Comment By: John Fouhy (johnfouhy) Date: 2004-10-26 06:13 Message: Logged In: YES user_id=1084032 I can reproduce this bug. I am running Python 2.3.4 on WinXP SP2. tk84.dll is version 8.4.3; tcl84.dll is also 8.4.3. The mousewheel works correctly with a Tkinter.Text object with no additional bindings. ---------------------------------------------------------------------- Comment By: Jon Ashley (ash101) Date: 2003-12-04 18:02 Message: Logged In: YES user_id=923903 Happens for me too, on Win2K with python 2.3.2. The fault is in TCL84.DLL at an offset of 1002a58c, if that means anything to anyone. ---------------------------------------------------------------------- Comment By: Gary Richardson (garyrxx) Date: 2003-11-03 03:42 Message: Logged In: YES user_id=899035 I'm using Win98SE. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-02 19:37 Message: Logged In: YES user_id=21627 What operating system are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834351&group_id=5470 From noreply at sourceforge.net Tue May 31 17:34:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 08:34:26 -0700 Subject: [ python-Bugs-1212077 ] itertools.groupby ungraceful, un-Pythonic Message-ID: Bugs item #1212077, was opened at 2005-05-31 10:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212077&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: itertools.groupby ungraceful, un-Pythonic Initial Comment: The sharing of the result iterator by itertools.groupby leads to strange, arguably un-Pythonic behavior. For example, suppose we have a list of pairs that we're about to turn into a dict and we want to check first for duplicate keys. We might do something like this >>> [ (k,list(v)) for (k, v) in groupby([(1,2), (1,3), (2,3), (3,5)], lambda x: x[0]) ] [(1, [(1, 2), (1, 3)]), (2, [(2, 3)]), (3, [(3, 5)])] >>> [ (k,list(v)) for (k, v) in list(groupby([(1,2), (1,3), (2,3), (3,5)], lambda x: x[0])) ] [(1, []), (2, []), (3, [(3, 5)])] >>> [ (k,list(v)) for (k, v) in groupby([(1,2), (1,3), (2,3), (3,5)], lambda x: x[0]) if len(list(v)) > 1 ] [(1, [])] The first result looks good, but the second two silently produce what appear to be bizarre results. The second is understandable (sort of) if you know that the result iterator is shared, and the third I don't get at all. This silent failure seems very Perlish. At a minimum, if use is made of the "expired" result iterator, an exception should be thrown. This is a wonderfully useful function and ideally, there should be a version of groupby that behaves as a naive user would expect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212077&group_id=5470 From noreply at sourceforge.net Tue May 31 17:54:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 08:54:41 -0700 Subject: [ python-Feature Requests-1212091 ] sets needs an 'arbitrary element' method Message-ID: Feature Requests item #1212091, was opened at 2005-05-31 10:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212091&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: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: sets needs an 'arbitrary element' method Initial Comment: It would be nice to have an "arbitrary element" method that would return some arbitrary element of a non-empty set (throwing an exception if the set is empty). Something like this >>> s = sets.Set([1,2,3]) >>> print s.element() 2 AFAIK, the current alternative would be to do something like this >>> print list(s)[0] which is somewhat expensive and unreadable. It'd be fine if the operator returned the same or a different element each time. Perhaps it'd be useful if it returned the same element each time for frozen sets. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212091&group_id=5470 From noreply at sourceforge.net Tue May 31 17:59:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 08:59:56 -0700 Subject: [ python-Feature Requests-1212091 ] sets needs an 'arbitrary element' method Message-ID: Feature Requests item #1212091, was opened at 2005-05-31 17:54 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212091&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: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: sets needs an 'arbitrary element' method Initial Comment: It would be nice to have an "arbitrary element" method that would return some arbitrary element of a non-empty set (throwing an exception if the set is empty). Something like this >>> s = sets.Set([1,2,3]) >>> print s.element() 2 AFAIK, the current alternative would be to do something like this >>> print list(s)[0] which is somewhat expensive and unreadable. It'd be fine if the operator returned the same or a different element each time. Perhaps it'd be useful if it returned the same element each time for frozen sets. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 17:59 Message: Logged In: YES user_id=1188172 For mutable sets, I think that pop() is better suited. Do you have a use case of your proposal with frozensets? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212091&group_id=5470 From noreply at sourceforge.net Tue May 31 18:16:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 09:16:13 -0700 Subject: [ python-Bugs-1212077 ] itertools.groupby ungraceful, un-Pythonic Message-ID: Bugs item #1212077, was opened at 2005-05-31 10:34 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212077&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: Python Library Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: itertools.groupby ungraceful, un-Pythonic Initial Comment: The sharing of the result iterator by itertools.groupby leads to strange, arguably un-Pythonic behavior. For example, suppose we have a list of pairs that we're about to turn into a dict and we want to check first for duplicate keys. We might do something like this >>> [ (k,list(v)) for (k, v) in groupby([(1,2), (1,3), (2,3), (3,5)], lambda x: x[0]) ] [(1, [(1, 2), (1, 3)]), (2, [(2, 3)]), (3, [(3, 5)])] >>> [ (k,list(v)) for (k, v) in list(groupby([(1,2), (1,3), (2,3), (3,5)], lambda x: x[0])) ] [(1, []), (2, []), (3, [(3, 5)])] >>> [ (k,list(v)) for (k, v) in groupby([(1,2), (1,3), (2,3), (3,5)], lambda x: x[0]) if len(list(v)) > 1 ] [(1, [])] The first result looks good, but the second two silently produce what appear to be bizarre results. The second is understandable (sort of) if you know that the result iterator is shared, and the third I don't get at all. This silent failure seems very Perlish. At a minimum, if use is made of the "expired" result iterator, an exception should be thrown. This is a wonderfully useful function and ideally, there should be a version of groupby that behaves as a naive user would expect. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-31 11:16 Message: Logged In: YES user_id=80475 Sorry, this is more of a rant than a bug report. The tool is functioning as designed and documented. The various design options were discussed on python-dev and this was what was settled on as the most useful, general purpose tool (eminently practical, but not idiotproof). Like other itertools, it can be used in a straight-forward manner or be used to write cryptic, mysterious code. In general, if you can't follow your own code (in situatations such as the above), a good first step is to unroll the list comprehension into a regular for-loop as that tends to make the assumptions and control flow more visible. Also, it can be taken as a hint that the itertool is not being used as intended. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212077&group_id=5470 From noreply at sourceforge.net Tue May 31 18:54:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 09:54:19 -0700 Subject: [ python-Feature Requests-1212091 ] sets needs an 'arbitrary element' method Message-ID: Feature Requests item #1212091, was opened at 2005-05-31 10:54 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212091&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: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: sets needs an 'arbitrary element' method Initial Comment: It would be nice to have an "arbitrary element" method that would return some arbitrary element of a non-empty set (throwing an exception if the set is empty). Something like this >>> s = sets.Set([1,2,3]) >>> print s.element() 2 AFAIK, the current alternative would be to do something like this >>> print list(s)[0] which is somewhat expensive and unreadable. It'd be fine if the operator returned the same or a different element each time. Perhaps it'd be useful if it returned the same element each time for frozen sets. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-31 11:54 Message: Logged In: YES user_id=80475 I had looked at putting in a choose() method but there were a shortage of use cases that were not better served by pop() or by iteration. Will leave this open as the request may yet prove its worth. To do so, I would need to see examples of practical code where choose() is a better choice than existing alternatives. For the record, here were some of the lines of thinking about choose(). * Given that any element could be returned, it was logical to return the first encountered. That led to the odd situation where the method would return the same value on every call (unless followed by a set mutation) making the method useless in a loop. * If needed, an efficient alternative is available: iter(s).next(). And here is a more readable, encapsulated version that a programmer could dash off in seconds: def choose(s, default=None): for elem in s: return elem return default * I had looked at a few textbook algorithms that were expressed in terms of choose(). Without exception, their Python code was better expressed using pop(), In a couple of cases, the pop() needed to be followed by an add() if the item was to be left in the set. Those two cases all had other set mutations occuring on each iteration (otherwise, the pop/add pair would always get the same element). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 10:59 Message: Logged In: YES user_id=1188172 For mutable sets, I think that pop() is better suited. Do you have a use case of your proposal with frozensets? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212091&group_id=5470 From noreply at sourceforge.net Tue May 31 19:59:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 10:59:13 -0700 Subject: [ python-Feature Requests-1212169 ] Prepending Text Message-ID: Feature Requests item #1212169, was opened at 2005-05-31 11:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212169&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: Aaron Elbaz (flamesrock) Assigned to: Nobody/Anonymous (nobody) Summary: Prepending Text Initial Comment: Perhaps this has already been considered, but I have an idea that would make neat addition to python: Appending a string to another string can be done with += or .join(), but currently, there is no elegant way to prepend to a string. How about something like- string.prepend(list.pop(0) ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212169&group_id=5470 From noreply at sourceforge.net Tue May 31 20:48:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 11:48:01 -0700 Subject: [ python-Feature Requests-1212169 ] Prepending Text Message-ID: Feature Requests item #1212169, was opened at 2005-05-31 19:59 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212169&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: Aaron Elbaz (flamesrock) Assigned to: Nobody/Anonymous (nobody) Summary: Prepending Text Initial Comment: Perhaps this has already been considered, but I have an idea that would make neat addition to python: Appending a string to another string can be done with += or .join(), but currently, there is no elegant way to prepend to a string. How about something like- string.prepend(list.pop(0) ? ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 20:48 Message: Logged In: YES user_id=1188172 -0. What's wrong with >>> string = something + string Also, the above conveys the notion that this is an expensive operation (when done multiple times, e.g. in a loop) better than a str method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212169&group_id=5470 From noreply at sourceforge.net Tue May 31 20:56:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 11:56:01 -0700 Subject: [ python-Bugs-1212195 ] str.lower() to have an IMPORTANT NOTE or it's for magicians Message-ID: Bugs item #1212195, was opened at 2005-05-31 21:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212195&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: Nikos Kouremenos (nkour) Assigned to: Nobody/Anonymous (nobody) Summary: str.lower() to have an IMPORTANT NOTE or it's for magicians Initial Comment: lower() {maybe others} should mention that if used with string object [not unicode object] it's likely the that encoding will change unde some locales [eg pl_PL makes it from utf8 to latin2]!! or this hsould be put in the beginning of the doc in str as a general WARNING/NOTE: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212195&group_id=5470 From noreply at sourceforge.net Tue May 31 21:32:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 12:32:00 -0700 Subject: [ python-Bugs-1212223 ] anydbm and 'n' flag Message-ID: Bugs item #1212223, was opened at 2005-05-31 12:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212223&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: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Moffitt (jackiem) Assigned to: Nobody/Anonymous (nobody) Summary: anydbm and 'n' flag Initial Comment: When a 0 length file exists and anydbm is asked to create a new database with that file name via the anydbm.open(fn, 'n') call, the call fails as whichdb detection fails. whichdb should not be invoked with the 'n' flag, since the purpose of this flag is to always create a database, not only if it is missing. This bug prevents creating a secure temporary file with mkstemp and then uisng that file to open a database. The workaround is to unlink the file then call open, but this is leaving a small hole. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212223&group_id=5470 From noreply at sourceforge.net Tue May 31 21:34:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 12:34:00 -0700 Subject: [ python-Bugs-1161031 ] Neverending warnings from asyncore Message-ID: Bugs item #1161031, was opened at 2005-03-10 16:34 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: Neverending warnings from asyncore Initial Comment: Changes in asyncore from 2.3 to 2.4 mean that asyncore.poll() now passes all the sockets in the map to select.select() to be checked for errors, which is probably a good thing. If an error occurs, then handle_expt() is called, which by default logs the error. asyncore.dispatcher creates nonblocking sockets. When connect_ex() is called on a nonblocking socket, it will probably return EWOULDBLOCK (connecting takes time), which may mean the connection is successful, or may not (asyncore dispatcher keeps going assuming all is well). If the connection is not successful, and then asyncore.loop() is called, then select.select() will indicate that there is an error with the socket (can't connect) and the error will be logged. The trouble is that asyncore.loop then keeps going, and will log this error again. My not-that-fast system here gets about 10,000 logged messages per second with a single socket in the asyncore map. There are ways to avoid this: (1) if the socket is blocking when connect()ing (and then nonblocking afterwards) an error is raised if the connect fails. (2) Before calling asyncore.loop(), the caller can run through all the sockets, checking that they are ok. (3) handle_expt() can be overridden with a function that repairs or removes the socket from the map (etc) However, I'm not convinced that this is good behavior for asyncore to have, by default. On Windows, select.select() will only indicate an error when trying to connect (nonblocking) or if SO_OOBINLINE is disabled, but this may not be the case (i.e. errors can occur at other times) with other platforms, right? Unless the error is temporary, asyncore will by default start streaming (extremely fast) a lot of "warning: unhandled exception" (not very helpful an error message, either) messages. Even if the error only lasts a minute, that could easily result in 10,000 warnings being logged. Do any of the python developers agree that this is a flaw? I'm happy to work up a patch for whatever the desired solution is, if so. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 12:34 Message: Logged In: YES user_id=341410 You seem to be unwilling to subclass asyncore.dispatcher to extend its functionality, and the only reason you have given as to why you are unwilling is "As much as possible a class should provide sensible methods, so that overriding is kept to a minimum." (I personally subclass dispatcher and its async_chat derivative qutie often) Now, in the case of the other standard socket server and client framework in the Python standard library, namely the SocketServer module and its derivatives, you will find extending the functionality of those classes is via subclassing and overriding methods as necessary. To me, when two 'competing' methods of generating socket servers and clients in the standard library offer the same method of extension of their base functionality, then perhaps that is what should be done. The fact that basically all of the standard library is subclassable (some C modules are exceptions to the rule, but should be fixed in Python 2.5), including types in the base language, further suggests to me that subclassing is the standard mechanism for extending the functionality of a class, regardless of its usefulness in its base state. In regards to the documentation, it seems to be that whenever an object has an error, the handle_expt() method is called (in spending two minutes reading the source). Whether or not those errors are rare, perhaps debatable (I've not seen any in years), but it seems to be application-specific as to what behavior the socket should have in the case of an error (you may want to close, I may want to report the error and reconnect, etc.). ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2005-05-31 00:42 Message: Logged In: YES user_id=552329 dispatcher is not at all unusable without subclassing. You can get data with recv() and send it with send() etc. It can be treated as a thin wrapper around socket objects. Yes, you will want to subclass it to get more useful behaviour than you can get from a basic socket. I don't see that this means that you should be required to override the handle_expt() function, though. As much as possible a class should provide sensible methods, so that overriding is kept to a minimum. At the very least, this is a documentation error, since the documentation states: """ handle_expt( ) Called when there is out of band (OOB) data for a socket connection. This will almost never happen, as OOB is tenuously supported and rarely used. """ "Almost never" is completely wrong. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 00:31 Message: Logged In: YES user_id=341410 I hate to point out the obvious, but dispatcher is wholly unusable without subclassing. How would you get data to/from a connection without replacing handle_read, handle_write? How do you handle the case when you want to connect to someone else or accept connections from someone else without overloading handle_connect or handle_accept? ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2005-05-31 00:15 Message: Logged In: YES user_id=552329 Yes this problem is easily solved by subclassing. However I firmly believe that it is a terrible default behaviour, and that it's likely to hit many asyncore users. A class shouldn't have to be subclassed to be usable (ignoring virtual classes and all that), and that really is the case here. The simplest solution would be to change the handler to not log the message. Or log the message once per socket or something. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 00:03 Message: Logged In: YES user_id=341410 Option 1 is not really an option in any case where a large number of connections are opened (so I don't believe should be the default). >From what I understand, certain methods are supposed to be overridden in a subclass if someone using a class wants different behavior. In this case, I believe you can perform either option 2 or 3 in your own code to avoid the thousands of logged lines; either by creating your own loop() function, or by creating a subclass of dispatcher and implementing a handle_expt() method that does as you desire. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&group_id=5470 From noreply at sourceforge.net Tue May 31 23:42:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 14:42:05 -0700 Subject: [ python-Bugs-860515 ] fileinput does not use universal input Message-ID: Bugs item #860515, was opened at 2003-12-15 20:11 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860515&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: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Nobody/Anonymous (nobody) Summary: fileinput does not use universal input Initial Comment: In Python 2.3.0 the fileinput module does not appear to use universal line ending mode for reading files. I found this using MacPython 2.3 (via the binary installer) but looking at the module it appears to be vanilla code. I confess I didn't see where the files were opened, so I cannot suggest a fix. Sample code: import fileinput for line in fileinput.input(): print line[0:20] try this with text files that have some other platform's line endings. For me, it works on MacOS X for files with unix line endings, but fails if the file(s) have Mac line endings. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 23:42 Message: Logged In: YES user_id=1188172 See patch #1212287. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860515&group_id=5470